My little masterpiece

[Kylearan]

Hi,

long time no see - I hope all is well with you all. I see CIV is still going strong, which is nice. :-)

Since we've talked about the Atari VCS in this thread, I thought especially T-Hawk might be interested to hear that I've just released my first production: TIM1T, a demo for the oldskool competition at the Revision demo party (where I'm at right now). If you are interested, you can find the demo here:

Pouet page (direct download)

It's PAL only, sorry about that, and a YouTube capture will have to wait until I'm home again.

This was one of the main reasons I gradually faded out from this forum, as spare time is really scarce these days...

Anyway, I hope those who remember the Atari VCS 2600 might get a kick out of it. :-)

-Kylearan

[T-hawk]

Very nice. Love all the transition effects, very smooth.

I can see how the "watch 3 get one free" is done, the color bars using the playfield and the sine waves or twisty pillar using sprites on the same scanlines. That couldn't be done with the sine waves next to the twisty pillar, for instance. Only experienced 2600 coders would see that.

And I see you slipped in a recreation of Atarsi's checkerboard in the credits sequence. Now I see how it's done - even though there's six regions on a scanline, only four edges are needed to be covered by player/missile objects, since there's only five edges in the first place not six (fenceposting) and one stays unmoving at the screen center.

Is any of the plasma precalculated or is that all real time?

[Kylearan]

I'm back from the party and can answer now.

Very nice. Love all the transition effects, very smooth.

Thanks!

I can see how the "watch 3 get one free" is done, the color bars using the playfield and the sine waves or twisty pillar using sprites on the same scanlines. That couldn't be done with the sine waves next to the twisty pillar, for instance. Only experienced 2600 coders would see that.

Actually, it could have been done in principal. The sine waves use the missiles and the ball, and the twister the player objects. I change colors mid-line anyway.

The reason for the effect positions is different. The plasma bars and raster splits both use a one-line-kernel (otherwise it looks ugly), so I cannot calculate the twister and sine wave data on the fly. Instead, I have to pre-compute the HMOVE values for the sine waves and the index for the graphics and color of the twister each frame. But I have not enough RAM to store the values for both effects at the same time, so I need to compute the data for the lower effect after the upper effect has been displayed (hence the black region between the upper and lower effects). And finally, computing the twister is faster than computing the sine waves, so I pre-compute the sine waves during VBLANK and the twister between the effects, so the black region doesn't get too large. So the twister has to be on the bottom, and the waves on top.

That took quite some elaborate pre-planning and testing...

And I see you slipped in a recreation of Atarsi's checkerboard in the credits sequence. Now I see how it's done - even though there's six regions on a scanline, only four edges are needed to be covered by player/missile objects, since there's only five edges in the first place not six (fenceposting) and one stays unmoving at the screen center.

Yep. Score mode gives us one free color change in the middle, and with a two-line kernel and some precomputation in VBLANK there's enough time to update HMMx and ENAMx values (missiles have to be hidden once they get too far left/right) while changing COLUBK twice each scanline.

Originally I didn't want to simply recreate the effect but display a much better-looking screen with it (up to three boards on the screen at the same time, rotating in and out of the screen - hard to describe), but I ran out of time. After two days and nights of straight coding, I was exhausted and then the deadline was there. Ah well.

Is any of the plasma precalculated or is that all real time?

It's a 9x11 plasma at its core. The color for each cell gets pre-calculated during VBLANK and overscan, using 99 bytes of RAM. During display itself I cannot do much, as fetching and storing 9 colors per scanline already eats up most cycles, and I also have to switch VBLANK on and off each scanline to be able to hide the background to the left and right of the plasma so I can pre-load four colors each line, thus making it possible for each cell only to be 8 pixels wide until the beam catches up with me. (I have to use color values for switching VBLANK on and off; that's the reason why two columns are a bit lighter/darker than the rest, as bit #1 of the color has to be set/clear).

In case you are interested, there's a technical write-up for each effect in the demo's info-file. I couldn't leave my old Realms Beyond past behind and just *had* to write a report.

[T-hawk]

Aha, I didn't notice that writeup in the zip. Just assumed a .nfo was a "thanks for downloading blah blah blah our gr0up rul3z" type of deal.

So the demo is named as a palindrome in order to display its name with a reflected playfield. That's thinking outside the box indeed. Shows how far reaching the constraints on the 2600 can be.

Yes I'm familiar with the difficulty of handover between kernel sections as in your logo build-up. One slip up on timing and the whole screen jumps. One of my games had to do this in the middle of still updating a player sprite, so I ended up with 11 different versions of that code based on that sprite's horizontal position, to get all the instructions in the right order for all the cases.

I caught the y-fighting flicker on the starfield and knew exactly what was going on there. I didn't realize it was truly 3d calculated and projected though, since it's pretty easy to fake a 3d starfield with just XY coordinates and velocities.

Wow, I had forgotten score mode for the playfield colors existed. Games hardly ever want half of the screen in a different color, but yup that's exactly what a demo might do.

What are the standards for 2600 demo coding? Are you allowed to use Superchip or Supercharger RAM? I see you have a 16k ROM, what bankswitching scheme is it?

[Kylearan]

Yes I'm familiar with the difficulty of handover between kernel sections as in your logo build-up. One slip up on timing and the whole screen jumps. One of my games had to do this in the middle of still updating a player sprite, so I ended up with 11 different versions of that code based on that sprite's horizontal position, to get all the instructions in the right order for all the cases.

Hehe, nice.

What are the standards for 2600 demo coding? Are you allowed to use Superchip or Supercharger RAM? I see you have a 16k ROM, what bankswitching scheme is it?

My demo is actually a 32k ROM, with F4 bankswitching.

There are no clear rules - until two years or so ago, people only made 4K demos, thinking that would be closest to the original spirit. My demo is only the fourth 32k demo (after Atarsi, Ataventure and Bang!), and I chose that size because I think more graphics, music and variety is needed to bring the VCS demo scene forward and keep it interesting.

Up until Revision, noone used extra RAM. The winning demo, Bang! by Xayax, did - but didn't tell the audience, which I found unfair. Extra RAM in itself is no problem since games back then used that as well, but the voters should know about it. But then Bang! also actively abused nostalgia (an Amiga ball and a C64 part), boobs, and promised free beer in the demo (and delivered during the compo), so they really, desperately wanted to win.

You could always come back to the VCS and do a demo yourself (or in coop) - I'm sure you're capable of impressing the scene, and we always need more active people...