Tuesday, November 07, 2006

XeO3: The Sprite Cache.

I finally got around to visualising the sprite cache, and in doing so I was in for a shock. It wasn't working! Well, not the way I'd planned. When I originally designed it, I had intended for sprites that were used a lot to stay in the cache, so I'd used a doubly linked list so that I could unlink and entry and place it at the bottom. This would then keep it as far from the TOP (which is the next free slot) as possible. Its a simple idea that works extremely well when used with textures on the PC. However, mine wasn't working - in fact, all that was happening was I was operating a simple queue system. It came off the front, and went on the rear. This means that when enough baddies have passed, I have to recache the graphics that are still in use - like the player ship. This wasn't the idea at all!

So, I added the missing code to push it down to the bottom of the stack where it would stay until it hadn't been used in ages and then it would get freed and used again. However...being a ful 16bit doubly linked list - it isn't quick, and sprite engine takes a hammering because of it; way too much in fact. So now I'm left wondering if I should in fact scrap this idea, and just use a simple queue. This would help speed up allocations, but I'd still have the same issues I have now - which you don't really notice anyway!

I'm just not sure.... the whole concept of the sprite system came about because I wanted to use the texture cache idea to help keep things fast, and now thats the code thats slowing it all down!

Bugger.....

6 comments:

Anonymous said...

Regarding the sale of the game on disk... would it be possible to sell the disk with the C64 version on one side and the Plus/4 version on the other? Or will the game be too big for that?

Regards,

Shaun.

Mike said...

Well, we haven't decided if wer're even going to sell them yet - we have no real numbers on it to see if its even worth while.

Also I suspect the C64 version will be finished some time after the +4 version.... Remember the +4 version has taken 6 years so far!

luca said...

Omg Mike, don't spread fear among the audience! :D

Mike said...

Well...okay, the C64 version won't take 6 moreyears, but my point was that it could take a while longer, and I don't want to delay a +4 release as we wait on a C64 version.

Anonymous said...

How many cached sprites you have? Using indexes instead of pointers cuts remove();addtail() to 47 cycles unless I forgot something. That limits the system to 255 sprites tho, and forces you to do table lookup to get real address of sprite.

It might be possible to cut some of those 47 cycles away if you just want the most recently used sprite set at the end of list without exact order.

Linked lists with real pointers would be so much easier with Z80 and three register pairs... :)

--
TNT

Mike said...

Yeah, Russell and I came to the same conclusion at lunchtime when we were speaking about it.

I'm about to write a bit more about it :)