English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Contest

 
 
Thread Tools
Old 07 January 2019, 19:22   #41
arcanist
Registered User
 
Join Date: Dec 2017
Location: Austin, TX
Age: 36
Posts: 187
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.
Attached Thumbnails
Click image for larger version

Name:	modsurfer-tricks.png
Views:	105
Size:	24.6 KB
ID:	61495  
arcanist is offline  
Old 07 January 2019, 19:29   #42
arcanist
Registered User
 
Join Date: Dec 2017
Location: Austin, TX
Age: 36
Posts: 187
Quote:
Originally Posted by ExiE View Post
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.
arcanist is offline  
Old 07 January 2019, 19:44   #43
LeCaravage
Registered User

LeCaravage's Avatar
 
Join Date: May 2017
Location: AmigaLand
Posts: 183
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.
LeCaravage is offline  
Old 08 January 2019, 03:27   #44
arcanist
Registered User
 
Join Date: Dec 2017
Location: Austin, TX
Age: 36
Posts: 187
Quote:
Originally Posted by LeCaravage View Post
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.

Quote:
Originally Posted by LeCaravage View Post
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!
arcanist is offline  
Old 23 January 2019, 07:56   #45
Steril707
Tigerskunk!

Steril707's Avatar
 
Join Date: Sep 2016
Location: Amiga Island
Posts: 941
Really impressive stuff, Arcanist...

Also, always nice to see people doing something apart from "ye usual BOB and Sprites Stuff"...
Steril707 is offline  
Old 23 January 2019, 10:58   #46
hooverphonique
ex. demoscener "Bigmama"
 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 927
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).
hooverphonique is offline  
Old 23 January 2019, 15:37   #47
arcanist
Registered User
 
Join Date: Dec 2017
Location: Austin, TX
Age: 36
Posts: 187
Quote:
Originally Posted by Steril707 View Post
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.

Quote:
Originally Posted by hooverphonique View Post
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.
arcanist is offline  
Old 23 January 2019, 15:58   #48
Pyromania
Moderator

Pyromania's Avatar
 
Join Date: Jan 2002
Location: Chicago, IL
Posts: 2,066
@arcanist

It looks pretty awesome!
Pyromania is offline  
Old 24 January 2019, 00:13   #49
invent
pixels

invent's Avatar
 
Join Date: May 2014
Location: Australia
Age: 48
Posts: 270
Great work Arcanist, i'm impressed.
invent is offline  
Old 27 January 2019, 18:23   #50
arcanist
Registered User
 
Join Date: Dec 2017
Location: Austin, TX
Age: 36
Posts: 187
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 ]
arcanist is offline  
Old 01 February 2019, 20:59   #51
amiman99
Registered User

amiman99's Avatar
 
Join Date: Sep 2009
Location: San Antonio, TX USA
Age: 45
Posts: 828
Greetings from SATX!
Looks pretty good, I can't wait till it's released!
amiman99 is offline  
Old 02 February 2019, 03:37   #52
Tsak
Registered User

Tsak's Avatar
 
Join Date: Jun 2012
Location: Athens
Posts: 512
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
Tsak is offline  
Old 02 February 2019, 11:24   #53
ExiE
Registered User

 
Join Date: Apr 2016
Location: T/C
Posts: 125
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.
ExiE is offline  
Old 02 February 2019, 21:28   #54
arcanist
Registered User
 
Join Date: Dec 2017
Location: Austin, TX
Age: 36
Posts: 187
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.

Last edited by arcanist; 02 February 2019 at 21:54.
arcanist is offline  
Old 03 February 2019, 03:45   #55
Tsak
Registered User

Tsak's Avatar
 
Join Date: Jun 2012
Location: Athens
Posts: 512
Quote:
Originally Posted by arcanist View Post
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

Quote:
Originally Posted by arcanist View Post
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

Last edited by Tsak; 03 February 2019 at 05:04.
Tsak is offline  
Old 03 February 2019, 16:13   #56
arcanist
Registered User
 
Join Date: Dec 2017
Location: Austin, TX
Age: 36
Posts: 187
Quote:
Originally Posted by Tsak View Post
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.

Quote:
Originally Posted by Tsak View Post
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.
arcanist is offline  
Old 04 February 2019, 00:11   #57
Tsak
Registered User

Tsak's Avatar
 
Join Date: Jun 2012
Location: Athens
Posts: 512
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).
Tsak is offline  
Old 27 February 2019, 14:46   #58
arcanist
Registered User
 
Join Date: Dec 2017
Location: Austin, TX
Age: 36
Posts: 187
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.
arcanist is offline  
Old 27 February 2019, 15:18   #59
DamienD
Global Moderator

DamienD's Avatar
 
Join Date: Aug 2005
Location: London / Sydney
Age: 42
Posts: 14,884
Nice one arcanist, well done
DamienD is online now  
Old 27 February 2019, 19:38   #60
Tsak
Registered User

Tsak's Avatar
 
Join Date: Jun 2012
Location: Athens
Posts: 512
Congrats arcanist!
Tsak is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Entry: ModSurfer arcanist Coders. Entries 13 27 February 2019 14:46
Discussion: XILEF E-Penguin Coders. Contest 17 17 December 2018 21:40
Old KGLoad Discussion killergorilla project.KGLoad 357 20 January 2011 16:08
Castlevania Discussion john4p Retrogaming General Discussion 30 30 January 2009 02:10
General Discussion Zetr0 project.Amiga Game Factory 12 15 December 2005 13:53

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 16:26.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.10084 seconds with 14 queries