Messages

Hi,
Welcome on the forum

The dialog box system has indeed completely changed between 1.0 and 1.1.

In Solarus 1.0, the dialog box is built-in in the engine. You call start_dialog() from Lua and that's it.

In Solarus 1.1, the dialog box *can* be scripted in Lua. There are two options:
- If you define game:on_dialog_started(), then your dialog box is in pure Lua. The engine does strictly nothing except suspending the game until you call game:stop_dialog().
- If you *don't* define game:on_dialog_started(), then there is a built-in, very minimal dialog box in the engine. Just text displayed immediately, without any frame, without a cursor for a question, etc. That's your case. But what you are saying is strange because you can normally close the dialog box by pressing the action key.

I don't know PhotoFiltre, but with GIMP I can explain.
Click the Layer menu > Transparency > Add an alpha channel. Select the pixels to make transparent and delete them.
Then, if you still have problems, try to convert your image to a 256 color palette (Image menu > Mode > RGB) because Solarus might have bugs with transparent pixels in RGB images.

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.

Your problem might be fixed by https://github.com/christopho/solarus/commit/add115937e122624be97e8df872b23ae02f5a992.
Pixel-precise collisions are supposed to work for any image, 256 colors or RGB, with or without transparent pixels. But I did not test the RGB case myself yet (I'm not the one who implemented the feature).

Note that transparency exists in RGB PNG images, so maybe you are not in 256 color mode.

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.

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.

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 from Nancy

Fixed in Solarus 1.1!
Thanks

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?

I can't see your images here at work because xooimage seems to be blocked.
Anyway, if you only modify PNG files, keeping the same dimensions of your sprites, this cannot affect the collisions.

Unless... the following three conditions are all met:
- You converted the image from 256 colors to RGB.
- The sprite uses pixel-precise collisions (yes, this is the case of crystals and bushes).
- You are using Solarus < 1.0.1. Before Solarus 1.0.1, pixel-precise collisions were only supported with images in 256 colors. This limitation no longer exists.

So make sure you have the latest release (1.0.4). If this is the case, try to convert the PNG image to 256 colors. If it fixes your problem, then there is a bug with pixel-precise collisions in RGB images.

Nice! And such enemies also exist in ALTTP and Link's Awakening.
Your code is clean, your explanations are very clear. This will probably help people. Thanks!

Yes, I confirm it is a bug. I entered it in the bug tracker: https://github.com/christopho/solarus/issues/284
Thanks for the report

With Solarus 1.1, the dialog box is fully scripted and yes, you can do more than two answers if you want.
In summary, you can pass any value to a dialog, and get any value as result (a boolean, a number, a table, etc.).

All details are here: http://www.solarus-games.org/doc/1.1/lua_api_game.html#lua_api_game_start_dialog

map:remove_entities() works, but entities are actually removed at the next cycle. For me, it is a bug that you can't re-use the name right now. So I entered it in the bug tracker: https://github.com/christopho/solarus/issues/282
I also entered another issue to implement conveyor:set_direction: https://github.com/christopho/solarus/issues/281

In the meantime, what you should do is to make with the map editor 4 conveyor in each spot (one for each direction), and use conveyor:set_enabled() to enable only one of them every time. Do you see what I mean?

In general, using set:enabled() is much easier than removing and re-creating entities. Actually, that's why this bug exist: I almost never remove and re-create entities in my games.

I hope it helps

That being said, your puzzle looks nice and your code is well commented. I hope you will share your game on this forum soon