Flappy Bird: What I Did for the Pandora Version


You already figured out how to submit highscores yourself. What keeps you from doing it? Lack of network coverage during a bus ride?

Whats your point?
Yes, that is my point. Lack of network coverage during a bus ride. In fact most of the time my wifi is disabled.And if I would want to start the spaghetti client on my own every time I have a not submitted highscore, we could just go back to the ROT competitions, post in a thread, what score we get, and assume, that nobody lies... I thought skeezix C4A idea was to make things easier. ;)
 
Only read the article now, it talks about using the GPU while the game isn't using GPU at all - doublebuffering is achieved by flipping buffers in the display controller.
Using hardware surface in python has nothing to do with the GPU?
Right, it's always kept off, you can even unload the driver (/etc/init.d/pvr-init stop) and it will all still work.
 
Last edited by a moderator:
Only read the article now, it talks about using the GPU while the game isn't using GPU at all - doublebuffering is achieved by flipping buffers in the display controller.
Using hardware surface in python has nothing to do with the GPU?
Right, it's always kept off, you can even unload the driver (/etc/init.d/pvr-init stop) and it will all still work.
So is there a way to get GPU acceleration via pygame?
 
Only using opengl renderer I guess. There is no 2D acceleration on sgx afaik.
 
glshim allows full Open GL calls to work (even though the driver supports only GL ES), so you can either use glshim + OpenGL calls, or just go with OpenGL ES (which the driver supports) and you don't need glshim.

If PyGame already supports GL, you'd need to check whether it is ES or full GL and make a decision based on that.

But, is performance even an issue on this game? I haven't tried it on Pandora, but I don't see why a game of this nature should have any concerns for performance.
 
True. If it runs good, don't bother.


2D rendering with gl is not always faster.


For example this F1 game would be much faster if it would not use gl and textures for every bitmap.


You could project a blitted frame onto a gl surface for scaling, but as the game already uses the full resolution it would only make it slower again.
 
If PyGame already supports GL, you'd need to check whether it is ES or full GL and make a decision based on that.
Pygame only supports full OpenGL that's why i was wondering how I would use glshim with it... Not sure how I can call glshim from a Python program.

2D rendering with gl is not always faster.
Well with GL acceleration you should get butter smooth scrolling, though.
 
So have fun converting the whole rendering of the game to glcalls...


Edit: be sure to only use stuff that glshim supports.
 
Last edited by a moderator:
Pygame as a high level language mix of sdl and python is not that fast, but for such a game it cannot be that bad.


For glshim: Just programm it as if you would use normal gl and then preload the libGL.so.1 that you compiled from lunixbochs git repository when running the game.
 
Last edited by a moderator:
2D rendering with gl is not always faster.
Well with GL acceleration you should get butter smooth scrolling, though.
Why would you think that? SGX sucks for 2D, none of my emulators use GL, DraStic doesn't use GL, and all of those can do smooth scrolling. You just have to sync your game with display properly, which can be done by enabling vsync in "my" SDL and removing all sleep calls in the game so framerate is driven by LCD and not by random sleeping.
 
Last edited by a moderator:
2D rendering with gl is not always faster.
Well with GL acceleration you should get butter smooth scrolling, though.
Why would you think that? SGX sucks for 2D, none of my emulators use GL, DraStic doesn't use GL, and all of those can do smooth scrolling. You just have to sync your game with display properly, which can be done by enabling vsync in "my" SDL and removing all sleep calls in the game so framerate is driven by LCD and not by random sleeping.
I am already doing that for Flappy Bird but nevertheless I can see some frames being skipped once in a while (not sure why), so I'm wondering if going to OpenGL could remove some of the load and help improve the overall smoothness. As you said, maybe it wouldn't do anything. 
 
Like said, it's because you're sleeping, with sleeps you're going to miss frames. Sleeps are caused by FPSCLOCK, you should remove that thing.

Also if you want a feeling of smoothness, your game should run at 60fps, not 30. Even if human eye/brain can't handle more than 20-something, there is certainly a difference on how it feels. You'll need to adjust the game logic to update at half speed though, as the framerate will double.
 
Last edited by a moderator:
Like said, it's because you're sleeping, with sleeps you're going to miss frames. Sleeps are caused by FPSCLOCK, you should remove that thing.

Also if you want a feeling of smoothness, your game should run at 60fps, not 30. Even if human eye/brain can't handle more than 20-something, there is certainly a difference on how it feels. You'll need to adjust the game logic to update at half speed though, as the framerate will double.
I took a look at your SDL_omap code (me and foxblock wondered, how you implemented the vsync wait).

So in SDL_Flip you call osdl_video_flip. Osdl_video_flip looks like this:

void *osdl_video_flip(struct SDL_PrivateVideoData *pdata)
{
void *ret;

if (pdata->fbdev == NULL)
return NULL;

ret = vout_fbdev_flip(pdata->fbdev);

if (pdata->cfg_force_vsync)
vout_fbdev_wait_vsync(pdata->fbdev);

return ret;
}Obviously vout_fbdev_flip does the flip and vout_fbdev_wait_vsync waits for the vsync.But why do you FIRST flip and afterwards wait for the vsync?

I know from DOS ages, that I have to wait for vsync and in the moment the vsync happens, I flip the buffers, because that is the moment the screen image is finished and no glitches will appear.

What did we overlook?
 
That's because flips on OMAP3 are not instant, the hardware only remembers that you want to flip and will do the real flip on vsync by itself (actually it's not even at vsync, but at VFP, which is slightly before vsync, yes OMAP is weird). So you want to inform the hardware as soon as you have a frame ready, if you wait for vsync you'll get 1 frame lag and end up drawing on the front buffer that the LCD reads, getting tearing and artifacts.
 
That's because flips on OMAP3 are not instant, the hardware only remembers that you want to flip and will do the real flip on vsync by itself (actually it's not even at vsync, but at VFP, which is slightly before vsync, yes OMAP is weird). So you want to inform the hardware as soon as you have a frame ready, if you wait for vsync you'll get 1 frame lag and end up drawing on the front buffer that the LCD reads, getting tearing and artifacts.
Thanks for the clarification.
 
Back
Top