Lotus Esprit Turbo Challenge - STE enhanced (WIP)

[chicane]

I've just uploaded this video showing some changes I've been making to Lotus Esprit Turbo Challenge to add support for the STE hardware.

So far I've hacked in some detailed road lines resembling those in the Amiga version, and also have some of the trackside scenery rendering at single pixel increments as opposed to the 16 pixel increments in the vanilla ST version. I also plan to bring over some of the sampled sounds from the Amiga version, and maybe also the sky gradient.

This is an open source project - you can view the current code at https://github.com/jonathanopalise/lotus-ste.

Feedback and comments are most welcome!

[junosix]

Wow, very cool so far, it would sound awesome with the .mod file intro and sound effects!

[Frank B]

Already looking good!
If you use anima's sprite rendering blitter technique you should be able to use timer b for the rasters. The speed up should also be significant for drawing the cars in the game.

[dma]

"Ah, long time since i had these dreams of seeing my favorite games STe enhanced... Wait it's real?!"
Congrats for working on such enhancements for this great game already then!

[AdamK]

This is cool. Can it be also applied to Lotus II and III?

[Cyprian]

great news chicane

[Fletch]

Awesome!

[CiH]

Liking it a lot!

[ST Graveyard]

Awesome project!

[rmd]

cool project; funny to see some php code there too.

[Marakatti]

Great idea, 2020 looks impressing already

[thomas3]

One of my favourites from back in the day. Thanks for doing this!!

[chicane]

Already looking good!

Wow, very cool so far

Congrats for working on such enhancements for this great game already then!

This is cool. Can it be also applied to Lotus II and III?

great news chicane

Awesome!

Liking it a lot!

cool project

Great idea, 2020 looks impressing already

One of my favourites from back in the day. Thanks for doing this!!

Thanks all for your kind words!

This is cool. Can it be also applied to Lotus II and III?

Theoretically yes. I haven't looked at the code for Lotus 2 and 3 but from casual observation they would appear to use very similar rendering code to Lotus 1.

funny to see some php code there too.

Ha ha, yes. PHP is my day job

it would sound awesome with the .mod file intro and sound effects!

The DMA playback in the STE is surprisingly easy to use, so I should be able to get the sound effects in there as long as I can extract and convert from the Amiga version. I didn't realise there was a MOD file in the Amiga version - I thought it was just a long sample?

If you use anima's sprite rendering blitter technique you should be able to use timer b for the rasters. The speed up should also be significant for drawing the cars in the game.

Thanks - I'll be sure to look that up. The original car/scenery rendering code is heavily optimised and makes use of unrolled loops and self-modifying code. I'm not entirely sure that I can surpass the performance of the that code with the Blitter. But it does give the benefit of being able to use Skew to render things at single-pixel horizontal accuracy.

[Frank B]

You can also shave 10% of the draw time with the blitter if the source sprite/mask data is properly aligned. You can use NFSR and null out the last column read as you'll be writing an extra column for the shift. For a 32 wide sprite spanning 3 words written to dest it would be rmw/rmw/mw instead of rmw/rmw/rmw.

[thomas3]

The original car/scenery rendering code is heavily optimised and makes use of unrolled loops and self-modifying code. I'm not entirely sure that I can surpass the performance of the that code with the Blitter.

Ah, so, that explains why the game ran so fast anyway. Nice to see that clever/dirty code was both used and delivered results outside of the demoscene

[junosix]

The intro music is a .mod file, as is the ingame music: https://www.exotica.org.uk/wiki/Lotus_E ... _Challenge

Possible to use the intro one at the start of the game? Probably a bit of a tall order to have ingame .mod files in any kind of quality with all the other CPU use going on too but the engine sound for the player car should be easy to pull off either with a simple frequency stepping routine or pre-stepped short loops for the different RPMs (wonder if it's easy enough to find the frequency period values from the Amiga version?).

[chicane]

You can also shave 10% of the draw time with the blitter if the source sprite/mask data is properly aligned. You can use NFSR and null out the last column read as you'll be writing an extra column for the shift.

Thanks - I should indeed be able to do that. The graphics data I've worked with so far is stored in memory with 10 bytes representing each 16 pixels, arranged as mmb1b2b3b4, where mm is the mask word and b1-b4 are the words representing each bitplane. Currently I'm doing 4 Blitter passes for the mask, and a Blitter pass for each of the bitplanes - so 8 Blitter passes in total for each sprite drawn. I don't think there's a way to do it with less passes without rearranging the data but I'm willing to be educated!

The intro music is a .mod file, as is the ingame music: https://www.exotica.org.uk/wiki/Lotus_E ... _Challenge

Possible to use the intro one at the start of the game? Probably a bit of a tall order to have ingame .mod files in any kind of quality with all the other CPU use going on too but the engine sound for the player car should be easy to pull off either with a simple frequency stepping routine or pre-stepped short loops for the different RPMs (wonder if it's easy enough to find the frequency period values from the Amiga version?).

I've not come across many instances of mod playing routines in STE games. Isn't it the case that Amiga's Paula has dedicated mixing hardware and can play mods with very little CPU utilization? As for the engine sounds, am I right in thinking that the STE can only play samples at four different speeds and there's no fine tuning of playback speed? That might be a bit of a problem with respect to using samples for engine playback unless (as you've suggested) I could store a ton of different samples for different revs. The other issue is the simultaneous playback of two different samples whilst in-game (e.g. both the engine and a collision sound) - we're back to needing to mix samples in real time which hammers the CPU.

In Pole Position, I used the YM for the engine sound and took samples from the arcade game for sound effects. It obviously doesn't give the best engine sound but perhaps it's the best compromise?

Ah, so, that explains why the game ran so fast anyway. Nice to see that clever/dirty code was both used and delivered results outside of the demoscene

Yeah - there's nothing groundbreaking there but it's impressive to see nonetheless in the context of game development timescales

[junosix]

The STE does only have four playback frequencies, so I think the most practical that could be hoped for is software-mixed .mod playback of the intro music on the title screen, and one looped sample ingame for the player car's engine selected from a table of samples. The collision and skidding sound would need to be software-mixed if you wanted to have them play at the same time as the engine. The engine loses its revs when the car collides so it wouldn't be so noticeable if the collision sound was played on its own, but the skidding sound is played along with the engine sound on the Amiga version so that could sound a bit janky if you're only playing that one then going back to the engine sound afterwards. One thing that could be used to an advantage is that in the Amiga it's either set to play music or sound effects, but the STE version could be playing YM music over the sound effects which could hide the fact that it's only playing one sample at a time.

Listening to the Amiga version there seems to be around 32 different steps/frequencies for the engine sound: https://www.youtube.com/watch?v=ug_px1vBzs8

A very quick play in Audacity taking the engine sound from the Amiga version and having 32 copies each increasing in speed by 5 percent and resampling it so that the playback frequency is 12.5kHz takes about 80kB (would be more accurate if the period values sent to the Amiga soundchip could be found, then exact frequencies could be derived), plus the other ingame sounds should bring memory usage to about 100kB at a rough guess.

[chicane]

Thanks for looking into all that! I was quite encouraged until I started thinking about 2 player mode and how to handle playback of two simultaneous engine sounds with a possible two sound effects playing on top! For all its shortcomings, the YM does allow three independent channels of sound with no need for software mixing, whereas the sampled sound capability of the STE falls apart once there's a need to mix multiple audio streams in real time.

Not sure what to do about this - might have to assume sticking with YM for the engine sounds until when/if we can work something better out. Or maybe sampled engine sound for single player and YM for two player, although that might be a bit weird

[dhedberg]

Sounds like a fun and interesting project!

[AdamK]

Maybe curb/middle line color could be done by rasters instead of drawing it in color? Then its drawing routine could be simplified and some CPU time could be used for diffrent things.

[junosix]

I was quite encouraged until I started thinking about 2 player mode and how to handle playback of two simultaneous engine sounds with a possible two sound effects playing on top!

Might not be the end of the world if you're mixing two fixed-frequency samples together. Earlier this year someone over on the Amiga scene did some research and depending on how much CPU you're left with you might be able to do something along these lines: https://www.youtube.com/watch?v=SPgN61ifQlQ

[FedePede04]

its looking great.

i have the same problem with the engine sound both on enduro racer and outrun.

i was thinking on if you can live with a pure square sound.

if you have one big square wave in memory. lowest frequency you need, and if you want to make it lighter just increase start point with number of step you want to make it brighter, and make it (step*2) shorter.
but that will also make it harder to add samples FX.

[chicane]

Sounds like a fun and interesting project!

Thanks!

Maybe curb/middle line color could be done by rasters instead of drawing it in color? Then its drawing routine could be simplified and some CPU time could be used for diffrent things.

Thanks for the suggestion! Do you mean changing the palette once per line, or changing it several times during each line? I think the latter would be both very timing dependent and heavy on CPU - I'm not sure if it's been succesfully done outside specialist apps like Spectrum 512.

Might not be the end of the world if you're mixing two fixed-frequency samples together. Earlier this year someone over on the Amiga scene did some research and depending on how much CPU you're left with you might be able to do something along these lines: https://www.youtube.com/watch?v=SPgN61ifQlQ

Thanks for pointing me to this! Currently I have no CPU time left - the Blitter version is actually running more slowly than the CPU version (although it looks and moves much more nicely!) I'll be sure to bear in mind your suggestion if I manage to somehow free up some CPU.

i was thinking on if you can live with a pure square sound.

if you have one big square wave in memory. lowest frequency you need, and if you want to make it lighter just increase start point with number of step you want to make it brighter, and make it (step*2) shorter.
but that will also make it harder to add samples FX.

Thanks for your thoughts. I don't know much about sound theory but I'll be sure to read up around this subject once I start work on this side of things. If it can be done without a need for software mixing then it's certainly a possibility.

[AdamK]

Maybe curb/middle line color could be done by rasters instead of drawing it in color? Then its drawing routine could be simplified and some CPU time could be used for diffrent things.

Thanks for the suggestion! Do you mean changing the palette once per line, or changing it several times during each line? I think the latter would be both very timing dependent and heavy on CPU - I'm not sure if it's been succesfully done outside specialist apps like Spectrum 512.

I think once per line should be enough.