Originally posted by HihiDanni
Originally posted by maple
oh gods what happened to this page's layout
Sorry about that. Should be fixed now.
So last night I came up with three possible strategies for allocating slots in VRAM for streaming sprites:
- All slots are the same size (eg. 32x32). The object requesting the slots needs to remember all of the slots, and do separate sprite calls to render the whole metasprite. It's easy to implement from the VRAM manager perspective but it really complicates things for users and bloats the memory used by game objects, neither of which I want.
- Slots can be different sizes, but each size of slot has its own exclusive region (e.g. 32x32 slots have one region in VRAM, while 64x64 slots have another). Easy to implement, but you waste a lot of space.
- Slots can be different sizes, and regions can be given to any size slot. Flexible, but requires defragmentation. Objects may spawn a few frames late as a result.
I'm currently looking to implement the third option. A couple things I will need to work out first:
- How to perform the defragmentation. I'm considering having it so that if any object is animating (i.e. it will need to stream to VRAM anyway), try to move it to any VRAM slot that is to the left.
- How to determine, with constant time complexity, which slots are remaining. I already have a system for this for creating and destroying game objects, but the different VRAM slot sizes makes this trickier, because you need contiguous space to allocate the larger spanning slots.
I'm going to prototype this before I implement it in the actual assembly code. Suggestions are welcome too.
Sorry for the late reply. I didn't realize this website was still around. I have a dynamic sprite allocation similar to the first one, but I managed to get around the memory issue with the use of having a linked list.
|