[Solved] Performance bug: Solarus DX

Started by ZoriaRPG, May 25, 2015, 05:03:45 AM

Previous topic - Next topic
May 25, 2015, 05:03:45 AM Last Edit: August 12, 2015, 10:18:43 AM by Christopho
A bug that I, and several mates have noticed (on different hardware), is that during area transitions that do not have a cross-fade, there is about a 1.5 second delay, while Solarus loads the map for the next screen area, in which the game jitters, and the music halts briefly.

We suspect, this to be caused by the Solarus engine, not pre-fetching the next map area, and I have a suggestion for how to fix this: Find the closest map area to where the player is at all times, and keep that loaded in memory, so that the game engine can instantly transition to it. This is relevant only to map areas, where there are screen region transitions.

Clearly, you would only need to pre-fetch touching map areas, and probably only those to which the player is close. Maybe within X pixels of a boundary, to avoid that lag.

Otherwise, I'm quite impressed with the engine itself, although I won;t be giving up ZQuest anytime soon, and in particular, the 50,000 lines of ZScript code that I've created to run with it. I do look forward to learning the Lua language for Solarus; although I think it will take me a while to adjust to the lack of a simple enemy, and item editor.

May 25, 2015, 08:45:01 AM #1 Last Edit: May 25, 2015, 08:09:32 PM by Christopho
Hi!
Thanks for your encouragement :)
Are you talking of immediate transitions? How big is the new map (in terms of size and number of entities)?
For fade and scrolling transitions, I never saw this bug, usually maps are fast to load. It was even improved in previous versions. Maybe I forgot to test immediate transitions between different maps.

As I was saying in another thread, Solarus is young, and actually before the last version (released 3 weeks ago), there was no dialog editor, no strings editor, no quest properties editor and a lot less features. I am not denying that ZQuest is far more advanced on the usability matter :) We can definitely learn a lot from a ZQuest expert. Thank you!

Right, immediate transitions. I suggest running it on some older laptops, to do testing, as most users won't have high-end PCs just to run this. Testing on older HW is good anyway, because it enables you to catch more performance-related bugs in general.

In the main DX project, moving between screen areas on the first map does this. There is a brief pause, the music stops, and the screen jitters. Then the screen transitions, and the music resumes.

I'm not the only user who's run into this. Moosh (also from PZC) has the exact, identical problem.

P.S. I had no idea that you added so much in the last month. That's quite astonishing, really, and it seems I picked the right time to explore Solarus, as a month ago, I probably would have skipped it without those editor panes.

Quote from: ZoriaRPG on May 25, 2015, 06:53:22 PM
Right, immediate transitions. I suggest running it on some older laptops, to do testing, as most users won't have high-end PCs just to run this. Testing on older HW is good anyway, because it enables you to catch more performance-related bugs in general.

In the main DX project, moving between screen areas on the first map does this. There is a brief pause, the music stops, and the screen jitters. Then the screen transitions, and the music resumes.

I'm not the only user who's run into this. Moosh (also from PZC) has the exact, identical problem.

I'm not certain I'd call myself a ZQuest 'ex[ert', but I'm at least an adept. :)

Have you used the ZC/ZQ programmes (2.50.x)?

P.S. I had no idea that you added so much in the last month. That's quite astonishing, really, and it seems I picked the right time to explore Solarus, as a month ago, I probably would have skipped it without those editor panes.

May 25, 2015, 08:12:27 PM #4 Last Edit: May 25, 2015, 08:20:35 PM by Christopho
Ok I will fix this in the next bugfix release.
https://github.com/christopho/solarus/issues/695

EDIT: no, I never tried ZC/ZQ.

EDIT 2: new features in the engine and the editor will come slower in the next months, because after this huge work on the editor, I am now working less on the editor/engine and more on our next Zelda project (Zelda Mercuris' Chest).

Best wishes tracing that error, and resolving it. For the record, it seems mostly on overworlds, as dungeon areas have fewer transitions of this sort, and after a while, i got used to it.

I also am not sure, but I think that freezing Link while swinging the sword is a bit different to the real Z3 engine. You may want to check the timing there.

Hi ZoriaRPG,
Can you give more information on the issue here: https://github.com/christopho/solarus/issues/695
Because I don't reproduce any slowness. And I need to reproduce it to identify the bottleneck. Thanks

I finally encountered these exact symptoms while working on a game.

This was because of a weakness of the engine when dealing with sprites: https://github.com/christopho/solarus/issues/723
Check that your sprites don't have a negative frame_delay value (which is illegal anyway). I will do the same in ZSDX :)

I encounter the same behaviour with GCW port of the engine (probably as the GCW Zero is weaker than any of my PC) and I found that changing it to ogg music seems to make things a bit better.

August 12, 2015, 10:12:47 AM #9 Last Edit: August 12, 2015, 11:45:52 AM by Christopho
The GCW port is quite old, but indeed SPC musics are very slow because they are emulated. However, there is no such problem with recent versions ZSDX that use IT musics everywhwere.

In my case and I think ZoriaRPG's case too, the slowness only happened when the game goes from suspended to unsuspended: when entering a map (after the fade-out), but also when unpausing a game, when finishing a dialog, etc.

Another key characteristic is that bug it that it is getting worse with time. And if the game was run from the quest editor, even stopping the execution does not improve the situation. There is no memory leak, this is due to the time counter from the beginning of the process that continues.

A way to see if your performance problem is when loading maps or when unsuspending the game is to test entering a map that shows a dialog at startup. Like dungeons of zsdx and zelda_roth_se:
Code (lua) Select

function map:on_opening_transition_finished()
   map:get_game():show_dialog("some_dialog")
end

If you have a slowness before the dialog, it might be due to the map loading phase, but if you have a slowness after, this is most likely the bug of sprites with negative frame_delays.

It will be fixed in 1.4.4. In the meantime, if you have this symptom, check your enemy sprite data files. ZSDX has the problem, so games based on it have it as well.
If you have lines frame_delay = -1 or frame_delay = 4294967295 in a .dat sprite sheet file, replace them by frame_delay = 0.

IIRW, GCW Zero port is based on 1.3 and already use SDL2, LUA JIT and IT music but you're right, it should be updated. Unfortunately, Shin-Nil seems to have disapeared from a while  :'(.

Ok, nice, I thought it was older.
1.3 is quite recent, the only main change of 1.4 is a new quest editor.

Do you have a new dist for the Solarus DX game?

Also, what is the proper method for moving my saved game to a directory with the updated (1.4x) engine, and a new game file?

It is fixed in the development version, and this will be available in Solarus 1.4.5 / ZSDX 1.10.2.

There is nothing special to do for savegames, they are compatible.