English Amiga Board Discussion: ModSurfer
 Register Amiga FAQ Rules & Help Members List  /  Moderators List Today's Posts Mark Forums Read

 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
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 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.

 07 January 2019, 19:44 #43 LeCaravage Registered User   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.
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 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 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!

 23 January 2019, 07:56 #45 Steril707 Tigerskunk!   Join Date: Sep 2016 Location: Amiga Island Posts: 967 Really impressive stuff, Arcanist... Also, always nice to see people doing something apart from "ye usual BOB and Sprites Stuff"...
 23 January 2019, 10:58 #46 hooverphonique ex. demoscener "Bigmama"   Join Date: Jun 2012 Location: Fyn / Denmark Posts: 943 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).
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 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 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.

 23 January 2019, 15:58 #48 Pyromania Moderator   Join Date: Jan 2002 Location: Chicago, IL Posts: 2,066 @arcanist It looks pretty awesome!
 24 January 2019, 00:13 #49 invent pixels   Join Date: May 2014 Location: Australia Age: 48 Posts: 272 Great work Arcanist, i'm impressed.
 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 ]
 01 February 2019, 20:59 #51 amiman99 Registered User   Join Date: Sep 2009 Location: San Antonio, TX USA Age: 45 Posts: 836 Greetings from SATX! Looks pretty good, I can't wait till it's released!
 02 February 2019, 03:37 #52 Tsak Registered User   Join Date: Jun 2012 Location: Athens Posts: 520 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
 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.
 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.
03 February 2019, 03:45   #55
Tsak
Registered User

Join Date: Jun 2012
Location: Athens
Posts: 520
Quote:
 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

Quote:
 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

Last edited by Tsak; 03 February 2019 at 05:04.

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 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 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.

 04 February 2019, 00:11 #57 Tsak Registered User   Join Date: Jun 2012 Location: Athens Posts: 520 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).
 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.
 27 February 2019, 15:18 #59 DamienD Global Moderator   Join Date: Aug 2005 Location: London / Sydney Age: 42 Posts: 15,063 Nice one arcanist, well done
 27 February 2019, 19:38 #60 Tsak Registered User   Join Date: Jun 2012 Location: Athens Posts: 520 Congrats arcanist!

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

 Similar Threads Thread Thread Starter Forum Replies Last Post arcanist Coders. Entries 13 27 February 2019 14:46 E-Penguin Coders. Contest 17 17 December 2018 21:40 killergorilla project.KGLoad 357 20 January 2011 16:08 john4p Retrogaming General Discussion 30 30 January 2009 02:10 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 Rules
 Forum Jump User Control Panel Private Messages Subscriptions Who's Online Search Forums Forums Home News Main     Amiga scene     Retrogaming General Discussion     Nostalgia & memories Support     New to Emulation or Amiga scene         Member Introductions     support.WinUAE     support.WinFellow     support.OtherUAE     support.FS-UAE         project.AmigaLive     support.Hardware         Hardware mods         Hardware pics     support.Games     support.Demos     support.Apps     support.Amiga Forever     support.Amix     support.Other Requests     request.UAE Wishlist     request.Old Rare Games     request.Demos     request.Apps     request.Modules     request.Music     request.Other     Looking for a game name ?     Games images which need to be WHDified abime.net - Hall Of Light     HOL news     HOL suggestions and feedback     HOL data problems     HOL contributions abime.net - Amiga Magazine Rack     AMR news     AMR suggestions and feedback     AMR data problems     AMR contributions abime.net - Home Projects     project.Amiga Lore     project.EAB     project.IRC     project.Mods Jukebox     project.Wiki abime.net - Hosted Projects     project.aGTW     project.APoV     project.ClassicWB     project.Jambo!     project.Green Amiga Alien GUIDES     project.Maptapper     project.Sprites     project.WinUAE - Kaillera Other Projects     project.Amiga Demo DVD     project.Amiga Game Factory     project.CARE     project.EAB File Server     project.CD32 Conversion     project.Game Cover Art         GCA.Feedback and Suggestions         GCA.Work in Progress         GCA.Cover Requests         GCA.Usefull Programs         GCA.Helpdesk     project.KGLoad     project.MAGE     project.Missing Full Shareware Games     project.SPS (was CAPS)     project.TOSEC (amiga only)     project.WHDLoad         project.Killergorilla's WHD packs Misc     Amiga websites reviews     MarketPlace         Swapshop     Kinky Amiga Stuff     Collections     EAB's competition Coders     Coders. General         Coders. Releases         Coders. Tutorials     Coders. Asm / Hardware     Coders. System         Coders. Scripting         Coders. Nextgen     Coders. Language         Coders. C/C++         Coders. AMOS         Coders. Blitz Basic     Coders. Contest         Coders. Entries Off Topic     OT - General     OT - Entertainment     OT - Sports     OT - Technical     OT - Gaming

All times are GMT +2. The time now is 00:49.

 -- EAB3 skin ---- EAB2 skin ---- Mobile skin Archive - Top