GP2X Little Help Porting Sdl App

[deluded]

I'm still waiting for my F200, but that's not going to stop me compiling my test program for gp2x.

But a few silly questions..

If I do a printf("Hello World\n"); - where does it go?? Can I telnet in and get the output?


What's the best way to init SDL? - I'm currently using

CODE

SDL_Surface* screen = SDL_SetVideoMode(320, 200, 16, SDL_SWSURFACE );



Is that OK for gp2x?


And what's the best way to draw to the screen - my current code is ripped straight from a tutorial and does:

CODE

// screen is main SDL surface, DrawSky / DrawBitmap both write 16bit pixels directly to it.

DrawSky(mazesky, screen, angle, (int)sky_xpos, (int)sky_ypos);
DrawBitmap(mazegfx, screen, heightmap, angle, (int)xpos, (int)ypos);

// Update the screen
SDL_UpdateRect(screen, 0, 0, 0, 0);



Thanks for your help - on the PC my simple 3d Voxel thingy does around 600fps - so will be interesting to see what the gp2x can get.

 

[frutbunn]

I'm still waiting for my F200, but that's not going to stop me compiling my test program for gp2x.

But a few silly questions..

If I do a printf("Hello World\n"); - where does it go?? Can I telnet in and get the output?

Yes, once you've setup USB networking. Otherwise you can see output via a BOB and a serial line.

QUOTE

What's the best way to init SDL? - I'm currently using

CODE

SDL_Surface* screen = SDL_SetVideoMode(320, 200, 16, SDL_SWSURFACE );



Is that OK for gp2x?

Yes, but the GP2X resolution is 320x240.

QUOTE

And what's the best way to draw to the screen - my current code is ripped straight from a tutorial and does:

CODE

// screen is main SDL surface, DrawSky / DrawBitmap both write 16bit pixels directly to it.

DrawSky(mazesky, screen, angle, (int)sky_xpos, (int)sky_ypos);
DrawBitmap(mazegfx, screen, heightmap, angle, (int)xpos, (int)ypos);

// Update the screen
SDL_UpdateRect(screen, 0, 0, 0, 0);



Looks fine, but it's polite to lock the surface before manually manipulating it:

CODE

#define LOCK(s) {if(SDL_MUSTLOCK(s))(void)SDL_LockSurface(s);}
#define UNLOCK(s) {if(SDL_MUSTLOCK(s))(void)SDL_UnlockSurface(s);}



QUOTE

Thanks for your help - on the PC my simple 3d Voxel thingy does around 600fps - so will be interesting to see what the gp2x can get.

Slow GP2X is SLOW :lol: Have fun!

 

[deluded]

Cool - my code actually has 240 as a #define, swapped them to numbers to make it more readable and wrote it down wrong.

The drawing routines use 32bit integer maths, no division, and very few multiplies so I'm hoping it will be fairly ARM friendly.

If not then I'll rewrite some of it in ASM which should be fun as I've never done ARM assembly before.

 

[frutbunn]

You should be fine! But I was quite surprised at how slow the GP2X was first time around. Although I never bothered compiling my Voxel landscape for it, I did try some stuff and found it to run quite slow. :lol: I suppose modern PCs have made me soft!

I think you'll have a lot of fun with this platform Deluded! It's a cool system to code.

Edit: Oh, one last thing: Don't let the toolchain grind you down... Some of them can be a bit of an arse to start out with...

 

[deluded]

I've been trawling the threads at work regarding tool chains and makefiles etc.. So hopefully I've got a load to go on.

Coding for this thing brings back memories of the Amiga, in fact my test app is based upon a Mario Cart style clone I started on the Amiga many years ago - although that used horrid copper hacks to draw the screen.

 

[earx]

just out of curiosity, is it a real voxel engine (using raycasting) or using zbuffer/painter's algorithm polygons?

about speed: gp2x suffers from low memory bandwidth to the SDRAM. but when stuff is in cache it's quite ok. also note that the ARM9 is not a superscalar cpu like the pentium, nor does it have L2 cache.

arm assembly is the best, love it more than 680x0.

 

[deluded]

It draws the landscape from front to back, using a second bitmap to tell it how many pixels to draw upwards to create the height.

It also uses an array of previous heights to work out if it needs to draw anything to the screen, so if say there's a big hill at the front, it wont bother drawing anything behind it - with any luck that array would stay in cache and speed things up nicely.

What I'd like to do is get it running on the second core, and allow the main core to draw any graphics on top of it using a tripple buffer kind of arangement.

 

[YakumoFuji]

good luck with that, the second core is next to useless.

 

[PokeParadox]

Next to useless is not quite useless. So with that being said, you won't actually know if it will help or not until you actually try.
There was a library to help use the 940 posted on the board: Command940 it would probably help with getting this on the second CPU.
Anyways good luck.

 

[deluded]

Why so??

I know it doesn't have the MMU which isn't a big deal. The only issue I can see is the smaller cache.

With a bit of optimisation, all of the code and lookup tables for a given angle should fit in the 4k caches - so it will only hit main RAM when reading the input bitmaps and drawing to the output bitmap.

I reckon at 30fps - it would give me 80 or so instructions per pixel to play with - which is more than enough even with wait states.

Or am I missing something here?

 

[rokdcasbah]

Or am I missing something here?

not that i can see. i don't think people realize how much lower the overhead is for this kind of engine.

also, for your first question...remember that you can always pipe the console output to a log file and check it later. but obviously it's better to use usb networking + telnet for seeing what's going on "live". as a small side note, i doubt telnet can get the output unless you're logged in before you launch the app. but you'll probably end up just launching the app from telnet anyway, so it's moot.

and yeah you should lock surfaces, including the screen, while messing with them.

this looks awesome i wish you oodles and oodles of luck.

 

[deluded]

Well my engine works the same way as my old Amiga one running on a 14Mhz 020, but with the addition of height mapping.

Just trying to get the Open2x tool chaing going on my linux box now (I like doing things the hard way!)..

Anyone know how to get glibc 2.4 on to an old ubuntu..

 

[deluded]

It compiles!!

CODE

-rwxr-xr-x 1 rich rich 1090806 2007-10-31 23:17 test.gpe



Bloody big executable when statically linked with the open2x stuff though.

Just need the F200 now to test it on

 

[Parkydr]

That's small - try adding a few more libraries like SDL_Mixer and its associated libraries.

 

[deluded]

Whoopeee!!!

Just got my F200 - ran the code I compiled last week and it worked first time!!!

Reckon 3-5 fps at the moment - so obviously a lot of room for improvement.

 

[deluded]

Bit of optimisation later - 8fps with the sky, 11 without it.

However, after looking at say duke3d - I know my code can go loads faster.

So a couple more questions:

I'm currently creating a 16bit screen with SDL_DOUBLEBUF|SDL_HWSURFACE set. My code writes to this 16bit pixel at a time, then calls SDL_Flip() when it's done.
It there a quicker way of doing this?? Are SWSURFACEs quicker or slower than HWSURFACEs for writing to??

My code hits memory a lot - can I speed memory access up?? Does this mmuhack.o make any difference.

Any other good ways of speeding things up?? I could move to the minimal lib, but I assume for just writing to screen memory, it would be similar speed to the SDL in Open2x.

 

[Alex.]

Definitely give SW surfaces a try!

Good luck with your project, it looks very interesting

 

[deluded]

What's the difference?? I understand on a PC, one is in system ram, the other on your VGA card. However, on this thing it's just the same memory chip(s).

 

[YakumoFuji]

if you want to use tv out you will have to use SW rendering anyway. just an fyi

 

[deluded]

ok - will try recompiling tonight with SW rather than HW and see if it makes any difference.