The Making of Lotus STE: Cars and Scenery
Vložit
- čas přidán 11. 09. 2024
- A short video describing some of the challenges and solutions relating to the development of Lotus STE.
Lotus STE is an unofficial update to the original Lotus Esprit Turbo Challenge for the Atari ST, intended to make use of the extra hardware in the Atari STE.
Music: Echo by Bio Unit, licensed under CC BY-NC 4.0.
freemusicarchi...
Great video, very clear explanation, looking forward to your 68K programming tutorials :-)
Thanks very much! I think there are people out there much better qualified than me to impart 68k knowledge - I'm just a novice compared to some of those ex-demoscene folk!
Jonathan, this is fascinating. Well done. Very nicely explained, even a NOOB like me can understand most of it!
About the video. What tools do you use to make these videos? Eg how do you create the green vertical and horizontal lines? Also, what beckground music is that?
Thanks Marty! I'm new to this video editing thing but learning slowly! All of the tools I've used to make this video are open source running under Linux. The video editor I'm using is Shotcut, the image editor is Gimp (used to produce the green horizontal/vertical lines), game footage is captured using SimpleScreenRecorder and I use the built-in Hatari screen capture for stills. The sequence of screens showing how sprites are drawn step-by-step was produced by modifying the Lotus STE code and capturing stills.
The background music comes from the "Free Music Archive" - freemusicarchive.org/home. There's a lot of royalty free music on the site, with most requiring you to credit the author appropriately (which I hope I've done correctly in this video - it's the first time I've done it!)
@@gridleaderretro It is an excellent tutorial video and visually very well done. I also use GIMP. I'm asking because I also try to make tutorial videos sometimes but I find those the hardest :-) So, one more thing, the green lines, you have a screengrab with and without greenlines and than you fade/disolve from one to the other?
@@AtariLegend Yeah it's quite time consuming to put these together - this one has taken me about 7-8 hours! With respect to the green lines, I have one image containing a screen grab, and another image containing the green lines with transparency behind them (it's a PNG file). The image with the green lines gets placed in a layer in Shotcut above the one containing the screen grab - the result of this is that the screen grab shows between the green lines. I can then just fade in and then fade out the image containing the green lines. Hope this helps :)
@@gridleaderretro well done! It is clear you have an eye for this stuff. We have not seen the last of you.
And talking about time. I think I did around 20 plus hours from script to finish on the lotus video...at least...but still, it is all worth it ;)
Great work, I’m enjoying playing Lotus STE and it could have really helped my arguments with my Amiga owning classmates in ‘91! Shame the STE’s strengths weren’t often explored by developers back in the day. Fascinating video too, interesting to hear about the game’s creation and more about the ST’s workings.
Thanks for the feedback, and I'm glad you enjoyed the video! I think the STE is best described as "quirky" - it's clearly not as strong as the Amiga but it's surprising what we were able to get out of it!
Thanks for sharing 👍
Having owned both Amiga and ST, I always noticed a slight speed increase with racing games on that ST. Probably the slightly faster processer. I think I recall noticing this especially with Super Hang On.
I think the Amiga version of Super Hang On had a few more colours and larger sprites though :)
It's an unpopular opinion but I feel that both ST and Amiga versions of that game were rather overrated. I loved ZZKJ's conversion work on Power Drift though!
Very interesting video, I hope there will be many like this one!
Thanks for your feedback! I'll try to make a few more vids covering the other areas improved by Lotus STE.
Incredible idea for a video. You're explaining techie stuff well, good to hear you too 😉
You must be mistaken. That's the voice of the Hollywood actor I hired for this ultra-high budget production :)
@@gridleaderretro ahhh that makes sense heh. You know your stuff mate. But you explain it well to numpties like me. Like the Blitter which we talked about.
Just great, waiting for more!
Thanks, I really appreciate the feedback!
Great, I remember the pains of using the blitter on the memory bus shared by the CPU, but I guess pumping up the MMU to 24Mhz to squeeze in another 8Mhz "DMA source" (in addition to the CPU and the Shifter) wasnt a viable option, it would have needed a much larger redesign of the architecture to accieve that. Great work done with the limited resources the STe after all has!
Thank you! I don't know much about electronics and hardware, but it does seem like a major limitation that only one of the CPU or Blitter is allowed to access the bus at a time. It took me quite a while to make the mental shift from "the Blitter is a parallel co-processor" to "the Blitter is an alternative tool to the 68k that is faster at some tasks". The 24 cycle startup time and spin down time is also a frustration.
What kind of work did you do with the Blitter in the past?
Awesome video! Super clear explanations of many of the techie buzz words and programming considerations I've heard over the past 30 years re: the ST, without ever really understanding what they meant. Would love more of these videos please 😃
Thanks very much, I really appreciate your feedback! I'll try to find some time to follow this video up with some more content relating to either Lotus STE or ST programming in general.
Great video, thanks for making it. Always fascinating to see what's under the hood with these games. Hopefully more to come from you :)
Thanks Marko, glad you enjoyed it!
Very interesting to hear someone talking about this - recall trying to understand all the blitter stuff back in the day - think a lot of info I gleaned from a Bullfrog tutorial in ST Format. Recall I also had to run the blitter in 'nohog' mode as I was struggling to knock out all the borders in STE Bombaman. If I recall I could never get it 100% so think I just stuck to the bottom border in the end for the main game (I wanted it running at 60Hz)... It just wasn't as easy back then to share problems and solutions.
Thanks for your feedback and I'm glad you enjoyed the video! I remember the Bullfrog tutorials but don't remember them covering the Blitter. But then the world of Devpac and 68k was rather mysterious to me as as a novice STOS coder back in those days!
You're right in saying that we're spoilt these days with the wealth of information and community support available. I'd never have gained the same level of traction with my ST projects back in the day with only the documentation to support me.
I've found the nonhog mode of the Blitter to be next to useless in a gaming scenario - the time slices are too large and interrupts get missed when you're trying to coordinate rasters, music playback and so on. I can't begin to imagine how painful it is with border removal. The only way I could get decent and predictable performance out of the Blitter was to use Hog mode and break things down into small individual blits. Unfortunately there's quite a lot of overhead to doing so (something like 24+ cycles for each blit) but we couldn't work out any better way!
@@gridleaderretro yes I think you've gone about it the right way - I tried everything back then to get the blitter to work well with the border busting and it worked 99% of the time but when it didn't (say every 40 seconds) it was obvious and detracted from the game even more than my graphics skills lol. I did look at not accessing the blitter as I got near the vbl but again I never quite hit on the solution.. I miss those challenges tbh.
And yes I seem to remember it needed a fair few clock cycles just to initialise the blitter .. Yes just looking through my old code I did a check to see if I was near the lowerborder before I touched the blitter.. think even this check didn't help the upper border 100% - I thought maybe it wasn't the blitter but spent so many weeks debugging, I gave up in the end. Looks like I went back to 'HOGBLIT' in disgust... :)
*************
* BLIT4SPRITE (4 planes)
*************
BLIT4SPRITE MACRO
movem.l a0-a2/a4-a6/d0,-(a7)
lea $fffffa21.w,a2 get timer B counter address
move.b (a2),d0 get count value
cmp.w #120,d0 near lower border?
bgt .cont\@ no.. continue..
jsr waitv yes, reuse this frame..
.cont\@
lea blitter,a2 blitter chip address
move.w #$ffff,d0
lsr.w d2,d0 mask off left edge
move.w d0,endmsk1(a2) Left end mask
move.w #$ffff,endmsk2(a2) mid mask
not.w d0
move.w d0,endmsk3(a2) Right end mask
move.b d2,skew(a2) shift data right
move.b #3,op(a2) REPLACE mode
move.l #BLIT_sa,a4 a4=srcaddr
move.l #BLIT_da,a5 a5=dstaddr
move.l #BLIT_yc,a6 a6=dstaddr
move.l a0,(a4) source address
move.l a1,(a5) dest address
move.w #\1,(a6) num of lines
HOGBLIT doblit
addq #2,a0 next source plane
addq #2,a1 next dest plane
move.l a0,(a4) source address
move.l a1,(a5) dest address
move.w #\1,(a6) num of lines
HOGBLIT doblit
addq #2,a0 next source plane
addq #2,a1 next dest plane
move.l a0,(a4) source address
move.l a1,(a5) dest address
move.w #\1,(a6) num of lines
HOGBLIT doblit
addq #2,a0 next source plane
addq #2,a1 next dest plane
move.l a0,(a4) source address
move.l a1,(a5) dest address
move.w #\1,(a6) num of lines
HOGBLIT doblit
movem.l (a7)+,a0-a2/a4-a6/d0
ENDM
Very informative and interesting video, yes I think you should continue with this video series and as Steve from Atari Crypt pointed out, good to hear you also Jonathan
Thanks Mark!
Great video!
Thanks James - glad you enjoyed it!
Very interesting! Thanks
Thanks - glad you liked it!
Atari STE was released in 1989.
Very interesting
Thank you!
How did you manage to modify the code - I assume you don’t have the original source code, did you go through insanity disassembly route!
We don't have the original ST source code, although I did stumble across some of the Amiga source at a late stage in development. But yes, for the most part, we went through the insanity disassembly route - just observing the game in a debugger and trying to isolate the parts of the code that we wanted to modify :)
Would it be possible to enhance this game even more for the Mega STE? Just asking out of curiosity
There's already a feature present whereby you can set the CPU to 16MHz on startup on a Mega STE, allowing for a smoother framerate. It would also be theoretically possible to enhance the graphics and sound further by making use of the additional memory present in the Mega.
So basically it took you under 4 minutes to upgrade the game and now what, you want a congratulations or something? Meh.
:p
But seriously, well done in not just the game upgrade, but this video too.
Thanks for the compliments! If only I had the talent to upgrade old ST games to STE standard spending 4 minutes on each one - I reckon I'd be quite rich by now!
@@gridleaderretro Out of curiosity, is the first Test Drive a game which could be improved by similar work?
@@Trusteft I would imagine so, although it depends on what you mean by "improved"! I'm sure the framerate could be improved as it's pretty jerky given the amount of stuff it's (not) drawing on the screen. If we wanted to improve on the visuals in some way, I guess we'd need to decide exactly what to do. This wasn't a problem with Lotus because we already had the benchmark of the Amiga version to aim for :)
@@gridleaderretro True true many people believed the Amiga version was better. Regarding TD, I am strictly speaking for framerate. As it is there are times when the framerate drops to what feels like 2 fps.
@@Trusteft I would hope there would be potential to improve the framerate of TD - it's rather slow given that there's hardly anything happening on screen!