Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

Some GP2x stuff

Sign in to follow this  


Having managed to get two images to display, one of top of each other with colour keying, I've since turned my attension to trying to get the hardware blitter to throw the pixels around for me.

The first step in the process was getting the image data into high physical ram so I could feed the address to the blitter chip, then it should just be a matter of telling it where to get the image from, where to put it and how big it is.

The putting the image into high physical memory was the first problem however. On the face of it it looked pretty simple, mmap the physical memory from 32meg to 64meg into my address space and then do a copy from the image to it, bish bash bosh job done.

However, no.
Well, yes but it didnt work to start with, all because I forgot that 'static' means something different in C++ and C, so my memory was claiming to be mapped to address "1", which was a terrible terrible lie indeed [sad] This made my image uploading function crash and die everytime it was called [sad]
A couple of accessor functions later and I can now grab the addresses into my C++ code from the C code, much saner and indeed the image upload now works flawlessly.

This has been tested by drawing the image, still by hand, from the higher memory address. As the image is 24bbp it comes out as a mess, but its the correct mess [grin]

Why is it a mess you might wonder?
Well, the blitter in the GP2x only supports 16bbp (565RGB) mode and currently I'm having to feed it a 24bbp image. Now, I can make 16bbp images via the DX Texture tool, however they come out as DDS images and currently the GTL doesnt decode that texture format correctly, so it thinks the texture data doesnt exist and we get back a null pointer, joy of joys.
So, at some point I need to check out that file with a hex editor and fit it [smile]

Next up I tried to get the hardware chip todo the work for me, with little success, all the happens is it crashes. This could be down to me setting it up wrong or it could be down to a duff memory pointer to the device (mmap again), so I need to check that out I think.

So, some progress has been made, once I've cracked this I'll move onto the second CPU for drawing stuff.

I mentioned videos a while back iirc, I tried todo some capture the other night, however as soon as I tried to run a capture my drivers bluescreened on me.
I'll try again once I install some new drivers, if that fails I'll install the 32bit drivers in a 32bit OS and try again as it could be duff 64bit drivers giving me the problems.
Either way, I have the technology now, which is handy [grin]
Sign in to follow this  

1 Comment

Recommended Comments

Now, I can make 16bbp images via the DX Texture tool, however they come out as DDS images and currently the GTL doesnt decode that texture format correctly
As a possibility...

You could write a command-line D3DX tool that created a scratch surface of 565 format, loaded in the 888 bitmap and then fed out the new data?

D3DX/D3D will handle all the conversion/loading, all you'd need to do is lock the surface and dump the contents back out to a file [grin]


Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!