Best way to get framebuffer access on Pandora? SDL? Raw OMAP? Example sources?

[Sdw]

OK, so I finally got my toolchain up and running, and now I want to start coding!

For now, I thought I would ignore the whole OpenGL ES business, and stick with a straight framebuffer.
Ideally I want the as little to do with the system as possible, just access to a fast (preferably double buffered and vsync aligned) framebuffer in fullscreen mode

What's the best way to go about this? I started reading a bit in the stickied thread about the enhanced SDL that seems to address some of these points,
Is that the way to go, use SDL (I've never actually done any coding with SDL before) or is it better to go straight to the OMAP hardware?
What modes can be used, I assume 800x480, but what about color bit depth? Any big speed differences between 32(ie. 24) and 16 bit col? Or is palettized 8bit (256 col) mode available and the fastest option?

Are there any good example sources I can look at (SDL or otherwise)?

 

[levi]

As my understand of it goes (mainly back to the 8-bit machines, but there you go) being v-sync aligned isn't a property of the framebuffer, it's something you code does just before it starts rendering, or just before it flips the buffer in the case of double buffering.

However I can't answer your question you posed. I hope someone else here can though.

 

[elw3]

The only example that flews to my mind is http://repo.openpandora.org/?page=detail&app=package.liveinfo.notaz
Different layer, but the pnd contains the sources and it shows how omapfb.h can be used.

I like the idea of coding close to the hardware, i usually get my button inputs from /dev/input on the pandora rather than using a proper joypad lib, but you will shoot yourself in the foot once you try porting it to something else
Stay generic instead, have the program write to its own buffer and then just select a proper method of displaying it later. Heck you could even have the program dump to ramdisk and have a picture viewer refresh 60 times a second. Ultra ugly but cosmetics comes when the program is finished.
I dont get why you are concerned about speed. The refresh rate of the screen is ultra slow compared with the rest of the system, regardless of how you do the display, no method will ever lack much.

 

[levi]

That all depends what you're trying to do. FWIW, a lot of ptitseb's projects are on his github pages, and they might be worth consulting to see what everyone else does (since they're mostly ports from other systems). But in terms of speed I believe the Pandora's screen is a 16-bit screen, so it's quickest to use that. Playback speed depends on what you're trying to do in between frames, and if you're doing a lot of calculations you can easily run out of time. Doing all the graphics in 16-bit depth stretches the time you have so it's generally worth bearing in mind.

 

[ptitSeb]

SDL1_omap sources from notaz also have direct Framebuffer access. Just a reminder, using "SDL_VIDEODRIVER=omapdss" use direct FB for all SDL1 drawing functions.

 

[ingoreis]

Had Notaz SDL not Problems with Touch and Mouse Controlls?
In many Cases and many Games..you do not need Mouse...then Notaz SDL will give very often a better Gaming Performance in Fullscreen Framebuffer.

 

[ptitSeb]

No, that's not linked. It's just, touchscreen device cannot always be used to simulated mouse, at least not easily, and especially if you don't have acces to the sources (like with DosBox). But again, that's not related to Framebuffer access.

 

[Sdw]

As my understand of it goes (mainly back to the 8-bit machines, but there you go) being v-sync aligned isn't a property of the framebuffer, it's something you code does just before it starts rendering, or just before it flips the buffer in the case of double buffering.

Yeah, I was more asking what methods are available to actually make a proper vsync-aligned buffer swap, perhaps SDL handles this internally already. Also, I'm not even sure if LCD screens have a vsync refresh rate in that way, but if they don't there need to be some other method to have smooth, non-tearing frame updates.

I dont get why you are concerned about speed. The refresh rate of the screen is ultra slow compared with the rest of the system, regardless of how you do the display, no method will ever lack much.

The speed converns is mostly about the framebuffer -> hardware layer. Sometimes it can be an issue if for example your framebuffer is in a format/color depth the hardware doesn't natively support, and suddenly some middle layer is doing RGB conversions on 800*480 individual pixels. But maybe that is not an issue here at all!