Re: [hatari-devel] OS X performance problem

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Le 04/06/2014 03:40, Bob Carpenter a écrit :
Nicolas,

Actually, it is a US shareware game. However, in any case, I am not doubting your floppy disk timings. Eero was questioning why he was seeing shorter load times than I see when loading this game. Unfortunately, timing this on a real STE is not possible for me. Without Hatari, I would have had to leave my ST memories behind about 6 house moves ago. :) I looked for a YouTube Frantick video, but the only one I found did not include the 640K music file so the load time is not equivalent.

With the latest Windows 1.8 development release and the status bar off, it takes 16 seconds to load in fast forward (frame skip=5). It was approximately the same time to load in fast forward with the status bar on in Windows. It takes approximately 4 minutes, 50 seconds to load without fast forward. I specifically used the Windows release to take the sub-par OS X SDL out of the equation.

My latest 1.8 OS X load times are as follows:
No statusbar
Fast forward - 29 seconds (frame skip=5)

Statusbar
Fast forward - 38 seconds (frame skip=5)

Because I am seeing the same timings in normal (non-fast forward mode), I am assuming the difference is due to the OS X SDL port. Since I do not see any effect in the gameplay, I think a few seconds extra to load a game in fast forward mode is perfectly acceptable. Hopefully, SDL 2 has an improved OS X port. However, I know there were some concerns about Hatari moving to SDL 2 so I am happy that the initial slowdowns have been resolved. At this point, they seem to be little more than benchmark differences. It has no effect on how the game actually plays and I think that is what is important.


Bob C


Fact is that if you use fastforward, all parts of the code will be called several times more per VBL. So, instead of doing 50 refresh per second, you might do 200 per sec for example (depend on your CPU's speed)..

This means x4 more calls to refresh the status bar ; so if SDL's implementation on OSX is the bottleneck, you loose more cpu by fastforwarding and doing more screen refreshes than the SDL backend can accept.

In the end, what you gained in emulation speed by running cpu/video/... at x4 is lost by the OS calls needed to refresh screen in SDL.

Nicolas




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/