archive.worldofdragon.org

sixxie wrote:Something like this? http://www.6809.org.uk/tmp/plasma-new.s

Nicely done sir! Self modding code on the pointers has really streamlined it.

Now all we need to do is pull another optimisation out the bag and double the speed again

well now stew....

if we want any more speed out of this baby, we are gonna have to unroll it even further....

in which case we lose the DP, question is, will the increased speed be better than a "semi unrolled" looped DP routine......

well, on the c64 we had a tendancy to unroll the whole thing....... so MAYBE we can gain more speed yet.....

/Simon

I have some ideas that probably work better in my head than in reality

I was thinking some data could be precalculated to allow one level of lookup to be removed, but I suspect the resulting animation won't be as complex. It might be useful for something though. I don't wish to abuse the board by posting loads of half baked code so I'll PM you some source if I can figure it out. (Plus anyone else who's interested)

well.... post away....

alot of stuff could probably be precalced to reduce the overhead.....

/Simon

You can anyway update your old posts with new attachments.

Thanks tormod, I'm such a n00b.

I've now updated the attachment to my earlier post. There is a new source and Dragon binary that updates at 50fps. The animation isn't as varied as the original but there might be a parameter tweak in there somewhere that gives a better effect.

The screen drawing routine might find some other uses as it hurls lines at the screen at a fairly respectable rate.

Certainly nice & fast - the pattern is a bit predictable though as you say.

Sort of thing you could get away with in a larger demo by showing it for a short bit then cutting away - maybe use a different precalc table when you come back to it... Showing for too long would let the viewer realise what's up

I noticed (edit: after SJ pretty much pointed it out two days ago - d'oh!) that the offsets into coltab were the same each line, so now I precalculate those each frame. Pulls a full update down to less than 2 PAL frames (still a touch over 2 NTSC frames though sadly, so it'll be slower on those machines).

Edit: scratch that. By directly storing the offsets as 8-bit indexes, that's down to less than 2 NTSC frames now, too.

That's just pure genius. You only use your powers for good, right?

Hah, actually I think Simon pointed out this exact possibility on IRC previously - so all credit to him! Took me a while to realise it would actually work, obviously