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.

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.

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.

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.

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.

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:

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