More Multicolour - Trailblazer Roadway

[Joefish]

Scrolling full-colour roadway at 50fps. Loads of time left in a frame. No sprite yet though. 128K machines only, not 48K.



Download TAP including source:
http://railtron.com/files/spectrum/Trailzz_05_Demo.zip

It uses 16-wide 8x1 multicolour for the top 24 pixel lines, then one last 16-wide multicolour line that stays up for two pixel rows. This gives time for the 29-wide 8x2 multicolour to start up for the remaining 38 pixel lines. If you just switch from 8x1 to 8x2 multicolour, there's an extra delay between the two routines you can't get rid of. So You have to make your last line of 8x1 multicolour actually last for two lines.

I know I haven't got the perspective depth of the tiles quite right. They're too big in the foreground and don't shrink down properly with distance. So they seem to 'pop' in size right at the front. Before adding a sprite, I'd need to track down all the places where the INK/PAPER could be inverted to favour the PAPER colour.

But if anyone else wants to meddle with it, the source is included. Just remember to give me a credit.

[DouglasReynholm]

Sounds great, can you put some sort of GIF showing it in action please? I think you'd get people even more interested if you could show it running. Thanks!

[Ast A. Moore]

Dang, that’s mighty impressive!

[Joefish]

I've not tried GIF recording from ZXSpin before. Seems like I have to set the border to full size, or the output isn't centred properly.
I have an animation package that can trim, rescale and optimise the recorded GIF, but it can't crop all frames to strip the border back down.

Anyway...



(And looks like I still have time to edit it into the original post!)

[Einar Saukas]

This looks great, good work!

I know I haven't got the perspective depth of the tiles quite right. They're too big in the foreground and don't shrink down properly with distance. So they seem to 'pop' in size right at the front.

Change the front part to suggest it's a conveyor belt. Then the back part "popping" will look perfectly natural.

Here's a rough sketch:

[uglifruit]

You do know you'd have been burnt at the stake if you'd written that in 1985.

[Joefish]

You do know you'd have been burnt at the stake if you'd written that in 1985.

And not for the first time!

[Ralf]

Very impressive!
(okay, only if you know Spectrum limitations )

Just please don't leave it as standalone effect.

If you don't feel like doing a full game with it, maybe do a demo (in demoscene meaning).
Add some scroll with greetings, some music, some bouncing ball and voila!

[Lethargeek]

i'm just hoping sprites won't look too ugly over this beauty

[Joefish]

i'm just hoping sprites won't look too ugly over this beauty

As I said, every single colour cell needs optimising (inverting yes/no) so that the PAPER colour always occupies the most pixels. Then you could add a sprite with fixed INK and transparent PAPER. And maybe make it smooth moving, but force it so it can only rest at whole character positions.

But that cell optimisation is weeks of work, which I don't have time for. Or maybe write more code to write the code!

[4thRock]

Could the effect be extended into the border ? The areas seem large enough for that.

[Joefish]

Could the effect be extended into the border ? The areas seem large enough for that.

Not smoothly. At the bottom of the screen they'd have to drop off straight down. You couldn't time the colour switches accurately enough for the tiles to keep growing wider. You could have rolling stripes in the side borders but the screen multicolour effect isn't wide enough to reach the borders.

[Ast A. Moore]

Could the effect be extended into the border ? The areas seem large enough for that.

Since you can’t use the inverted INK/PAPER trick in the border area, the minimum step for a color change in the border area is eight “pixels” (four T states). That, and the inability of the ULA to render bright colors in the border, makes extending the effect seamlessly into the border area impossible.