Atari STE 50fps racer - WIP 10 June (real hardware)

Another WIP video of my upcoming racing game loosely based upon WEC LE Mans. This time from real hardware rather than emulation - a stock 8MHz STE with 1 meg of memory.

[@JoanOrfila]

Very impressive. Technically it will be a complete blast.

[@gridleaderretro]

Thank you! I'm hoping to make it both a technical showcase of the STE and also fun to play!

[@PaulMJohnson]

That's really impressive. The impression of speed is excellent, and great job keeping the frames up as more things appear on screen.

[@gridleaderretro]

Thank you Paul!

[@soviet9922]

Thats amazing is lightyears away from lotus turbochallenge

[@gridleaderretro]

Thank you. It's not quite as advanced as Lotus (no hills) but I like to think the faster framerate more than makes up for it!

[@goddessesstartrekonlinefle3061]

Super scaler eat your heart out :D. Looks great! If you fancy a extra challenge, implement branching route choices!

[@gridleaderretro]

Branching unlikely I'm afraid - this is already working the Blitter chip very hard!

[@goddessesstartrekonlinefle3061]

@@gridleaderretro still looks amazing! ST has much untapped potential as demo coders been long proving :D. Getting the experience perfect and then innovating furthur in the next game generation is the racing game way! Like the evolution of Lotus Esprit. Super cool.

[@AtariCrypt]

And I thought Pole Position was fast n furious 😮😮😮

[@gridleaderretro]

You ain't seen nothing yet :)

[@kevcall]

Great work, thing I always hated about these games was the lack of (my) car sprites, ie 3, guess it would only use a little more memory to add 2 or 4 more..? Takes me back to when I wrote Bombaman-STe.. Good times but very time consuming lol

[@gridleaderretro]

Thank you! I could theoretically add a couple of new cars with little memory overhead as long as the basic car shape remains the same, but the constraint is the number of colours available. Once I need different car shapes, the memory requirement starts lifting quite dramatically due to the Blitter-based sprite rendering method in use.

[@kevcall]

​@@gridleaderretro I actually meant intermediate car images as a jump to (say) 20 degrees is a distraction but understand it's difficult with the colours available. I'm intrigued to know what blitter method you're using, my memory is a little rusty lol. Think for my moving sprites I only used 3 bitplanes and the 4th for the mask.. Either for speed or laziness, I forget (I was slated for my awful graphics lol) On another topic, I did wonder if you could do a palette swap on the hbl just above your car sprite to get more colours but I do recall I had issues with hog/nohog mode affecting hbl interrupts and had problems knocking out the borders; spent weeks and weeks on it and the best method was to run in hog mode sometimes - think I had macros for HOGBLIT and NOHOGBLIT and figured out which to use where.. Anyway I digress lol.. It's clear you're much more up to date on all this than I am. Such impressive work 👍

[@gridleaderretro]

Ah okay. I'm planning on adding intermediate images for the turning of the player car only - to do it for all the scaled versions would be too much of a memory overhead. I've thought in the past about using HBL/Timer-B to get more colours in the cars, but the problem is that it affects any sprite on those lines using the colours that get reassigned. It places quite a lot of limitations on what colours you can use on what lines, and also adds quite a lot of code complexity - not what you want when you're targeting 50fps! The sprite rendering is based upon information I've gleaned from reading stuff written by clever people like Anima and DML on Atari-Forum. It's a single pass renderer that uses the end masks for masking, draws things in 4-bitplane horizontal spans, and always runs in Hog mode. Heavy compile-time preprocessing of the sprite data is involved to minimise the amount of calculations required at runtime.

[@kevcall]

​​​@@gridleaderretroI understand, will watch this development with great interest. It's so smooth and gives a great impression of speed. Yes the HBL palette swap may be too much of a headache vs benefit issue.. (and yes I kept Bombaman to 60fps for some reason.. Didn't need it tbh but this improves yours no end)

[@kevcall]

​@@gridleaderretroyou say 'compile time'.. You haven't written this in C have you..??

[@francois-xavierrobin432]

Whaouuu. I guess it's based on your previous works like "Lotus STE". It's so smooth. It's barely incredible.

[@gridleaderretro]

Yes, that's right - it's a further evolution of what I learned in Pole Position and Lotus. Whoever thought the STE could do a 50fps eh? :)

[@francois-xavierrobin432]

@@gridleaderretro yes it's amazing

[@simonebernacchia5724]

STE Le Mans

[@gridleaderretro]

Yes, sort of! It's not intended to be an STE conversion of WEC Le Mans, but is heavily influenced by that game.

[@lucasjokiel]

OMG!

[@gridleaderretro]

I guess that means you're impressed and you like it :)

[@lucasjokiel]

@@gridleaderretro Hell yeah! :)

[@jasont6287]

what do you think about the blitter on the STE could have atari done it better?

[@gridleaderretro]

I've come to quite like the Blitter over time, even though the way in which modern prods use it bears little resemblance to how the original designers intended! It would have been great if the original design had the capability to pull data from multiple sources into one destination, as is possible with the Amiga's Blitter.

[@alexisread5325]

I wish they had used a T212 transputer instead- 10mips at 20mhz with a 2k cache. Atari had access to Inmos chips at the time and they work better as coprocessors rather than in a dedicated computer like the Atari ATW

[@gridleaderretro]

@@alexisread5325 Just guessing, but wouldn't such a processor have been - More powerful than the 68000 (which would have a strange decision given that the 68000 was the "primary" CPU) - Much more expensive than the Blitter?