GP2X Future Sdl<->hardware Scaler Support?

[bosteen]

Is there anyone in the know who can give me a clue here. A number of SDL games have a hard-coded minimum resolution of 640x480. Currently, asking for any mode above 320x240 though SDL causes it to fail.

Rather than code a workaround for each game/emu/whatever that does this, will it be possible in the future to ask for a 640x480 res display and let the hardware scaler scale it down for the screen? In other words, is there going to be support for higher resolutions through SDL, or is it just false hope?

Ben

 

[DJWillis]

I have been looking at doing this with the GPH SDL patches, it's not working yet but the concept is sound (it will be slow and I don't think it will look very nice).

 

[Oscaruzzo]

Is there anyone in the know who can give me a clue here. A number of SDL games have a hard-coded minimum resolution of 640x480. Currently, asking for any mode above 320x240 though SDL causes it to fail.

Rather than code a workaround for each game/emu/whatever that does this, will it be possible in the future to ask for a 640x480 res display and let the hardware scaler scale it down for the screen? In other words, is there going to be support for higher resolutions through SDL?

​

Probably not, but the second thing i'll try when i get my gp2x will be adding support for hardware accelerated blitting and scaling to SDL (so you could render to an off-screen surface and then scale and blit it on the 320x240 frame buffer).

 

[bosteen]

I have been looking at doing this with the GPH SDL patches, it's not working yet but the concept is sound (it will be slow and I don't think it will look very nice).

​

[please forgive ignorance in this post]

It may be slow, but if we could offload the '640x480 surface to 320x240 display' code to the second processor, it might be bearable for those tricky to port SDL apps, even if the (future) power consumption will double. For example, blob wars is a top sdl game, and probably well suited to a handheld, but it runs at 640x480. You could try to rewrite it to run at 320x240, but it could be easier and possibly acceptable just to bolt on this display kludge.

This hopefully also leaves the vague possibility of running at full resolution through the TV-Out, but I probably have mistaken how the TV-out will operate. And I also have no idea how to program for both proc's yet, so I could be talking out of my you-know-what.

[/please forgive ignorance in this post]

Ben

 

[Radek]

The GP2x's MMSP2 chipset does actually have a hardware scaling of surfaces in its Video Post Processor. It should be able to use just 640x480 surface natively then let the hardware do the scaling to LCD's 320x240 (or whatever). At least docs sugests so.

 

[Squidge]

I've played with the hardware scaler, and yes, dividing the resolution in half is incredibly easy (the hardware scaler works on a ratio system, where 1024 is a scale of 1.00).

 

[karmacop911]

but you've missed the all important question - how badly do you even really WANT to play games made for 640x480 on the gp2x?

not to say that the hardware scaler isn't useful...

 

[theoddbot]

Does the scaler work on RGB surfaces or only YUV? I can't see anything about RGB in the documentation.

Hardware accelerated blits should be great though.

 

[Squidge]

Well, I managed to get the scaler to work on the gp2x menu, so I guess RGB

 

[theoddbot]

Awesome

 

[geniv]

excuse my ignorance but what is:

blitting? when u guys refer to hardware blitting

 

[codesmith]

excuse my ignorance but what is:

blitting?   when u guys refer to hardware blitting

​

"Blit" is short for "BLock Image Transfer". It basically means copying a rectange from one part of the screen to another, or from memory to screen, screen to memory or memory to memory. Hardware blitters are very very useful because 1) they are usually faster than the CPU and 2) they are also usually capable of running separate from the CPU, so while the blitter is busy copying stuff the CPU can be doing other calculations. Most hardware blitters (including the one on the GP2X) can also do boolean arithmetic on the data as it's being copied, so you can use them to do all manner of useful effects. The one on the old Amigas could even be programmed to draw straight lines at any angle, I'm not sure if you can do the same with the one in the GP2X.

 

[gp32rich]

BUT!....

If you scale a large image down you're asking the processor to do four times the work it needs to!

For a quick hack to check the code works, okay.


But wouldn't it be better to recode the output to use native resolution? (TV out excepted )

 

[Radek]

BUT!....

If you scale a large image down you're asking the processor to do four times the work it needs to!

For a quick hack to check the code works, okay.


But wouldn't it be better to recode the output to use native resolution? (TV out excepted )

​

That's depending on what the program is doing. For an example native resolution of emulated system might be higher than 320x240 so there is need to process at higher res anyway. For some things you would also prefer using 640x480 downscaled to 320x240 (if perfomance permits) as it's like a supersampling then.

 

[icurafu]

Would be be a good idea to scale the DOS resulution up to QVGA. It would save a lot of annoyance, writing your own scaler.