Porting the game to a screen with 800x480

Discussion around programming R'n'D, its source code and its tools.

Moderators: Zomis, Flumminator

Post Reply
Blue Ion
Posts: 2
Joined: Fri Jun 25, 2010 7:55 pm

Porting the game to a screen with 800x480

Post by Blue Ion » Sat Jun 26, 2010 7:14 pm

Such screen comes on the OpenPandora, and as such not all the screen can be shown.

Other than that, the device is a fully fledged linux computer, with the only "limitations" of ram an perhaps cpu speed.

Angstrom provides all the libraries needed and the porting was a straight "make".

I've read the wii port thread and its good to hear a cropping solution is at least being thought.
Until then, wouldn't a quick 'n' dirty stretching solution be possible? An idea I had was to create an other SDL surface of 640x480 an let RnD work with the odd sized one. Then hijack sdl flip (or what ever is being used) so the RnD surface gets copied resized to the actual screen surface and then call the real buffer flip.
Perhaps the copying wouldn't be that fast, but until I figure how to use OpenGL ES for the resizing, a nearest neighbourhood should suffice. More so, the cpu isn't that weak and perhaps a more accurate software rescaler could work just as well.

Other than that, the game works marvellously on the device, no slowdowns, full sounds...
I'm going to try some mods like Alan Bond's Snake Bite or BD2k3 for a bit more complex things.

Thanks for such great game.
Cheers.

PS: I'm going tomorrow on a trip for a week so I won't be able to respond until then, but I felt asking this so you could take your time.

PSS: I've also tried Mirror Magic and compiles and works just as well, with the exception that a "extern struct JoystickInfo joystick[];" at main.h (sorry, can't look up the line number right now) makes the gcc moan about a error I can't remember right now (sorry). Changing joystick[]; to *joystick; fixes the problem. Once I come back, I'll be able to help you more.
The gcc version provided by the Angstrom distribution is 4.3.3
Just so you know.

User avatar
Holger
Site Admin
Posts: 2929
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Post by Holger » Tue Jul 06, 2010 3:31 pm

Just a quick note: I need some more time for a decent answer -- please stand by! :-o :-)

Thanks! And sorry for the delay...

User avatar
Holger
Site Admin
Posts: 2929
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Post by Holger » Tue Jul 06, 2010 9:31 pm

> Angstrom provides all the libraries needed and the porting was a straight
> "make".

That's quite cool and great to hear! :-)

> I've read the wii port thread and its good to hear a cropping solution is at
> least being thought.

The possible solution described there (to use "well-known" fullscreen resolutions, but also arbitrary resolutions just as needed for the output device in question) is nearly completely implemented now (in the current development version not publicly available yet), together with an option to use 16x16 pixel sized tiles while playing the game, which both combined should remove most problems in porting R'n'D to (mobile or whatever) devices with "unusual" or small display resolutions.

To use these new possibilities, it is required to define a custom artwork set to use "unusual" screen sizes, while the half-sized tiles can be selected as an option in the graphics setup menu (although it may be possible to also add an option in the custom artwork to select a "recommended" tile size and choose to use this "recommended" tile size in the setup menu -- this is not finally decided yet). This means that it would be possible to create a custom version of R'n'D (tailored to a certain device) just like the already existing special version "R'n'D jue", which means that all existing levels sets without custom artwork could be played out of the box with the desired screen resolution, while level sets with custom artwork (like Snake Bite or Zelda) could only be played with such a screen resolution after some changing of the custom artwork definitions (and some of the artwork itself, namely the screen border/background graphics and the menu definitions).

> Until then, wouldn't a quick 'n' dirty stretching solution be possible? An
> idea I had was to create an other SDL surface of 640x480 an let RnD work
> with the odd sized one. Then hijack sdl flip (or what ever is being used) so
> the RnD surface gets copied resized to the actual screen surface and then
> call the real buffer flip.

This would most probably work just fine, with some impact on graphics performance, of course (which might be no problem with current graphics hardware, although I'm not sure about 2D performance of current graphics cards).

> until I figure how to use OpenGL ES for the resizing

This would most probably be the best and most flexible solution for existing levels with custom artwork! In fact, this is already being worked on by somebody else, but apparently it isn't that easy, as OpenGL apparently requires the whole screen to be redrawn each frame, while R'n'D just changes the needed parts of the screen from the previous frame and only does a total screen redraw when changing the game mode (like menu->editor, menu->game or game->menu).

> Other than that, the game works marvellously on the device, no
> slowdowns, full sounds...

Again, great to know! :-)

> I'm going to try some mods like Alan Bond's Snake Bite or BD2k3 for a bit
> more complex things.

These would need some tweaking for non-native resolutions, but it would be possible (and definitely worth the effort). (Level sets which may be impossible to adjust to different screen sizes may be Zelda and Zelda II, as they rely on a certain visible playfield size, but maybe even this would be possible).

> PSS: I've also tried Mirror Magic and compiles and works just as well, with
> the exception [...]

Yes, that's right -- the (quite old and not really maintained) Mirror Magic source code has some problems when compiled with current versions of GCC. I should clean up these issues, as the game elsewhere has no other show stoppers to be compiled and run on current systems (including those which prefer to have a "usual" screen size ;-) ).

Blue Ion
Posts: 2
Joined: Fri Jun 25, 2010 7:55 pm

Post by Blue Ion » Thu Jul 08, 2010 8:39 pm

Well, I give up on the software rescaler. Doing what I said, that is, hijacking SDL_UpdateRect, I've managed to rescale the game to 640x480.
It is slow, and not pretty, and considering I initially used floating point operations, which is lethal on Arm cpus the game was unplayable.

I've tried removing as much of it and is kinda faster, but aside that looks worse, it still is too slow.

Here is what I've made so far, in case you might I have some better idea and I suck at coding.
sdl.c contains the the few changes to put my rescaler in.

I'm going to try now using OpenGL ES using pbuffers or something similar but this might end up worse.

Copying the surface is probably the culprit so hopefully it will be possible to map the SDL surface to a pbuffer texture and avoid the copying.

Post Reply