@@gridleaderretro Cheers. I'm always amazed how much interest there is for the old games. I can barely remember that long ago, certainly not how things worked, but It brought back many memories of optimising things. Great to see the Atari version looking and sounding like the Amiga one. I have no idea how you even did this without any sourcecode. Amazing.
Hey Shaun ... we were speaking about this earlier on messenger. Nice to see you stopping by mate. Great games are great games. Thats why we still play what you and Andrew created👏
There's still a lot of love for these games - as Amiga1200Mark says below, good games are good games! I'm glad that the video gave you a trip down memory lane. I imagine they were good times, if possibly somewhat stressful and pressured given the sheer quantity of code you wrote for Lotus across both platforms! I'd love to say that there was some degree of genius behind what we've done here, but I guess we're just two reasonably motivated and intelligent guys with access to much better tools than were available back in 1990! We were able to trace through the game code in the CARS.REL game code file using an emulator debugger, identify the parts we wanted to change, and then drop in new binary patches created using an assembler. It helped a lot that the original Lotus code was well-written and easy to follow - even the parts using self-modifying code! We've published our source code for the benefit of the community at github.com/jonathanopalise/lotus-ste if you do wish to explore further. Thanks so much again for dropping by and leaving the comment - it means so much that our humble little project has been noticed by one of the original dev team behind this timeless game.
@@gridleaderretro It's a long time ago now, so my memory of exactly how the Amiga and Atari worked is hazy, but I always wrote in assembler - Devpac on the Amiga ? All the art was done by Andrew Morris in Deluxe Paint. I have the sourcecode (for the Amiga version ) if you want a look - cant find the Atari code though most would be the same - but it seems you've done everything well enough without it. The Atari versions of all the Amiga games were always ports, usually took a month. I think on some games, maybe Supercars, we prerotated maps for machines with more memory. As I said though, it's a very long time ago :)
Very interesting. You are displaying more to the screen in the STE version, so it looks better and the single pixel skew maves it look smoother, The perception is that it's just as fast or faster because of the added content and smooth rendering.
Now this is a VERY interesting comparison between the two ST(e) versions of the game. Quite surprising to see the ST rendering quicker, but with less content and details (road lines). A very good video series! 👍
Thanks for your feedback - I'm glad you're enjoying the series! We could almost certainly get the STE version to render as quickly as the ST version if we were to use more memory, but that would of course be cheating :)
A bit off topic, but I think it would be a great idea to port 8-bit Sonic 1 to Atari STe. It has a faster CPU compared to the Master System, but the sound chip is almost the same. Maybe we can add some more colors too
Interesting idea! I imagine the STE could do something in-between the Master System and Megadrive/Genesis versions. Zool on the STE gives a good benchmark of what might be possible.
This seems indeed very likely as their fluid motion is immediately visible whereas 16 pixels movement seems likely to be interpreted as choppy. This may be a case where it may have been preferable to go with much simpler car rendering (pseudo 3D flat surfaces) to allow them to be positioned at pixel precision rather than super nice cars at 16 pixels intervals.
Here's one I made earlier: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-pJtaB_JPx5U.html The framerate shown in the STE (top half) is a bit slower than the final version as some further optimisation work was done after this video was produced.
@@gridleaderretro Yep, I saw that one, but I thought it was interesting to see one frame drawn like in this video :) Edit: Aha, so the STE is an unofficial work in progress version?
@@d_vibe-swe Ah - you mean you'd want to see a frame buildup video for the Amiga version? Sorry, I know very little about the Amiga and wouldn't know where to start :) The STE version is considered finished by the way - I don't have plans to do any further work on it.
I thought that if you don’t run the blitter in HOG mode then you wouldn’t have to split up the drawing into small blocks, you do need a tight cpu loop though after starting the blitter to restart it if the operation is not complete. Or did you try this and found it to be slower?
I tried the Blit mode (the mode that isn't Hog) in Lotus STE and it didn't work unfortunately - there were interrupts being missed and the whole game was being slowed down. Using the Blitter in Hog mode and splitting into small chunks (of around 20 words each) seems to be the key to balancing the need for fast blitting and interrupts being serviced. It's a pain, but it is what it is :)
It would be really interesting to perform single pass masking using Anima’s masking technique. It would cost memory to pre shift the masks but it would be far better for rasters and probably twice as fast. Span filling the car in the foreground would be very very quick indeed. I think you might get a solid 25fps out of the blitter that way :)
Yes - there's definitely scope for speeding things up using techniques like that. I have made the source available on Github for anybody who fancies the challenge :)
This is fascinating to look at again! Keep on doing these! One question: Do you manually clear the screenbuffer before your recording, to start on a blank black canvas? I ask because in ANARCHO Ride I just draw over the last frame in the buffer - reusing as much as I can from the dashboard. Even if I could record the drawing, it would never be on a blank screen.
@@gridleaderretro ah cool was doing fast cheap hacks on the amiga version. But your tech is fantastic. Would love to colaberate some info if possible. I dont know any st hardware info, only amiga, but i know that lotus 1 , 2 and 3 basicly use recycled code with mods and enhancement. Rough inspection i see track data is in segs then read and turned into straights hill and curves in a table then that is read again and turned into copper and blitter etc etc I know there is a few luts for calcs. Ive done a few cheats some already in trainers. Speed collisions time , force fuel etc etc Anyway be good to talk about it.
i wonder if you can help me? i tried to code a racing game for the C64 but could never figure out the maths for displaying the road properly? would you have a general idea or point me in the right direction?
The problem you're likely to have is that the most "correct" maths for displaying the road correctly will be way beyond the capabilities of the C64's CPU. You'll need to improvise heavily in the same way as the majority of commercial C64 racing games did. You may be able to get some inspiration from Lou's Pseudo 3d Page at www.extentofthejam.com/pseudo/, but you will almost certainly need to tailor these methods heavily to accommodate the constraints of the C64's CPU.
I like to think that the additional lines on the road speak for themselves in the visuals! The gradient isn't "drawn" as such - it's a solid block of colour 15 like on the ST but is put in place by means of Timer B rasters.
No doubt the framerate of Lotus 2 could be increased - the real questions are "by how much?" and "how long would somebody have to spend on it?" 😀 Shaun Southern did a great job of optimising Lotus 2 for the ST - I suspect he reached a point of diminishing returns and left it there. I suspect the potential gains are in single figure percentage increase of framerate, even with use of the Blitter.
@@gridleaderretro That new homebrew based on WEC Le Mans arcade for the STE is as fast and smooth as Lotus II on the Amiga so an STE port I suspect could be identical. The STFM however like you say is probably highly optimised, I know for a fact there is no chipset bandwidth left spare on the Amiga version hence to run Lotus III with zero frame drops you have to run it on an Amiga 1200 or better model as the RECS system needed some DMA/chipset bandwidth etc and something had to give. Lotus II is the fastest and smoothest STFM 2.5D routine I know of personally.
@@retrotronics1845 That new homebrew based on WEC Le Mans arcade for the STE (my very own project in case you're not aware!) is much smoother than Lotus 2 on the Amiga. Lotus 2 on an OCS/ECS Amiga runs at around 20-25fps I believe, whereas the STE WEC game runs (mostly) at 50fps. But the STE WEC game is doing much less work than Lotus 2 (appearances can be deceptive I know). I personally don't think that Lotus 2 on the STE could be as smooth as the Amiga version without some superhuman effort, although it could come close (as we've done with the STE version of Lotus 1). The Amiga version makes heavy use of the Copper, and even with the extra chips in the STE, all those colour changes have to be done in software with the 68k carrying the burden. It might be possible to get some extra performance out of the STE by upping the memory requirement to 4 meg and making use of memory-intensive techniques such as compiled Blitter sprites (as used by the WEC game). You might also want to check out Crazy Cars 3 for the ST, which to me comes very close to Lotus 2 in terms of accomplishment.
@@gridleaderretro Oh! I didn't know. I must congratulate you on such amazing work for the STE, I saw it on a thread on Amiga forum a couple of weeks ago. Your video is as impressive as the new MegaDrive 2.5D homebrew racing game or better even. PS I have two Mega STEs with 16mhz 68000 if you would like to support the limits ;) Rare machine but I needed a 16mhz ST/STE to play Gauntlet 1 smoother!
Thanks! By "accredited STE", do you mean real STE hardware rather than an emulator? If so, yes - we were testing on real STE hardware throughout the course of development to ensure compatibility. If anything, compatibility with real hardware is more important to us than compatibility with emulators!
Would there be enough memory to fully pre shift the masks so that you could use the CPU instead of the blitter to mask all 4 planes using the same data registers? If not could the blitter be used to shift the mask off screen then use the CPU to apply the mask on a screen? Would it save enough time to be worth the trouble though.
It's certainly a possibility, although it would involve a considerable amount of extra work, and as you say, it would need to be profiled. With the current implementation, we've been very fortunate in that we've not had to add or modify any of the existing graphics data in order to leverage the Blitter. The only exception to this is the data for the background mountains, which gets preprocessed on load for each stage.
Very surprised indeed. Would it be too much to ask to do a video like this for ST, STe and the Amiga version of the game? I think WinUAE has some cool features that allows you to see how efficient you are using the DMA slots. Someone said the Amiga version was in fact very well done. I always looked at it as a CPU only port from the ST, guess I was wrong.
What you have here already shows both ST and STE. I'm sorry, I wouldn't have a clue how to do this for the Amiga :) The Amiga version is anything but a CPU port from the ST. As I understand it, the game was designed and built around the Amiga hardware, and the ST version was then derived from the Amiga version with a whole load of sacrifices made to get the game working on the ST. There are lots of magazine articles from the time where Shaun Southern goes into some detail about how the game is designed to make specific use of the Amiga hardware.
WinUAE is unfortunately not very scriptable (or at least was not, last time I checked) so it would require tinkering with its source code to add the "freeze and simulate screen display" feature that @gridleaderretro is using here. It is definitely possible but unlikely to be easy.
@@nekononiaow Just to be clear, the backbuffer captures shown in this video don't involve any modifications to either the emulator or the game code. All I'm doing is setting the emulator debugger to break on horizontal blank, and then capturing the contents of the backbuffer to a numbered binary file every time this happens. I then convert the resulting sequence of binary files to PNGs and then sequence them into a movie. There's a bit of additional magic to make sure that the rasters show correctly. Assuming that the WinUAE debugger can also break on a horizontal blank or similar, a variation of this approach should also be possible on the Amiga (putting aside the additional complexities that things like the Copper and hardware sprites bring to the table). I can help out if somebody wants to give it a try.
@@gridleaderretro Nice, I like the simplicity of it. On the Amiga things would be quite complicated by the presence of the Copper list which would need to be re-interpreted when drawing the back buffer with the proper colors. Some games also have mid-screen bitmap splits which would actually require the Copper list to be interpreted before drawing the back buffer. But all in all, the principle is indeed the same. Great idea.
@@gridleaderretro For sure, it might be! I admit that : ) It's just my 'disappointment' on how Lotus doesn't run smoothly even on A4000/4000T. As far as I've understood, they have a processor that is somewhat equivalent to the i486... which can run the lotus super smoothly! Lol. Not that these things would actually matter. I love playing with my c64, a500 and pentium II pc : )
@@d_vibe-swe Ah! I didn't know cpu isn't reserved for such taxing or heavy screen scrolling operations. Blitter and copper? Yeah. It's quite smooth for amiga :- ) but when I saw the PC version I was like lol this scrolls way too smooth it's almost disturbing, but yet, somehow nostalgic and nice : p
It would be great to see you develop an STe version of Super Hang-On. It's a decent racing game for the original machine, but it pales in comparison to the Amiga port
So would it not be possible to use the original sprite drawing in the ste version? Or would it still be slower due to the sound? Is it something you have tested?
The original sprite drawing works fine in the STE version, but it's restricted to drawing the sprites at 16 pixel horizontal intervals. Using the Blitter gives us the ability to draw sprites at 1 pixel horizontal intervals (as with the Amiga version) but looks to be a little slower.
@@gridleaderretro sorry. What i was getting at was is it possible to revert that part of lotus ste back to the faster older code to speed things up or would that mean that the blitter couldn't be used for any of it like the road drawing?
@@Barcrest Yes, you could revert the sprite drawing back to the original code very easily. The performance gains would be marginal though, and it would look absolutely awful as with the original ST version :)
