Compusphere was short but fun. They’d shortened it to sat-sun instead of fri-sun and will do another one in autumn instead. It was shorter for me because my demo was done and emailed to orgas at something like 7PM and I had a 2.5 hour drive to get there in time :) They made the most of it though, with a live fastcompo vs online participants in the middle of the night and drinking and talking until 3-4AM…
I sat next to Elfan who had flown over from England, he had his silly hat on as usual. Heh. Ziphoid had set up his booth and radioed out a Scenesat show from the party.
After some hardware trouble (2 sound channels, grr) I managed to show UTSonix on the bigscreen and I won the combined demo over a NES demo. I’ve managed to forget the name but I hope it will be on Pouet soon. 8-bit had no chance versus the might of 16-bit, so what can I say? Competition was none. :P
Hey wait, that’s not a Scoopex slogan. Hm.
About the fucking boing ball: It’s not some cheesy votegrab. I started drawing a spinning Elite-style UFO that would fly through the tunnel vertically, but it looked like shit. I couldn’t come up with anything else that would hunt a pixel in a tunnel, so I went with this.
Anyway. Now I’d like to whine like those poor pigs in the oven, about all kinds of things, because this one was a pain to code. Much of it is my own fault for being stubborn enough to finish stupidly conceived things that will never work. :)
To put it short, this demo is a perfect list of the worst possible decisions you can make in order to code an A500 demo. First of all, the player runs on tasks, which means you can’t forget about the system and use 100% of the CPU. If I used more than 40-60% CPU, it would lag the music. And of course I decided to use 6 bitplanes and overscan for every part, which leaves 25% of that to do the effects. Oh yeah, did I mention the playroutine loads a song and loose samples as files? Forget anything interesting while the OS jumps all over the disk.
But there’s more stupidity coming. I ran it on copper interrupts. Seemed like a good idea at the time, just swap copper and copperint and you have a flawless switch to another part! Not so fast… When some interrupts were enabled in the loader parts (basically, to allow loading. …) the high number of bitplanes could easily make a certain block-read start at the end of one frame and last for 1.5 frames, very efficiently blocking the copperint from running the modest task of just please change some bitplane ptrs and scroll registers please. This would cause a nice big CHOP in the smooth scroll. The solution was to disable ints with the copper right after trigger the copperint, and enable them at the end of the copperint, and to move the copperint trigger to the bottom of the raster.
On top of this, I decided to code this demo the “DevPac way”, that is be all system friendly with sections and tons of include file, instead of going ORG/LOAD and EXTERN until the final version. Let me tell you, compile times were… prohibitive.
This in turn forced me to go against my principles of coding only on A500 and use my A1700-060. (It’s A1200 in an A500 case to fit in the second memory module on the Apollo card.) I no longer had to wait 1.5 minutes to assemble (and if a branch was made longer, another re-assemble). Well, I can code compatibly, so all the parts worked perfectly right away and I could continue coding.
But I got the same gotcha that is the reason I recommend coding only on non-accelerated Amigas (or with frequent checks with accel turned off): you fool yourself into thinking you have more CPU time than you have. In my case, this was the reason I thought my optimized effects were optimized enough: the endpart fractals hadn’t consumed more than 50% CPU time average on A500 and so I didn’t have to optimize the scroll. WRONG. Anyway, what this leads to is to hacking something together and writing lots of finished code, and then when you find out you have to optimize, you have 1000 code lines of hacks to optimize instead of a nicely coded pretty much finished one.
Oh well, made me do my job really properly (anally) I guess. There is zero fat on any of the effects in the demo now. I almost screamed when the RGB tunnel part lagged on A500: “But I’m just doing 87 setpixels and filling a bitplane!!” :) Well, add the RGB fade/mapping, clearscreen and mirroring to the overscan halfbrite mode and it was enough to bring it to 50% raster left, which lagged the music.
The main part with the sprite scroll was started first of all, as a quick hack that would be the only screen of the musicdisk, and Uncle Tom would write some scrolltexts for me about each song and that would be that. But when I listened to the music, I wanted to make a few scenes to match what I heard in them. I couldn’t use any of my unreleased routines since they all maxed out CPU time and expected, nay, demanded a 3-scanline Protracker playroutine, so I had to code every single thing in this demo straight up and down from scratch.
In order for the parts to not look like barren, stripped down, badly coded effect I decided to add some graphics to look at. When there was room for new hit games on OCS, I was to code a game he made graphics for. I didn’t want to use up all gfx in case someone wants to have a go, so I just added a few anims that I liked. And this in turn demanded minimum 5 bitplanes.
And that’s how the parts ended up the way they are.
What started with me resourcing the Sonix playroutine for his tunes to work on all Amigas ended in a demo / musicdisk that really pushes no boundaries. But I hope you like it for its other qualities and that coders make something nice with the playroutine on faster Amigas. I really like the synth sound of Sonix and some AGA musicdisk with some synthy tunes would be awesome :)
At the end I had a world of trouble making WinUAE like crunched WO executables vs. intmasks that would allow loading and playing on all kickstarts (in WinUAE). There were random glitches that appeared rarely on misc. real Amigas due to the task vs copperint thingy.
I’ve already sworn not to touch other people’s sources/playroutines, or semi-system-friendly slash hardware banging coding, again.
And as I write this I know I will have to face file-loading-with-hardware-banging once again for the next release, a slideshow with a new gfx mode. Well, at least that’s inside my demo engine and just needs a textwriter and a trackloader for disk 2, so I hope I won’t have angst-attacks.
Til the next time… say the mantra: fame is just a release away… keeper of the light signs off.
/Photon