07 January 2019, 19:22 | #41 |
Registered User
Join Date: Dec 2017
Location: Austin, TX
Age: 41
Posts: 418
|
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. |
07 January 2019, 19:29 | #42 |
Registered User
Join Date: Dec 2017
Location: Austin, TX
Age: 41
Posts: 418
|
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 |
Registered User
Join Date: May 2017
Location: AmigaLand
Posts: 459
|
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 | ||
Registered User
Join Date: Dec 2017
Location: Austin, TX
Age: 41
Posts: 418
|
Quote:
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:
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 |
Inviyya Dude!
Join Date: Sep 2016
Location: Amiga Island
Posts: 2,803
|
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 |
ex. demoscener "Bigmama"
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,659
|
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 | |
Registered User
Join Date: Dec 2017
Location: Austin, TX
Age: 41
Posts: 418
|
Quote:
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 |
Moderator
Join Date: Jan 2002
Location: Chicago, IL
Posts: 3,454
|
@arcanist
It looks pretty awesome! |
24 January 2019, 00:13 | #49 |
pixels
Join Date: May 2014
Location: Australia
Age: 53
Posts: 476
|
Great work Arcanist, i'm impressed.
|
27 January 2019, 18:23 | #50 |
Registered User
Join Date: Dec 2017
Location: Austin, TX
Age: 41
Posts: 418
|
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 |
Registered User
Join Date: Sep 2009
Location: San Antonio, TX USA
Age: 50
Posts: 1,185
|
Greetings from SATX!
Looks pretty good, I can't wait till it's released! |
02 February 2019, 03:37 | #52 |
Pixelglass/Reimagine
Join Date: Jun 2012
Location: Athens
Posts: 1,070
|
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 |
Registered User
Join Date: Apr 2016
Location: T/C
Posts: 199
|
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 |
Registered User
Join Date: Dec 2017
Location: Austin, TX
Age: 41
Posts: 418
|
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 | ||
Pixelglass/Reimagine
Join Date: Jun 2012
Location: Athens
Posts: 1,070
|
Quote:
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:
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 | ||
Registered User
Join Date: Dec 2017
Location: Austin, TX
Age: 41
Posts: 418
|
Quote:
These are both good suggestions. If I can find the time I'll experiment with shadowed tiles. Flashing is a good fallback idea. Quote:
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 |
Pixelglass/Reimagine
Join Date: Jun 2012
Location: Athens
Posts: 1,070
|
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 |
Registered User
Join Date: Dec 2017
Location: Austin, TX
Age: 41
Posts: 418
|
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:
|
27 February 2019, 15:18 | #59 |
Banned
Join Date: Aug 2005
Location: London / Sydney
Age: 47
Posts: 20,420
|
Nice one arcanist, well done
|
27 February 2019, 19:38 | #60 |
Pixelglass/Reimagine
Join Date: Jun 2012
Location: Athens
Posts: 1,070
|
Congrats arcanist!
|
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 |
|
|