Which Function For Scaling/zooming?

[john4p]

I'd like to zoom/scale the displayed area of an emulator.

Tried SDL_SoftStretch which works, but it's slow and doesn't interpolate.
Then I tried SDL_zoomSurface from SDL_gfx -> SDL_rotozoom.h. That's horribly slow (maybe I'm doing something wrong).

Is there a better (also easy to use) alternative to these functions?

 

[EvilDragon]

I'd like to zoom/scale the displayed area of an emulator.

Tried SDL_SoftStretch which works, but it's slow and doesn't interpolate.
Then I tried SDL_zoomSurface from SDL_gfx -> SDL_rotozoom.h. That's horribly slow (maybe I'm doing something wrong).

Is there a better (also easy to use) alternative to these functions?

Not yet - someone need to work on better SDL for the Pandora.

notaz uses hardwarescaling via framebuffer...

I'm no dev, but I think he included that in this little tool

 

[john4p]

Okay, thanks (don't really understand notaz' tool).

Can you tell me how to use the often mentioned 400x240-screenmode of the Pandora? If I use SDL with these dimensions I only get a 400x240-rectangle in the middle of the screen surrounded by darkness...

Also can we create custom resolutions like e.g. 320x200 or 320x256 as additional screenmodes (which then would get scaled automatically to use the full height of the screen)?

 

[skeezix]

To use fb scaling you're no using sdl.. Youre using Linux framebuffer directly. Or maybe sdl in fb mode using chart would work, would have to look I to that

for sdl surface, you'd open the full size scaled surface and have to write a scaler using c or asm . Iike a bresenham scaler or somesuch works okay. Could use gles as well

I'm no really here right now so can't say much sorry

jeffphone

 

[john4p]

Thanks. As I don't have the knowledge to use the Linux framebuffer directly or write an own scaler I'll just wait for now...

What about the 400x240-screenmode? How can I easily use this (with SDL)?

 

[paeryn]

I'm hoping to finally have some free time from tomorrow to look into what bits of SDL the pandora can accellerate.

And this time I won't have to override the OS (shudders at what I had to do to work around the gp2x's fbcon), so there won't be any nasty suprises.

:gp2x < andora2ut4: :wub:

 

[Exophase]

What about the 400x240-screenmode? How can I easily use this (with SDL)?

Until proven otherwise I would assume that the LCD doesn't actually have a 400x240 mode. If it's there then at the very least no one has set it.

 

[notaz]

I'm no dev, but I think he included that in this little tool

Nope, this one is for making fb apps X friendly.

What about the 400x240-screenmode? How can I easily use this (with SDL)?

It's not usable at the moment, maybe we can make use of it in future.


What I recommend is doing it like psx4pandora does, using wrapper script technique:

ofbset -fb /dev/fb1 -pos 0 0 -size 800 480 -mem 307200 -en 1
fbset -fb /dev/fb1 -g 320 240 320 480 16
export SDL_VIDEODRIVER=fbcon
export SDL_FBDEV=/dev/fb1

op_runfbapp ./your_app_here

ofbset -fb /dev/fb1 -pos 0 0 -size 0 0 -mem 0 -en 0

EDIT: this doesn't work with SDL, because it wants to grab console and fails to do it from X. This will work if you use framebuffer directly though.

What it does:

• allocates OMAP DSS layer, asks video output to be 800x480 at position 0,0 (could set it to 640x480 at 80,0 instead to get centered 2x scaling of 320x240). 307200 bytes of video memory are allocated for 2 320x240 16bpp screens (for doublebuffering).
• sets video mode to 320x240@16bpp, virtual resolution 320x480 for doublebuffering.
• asks SDL to use the new layer through /dev/fb1
• runs your app and hides X (since SDL is now in framebuffer mode)
• cleans the video layer on exit

After this, you can act as if the screen was 320x240 in your code.
Hopefully in future we'll have SDL handling this transparently
*looks at paeryn's post above*

paeryn: I'm slowly documenting kernel stuff at http://pandorawiki.org/Kernel_interface , could probably expose OMAP DMA for GP2X blitter like functionality.

 

[DaveC]

Thanks. As I don't have the knowledge to use the Linux framebuffer directly or write an own scaler I'll just wait for now...

What about the 400x240-screenmode? How can I easily use this (with SDL)?

400 x 240?

There is no emu that I know of that used that resolution.

None even go into that evenly. Using that will result in ugly blocky fractional scaling that would cause ripple in scrolling. Most filters just make it blurry.

I don't know what emu you are porting but it is best to include an option for even 1:1, 2:1, etc. A small border can. Look better than distorted rippling pixels.

 

[john4p]

What I recommend is doing it like psx4pandora does, using wrapper script technique:

ofbset -fb /dev/fb1 -pos 0 0 -size 800 480 -mem 307200 -en 1
fbset -fb /dev/fb1 -g 320 240 320 480 16
export SDL_VIDEODRIVER=fbcon
export SDL_FBDEV=/dev/fb1

op_runfbapp ./your_app_here

ofbset -fb /dev/fb1 -pos 0 0 -size 0 0 -mem 0 -en 0

What it does:

• allocates OMAP DSS layer, asks video output to be 800x480 at position 0,0 (could set it to 640x480 at 80,0 instead to get centered 2x scaling of 320x240). 307200 bytes of video memory are allocated for 2 320x240 16bpp screens (for doublebuffering).
• sets video mode to 320x240@16bpp, virtual resolution 320x480 for doublebuffering.
• asks SDL to use the new layer through /dev/fb1
• runs your app and hides X (since SDL is now in framebuffer mode)
• cleans the video layer on exit

After this, you can act as if the screen was 320x240 in your code.

Great, I'll use this. Thanks a lot!

Btw., could I allocate 384000 bytes to use a 400x240 video mode (400x480 for doublebuffering)?


@DaveC: Of course I would take care of correct aspect ratio and not ugly stretch gfx in 4:3-format to the whole width.
I just read that 400x240 was available as one of the Pandora's default screen-modes (it's half the width (800) x half the height (480) of the Pandora's screen).

400x240 would still be useful for example for Amiga "widescreen" games with a resolution of 320x200 pixels:
320x200 pixels is a x:y-ratio of 1.6.
This could be (hw-)scaled up to 384x240 pixels which would keep the x:y-ratio of 1.6 while almost using the complete screen of the Pandora (so only 8 pixels wide black bars on the sides would remain for these 320x200-games).

 

[DaveC]

[quote name='john4p' date='17 June 2010 - 06:49 PM' timestamp='1276796983'

@DaveC: Of course I would take care of correct aspect ratio and not ugly stretch gfx in 4:3-format to the whole width.
I just read that 400x240 was available as one of the Pandora's default screen-modes (it's half the width (800) x half the height (480) of the Pandora's screen).

400x240 would still be useful for example for Amiga "widescreen" games with a resolution of 320x200 pixels:
320x200 pixels is a x:y-ratio of 1.6.
This could be (hw-)scaled up to 384x240 pixels which would keep the x:y-ratio of 1.6 while almost using the complete screen of the Pandora (so only 8 pixels wide black bars on the sides would remain for these 320x200-games).
[/quote]
I think you misread what I said. I wasn't talking about aspect I was talking about pixel sizes being even.

With Amiga for example stretch 320 to 384 would look HIDEOUS. 320 does not go into 384 evenly so you get uneven pixel sizes causing ugly distorted graphics and scroll ripple.

If you just did a straight double to 640 x 400 for 320 x 200 stuff you would get even pixel sizes not fractional uneven ones. That would look MUCH cleaner.

Fractional scaling looks ugly and alternative integer options to that should be given.

 

[torpor]

If you want accelerated graphics, using OpenGL ES is the simplest way. A simple GL ES 2D library is a very easy thing to code up in a couple of hours/days, and I really doubt you're going to get better performance for graphics i/o than to use the SGX itself for your 2D needs ..

 

[john4p]

I think you misread what I said. I wasn't talking about aspect I was talking about pixel sizes being even.

With Amiga for example stretch 320 to 384 would look HIDEOUS. 320 does not go into 384 evenly so you get uneven pixel sizes causing ugly distorted graphics and scroll ripple.

If you just did a straight double to 640 x 400 for 320 x 200 stuff you would get even pixel sizes not fractional uneven ones. That would look MUCH cleaner.

Fractional scaling looks ugly and alternative integer options to that should be given.

That's where hardware-scaling comes into play. 240 pixels height don't go into 272 pixels height either. Still 2D-games like Alundra, Castlevania - Rondo of Blood or Symphony of the Night look great upscaled from 320x240 to 3??x272 pixels on PSP.
Hardware scaling using bilinear filtering does the trick (2xSaI and Scale2x are even better of course).
Uneven software-scaling looks hideous, no doubt.
With interpolated hardware-scaling it looks good. Of course a bit blurry and not as crisp, but nice.


@torpor: Yes, OpenGL (ES) will be the solution. I'll just wait until someone else creates such a library and makes it available for the Pandora-community...

 

[DaveC]

What I recommend is doing it like psx4pandora does, using wrapper script technique:

Actually though for PSX it just scales fractionally to a size then adds a fuzzy filter over that. The graphics in PSX4all right now are blurry. I certainly don't think that is desireble for many as while not too horrible for 3D, it trashes pixel art.

Actually the way Picodrive does it looks much nicer. Clean pixel sizes with no blurry filter.

 

[DaveC]

I think you misread what I said. I wasn't talking about aspect I was talking about pixel sizes being even.

With Amiga for example stretch 320 to 384 would look HIDEOUS. 320 does not go into 384 evenly so you get uneven pixel sizes causing ugly distorted graphics and scroll ripple.

If you just did a straight double to 640 x 400 for 320 x 200 stuff you would get even pixel sizes not fractional uneven ones. That would look MUCH cleaner.

Fractional scaling looks ugly and alternative integer options to that should be given.

That's where hardware-scaling comes into play. 240 pixels height don't go into 272 pixels height either. Still 2D-games like Alundra, Castlevania - Rondo of Blood or Symphony of the Night look great upscaled from 320x240 to 3??x272 pixels on PSP.
Hardware scaling using bilinear filtering does the trick (2xSaI and Scale2x are even better of course).
Uneven software-scaling looks hideous, no doubt.
With interpolated hardware-scaling it looks good. Of course a bit blurry and not as crisp, but nice.


@torpor: Yes, OpenGL (ES) will be the solution. I'll just wait until someone else creates such a library and makes it available for the Pandora-community...

Actually I hated the way stuff looks on the PSP due to that awful blurring. That is one major reason I never got into PSP emulation, everything looks a blurry mess.

Just plastering a muddy filter over everything "does the trick" if you are looking for blurry graphics. It hides uneven pixels for blurr and loss of contrast. Bi-linear sucks.

That is why I think you should include a standard even 2X mode too. No blurr, no loss of contrast, just clear graphics. To me it is not worth all of that blurr and fuzzyness just to gain a few extra pixels in size.

 

[john4p]

That is why I think you should include a standard even 2X mode too.

Yes, there will be a "normal" mode - just with doubled pixels - should I release anything...

 

[DaveC]

That is why I think you should include a standard even 2X mode too.

Yes, there will be a "normal" mode - just with doubled pixels - should I release anything...

Would be cool, options never hurt.

I wonder if there could be a way for the user to set possibly in a config per game the frame or "canvas" size then let the hardware scale to that. For example the "I want every pixel used" crowd could set the frame to 800 x 480 and get full screen stretched. For the "I want clean non-rippling integer graphics" crowd you could for example set the frame in the case of Amiga to 640 x 400 which would yield the even 2X mode for 320 x 200. For the "aspect is everything" crowd they could set frame to 640 x 480 in Amiga case to get correct aspect and sacrifice even pixels.
If something uses multiple resolutions then a multi line config could be made for solutions to each mode. Then the emu would use the solution depending on which mode it is in at the time.

This way the user can set the screen up how they want. If it was per game then games that were different resolution (megadrive comes to mind) could have different frame sizes.

The one filter that I have seen that actually does look good is that phosphor 2x and 3x. I don't know if that could be done on pandora though.

Good luck.

 

[Jan-Nik]

@torpor: Yes, OpenGL (ES) will be the solution. I'll just wait until someone else creates such a library and makes it available for the Pandora-community...

I made one (http://jngl.watteimdocht.de) but couldn't ported it to the Pandora yet (because I haven't got mine yet). It works on the Wiz (OpenGL ES 1.1) though so it should be no problem to port.

 

[john4p]

Thanks - I'll have a look at your scaling functions. But doesn't the Pandora use OpenGL ES 2.0 which is not backwards compatible to OpenGL ES 1.1?

P.S. Could you please extend your library's scaling function so that it just accepts an SDL_Surface, scales it by the given x- and y-factors and then gives back another SDL_Surface? Thanks.

 

[torpor]

You can use both OpenGLES 1.1 and 2.0 on the Pandora .. and I guess I don't understand why you don't just use GLES 1.1 and make a simple library for loading textures and rotating/scaling/transforming them using GL itself, as this is very fast, and quite well proven as a technique for doing 2D with GL ES ..