GCW Zero (http://www.gcw-zero.com/ (http://www.gcw-zero.com/)) is a little, yet powerfull handheld device.
CPU: Ingenic JZ4770 1 GHz MIPS processor
GPU: Vivante GC860, capable of OpenGL ES 2.0
Display:3.5 inch LCD with 320x240 pixels; 4:3 aspect ratio is ideal for retro gaming
Operating system: Linux 3.x (OpenDingux)
Memory: 512 MB DDR2
Internal storage: 16 GB, most of which is available for applications and data
External storage: micro SDHC up to 32 GB or micro SDXC of 64 GB (SDXC cards must be reformatted before use)
(http://allgamers.fr/archive3/gcw-zero-1.jpg)
Currently, a dev named Shin-Nil is working on a port of Solarus engine to the Zero.
He already ported the Zelda Trilogy (ROTH, OLB and 3T) as you can see in that post :
http://boards.dingoonity.org/gcw-releases/zelda-trilogy-(roth-olb-and-3t)/ (http://boards.dingoonity.org/gcw-releases/zelda-trilogy-(roth-olb-and-3t)/)
I think that it's a nice addition for the handhelds, and even more with the upcoming Solarus 1.1
Keep up the good work Christopho !
Greetings from France !
Hi,
Such a port would be so great :)
Solarus is already working on OpenPandora, and I think it should not be hard to port it to GCW Zero. We use libraries similar to the ones of Zelda ROTH/OLB/3T, but also OpenAL.
For libmodplug, make sure you use at least version 0.8.8.4. It might be hard to find so I have a fork here: https://github.com/christopho/libmodplug
In the next release (Solarus 1.1, ZSDX 1.7, ZSXD 1.7), I improved performance and portability. You can use the git versions (branch master) of them before the official release.
- Performance: I only use .it musics instead of .spc musics that were so slow to decode. (That's because I finally figured out how to convert them without quality loss.)
- Portability: you can set up a quest size larger than 320x240 if you want to occupy the whole screen without stretching the image or adding black borders. Actually, you can already do that with Solarus 1.0 but it is fixed at compilation time.
Don't hesitate to report any problems, like performance issues or problems when playing with a larger visible area like 400x240. I would love to help.
PS: where are you from in France?
Hi, I'm not the port author (it's Shin-Nil, who is spanish or brazilian, not sure) : http://shinnil.blogspot.fr/ (http://shinnil.blogspot.fr/)
He already ported some nice projects to the zero and to the dingoo a320 (I currently only own the last and I'm waiting for the zero)
I'm quite impressed since he managed to port the Zelda Trilogy (ROTH, OLB and 3T) without owning the gcw zero !
Since then, he got his device. The zero has a native resolution of 320x240 so it should be able to handle solarus engine quite well.
Currently, I think there's no support for openAL but Shin-Nil reported that he got the engine in a working state.
I'm from Lens, what about you Christopho ?
I'm from Nancy ;)
Hello again fosamax, nice to meet you Christopho!
I almost did not need to make changes to have a Solarus working version on GCW-Zero, I just needed to compile some additional libraries, openal, for example.
I still did not release a public version because I'm trying to improve performance, it's playable but not at full speed. I replaced the use of std::list to std::vector for sprites allocation, but I did'nt feel much of improvement.
Thank you for sharing this great piece of software ;)
Profiling says that most of the time is spent emulating .spc musics and blitting SDL surfaces. The spc musics are not used anymore in our games as of Solarus 1.1, and we will switch to SDL 2 in Solarus 1.2.
Do you use Solarus 1.0 / ZSDX 1.6 or the git version: Solarus 1.1 / ZSDX 1.7?
You should have a great improvement with Solarus 1.1 / ZSDX 1.7 because .it musics are used instead of .spc ones.
I'm using the git version for both Solarus and ZSDX, so it's using .it musics. I still unable to profiling on the real device, so I do not know for sure where the bottleneck is.
I will recompile the libraries and the engine using a new version of the GCW toolchain, perhaps we can get a small performance improvement.
Ok good.
I am working on the OpenPandora port and I have a few performance issues too, and not only because of SDL. So I will continue to improve this.
Thank you Christopho, good to know that.
Can you update to the latest git version and tell me if performance has improved since yesterday?
I made some profiling (on my computer) and realized that this Solarus 1.1 change (http://www.solarus-games.org/2013/08/07/ice-low-walls-and-other-improvements-about-grounds/) (detecting correctly the terrain in all cases) introduces a serious bottleneck. So I just made some optimizations and now, I except the speed to be about twice faster.
I could do better with quadtrees, but I think that will be enough for 1.1. It should be much more playable now.
Thanks Christopho!
See the results by yourself :P
http://youtu.be/OVBKgBP_BOM
Looks really good ! :)
Thanks Shin-Nil for the port and Christopho for writing such a good engine and making it open source !
Hello again Christopho :)
I'm trying to remap the keyboard key names according to GCW-Zero, so I've modified the lowlevel/InputEvent.cpp using something like this:
...
#ifdef GCWZERO
keyboard_key_names[InputEvent::KEY_UP] = "up";
keyboard_key_names[InputEvent::KEY_DOWN] = "down";
keyboard_key_names[InputEvent::KEY_RIGHT] = "right";
keyboard_key_names[InputEvent::KEY_LEFT] = "left";
keyboard_key_names[InputEvent::KEY_BACKSPACE] = "R";
keyboard_key_names[InputEvent::KEY_TABULATION] = "L";
keyboard_key_names[InputEvent::KEY_RETURN] = "start";
keyboard_key_names[InputEvent::KEY_ESCAPE] = "select";
keyboard_key_names[InputEvent::KEY_SPACE] = "Y";
keyboard_key_names[InputEvent::KEY_LEFT_SHIFT] = "X";
keyboard_key_names[InputEvent::KEY_LEFT_CONTROL] = "A";
keyboard_key_names[InputEvent::KEY_LEFT_ALT] = "B";
keyboard_key_names[InputEvent::KEY_PAUSE] = "power down";
#else
...
Doing this the controls doesn't work anymore, I've even edited manually the save.dat file to match the new names with no luck. Am I missing something?
Thanks!
Hi,
This lowlevel/InputEvent.cpp code essentially encapsulates SDL, by giving names to the keyboard keys enum values defined in SDL. So you shoud not change it.
And savegame files indeed store the names of these keys. Changing them breaks existing savegames, breaks compatibility between savegames on different systems, and more importantly, breaks Lua scripts of quests.
The change you made in Savegame.cpp is okay: you set default commands that are relevant for GCW-Zero. But I guess your problem is that the options menus shows the real key names, like "tabulation" for the L button and "backspace" for the R button. I suggest to keep it that way, because these are really the keystokes sent by the device.
We have the same situation on Pandora. I think this is okay to show the real underlying key to the player.
Hello Christopho, long time no see you ;)
Well, I'm building solarus 1.2 for GCW-Zero, as the latest toolchain (2014-05-05) included LuaJIT and experimental SDL2.
The building process ocurred just fine, but I noticed a strange behavior, the screen is being displayed at 640x480 using "normal" video mode, and my maximum resolution is 320x240, so it only displays 1/4 of the screen.
To successfully test the application, I had to force a lower resolution video mode on Video.cpp:
// Initialize hardcoded video modes.
const Rectangle quest_size_1(0, 0, quest_size.get_width(), quest_size.get_height());
const Rectangle quest_size_2(0, 0, quest_size.get_width() * 2, quest_size.get_height() * 2);
const Rectangle quest_size_3(0, 0, quest_size.get_width() * 3, quest_size.get_height() * 3);
const Rectangle quest_size_4(0, 0, quest_size.get_width() * 4, quest_size.get_height() * 4);
all_video_modes.push_back(new VideoMode("320x240", quest_size_1, NULL, NULL));
all_video_modes.push_back(new VideoMode("normal", quest_size_2, NULL, NULL));
all_video_modes.push_back(new VideoMode("scale2x", quest_size_2, new Scale2xFilter(), NULL));
all_video_modes.push_back(new VideoMode("hq2x", quest_size_2, new Hq2xFilter(), NULL));
all_video_modes.push_back(new VideoMode("hq3x", quest_size_3, new Hq3xFilter(), NULL));
all_video_modes.push_back(new VideoMode("hq4x", quest_size_4, new Hq4xFilter(), NULL));
default_video_mode = all_video_modes[0];
As a newbie in SDL2, I wonder what would be the expected behavior, should the screen be automatically resized to my resolution (320x240)? Perhaps the experimental SDL2 provided by GCW-zero team is not yet complete...
Hi,
Wow that was fast :)
Which exact version of SDL2 is used? SDL 2.0.0 is known to be buggy, and SDL 2.0.1 works fine on PCs.
Are you in fullscreen when you have the bug?
By default, in windowed mode, the "normal" video mode uses a window size of 640x320 indeed. But this should not impact fullscreen.
Can you try this patch: https://github.com/christopho/solarus/commit/5ffb8333634a4623b35c240bfa116ca79eee1109
This is a commit that vlag did to fix a bug similar to what you describe. (I reverted it for now though because it introduced other problems.).
Thanks for the fast reply, Christopho ;D
It's SDL 2.0.3. I've just used windowed mode, which is the default. I'll give a new try using fullscreen as soon as I get my device in hands tonight.
Thanks for the tips!
EDIT: it worked on fullscreen ;)
Hi Christopho!
I'm testing a pre-release of the new GCW-Zero firmware that seems to be working well with SDL2 :)
My question is, what's the best way to fix/force fullscreen mode for that device?
Hi,
This is good news!
I just opened an issue to force fullscreen mode at compilation time, because this is not currently possible:
https://github.com/christopho/solarus/issues/560
Thanks!
I don't know if due SDL2, LuaJIT or both, but now Solarus is running smoother than ever before.
Shin-NIL: is everything working? Did you make the updated package? I would like to upload it to the website. Thanks
Yep, it's working fine forcing fullscreen mode.
I'm still waiting for the new GCW-Zero firmware public release though.
Hello again Christopho!
Good news, the new GCW-Zero firmware with proper SDL2 support was released :D
I've compiled solarus 1.3, but I'm still with the fullscreen problem, any tips or workaround I can use?
Thanks!
Not yet. You can do the change you suggested in a previous post in Video.cpp for now.
The guys from dingoonity have been testing the 1.3 build last days, so I think it's ok.
Here's the binaries:
http://www.mediafire.com/download/z2mx9xum67nnnse/solarus.opk (Solarus OPK)
http://www.mediafire.com/download/0v2ksxfj035uapj/data.solarus.zip (ZSDX)
http://www.mediafire.com/download/mpzwh42a3yt9o4p/data.solarus.zip (ZSXD)
Thanks! Great work! I will update the download page.
Question about future releases: can you compile with C++11 on GCW-Zero? (and other devices?)
Because we are working in a separate branch with C++11, improving the quality of the code. I am not sure yet of when I can merge this work into master, it essentially depends on how C++11-compilant compilers are.
I'm not sure, but I think it supports C++11 as the latest toolchain is using gcc 4.9.1.
Thanks again ;D
Sorry for posting in an old thread but i thought it was better than starting a new post.
Shin-Nil hasn't breen active on solarus or dingoonity forums for quite a while now so I was asking myself if you could help me with updating solarus engine on the GCW Zero.
I have zero experience in compiling (without speaking about cross compiling) but have access to a pc dual booting Win7/linux mint.
It should also be noted that lately a GCW simulator was built so you can run native applications for the GCW Zero via QEMU on a computer.
http://www.gcw-zero.com/news.php?id=13 (http://www.gcw-zero.com/news.php?id=13)
We'd like to announce a new column, written by Dmitry Smagin: "Running GCW Zero applications with QEMU". Now you can try OpenDingux on your computer!
Unfortunately, I doesn't support SDL2 ATM.
I also made little changes to the ZSDX to better reflect GCW zero layout but it needs a little polishing.
Thanks for any help.