After yesterdays head-banging moment, I sorted out exactly what I'd need to do in order to get a proper double buffered star field. Then after groaning inwardly at the effort involved just to get a bloody star field running, I slapped myself hard across the face with a virtual fish - and got on with it. I now needed another two 100 byte tables (CPU built, so theres stack of memory for that), 4 star routines in total (2 to draw, 2 to clear - ouch!), but could reduce the size of my logo drawing code to almost nothing - much better.
So...What does the new Star code do? Well, picking up from yesterday... It now copies the current index into a SAVE_STAR table (2 of these, 1 fro each frame), checks to see if it can draw a star at the desired location, and then draws the correct character, and colours it with a random colour (multicoloured stars are much nicer than depth queued gray ones) at the same time making sure its in HIRES mode (top half of the screen is in MCM mode). This is fine... Now comes the really annoying part. To wipe them, I read from one of the SAVE_STAR tables, check to see if a star is actually there, and if so wipe it. I dont need to wipe the colour, as theres nothing else going to go there.
Now for 360 stars, this is horrible, much slower than clearing screen and blasting it on. However.... for the original 100 stars, its much faster. So...strike a little bit of a middle ground (240 stars or less - undecided just yet), and the fact I no longer have to continually draw the text and the logo, means I win out over all. So the original idea wasn't that dumb after all, and while I may actually be as stupid as I look, at least this time I get to keep my head firmly attached to my shoulders - but theres always tomorrow.
6 comments:
I too nicked Delta star routine (more than 18 years ago!) and used it in my first "real" demo. After reading your rant I re-wrote it and managed to get ~50*4 stars done in the border area. I don't rewrite colors all the time, but have a routine to change colormap randomly if there is no need to do actual char plotting.
It dawned on me that if you have two sets of stars which move at the same speed, but are 4 pixels apart in x direction, you can cut maximum screen update time to half. Total time is still the same, but it's spread over two frames. Code can be self-modified so it won't double the space requirement.
--
TNT
Ooops... 50*4 stars on C64, plus/4 can surely handle more :)
--
TNT
Proof-of-concept code for C64 here with source. 352 stars, doesn't touch chars < $f0, needs <112 lines.
--
TNT
That's a bit too regular for my liking. needs to be more random, and have a few more layers... More doesn't always mean better.
:)
If you look how stars are placed you see why they are so regular. This was written just to see if the idea works.
More layers can be added easily, only thing is that with two separate layers per depth it soon eats away all your chars. For 3 different speeds you need 2^(2*3)= 64 chars, 4 speeds eats whole charset :(
--
TNT
3 layers, 288 random stars :)
To save chars the front stars use only one layer, so 32 chars are used in total. As this was a quick hack front layer doesn't use the same routine as others, but that could be done quite easily.
"More doesn't always mean better."
Faster usually means better, unless it's much bigger :)
--
TNT
Post a Comment