Pandora improved SDL for pandora

[notaz]

Steven: it looks like data segment corruption to me (most likely caused by game), I'd need live gdb session to do more.

OK, here is a simple test program that demonstrates the bug. I forgot to set SDL_VIDEODRIVER to omapdss first, which made it impossible to reproduce the bug. Also the double buffering means that the bug only triggers when you blit to one buffer, but not when you blit to the other. And it's a border case that only happens in quite rare blit positions, so I had to try a bit to find a problematic example. But this example reliably segfaults, at least on my Pandora.

Thanks for the test and nice choice of sprite. I've finally went through it and implemented what's needed, would be nice if you tried it in your game with workarounds off and also checked if there are any visible performance degradation caused by extra checks. I've updated SDL git and reuploaded the binary here:

http://notaz.gp2x.de/tmp/libSDL-1.2.so.0.11.3

 

[_wb_]

It seems to be fixed - at least I couldn't get any segfaults anymore. I don't think the extra checks will make any difference for performance - nothing I could measure anyway.

Thanks for fixing this!

 

[ExquisiteCorpse]

Having a real hard time getting this to work. When I click the git link I cant see Where to download it

Anyone fancy doing a fairly newby guide?

 

[TrashyMG]

You need to download it with git..

I take it you're using codeblocks PND or a cross compiler.. you can get the code by downloading with git

go to the directory where you want to download the code and type:

git clone git://notaz.gp2x.de/~notaz/sdl_omap.git

The codeblock PND has git when you run the command line utility.. or if you're using a cross-compiler you can just install git however you normally install new programs with your particular distribution.

 

[notaz]

Well if you just want to use it in some app, you don't have to download it, it's in all newer firmwares.

 

[ExquisiteCorpse]

You need to download it with git..


I take it you're using codeblocks PND or a cross compiler.. you can get the code by downloading with git


go to the directory where you want to download the code and type:


git clone git://notaz.gp2x.de/~notaz/sdl_omap.git

The codeblock PND has git when you run the command line utility.. or if you're using a cross-compiler you can just install git however you normally install new programs with your particular distribution.

I feel fairly retarded now and I've actually made some small C++ text games and still don't really understand any of that.

 

[elwing]

git is a tool to fetch code from a repository and "git://notaz.gp2x.de/~notaz/sdl_omap.git" is notaz repository is a code repository. that command will just copy the code to the directory from where you execut de command. and he's telling you that if you have the codeblock PND you normally already have git on your pandora

 

[notaz]

I've finally got around to implement minimize icon, it should start showing app icon on pandora-button-minimize after you run OS update.

 

[FelixNemis]

I've finally got around to implement minimize icon, it should start showing app icon on pandora-button-minimize after you run OS update.

Woot!

 

[_wb_]

Ah neat, now people will finally see the Microbes and NubNub icons when they minimize those games

Did you also push the blit bugfix to the firmware repository?

Edit: Yes, the blit heisenbug is also fixed now. Nice!

 

[Ziz]

Hi,

foxblock got some interesting problems with notaz SDL and sparrow3d shown in this video:

https://www.youtube.com/embed/t0XZNwW0iek?feature=oembedIt flickers like hell.

For my purposes I do a lot of direct access of the pixels pointer of the surfaces. I read the textures pixels and read & set the target surfaces pixels. May this cause the problem? Is there a possibility to circumvent this behaviour or should we just don't use notaz SDL for sparrow3d, because it wouldn't improve anything anyway as long as I do my direct access stuff instead of using SDL bliting functions?

greeetings,

Ziz

 

[mcobit]

Could also be a problem with doublebuffering.


Did you try to set the according envvar?


Edit: sorry. Didn't watch till the end before posting.

 

[Ziz]

foxblock did this and furthermore I create the screen surface with

spWindow = SDL_SetVideoMode( x, y, 16, SDL_HWSURFACE | SDL_DOUBLEBUF | ( fullscreen ? SDL_FULLSCREEN : 0 ) );

 

[mcobit]

You could try to not use dublebuffering I mean.

 

[PokeParadox]

I think it's double buffering - I've had similar issues with Penjin doing buffered effects (blur, etc)

I only use SW surfaces now.

 

[foxblock]

Removing the SDL_DOUBLEBUF flag does indeed fix the problem.

 

[Ziz]

 

[Wally]

Hahaha Best use of this GIF.

 

[_wb_]

I also don't quite understand what is going on with the SDL_DOUBLEBUF  flag. IIRC, notaz' SDL actually uses triple buffers if you set it to double buffers. I don't know why. I've also noticed flicker in NubNub when using SDL_DOUBLEBUF together with no vsync. I don't understand why it would flicker in the way it did because all previous frames were similar enough but somehow the double buffering didn't seem to work.

 

[notaz]

Triple buffering is used because double is not enough to ensure there won't be tearing/artifacts without vsync as LCD refresh runs asynchronously to everything. If there were only 2 buffers, as you flip the buffers you'll get a pointer to buffer (surface) that the display controller is still reading from, and for example if you clear it (as it's often done before redrawing stuff or whatever), part of LCD will get black color instead of what's intended.

From the above video it looks like the game is assuming there is only one screen surface, but SDL_DOUBLEBUF specifies that there is at least 2 screen buffers ("front" one to display and "back" one for you to draw to), and in pandora's case there are actually 3 of them. You have to redraw full frame if you specify SDL_DOUBLEBUF.

_wb_: if you are fully redrawing each frame you should not get what you are describing. Maybe you were running over 60fps and consumed the buffer chain too fast which made you draw to front buffer eventually?