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]