Top down racer

[D3thAdd3r]

I wasn't expecting to see all that, this really blows me away

[Gosma]

simply amazing!

[uze6666]

awesome!

Couple things, that steering sound could be improved a bit...Also there's some slowdown when there's lot of cars, wondering if your custom car blitter is in assembler? Or perhaps you don't use the inline mixer? Do you have -DSOUND_MIXER=1 in your makefile's kernel options? Because with it you regain about 12% of RAM (524 bytes) and many lines worth of CPU during vsync.

[CunningFellow]

Awesome work.

Needs some throttle steering to add to the fun.

And should the pedestrians turn red when hit?

[jhhoward]

Thanks for the feedback everyone, I'm glad to see that you enjoyed the demo!

awesome!

Couple things, that steering sound could be improved a bit...Also there's some slowdown when there's lot of cars, wondering if your custom car blitter is in assembler? Or perhaps you don't use the inline mixer? Do you have -DSOUND_MIXER=1 in your makefile's kernel options? Because with it you regain about 12% of RAM (524 bytes) and many lines worth of CPU during vsync.

Yeah, the sounds are a bit rough right now. I've had some problems getting things to sound nice. The 'engine' noise is a simple TriggerNote() with a different note based on the speed of the player's car. However, it tends to have quite a noisy / crackle sound. The patch is a very simple wave with volume envelope, so I'm not sure why this happens. I think I can improve the steering / tyre screeching sound by adding a tremolo effect, I'll see what I can do.

There is certainly some need for performance optimisation, but I'm not sure where the bottleneck is yet. The custom sprite blitting code is really just an extension of the existing BlitSprite() function. The only difference is that each sprite also has an extra 'colour mask' byte, which is applied with a logical AND to each pixel before it is written. It's a couple of extra lines, and all in assembler. I also have the inline mixer enabled too. I have a feeling the culprit may be the physics / collision detection, since the slow downs happen when cars are near each other.

Awesome work.

Needs some throttle steering to add to the fun.

And should the pedestrians turn red when hit?

Thanks! I'll see what I can do about the steering. Are you finding that the turning circle is too large? The pedestrians aren't meant to turn red right now, but I could change that for extra pixely gore.

I'll be adding some more missions for the final release. I just received an extra controller, so I'm going to try add a 2 player mini game too.

[D3thAdd3r]

This would be a cool game for the link cable. Uzelink should work right now as is and it's easy to add and not too much codespace. I think this is not completing game logic before vsync some frames where the cars are close together, so that might not work.

How is the collision done in your game?

[jhhoward]

This would be a cool game for the link cable. Uzelink should work right now as is and it's easy to add and not too much codespace. I think this is not completing game logic before vsync some frames where the cars are close together, so that might not work.

How is the collision done in your game?

How does the link cable work exactly? One method of networking the game would be to have all logic running on the host, and just replicate the car positions on the client. The client then only needs to send it's gamepad input over to the host.

The game currently runs at 30 fps most of the time, but sometimes that drops down to 20. The tiles and sprites are configured before the first vsync, but the logic, ai and physics takes too long to process, so a second vsync is hit, giving the 30 fps rate.

The physics system is fairly complex. The world is organised as a simple grid, with tiles being collidable or non-collidable. Each car is modelled as two connected particles, representing the front and back of the car. Positions are stored as unsigned fixed point values, with 11 bits used for the integer part (0-2047) and 5 bits for the fractional part (precision of 1/32). I use verlet integration to move the particles, and a simple constraint system to keep them together at a fixed length. Collisions between cars are processed by comparing the square distance between each of the cars particles, and using the constraint method to push them apart if they are too close together. Because of the nature of the verlet system, this creates a nice collision response. For example, you can ram the front of a car, and cause it to rotate correctly. There are also some friction models applied to the front and back particles based on the orientation of the car and the steering direction of the front tyres.

I will be putting up the full source code once I've submitted entry for UCC2014

[Harty123]

Hey this demo looks relly cool!!!

[D3thAdd3r]

How does the link cable work exactly? One method of networking the game would be to have all logic running on the host, and just replicate the car positions on the client. The client then only needs to send it's gamepad input over to the host.

Hmm I tend to speak too soon. The link cable is easy you just call the initialize function, attach it as a user VsyncCallback, and treat pad 2 just like a controller is plugged into the machine. You just have to check the state each frame, if you didn't receive a padstate from the other machine then halt game logic until that happens to stay synchronized. Then, you don't need to do any client replication work since each tick happens exactly the same on both machines, and neither one proceeds until the other one is at the same point. It is also only 16bits as opposed to however much data object positions/states would take. There can be no errors or missed data "packets" of course, but it takes care of that with resend codes and a checksum on received data....but with varying frame rates I think I will have to get it to a more sophisticated state before I would subject someone to undiscovered "features" in the code. It is only tested with trivial programs where it easily hits 60fps.

I noticed that some frames all sprites would disappear from the screen, and I think it might be because the code has too much work to do and maybe resets sprites and before setting them back up the frame renders? If you made sure nothing would redraw unless there was enough time that frame(just redisplay last frame if needed) it might help? Physics seem to work very nicely but I agree the turning could be 25-50% tighter...or one of the shoulder buttons works like a hand brake to do power slides? I would also like to see low resolution 8 bit gore

[Harty123]

I've added a very basic wiki page in the "work-in-progress" section:

http://uzebox.org/wiki/index.php?title=Joyrider