Optimization & Frame Rate Issues.

192 views
Skip to first unread message

Chris White

unread,
Jul 15, 2013, 10:02:36 AM7/15/13
to emscripte...@googlegroups.com
Hi,

I successfully ported my C++ based OutRun engine using Emscripten. (Oriiginal engine ref: https://github.com/djyt/cannonball/wiki). Great work on Emscripten!

Once I managed to get the build system configured correctly with CMake it was relatively straightforward. However, I have some questions:

1/ Currently rendering uses SDL surface and software rendering. For the SDL original, coding an OpenGL renderer yielded a decent performance improvement. Would I see a significant performance enhancement if I were to code a WebGL based renderer? Bear in mind I am simply blitting a 320x224 array of 32 bit values, and there is no 3D specific rendering. I don't want to spend a lot of time on this if the difference would be marginal. 

2/ The Javascript version isn't running full-speed. I would say it's running at ~20fps, when I would be aiming for at least 30fps. I am compiling with -O2 and a selection of the -O3 options. Now I don't know very much about Javascript, so I profiled the code in Chrome's profiler. It reported that 80% of the time it was Idle. 

Related to the above if I pass a value of zero, rather than 30, to the emscripten_set_main_loop call the engine runs at approximately 3x the expected speed. 

Am I doing something weird/wrong? It feels like I should be getting 30fps, but for some reason passing the fps value is causing a weird slowdown problem that isn't noticeable when passing zero. 

For what it's worth a few minor issues I found along the way:
- I had to manually change the key codes for the cursor keys.
- I'm not sure if the SDL surface RShift, GShift, BShift values are being set correctly. I had to set these manually. 

I was impressed that the results even ran on my Samsung Galaxy S3 at a decent framerate.

Thanks,
Chris. 

Alon Zakai

unread,
Jul 15, 2013, 2:13:20 PM7/15/13
to emscripte...@googlegroups.com
Regarding GL, it depends on the browser. Some, like IE9+, have very good hardware acceleration of 2D canvas, and GL might not help much. But in general, GL gives you a guarantee of full hardware acceleration, where it works.

Regarding it being idle most of the time, that might be that it spends the "idle" time doing rendering (so it is "idle" from the perspective of the JS profiler). If you have a simple way to disable rendering but run everything else, that might be a way to test that theory.

It is recommended to pass a value of 0. 0 means to use the browser's native refresh rate using requestAnimatioFrame, which is often better optimized than a manual setInterval (which might miss the right times to render).

- Alon




--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Chris White

unread,
Jul 15, 2013, 4:33:10 PM7/15/13
to emscripte...@googlegroups.com
Thanks for your help with this. I passed zero to use the browser's native refresh rate as suggested.

I then refactored my main loop in the following rather horrendous manner. Here's the pseudo-code: 

static void emscripten_main_loop()
{
  tick_program();
  time = getTickTime();

  // Create a delay
  while (time < expectedFrameTime)
  {
      time = getTickTime();
  }
}

This results in my engine running at a solid 30 fps (rather than the choppy 20fps I got when passing a value of 30 to emscripten_set_main_loop)  which it needs to as it's essentially emulating an old tick based game. 

However, I'm sure this can't be correct! What's the correct/clean way of doing this?
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

Chris White

unread,
Jul 15, 2013, 5:05:52 PM7/15/13
to emscripte...@googlegroups.com
Hmm.. I just noticed that the Snes9X Emscripten port actually does a lot of its timing from handcrafted Javascript:

Maybe this is the sensible approach. 

Alon Zakai

unread,
Jul 15, 2013, 5:30:16 PM7/15/13
to emscripte...@googlegroups.com
You shouldn't do a busy-wait, but yes, you do need to measure the time elapsed, because it can be slightly unpredictable. Then do the proper amount of processing in your tick for the amount of time that passed.

- Alon



To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages