Regarding LoadAnimImage...
When I first read that I thought - well, duh, that's obvious. So whipped up a test to compare LoadAnimImage versus loading a pixmap and then loading images from it using Pixmap window.
Strangely, there was really not much difference in speed.
In fact, on this old computer at work the pixmap method was faster.
On a 512x512 tileset:
LoadAnimImage took: 122 ms
LoadPixmap took: 82 ms
LoadImage from Pixmapwindow looped 255 times took: 3 ms
So the pixmap method was 37 ms faster. I tested this multiple times and it always turned out to be faster, strangely.
This test stirred up a revelation though. Both 85ms or 122ms are just too long to load a single tileset. There are times when I might need to load 2 or 3 tilesets, and I'd really prefer not to have any frame-rate hiccups while doing so. I thought that I could stream the pixmap into a bank and then load it from the bank instead of straight from disk, but that didn't seem to speed things up at all.
So pre-streaming the tilesets isn't going to get rid of the bottleneck since the bottleneck is when I actually call LoadAnimImage or LoadPixmap.
I don't know how to get around this. I tried loading a single tile sized image (with the idea that if this was considerably faster I could just load a single tile every frame or couple of frames) - but this is only marginally faster than loading the whole tileset. Loading each tile this way would take 25 times longer than loading the whole tileset - so that's a no go.
Loading from banks doesn't seem to be any faster than loading from disk, either. So pre-streaming individual tiles into banks to be loaded doesn't help, just as it didn't w/ full tilesets.
Incbinning speeds things up but I'd really prefer not to go that way.
The only other idea I've got is to try and utilize a Ram stream, although I really don't know if that's possible. I'm going to go play around with that for a bit.
Your software z-buffer approach is interesting. I've got some thoughts and questions that I'll toss around later, after I get some more tests in.
When I first read that I thought - well, duh, that's obvious. So whipped up a test to compare LoadAnimImage versus loading a pixmap and then loading images from it using Pixmap window.
Strangely, there was really not much difference in speed.
In fact, on this old computer at work the pixmap method was faster.
On a 512x512 tileset:
LoadAnimImage took: 122 ms
LoadPixmap took: 82 ms
LoadImage from Pixmapwindow looped 255 times took: 3 ms
So the pixmap method was 37 ms faster. I tested this multiple times and it always turned out to be faster, strangely.
This test stirred up a revelation though. Both 85ms or 122ms are just too long to load a single tileset. There are times when I might need to load 2 or 3 tilesets, and I'd really prefer not to have any frame-rate hiccups while doing so. I thought that I could stream the pixmap into a bank and then load it from the bank instead of straight from disk, but that didn't seem to speed things up at all.
So pre-streaming the tilesets isn't going to get rid of the bottleneck since the bottleneck is when I actually call LoadAnimImage or LoadPixmap.
I don't know how to get around this. I tried loading a single tile sized image (with the idea that if this was considerably faster I could just load a single tile every frame or couple of frames) - but this is only marginally faster than loading the whole tileset. Loading each tile this way would take 25 times longer than loading the whole tileset - so that's a no go.
Loading from banks doesn't seem to be any faster than loading from disk, either. So pre-streaming individual tiles into banks to be loaded doesn't help, just as it didn't w/ full tilesets.
Incbinning speeds things up but I'd really prefer not to go that way.
The only other idea I've got is to try and utilize a Ram stream, although I really don't know if that's possible. I'm going to go play around with that for a bit.
Your software z-buffer approach is interesting. I've got some thoughts and questions that I'll toss around later, after I get some more tests in.