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

GP2x Texture Management Part 1

Sign in to follow this  


So, having put it off for the last few days due to being "ill" I finally got my head down todo some work on the texture management for higher memory storing of images.

Currently its nowt special, it just allows you to upload a texture to memory and get given a id for it. This id allows you to query its size and physical memory address later on so that the blitter can draw it.

However, its a step in the right direction. Initally I was pondering how todo alot of this work on the 2nd CPU, but it occured to me that it would be faster and easier to control it on the primary CPU and then on drawing send the data across via a FIFO memory location and just have the cpu setup and kick off the drawing.

One of the 'fun' things I'm having to consider is how to delete images and return the free'd memory for useage. Right now I dont do anything like that, you cant free the image memory at all (and it doesnt really matter as the higher ram isnt used for anything unless you force the issue), however for final useage its possible that images will be uploaded, used and then deleted, so I need to come up with some code to handle this. Reusing the ID is easy enuff, just maintain a queue/stack of used and free'd id and return one of them in favour of a new one.

Memory becomes a more intresting problem, as when a block is 'free' it should really be merged in with any blocks around it to create a new large block. Right now, I'm not sure how I'm going to deal with this, however I suspect plenty of information out there on memory allocation schemes so digging up some ideas shouldnt be that hard.

The other thing I played with quickly was sorting out clipping for the data which is being copied. This infact has given me a new video showing the clipping in action : clicky (requires quicktime or something like that)

Finally, I had a little play with the ROPs (raster operations) which is a set of logical operations which can be applied to data as its moved around (source, dest and pattern) to combine it in intresting ways. Something however jumpped out pretty quickly about using ROPs, colour keyed transparency goes out of the window. It appears (and I'll confirm it once I've read some more) that ROPs are performed BEFORE the transparency rejection. I hope there is a way around that, because its not overly helpfull if this is the case [sad]

So, not a great deal to report, but things are starting to roll. I need to work on the memory management scheme for the ram tomorrow I think, so that things can be removed and uploaded adhoc, however I've managed to get something done tonight which was my aim.
Sign in to follow this  


Recommended Comments

There are no comments to display.

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!