Dogma demomaking
category: general [glöplog]
i'm a stay-at-home-dad so, not interested, sorry
Slow and innefficient workflow is the least of my worries when coding a demo.
Type to think ratio is strongly biased towards the latter. =)
Type to think ratio is strongly biased towards the latter. =)
Get a presentation of my super efficient Dogma level 2 toolchain at Evoke, inshallah!
Quote:
Everyone pointing out crossdev isn't new, can only cite games as examples. Did anyone do crossdevelopment of demos in the old days?
I've felt personally the crossdev attitude can get out of hand, as I try to find faster and more effective ways of compiling and producing. It only lead to burnout and boredom eventually.
With a build cycle of less than second, coding can become a matter "didn't work, I change this a bit, didn't work, change again, didn't work, change, oh now it works" rather than thinking it properly through and getting into the actual hardware.
The dogma might be a useful exercise for personal sanity, like a musician throwing away the omnipotent DAW and going to non-computerized synths, building modulars and analog sequencer etc.
I suspect the demos that would come out of this attitude might be different. Maybe smaller and with less content!
But perhaps it shouldn't be too "dogmatic", not a specific category or a debate of "is this really a dogma demo or not?"
There is another huge angle for cross-development. If the language used is c/c++, and the project also compiles for another platform like windows. imagine debugging something in visual studio, that then cross-compiles and runs on the target platform huge amounts of bug finding, fixing and huge parts of dev can be done in a modern environment.
VBCC can do this for Amiga now. It's out there documented.
Dogma level 1 should be
- cross compile
- run in winuae/winfellow
(so solely PC based)
Dogma level 2
- cross compile
- run on targeted emulation A500 mini / A600 GS / Raspberry Pi with PiMiga or another distro
(and the just announced A500 maxi coming Q1 2025 which may really pique some peoples interest)
THEN add the restrictions incrementally for higher levels.
dogma 3 -> old dogma 1
dogma 4 -> old dogma 2
dogma 5 / 5.4 -> old dogma 3 / 3.5
which brings me to..
dogma 6.. or should it be 68K?
68k asm only.
Banter aside.
I fully understand the arguments for dogma, but also all these modern advances and routes to emulate are opening the door for nostalgic types to "have a go" and getting more involved with commercially dead platforms. Gatekeeping never helps anyone.
dogma level 7: build the fucking computer yourself
Dogma Level 3 - The art of Party Coding!
Dogma level 100:
You wake up naked in middle of desert. You have no idea who, when or where you are. There is a mysterious tattoo in your left arm "YOUR MEMORY HAS BEEN WIPED. MAKE A DEMO ABOUT IT."
You wake up naked in middle of desert. You have no idea who, when or where you are. There is a mysterious tattoo in your left arm "YOUR MEMORY HAS BEEN WIPED. MAKE A DEMO ABOUT IT."
But I guess a demo could advertise Dogma level 1/2/3 as a way of fishing votes/respect. There are various other methods, such as the (mostly PC-made) demos listing A500 specs at the start of every demo. What a surprise to see an A500 demo in an A500 demo competition(!) :)
I don't think that's quite true. It depends on if the demo or scene idea grows from the coder experimenting, or from design/scripting. Sometimes, code ideas (based on cells, geometry, logic or math) start and are made clear on grid paper before the first code line is written.
Fast iteration can help keeping the code changes in (human) memory as you sculpt the approach, which cuts down on the need to debug.
This is also why coders on A500 learned to do fast iteration using only 1MB and 1-2 floppy drives. By using available memory instead of allocating it, and the EXTERN command instead of INCBIN, and by including sub-sources instead of INCLUDEing them, a demo part would assemble and run in 2-3 seconds - no loading of any file needed, everything in RAM. This mostly only applies to the Seka and later Assembler variants.
Accelerated Amigas with harddisk are 100 times faster, which means it assembles and starts even faster, even if some files are included.
So, a PC is not a requirement for fast iteration, and coding on an A500 with floppy doesn't need to be a handicap, but can be blazingly fast.
I also very much like the directness of coding on a real Amiga, knowing that the timing and behavior of the hardware will be exactly as designed, whether or not I write illegal values in the memory or hardware registers.
One advantage of this directness is that there is no extra clicking, switching windows, or typing the name of a script in a terminal window to start the program.
~
Regarding dogma or extra rules: For me, it's more about what type of idea I want to create. Normally, I want to write something dynamic and real-time, and this means I avoid most of the temptations that can also come with a PC tool chain: sloppy graphics conversions, replaying datalumps, and not optimizing but relying on a PC cruncher to fix it.
I also think a demo can be great and very unoptimized and free of technical extra rules, such as these dogma rules or artificial limitations. It depends on if it's dynamic, enjoyable, entertaining, or shows something technically proficient running, i.e. not necessarily technically proficiently built or built using certain tools or rules.
This goes for the datalump replay demos also, but they are rarely dynamic, and there is then not much for me to enjoy in them. I mostly ignore them, unless they perpetrate something particularly egregious or cynical. And I don't hang much anywhere these days, rightfully or wrongfully blaming time. Cheers anyway. :)
Quote:
Fast iteration enables content that would not otherwise be feasible.
I don't think that's quite true. It depends on if the demo or scene idea grows from the coder experimenting, or from design/scripting. Sometimes, code ideas (based on cells, geometry, logic or math) start and are made clear on grid paper before the first code line is written.
Fast iteration can help keeping the code changes in (human) memory as you sculpt the approach, which cuts down on the need to debug.
This is also why coders on A500 learned to do fast iteration using only 1MB and 1-2 floppy drives. By using available memory instead of allocating it, and the EXTERN command instead of INCBIN, and by including sub-sources instead of INCLUDEing them, a demo part would assemble and run in 2-3 seconds - no loading of any file needed, everything in RAM. This mostly only applies to the Seka and later Assembler variants.
Accelerated Amigas with harddisk are 100 times faster, which means it assembles and starts even faster, even if some files are included.
So, a PC is not a requirement for fast iteration, and coding on an A500 with floppy doesn't need to be a handicap, but can be blazingly fast.
I also very much like the directness of coding on a real Amiga, knowing that the timing and behavior of the hardware will be exactly as designed, whether or not I write illegal values in the memory or hardware registers.
One advantage of this directness is that there is no extra clicking, switching windows, or typing the name of a script in a terminal window to start the program.
~
Regarding dogma or extra rules: For me, it's more about what type of idea I want to create. Normally, I want to write something dynamic and real-time, and this means I avoid most of the temptations that can also come with a PC tool chain: sloppy graphics conversions, replaying datalumps, and not optimizing but relying on a PC cruncher to fix it.
I also think a demo can be great and very unoptimized and free of technical extra rules, such as these dogma rules or artificial limitations. It depends on if it's dynamic, enjoyable, entertaining, or shows something technically proficient running, i.e. not necessarily technically proficiently built or built using certain tools or rules.
This goes for the datalump replay demos also, but they are rarely dynamic, and there is then not much for me to enjoy in them. I mostly ignore them, unless they perpetrate something particularly egregious or cynical. And I don't hang much anywhere these days, rightfully or wrongfully blaming time. Cheers anyway. :)
Quote:
But I guess a demo could advertise Dogma level 1/2/3 as a way of fishing votes/respect.
Ironic, I thought these days thats *exactly* the fucking point :/
Rather than make what you want, make what the *public* wants instead. For votes. Since apparently thats all that matters. Engagement, likes, votes, fame, fortune, etc.
The .produkkt will forcibly make you happy. >_>
Quote:
Dogma level 100:
You wake up naked in middle of desert. You have no idea who, when or where you are. There is a mysterious tattoo in your left arm "YOUR MEMORY HAS BEEN WIPED. MAKE A DEMO ABOUT IT."
That sounds like a plot coming straight out of a B-Movie. /shrug
If I should choose a dogma for C64 demos it should be:
- No animations
- No effects based on bitmap colorcycling
Since both are boring, have been seen 384790231487 times and take up a lot of disk space, causing long loading times.
- No animations
- No effects based on bitmap colorcycling
Since both are boring, have been seen 384790231487 times and take up a lot of disk space, causing long loading times.
I thought dogma demomaking was about constraining the IDE (toolchain hardware+software) not about proscribing certain kinds of content.
Quote:
Did anyone do crossdevelopment of demos in the old days?
Of course. Censor used Amigas for C64 stuff. X-Ample used PC (PDS). The Dreams used PC (their own assembler). Taboo used PC (their own assembler). There was a popular version of TASS that worked from one C64 to another C64. There were a dozen different tools just to transfer a binary from PC to C64 and then execute it. Fairlight had an entire Website dedicated to it (ok that was a bit later, mid 90s)
I'd say everyone who could afford the setup was doing it at some point, although there were also always some people who would cry out loud and call them lamers for doing it :)
