[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [pygame] Best practices for creating multiple resolution 2D pixel-art games?
I see...
So, as I suspected, there is not "easy" answer.
I just was hoping that everybody would already faced this problem before me with alternatives different to:
a.- Render the display with OpenGL.
b.- Force fullscreen fixed resolution.
c.- Force windowed fixed resolution.
d.- Support a couple of concrete resolutions.
Thanks everybody for the answers. I'll have to make some tests, but I've got the following (let me know what do you think):
1.- I don't have the resources to do precious hi-res aliased cartooned or cell-shaded graphics like those that can be seen in recent Android, iOS or PC games. Surely, even in low-res modes you need an army of artists to create such graphics (just see "Wario Land: Shake It" screenshots in Wii, at 640x480: http://www.google.es/search?hl=es&q=wario%20land%20wii%20screenshots&um=1&ie=UTF-8&tbm=isch&source=og&sa=N&tab=wi&ei=Ig1-T-3-NM6whAf5_Mn3DQ&biw=1012&bih=555&sei=JA1-T7qhLoqnhAeX7NSKDg )
1.1- For retro-like sprites (pixels like fists): seems to fit with 640x480 or at. max. 800x600 display windows, windowed or fullscreen.
1.2.- For precious-graphics, it seems to be better to draw highres or midres (minimum 1024x768) and downscale / upscale with aliasing.
2.- For the Widescreen vs 4:3 problem, with my retro-graphics games, I think the best option is to find the nearest videomode to 800x600 in widescreen and center the "game area" in the screen.
2.1.- If the game-type allows "extending" the viewable area (top-down view games like RPGs, and so on), don't scale the graphics, just extend the area the player can see, including the user interface.
2.2.- If the game does not allow "extending" the viewable area (example: Bubble Bobble, Manic Miner), just keep black (or textured) frames around the game area.
2.3.- Allowing 1.5x, 2x and 3x zooming would be a possibility not to hard to implement to allow the player select bigger resolutions.
3.- As you've said, I have to separate "game/world coordinates" from "screen coordinates". And "sprite-speed" should be related to game-coordinates, not screen coordinates.
4.- Maybe in the future, when OpenGL rendering is totally transparent for pygame programmers (I mean, totally transparent, just a flag when setting the video mode), test it :-)
Thanks all :-)
--
Santiago Romero
Ubuntu GNU/Linux
http://www.sromero.org