Jump! (Amiga Yoomp)

[Juz400]

Originally Posted by Kefir

Yes, it's a great game. There are a number of differences compared to the Atari version of Yoomp but the idea of synchronizing music with the ball movement is perfect and I'm going to do it in the same way. Soundtrack will be created especially for the Amiga version and will be a bit faster due to the faster pace of the game compared to the Atari.

It took me a little while to notice, then I thought `Is that ball bouncing with the kick drum? IT IS!`
Its touches like this that add a real shine to finished product!


Roll(or bounce) on 2020


(CD32 with TF330)

[Cyprian]

Kefir, what about technical details? Do you pregenerate frames in FastRam or do it on the fly?

[aros-sg]

Originally Posted by Cyprian

Kefir, what about technical details?

It's surely "just" pre rendered tunnel animation for each possible tile. So there's one prerenderd animation of tunnel which uses only tile #1. Then there's antoher prerendered animation of tunnel which uses only tile #2. Then there's another prerendered animation of tunnel which only tile #3. etc.

Additionally you need masks for each frame of animaton for each tile position in the tunnel.

Then each frame just mask blit together pieces from various tunnel animations.

Maybe some of the prerendered tunnel animations are only half size vertically as they are symmetric and can be flipped while blitting.

[aros-sg]

Then each frame just mask blit together pieces from various tunnel animations..

Optimization to this would be to find out the best possible order in which to blit the tunnel tiles, because if you do it correctly some may be blitted with standard copy, not masked copy.


Simple example: you could first blit all the tiles which lie at 12 o'clock and 6 o'clock without mask.

[Solo Kazuki]

Originally Posted by aros-sg

It's surely "just" pre rendered tunnel animation...

Someone on PPA try to guess how it's done and said about pre-rendering. According what author (Kefir) answer him, tunnel is not pre-rendered but real time calculated, that's why it needs 68020 and Fast RAM.

[aros-sg]

Originally Posted by Solo Kazuki

According what author (Kefir) answer him, tunnel is not pre-rendered but real time calculated, that's why it needs 68020 and Fast RAM.

Hmm .. no idea how cpu intensive that is, but looking at video it seems there are only few colors for the tiles if one ignores shading/raytracing look. So it could be rendered in maybe 3 bitplanes only, and the shading/raytracing look is added/overlayed ~automatically (no cpu/blitter time) with 4 other bitplanes with a fixed prerendered shading animation (in video it does not look like that shading is "fixed" single frame).

(4, not 5, because part of palette for boing ball sprite required)

[clebin]

Wow, this looks stunning. Can't wait to play it. Good work!

[Tigerskunk]

In which ever way Kefir has done it, it looks amazing!

Wow..

[grond]

Originally Posted by Solo Kazuki

According what author (Kefir) answer him, tunnel is not pre-rendered but real time calculated, that's why it needs 68020 and Fast RAM.

I would assume it uses a large LUT that basically maps screen coordinates into polar tile coordinates like all those rotator and tunnel effects in the demos do. Add a constant offset that changes per frame and you "move" through the tunnel. Add a constant offset per frame and you rotate the tunnel. Then do c2p with no more than four bitplanes. The other bitplanes are constant or looped animation for lighting and background.

It is very well executed and looks very nice.

[DanScott]

Originally Posted by grond

I would assume it uses a large LUT that basically maps screen coordinates into polar tile coordinates like all those rotator and tunnel effects in the demos do. Add a constant offset that changes per frame and you "move" through the tunnel. Add a constant offset per frame and you rotate the tunnel. Then do c2p with no more than four bitplanes. The other bitplanes are constant or looped animation for lighting and background.

It is very well executed and looks very nice.

A1200 with 4mb fast ram can't do C2P that quick for 1x1 pixel resolution (as seen in the video)

[britelite]

Originally Posted by grond

I would assume it uses a large LUT that basically maps screen coordinates into polar tile coordinates like all those rotator and tunnel effects in the demos do. Add a constant offset that changes per frame and you "move" through the tunnel. Add a constant offset per frame and you rotate the tunnel. Then do c2p with no more than four bitplanes. The other bitplanes are constant or looped animation for lighting and background.

I would guess something like this, except not using a c2p.

Basically a looping 4 plane animation with all bricks visible, then a few planes of overlay to black out or change the colors of the bricks (and one bitplane for those single color icons on top of the bricks).
There's quite a few ways of doing the overlay, and wouldn't necessarily require a c2p.

[grond]

Originally Posted by DanScott

A1200 with 4mb fast ram can't do C2P that quick for 1x1 pixel resolution (as seen in the video)

Not even with just two or three bitplanes?

[ross]

Originally Posted by Solo Kazuki

According what author (Kefir) answer him, tunnel is not pre-rendered but real time calculated, that's why it needs 68020 and Fast RAM.

It's just the opposite

Precisely because it requires 'only' a 020 and 4MB that the tunnel graphics are pre-rendered (and Blender as a support tool makes it a certainty).

I suppose Britelite and aros-sg assumptions are very close to how it was made (no c2p here).

And I add that he probably also had a lot of difficulty put all that graphics in 4MB+2MB of RAM

[grond]

Originally Posted by britelite

Basically a looping 4 plane animation with all bricks visible, then a few planes of overlay to black out or change the colors of the bricks (and one bitplane for those single color icons on top of the bricks).

Ah, yes, this is more likely. Basically the bricks are a checkerboard pattern (i.e. one tile uses e.g. colours 0..., neighbouring tile colours 16...) and each tile gives some time to change the palette for the next tile depending on whether it is transparent or has a different base colour. The center part of the tunnel where tiles are close together could be blitted.

EDIT: the signs on the tiles would have to be drawn for each frame, though...

[britelite]

Originally Posted by grond

EDIT: the signs on the tiles would have to be drawn for each frame, though...

That's only one bitplane, so could even be done with blitter filling

[Solo Kazuki]

Originally Posted by ross

It's just the opposite

Precisely because it requires 'only' a 020 and 4MB that the tunnel graphics are pre-rendered

Then explain tunnel turns, which are optional. Prerendering of every possible tunnel turns (mind that there are some turn arrows in serie)?

Nb: Kefir (maybe as a joke) told that he thinks about adding tunnel bends.

[Tigerskunk]

But then I don't understand how the shifting perspective is done..
Seems like tons of graphics would be needed for this...
Hard to believe this fits in 4mb if everything is prerendered.

[ross]

Originally Posted by Solo Kazuki

Then explain tunnel turns, which are optional. Prerendering of every possible tunnel turns (mind that there are some turn arrows in serie)?

Why not?
You do not need to pre-render for a full turn, but positions between two (full turn/16).
And a 360°/16 turn is really fast during the play: at 25fps probably 5/6 pre-rendered positions suffice.

Originally Posted by Steril707

But then I don't understand how the shifting perspective is done..
Seems like tons of graphics would be needed for this...
Hard to believe this fits in 4mb if everything is prerendered.

Yep, tons of graphics for sure (but seems only a few bplanes are prerendered)

[saimon69]

The shifting perspective is the simpler one, watching the video to me seems to use a similar method to Stardust warp tunnels; the tunnel is probably 2x of the visible area and the camera is adjusted according to it

[Tigerskunk]

Originally Posted by saimon69

The shifting perspective is the simpler one, watching the video to me seems to use a similar method to Stardust warp tunnels; the tunnel is probably 2x of the visible area and the camera is adjusted according to it

No