View Single Post
Old 05 October 2020, 14:19   #11
mcgeezer
Registered User
 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
Quote:
Originally Posted by a/b View Post
Did you consider using (b)splines, so only use a handful of control points and then generate all the in-between coordinates? Turning could be controlled through deltas between previous and current position. Variable speed could be emulated by doing smaller/larger increments of the parameter.
Not sure if that covers all your bases, it's something you generally decide early on and then build other systems on top of that, so maybe it's too late for this kind of approach.
No, it's pretty early on at this point so I have a blank page to work at.

Quote:
Originally Posted by BastyCDGS View Post
Another possibility is to store only the player key presses (one byte per frame with zero byte meaning no key input) instead of the coordinates and RLE compression (very fast).

If there is random enemy movement involved, also store the seed at the beginning and reuse it during replay.

EDIT: Attached m68k Asm sample code which I did back in the day with on-the-fly RLE compression.

Lumps.s: Compresses input from RAW: console to RAM:
LumpsPlayback.s: Decompresses input from RAM: to RAW: console, duplicating keypresses.
Thanks for the suggestions guys, I'll look into them.

The drone cars need to interact with the environment, they can be pushed off course by other cars, different levels will assign different attributes to the cars (max speed, throttle and traction).

I think it might have been Dan that mentioned doing a kind of circuit guide for the cars, so if they go off track they can be guided back on... I think I'll try this approach next.

It's certainly an interesting one to figure out properly.
mcgeezer is offline  
 
Page generated in 0.04811 seconds with 11 queries