Discussion: ModSurfer

[arcanist]

Lou's Pseudo 3d Page has got you covered for the maths.

I've attached an image showing the bitmap used by the game. It's drawn with the blitter and has some perspective-correct stripes in different colors. If the closest visible object is at z=1 then the most distant is chosen to be at z=7. This ratio 7:1 approximates the camera field-of-view. It's an arbitrary choice and I chose it for aesthetics.

The edge of each stripe is placed at some horizontal position near_x (center of the screen at x=0, negative to left, positive to right). At the farthest (highest) point on the screen: far_x = near_x / 7 . These form straight lines to draw with the blitter and fill between with colors. After this point the bitmap is not changed during gameplay.

The copper does all the magic. On every row of the screen (about 200 in total in the playing area) a new color value is set for color indices 1-6. These values are decided by the CPU and written into the copperlist during each frame. There are about 50 different color values used in total, but the bitmap records only 8 unique areas of color per row.

The camera position is tracked horizontally (camera_x) and into the screen (camera_z). Shifting the camera horizontally uses a classic pseudo 3D trick: shift each row of the display by a different amount, more closer to the camera than further away. This gives the illusion of parallax. For a chosen near_shift_x we can calculate: far_shift_x = near_shift_x / 7. Big values close to the camera, small values far away.

camera_z starts at 0. As the music plays camera_z increases at a rate consistent with the speed of the MOD (which can vary throughout the song), once per frame.

For each row of the display the corresponding Z position is calculated. screen_z = camera_z at the bottom. Progressing up the screen a different value is added at each row. These values are smaller at the bottom and larger towards the top, since things further away appear smaller. This part's described well by Lou's page linked above, summarized in: y_screen = (y_world*dist)/z_world. The Z steps are inversely proportional in size to Y.

Given a Z value for each row then the rest is quite easy. Track stripes are as simple as testing (z & (1 << some_bit)). e.g. for bit 8, Z values 0-255 give false, 256-511 give true, 512-767 give false, etc. Based on true/false just set the stripe color value to foreground or background. Since our Z values already scale correctly with perspective the stripes will seem to "move" faster as they get nearer to the camera.

Blocks on the tracks are drawn in a similar way. Colors 2,3,4 (left/middle/right) are set to foreground (actually a different color representing pitch) or background depending on whether they intersect the Z position for that screen row. A separate data structure records where the blocks are located and is walked through in sync with the MOD replayer.

[arcanist]

Originally Posted by ExiE

Looks really cool, just the ball is not there yet It looks like the ball has no weight and the animation is weird and still the same no matter what direction is the ball moving. But with free cycles, the ball could really roll...

I've had the same thought! It's not too difficult to do, just need one pre-rendered sprite for each rotation amount and select the right one according to mouse movement. I'll add it in.

[LeCaravage]

Must read again your last post, got a headache (^^).


Seing your last video makes me think :

Why not add vu-meter for each track with copper gradient in it (like Protracker).

The Z acceleration/deceleration seems too abrupt, why not make them gradually ?

Why not adding lateral acceleration/deceleration and simulate a settle into track ? Of course this could be only visible during slow lateral movement, when it's too fast we could hardly see it.

Why not pop-up funny/supports messages (or funny animations) right in the middle of the screen when the tracks are empty and the player could recover ?

Of course, just ideas coming from impression when watching your track's marks rolling. No way trying to influence.

[arcanist]

Originally Posted by LeCaravage

The Z acceleration/deceleration seems too abrupt, why not make them gradually ?

I had a plan to do this originally but it became impossible when I made instrument playback depend on the player hitting the corresponding blocks. The problem is if the player accelerates slowly up to a higher speed then MOD playback (which must have instant speed changes to sound right) runs ahead. It has to decide whether to play an instrument before the player has reached the block, which doesn't work.

I agree it's a bit ugly in places. Perhaps I could have allowed instruments to play if the player was too far behind, but it would have been complicated to implement.

Originally Posted by LeCaravage

Why not add vu-meter for each track with copper gradient in it (like Protracker).

Why not adding lateral acceleration/deceleration and simulate a settle into track ? Of course this could be only visible during slow lateral movement, when it's too fast we could hardly see it.

Why not pop-up funny/supports messages (or funny animations) right in the middle of the screen when the tracks are empty and the player could recover ?

Of course, just ideas coming from impression when watching your track's marks rolling. No way trying to influence.

Time, mostly. My approach to projects is to decide on a deadline and a minimum feature set. It helps me avoid endlessly tweaking and bolting on new features when that creativity would be better directed at something new.

The underlying goal of this project was to see if I could make lead instrument detection work. It didn't work 100% but much better than I expected. My brain has moved on to a new challenge so I'm spending the remaining 7 weeks putting finishing touches on, tidying up the code, and maybe hunting down some more fast MODs to play, then starting a new project.

I appreciate the ideas, though!

[Tigerskunk]

Really impressive stuff, Arcanist...

Also, always nice to see people doing something apart from "ye usual BOB and Sprites Stuff"...

[hooverphonique]

Just looked at your latest vid - very nice :-)
It looks a bit like the rolling ball is floating/not in contact with the surface, though. A drop shadow might help here (yes, I know the surface is black, so that would need changing for it to work).

[arcanist]

Originally Posted by Steril707

Really impressive stuff, Arcanist...

Also, always nice to see people doing something apart from "ye usual BOB and Sprites Stuff"...

My original plan was to try this on the C64 and synchronize with SIDs, so the idea was already raster tricks before I started on the Amiga.

Originally Posted by hooverphonique

Just looked at your latest vid - very nice :-)
It looks a bit like the rolling ball is floating/not in contact with the surface, though. A drop shadow might help here (yes, I know the surface is black, so that would need changing for it to work).

Yup, I fixed this on the weekend. The ball now rotates left/right to give a much better feeling of friction with the surface. I'll put a video up next week.

[Pyromania]

@arcanist

It looks pretty awesome!

[invent]

Great work Arcanist, i'm impressed.

[arcanist]

ModSurfer is now feature complete! I plan to spend February making small tweaks and testing. The game will release into public domain on the competition deadline.

This update introduces a left/right rolling ball animation. It isn't quite how I hoped to implement it. I learned that the color cycling boing ball always rolls in the direction of the checker pattern. If the pattern is rotated then it's not possible to get a forwards-rolling effect with color cycling (without a lot more colors).

To overcome this the ball rolls back upright when movement stops. I think it still looks quite good. Might need a little tweaking to smooth out motion when the ball is rolling slowly. Instead of making one sprite for each angle in Deluxe Paint I coded a small ray tracer into the build system.

There's now a primitive VU meter into the borders of the track. This was a suggestion from the discussion thread but made a bit simpler. I thought about doing one meter in each lane but without more colors I couldn't fill the width of the lane; only the width of the block. It looked better to me in the borders.

In this video I try three increasingly difficult tracks (and rage quit at the end ). I'm a bit better outside recording with lagless vsync but not much! Two MODs by Xtd and one by Randall. I really like Xtd's MODs because they vary the speed quite a bit. Lots of them work nicely in the game.

[ Show youtube player ]

[amiman99]

Greetings from SATX!
Looks pretty good, I can't wait till it's released!

[Tsak]

Hey there, great progress!

I was wondering how the game would look with a bit more color and some extra details, so I did this quick experiment:



A similar result with the above (with the gradients translated to the proper OCS palette of course) might be doable :

-8 colors, all copperised. F.e. 1 for the background and HUD, 2 for the logo, track name font, the road and the road edge, 1 for the road lines, 1 for the blocks, 1 for the block and ball shadows and 2 for the ball.
-My guess is that the ball shadow could be easily added, either as a shape or a simple sprite. Adding the block shadows is a cool detail that helps with the 3d effect, however this would probably mean to double the blocks on screen

[ExiE]

White/red ball with shadow under the ball and on the ball makes it look more "spherical" and would be quite a big improvement. Percentage text is less readable though.

[arcanist]

That's like a retrowave remix of my game. Looks sweet!

A sprite shadow for the ball might work but it would need to be a single color, regardless of being over the ground or a tile. I can't alter the color if the ball sits horizontally on the edge of a tile. I'm not sure if that would look good but it'd be easy to try. A real shadow tinting the color below would be quite a bit more complicated.

I love the lighting on the ball. I'm using color cycling to conserve chip memory for mod samples; 17 left/right rotation frames at 32x32x4 = 8KB. To shade the colors would either need one frame per forward rotation as well (8KB * e.g. 16 = 128KB, too much) or the copper would need to change 14 colors per scanline, on top of the existing 6 colors + 3 scroll registers; I think that's too much for OCS copper?

Maybe doing alternating sets of 7 colors per line. Probably too difficult at this stage.

The tiles are all drawn from one color per lane (see the screenshot at the top of this page). I think a shadow below would need an extra bitplane to hold the additional colors. There's still a lot of frame time left so the extra DMA might not be a problem. Not sure if I'll have time to try this, though.

Coppering up the title/text would be easy. I might do that.

[Tsak]

Originally Posted by arcanist

A sprite shadow for the ball might work but it would need to be a single color, regardless of being over the ground or a tile. I can't alter the color if the ball sits horizontally on the edge of a tile. I'm not sure if that would look good but it'd be easy to try. A real shadow tinting the color below would be quite a bit more complicated.

The issue (imho) with the current implementation of touching the blocks/tiles with the ball, is that it's difficult to understand which you are hitting and which you are missing (especially in fast sequences). The blocks you touch just darken, the color shades between touched and untouched ones are too close and the tiles you hit stay on screen. So the visual feedback the player gets when connecting with them is very weak overal (which also deducts points from the general feel of the 'hit and miss' gameplay loop).

What you could do instead is flash to white the tile (for a frame or two) when you touch it and then remove it, letting the others you missed to pass by you. This can automatically also solve the issue of needing the ball's shadow to overlap with any of them

Originally Posted by arcanist

I love the lighting on the ball. I'm using color cycling to conserve chip memory for mod samples; 17 left/right rotation frames at 32x32x4 = 8KB. To shade the colors would either need one frame per forward rotation as well (8KB * e.g. 16 = 128KB, too much) or the copper would need to change 14 colors per scanline, on top of the existing 6 colors + 3 scroll registers; I think that's too much for OCS copper?

No copper color change is needed for the ball animation. To create the ball shades you just need 2 static copperlists, one for color white and one for red.
Am I missing something?



Here's also a sample with full OCS color btw

[arcanist]

Originally Posted by Tsak

The issue (imho) with the current implementation of touching the blocks/tiles with the ball, is that it's difficult to understand which you are hitting and which you are missing (especially in fast sequences). The blocks you touch just darken, the color shades between touched and untouched ones are too close and the tiles you hit stay on screen. So the visual feedback the player gets when connecting with them is very weak overal (which also deducts points from the general feel of the 'hit and miss' gameplay loop).

What you could do instead is flash to white the tile (for a frame or two) when you touch it and then remove it, letting the others you missed to pass by you. This can automatically also solve the issue of needing the ball's shadow to overlap with any of them

Yes, the visual feedback could definitely be improved.

These are both good suggestions. If I can find the time I'll experiment with shadowed tiles. Flashing is a good fallback idea.

Originally Posted by Tsak

No copper color change is needed for the ball animation. To create the ball shades you just need 2 static copperlists, one for color white and one for red.
Am I missing something?

The ball sprite has 14 colors, 7 red and 7 white. For a simpler example of 4 colors, palette cycling works like this: RRWW WRRW WWRR RWWR. This gives the illusion of the ball rolling forwards over 14 frames without needing 14 different sprite images. Each scanline has more than two sprite colors for the copper to change, though. Perhaps not all 14 due to the ball's limited curvature. Tricky to figure out which colors to change on each scanline, though.

14 sprite images in itself wouldn't be a problem but the ball also has 17 frames of rotation left/right. In total it'd require 238 images. With this approach the copper could change just 2 colors per scanline (red and white). I miscalculated in my previous post. These would need only two bitplanes each, so about 60KB in total. I'd be a bit nervous spending that much chip RAM on an A500 as it limits the largest MODs that could be loaded.

But perhaps it could look OK with fewer frames of animation.

[Tsak]

Ah, I missed previously the palette cycling detail. Cool, I get it.

Note that visually you can get a legit result also by just shading the white color only. The curvature effect will be retained and the flat red will give a translucent feel to the ball.



While this might help I'm not sure it's a proper solution given your notes though.
If you're lacking copper bandwidth it'd be better served updating the other parts of the scenery over the ball I think (which is what the player will be focused on).

[arcanist]

Release thread

Direct link

Thank you to everyone who contributed on the development thread. I didn't manage to incorporate all the feedback but it helped me shape the game and was appreciated. Six months is a tough timeframe.

Some clarification for judges:

• The game was written by myself except for...
• MOD replayer: Aminet mus/play/ptplayer by phx (with minor changes for gameplay)
• MOD pack: All MODs composed by great musicians who I'm not affiliated with

The MODs I selected for the pack work particularly well, but feel free to try out your own as well. Out of ~400 MODs I tested I'd say the algorthm worked well about 70% of the time. Much better odds than I expected.

[DamienD]

Nice one arcanist, well done

[Tsak]

Congrats arcanist!