Plasma Effect

[sixxie]

Sure - outside the main loop it has no real effect on speed. Added.

[sorchard]

Love this plasma effect guys - great job!

I've done some cooking of my own for even more speed The additions in the inner loop can be removed by manipulating the table pointers before each line. The tables have to be doubled up but it's worth it for the speed boost. Just wondering where best to send the modified source as I'm not being allowed to attach files...

It's been a while since I've done anything Dragon related. I've got a load of stuff in the loft that I'll have to go through at some point to see if there's anything not in the archive.

[rolfmichelsen]

Welcome aboard. You're now a full member of the forum. You should be able to attach files now.

-- Rolf

[sorchard]

Cheers!

I think I must be doing something wrong. So far I've been refused to attach .s, .bin and .txt files. Off to the FAQ I go...

[sixxie]

I'm not sure what files the forum accepts... Good idea, though!

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

Can probably do the same to the use of the Y reg (edit: done)...

[admin]

Its been that long - even I can't remember what file formats are allowed. Put them in a ZIP file is probably the safest way to attach them.

[sixxie]

That optimisation makes it fast enough to remove the "cheat" which guessed the next colour, and still complete an (interlaced) update in less than 3 frames! Nice!

So I'm guessing there can't be that many S. Orchards around - are you perhaps the author of one of my all time favourite games?

[sorchard]

Yep, that kind of thing. As you point out, the same thing can be done with the y reg to get rid of the addb #2 which in turn means the t41 line can be moved out.

Other observations:

I redeclared the pos and neg halves of each table as macros just to make it easier to specify the doubled up tables, though in a demo setting it would probably be more space efficient to generate the expanded tables on demand.

The p3/t3 bit of code at the top of y1loop can be moved outside the loop because t3 doesn't change during the loop.

The sine table amplitude can be increased to 41 without overflow.

A new table could be precalculated so that the source bytes are stored consecutively allowing two source bytes to be loaded at a time. The downside would be the animation would lose a bit of variety as a result because there are no longer any 'in-between' positions for t41 to explore.

It might also be fun to explore how well it could be made to work with a single lookup table i.e. have a precalculated table of colours that already follow a sine function. This could be made to run a lot faster.

I must admit this has been a bit of an eye-opener for me. It never occurred to me before that demoscene code could be so accessible. I'm now intrigued as to what else might be possible...

xroar is utterly brilliant by the way! I had a play with hsyncs and was impressed to see the two 'holes' where the PAL circuitry kicks in.

Ah. I managed to attach a zip with the modified source. Apologies if my windows setup has mutilated the tabs and LFs!

Yep, I'm afraid I wrote Balldozer & ROTABB. Wish I had my additional quarter-century of programming experience back then and I might have done a better job Glad you got some enjoyment though!

Edit: Attached new source and binary. Experimental 50fps version.

[simon]

see.. this makes me happy happy happy !!!!

I knew my c64 background in demos would prove useful on the coco/dragon....

cheers guys !!

/Simon Jonassen

[simon]

what i will do "though" is point you all to an error that wasn't part of the original code.....

alot of ppl won't notice it as it runs fast and looks nice...

but if you study the attached file, you can see that the LSB/MSB should be swapped in certain situations.....

ok.... sixxie sorted that out.......

/Simon Jonassen

the MSB/LSB is swapped !!!

error.jpg (364.54 KiB) Viewed 6611 times