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.
