GP2X Hardware Scaling


deluded

Member
Joined
Sep 28, 2007
Messages
162
Is there any way the gp2x can do hardware scaling? I've seen mentions of scaling but haven't figured out what the hardware can do.

I'm just after the ability to zoom in and out of a larger surface (say 640 x 480).
 
Yeah, using SDL at the moment.

I want to be able to zoom into a board when the user presses a button - but only part of the screen..

Not a big deal as this isn't the 3d thing so can be a lot slower.

Kind of anoying developing for the gp2x when my unit wont arrive until monday!
 
The display scaler that's used by my SDL port and Ryleh's minilib is realtime - it's a trick of the display hardware, there's absolutely no speed penalty for using it.
The way I did it in SDL is that you specify the top left coordinate of the screen surface to appear on the LCD and how many pixels wide and deep of that surface you want to fit to the LCD. You can go all the way from shrinking a 1024x768 surface to the LCD or expanding one pixel to fill it - all for free.
 
Hmm one pixel to fit - not sure what use that is other than a mini rave :)

So I accept I can rescale a 640x480 image with minimal effort, but how would I go about zooming in?? Can I set up view ports, or is it a manual job of blitting the bit I want to an unzoomed 320x240 surface?

PS. That's got to be the most inteligent thing I've ever written after a few pints of home brew.

PPS. I live 30mins up the M1 in Wakey :)
 
Firstly the scaler only works on the screen surface, and always full-screen, it doesn't create or physically alter any bitmaps. If you want to scale any other surface or require a physically scaled surface you'll have to do it manually.

Taking your 640x480 surface (screen), if you wanted to zoom in to a 160x120 rectangle of it starting at (40,20) all you'd have to do is
CODE
SDL_Rect visible_area;
visible_area.x = 40;
visible_area.y = 20;
visible_area.w = 160;
visible_area.h = 120;
SDL_GP2X_Display(&visible_area);

and that area is all you'll see on the screen. You don't have to keep calling it every frame, only when you want to change the area to be visible.

It's been years since I was last in Wakefield - a friend from uni lives there (or he did 12 years ago!)

Annoyed by Royal Mail - they tried delivering my F200 at silly o'clock this morning so I've got to wait until Monday before I can pick it up :-(
 
Last edited by a moderator:
That sounds useful.

I guess it's just nearest pixel rather than bilinier.

Cheers for your help! :)
 
deluded said:
That sounds useful.

I guess it's just nearest pixel rather than bilinier.

Cheers for your help! :)
yeah it's coarse scaling. but if you're using it for quick zoom effects (which, has anyone even done this before on gp2x? sounds sweet.) that might look fine.

for a pretty static image like a background, 640x480 scaled down 50% looks pretty clean, unless there's text on screen. i think hex-a-hop was ported like this.

and if the image moves and the frame rate stays high...i don't quite know how to explain it but i bet that the different pixels getting drawn or not drawn will change each frame, so over a few frames, the information does end up being there. like standing behind a screen door and moving sideways quickly...the mesh disappears.
for totally 2d game, this could be shimmery and weird, for 3d, it could work better, but i'm just guessing.

obviously there is the issue of rendering a picture in which 75% of the information is getting discarded...but hey, the scaling is free. anyway, good luck.

side note: i think the chip used to play movies can do smooth scaling. i'm fuzzy on the details now, but this is what i sort of remember people saying. i don't think it's bilinear or anything pixel-related but instead more of an analog scaling. anyway it's not something we have access to unfortunately.
 
Last edited by a moderator:
Back
Top