pouët.net

totally awesome! this one really rulez :)

it rocks! :)

are every such simple effect so impressive in 256 bytes, or is it so difficult to do such an effect in 256 bytes on a C64 ?

no offense, i'm just wondering ... a fire effect is really a simple effect, and can be done in much less than 256 bytes, but as i did it only on PC i don't know how hard it is on C64 ...

it's much more compilcated on c64 to do the graphics output than on a pc (AFAIK)

btw, show us your pc fire effect in less than 256b :)

haskell wtf? why would anyone need/use haskell for a simple fire effect??? why would anyone use haskell (except for icfp :P) in the first place? :)

otherwise i second cyraxx in my lack of knowledge regarding c64 size optimisation.

shiva: jazzman is a haskell freak :))

Hum, perhaps some more informations could be interesting. The nfo say nothing for instance about how to execute a "prg" file. Since I never use a C64 in my whole life (well, play some game on it, but it's never me that have to type the run/list/whatever/*""*" commands), so by indicating nothing about running that demo you seriously reduce the possible audience.
Also note that in the 256b pc demo scene there is a tradition => source code is often included with the executable to show to the world wide how you code is tiny, smart and marvelous :)

flure/cyraxx: it is definitely more difficult to achieve a similar effect in the same amount of bytes on the C64 than on the PC. the assembler instructions are just way less powerful. consider that the 6510 is a 8-bit processor, but has to work on memory ranges far larger than 8 bit (text buffer 1000 bytes, character map up to 2048 bytes, ...).

shiva: i use haskell merely as an intelligent macro assembler. it simplifies many tasks, for example compiling graphics into custom code.

Dbug: if you don't have a C64 handy, you can run it in a simulator - I use vice. just start x64.exe, then "autostart disk/tape image", select fire.prg and it runs!

(whoa, every second comment here is by me ;)

there are lots of pc <= 256byte fire effects. for example, look at http://www.df.lth.se/~john_e/small/fire/fire.html, which contains several version of a 128byte and smaller fire effect.

here on pouet, there's even a 33bytes fire effect... http://www.pouet.net/prod.php?which=4786.

So yes, you can make a fire a lot smaller on PC :) Can't judge the C64 code tho.

Ok, it's running fine. But now I need some technical information to evaluate the performance. What exactly is this graphic mode ? It looks too fine for beeing a kind of text mode, but too grainy for beeing graphics, what's this exactly ?

dbug, it's multicolor text mode (4*8 pixel characters) with user defined characters. i spent more than 100 bytes on the character generation...

and if by performance you mean speed - the demo isn't really optimized for speed at all. it was fast enough from the beginning, so i didn't need to tweak it :)

"btw, show us your pc fire effect in less than 256b :)"

Have a look at 'ansi fire', a nice looking ansimation in 64 bytes. :)

blah blah, believe it or not : my washing
maching take only 12 machine cycle to
complete a wash.

sheesh, ostyl... how did you do that? are you using hand optimized rotation code? how many colors does the laundry have? is the engine overclocked? how many megaperls? do you use water cooling?

This is great! good work i really liked it

Yep, well I have also a fire effect in text mode on my oric, but it was not coded for size, it was mostly a test bed for my pseudo colored text mode, so I will have a try to this one day.

One last question: how much bytes are wasted in the C64 prg format ? On the Oric we have a minmum of 16 bytes in a TAP file.
(synchro, filename, start and end adress, file type, ...)

.prg wastes two bytes (load address) plus a minimal basic program (11 bytes IIRC). the basic program definitely needs to be counted, but i'm not sure whether the load address should be. if not, fire is 254 bytes rather than 256.

i even wasted 11 more bytes in the basic program... type "list" and you know what i mean :)

now that i understand a little that it's hard to do a 256b effect on a C64, i can give it a thumb up :)

by the way, DBug, are there any Linux Oric emulators out there ?

thanks, flure ;)

Jazz: yep, all single bytes required to get the program working from the storage device have to be counted. Why do you need a 11 byte basic program ? You cannot directly load the assembly code ?

Flure: Yep, there a linux version of Euphoric, but it's lagging behind the windows version so I do not know if it's capable to run the demo, but well I don't know of any reason for this anyway :) => http://oric.free.fr/emulator.html

dbug: i could save the pure assembly part, but then you couldn't just "load" and "run" it, but had to load it with ",8,1" and execute a command like "sys 10000".

the basic program doesn't make a real size difference for 1k or above, but for 256b or 128b it is noticeable. since there are no other c64 256 byte demos yet, the question whether pure assembly is ok still awaits to be debated :)

We just released the 125-byte successor to this: glow.

Wow, that many comments on such a small demo.

Anyway, in my humble opinion the two load address bytes should not be counted, as only the real executable data counts. As far as I know, the 4k rules at Mekka don't consider those two bytes to be counted, either.

I do think the basic portion is needed. Just load+run, better than fiddling around with sys commands.

Something big at MS03? Bin ja gespannt wie'n Kreuzbogen.

i think it could be easier to fit something on c64.. cause of 16 bit addressing, cause instructions are less powerful, yes but they take less bytes too.. ofcourse you have to set up some VIC registers but might be even more to do on PC.. who knows.

but looks nice!

okay so you might want to check another 256b c64 fire effect, it's on http://www.pouet.net/prod.php?which=7071 and it dates back in 1997, so it's the real first fire in 256b on c64 har har!

jazzman: no, i use a special wash algorithm
called SKIP-ENGINE

this is cool.

absolutely wonderful looking =))