Mmm...Now it gets interesting! Now that the cache routine is working properly, I can finally visualise it and see how much is used, and how it behaves... It's showing that its actually got a little room to spare - which is great as it means I can always steal some if I need to - however, that little function below that makes the cache work takes around 50+ cycles per sprite per game cycle for normal usage. That is when its not at the end or whatever... Thats 10 scanlines at least! Everygame cycle! (when all sprites are active)
so once again... its down to a balancing act - do we use the cache and perhaps get a couple of K back...or do we ditch it and gain 10 scanlines? Of course theres also an additional penalty of having to rotate the player ship everynow and then if we dont use the cache properly, and it could come at anytime, where as the cache is reasonably predictable.
It's never easy.....I suspect the cache will stay as 10 scanlines is less than rotating 1 sprite, and if I dont overload the screen with NEW sprites, I can be sure that it wont rotate + the full 10 scanlines at anyone time. I'll have a think....perhaps theres an even quicker way of doing this....
8 comments:
You could have first N cache entries reserved for player sprite, but without testing it's hard to know how that affects the rest of cache.
Another idea is to add preload codes to levels - that way you could rotate some of the new bad guys into the cache between attack waves when there's a bit more time.
--
TNT
Possibly.... With the cache working, I shouldn't have to save any for the player as it pretty natural for him to stay in the cache.
And the whole idea is that I only rotate "bits" of sprites. For example, if a sprite is moving over the screen from right to left, and animating through (say) 10 frames, then I'll simply never get certain frames in certain rotations because the don't come up. This saves loads of cache space. Otherwise 10frames*4 rotations = 40 slots.
I put "without testing" there just to get away from the idea if you say it won't work ;)
With preloading I meant levels having a hint system where you can create *actually needed* sprites in advance. With predictable enemy movement you can check for tight spots and create some of the sprites half a second earlier. That leads to more predictable CPU usage.
Hints can only be added at the last minute of level design tho - you don't want to change hints every time you adjust enemy attack patterns.
--
TNT
Yep, I know what you mean about hints.... My main problem with it isn't the HINT system, but without knowing WHAT to cache, you'll end up caching way to much.
For example. If I hint that baddie 5 is about to come on, then without knowing its path, I cant know that I need frame 1 in rotation 2,1 and 3, frame 2 in rotation 4 and frame 3 in rotation 1. I'd have to rotate them all. And the problem with that is not that the CPU idle anyway so why not, but that it pushes out useful baddies cached there already.
If I could figure a way out of that without pushing useful data out, I'd probably use it.
If your enemies follow predefined pattern and appear at specific points then you *do* know which rotations are used. In that case I would do a special version with front end or something else removed, then let the game scroll through a level and build a table telling where enemy sprite are created and which sprite rotations they are.
In a real game you have plenty of other sprites to keep in cache, but you are guaranteed to have to build at least those sprites noted in the above table. It might be useful to use smaller cache size for the scroll-through to compensate for lacking explosions etc. which will push out baddies during game.
If your enemies follow player in x-direction then you can't use hints, but for seeking missiles for example you might only need y movement.
--
TNT
wow...that sounds like way too much work! :)
Too much data as well I think. I only have 3k for scripts, and I expect it to be pretty full. That aside, I'm not a bit fan of having a tool like that really. it might help a bit, but its a lot of work for very little gain.
See, when a wave comes on they will tend to come on one at a time, and because of this, its a low CPU load at that point anyway, so the inital sprites are cached when its not that busy. By the time it IS busy, you've cached most of the graphics you need (as in general sprites followng follow the same path as the 1st one).
I suspect thats a lesson for the reader, I think thats too much effort for me - I just dont think I'll get back the size of reward I'd expect. :)
Yes, that's something you avoid if you can, but helps if you run out of time in the end. Having unused speed-up methods in your arsenal never hurts :)
I wouldn't mind reading a blog entry on your script system. I tried to write one "back then" and didn't find satisfactory compromise between flexibility, efficiency and compactness.
(Don't let that keep you away from weapons system tho - Luca will kill me if I delay that any longer ;)
--
TNT
lol - he's been waiting on a script document for about a year now :)
I'll write something up, its pretty basic - but only once you know....
Post a Comment