GCW Zero (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)



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)/

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 !

[Christopho]

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/

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 ?

[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

[Christopho]

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.

[Christopho]

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.

[Christopho]

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 (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 

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:

Code: [Select]

...
#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!

[Christopho]

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:

Code: [Select]

  // 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...