Sign in to follow this  
  • entries
    455
  • comments
    639
  • views
    422038

GP2x Texture Management Pt2

Sign in to follow this  
_the_phantom_

86 views

So, having pondered the problem for a few days on how to manage my upper memory area I've finally settled (for now at least) on a frame based allocator, namely the one from Game Programming Gems 1 (section 1.9, pg 92 for those reading along at home).

After a bit of consideration this currently looks like the sanest method to use because of how envision texture memory useage to go; namely load at the start of the level and dont change between then and the next level load at which point all the data could be flushed.

While the frame based allocator works perfectly its interaction with the texture manager (and other managers) is going to be intresting to sort out.

The allocator works much like the C++ static, memory is deallocated in the reverse order to which it was allocated. So, if you want to remove a texture you have to deallocate all the textures which were allocated after it. On the plus side, this means that you dont fragment memory, however its an all or nowt system.

Now, you can allocate 'frames' which let you only deallocat to a point, which solves the sweeping all of the memory issue, however as the texture manager uses handles it needs to know which handles are around and which arent.

Now, if we accept that everything is unloaded and reloaded on level change, this isnt a problem, as all handles are invalid, so all we have todo is reinit the texture manager and off we go again. For now, this is going to be how things work, other schemes would just be too complex and this seems like a sane way of doing it.

Right now the allocator is, by default, only using the first 16meg of the higher 32meg of ram. This seems like a fair amount of room for both textures AND sound data (both can be allocated on the same frame). The upper 16meg might well be useable as well, although a fair chunk is reserved for other stuff, which I may or may not be able to trample over, so until I've confirmed either way I'll stick to using the 16meg I know is free [grin]

So far progress towards 'something' looks like;
- Texture loading : via GTL
- Texture manager : simple system in place
- Memory manager : Quick framebased allocator in place

However, my stated goal was to get the 2nd core doing the drawing commands and just issuing a command stream from the main CPU, so that looks to be my next tasks;

- Invent command stream format
- Invent API to send drawing commands
- Write 2nd CPU code [grin]
- Write 2nd CPU management code
- Intergrate above code with memory manager

The first 2 should be easy, as should the last one, the middle 2 should be... intresting... the management code I'll probably base off someone elses library, the main loop code I'm not sure about as yet, I'm torn between assembler and C, as both are doable.

Still, things are progressing, which is always good [grin]
Sign in to follow this  


0 Comments


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