Power Drift-style graphics engine for the Atari STE

I'm working on a graphics engine for the Atari ST (that will possibly eventually become a game) to mimic the style of Sega's amazing Super Scaler arcade game Power Drift.
Something similar has obviously been done previously in the form of the official arcade conversion of Power Drift for the ST, which interestingly supports the Blitter chip in the STE. However, I'm having a go at doing it better this time around, helped greatly by the tools, techniques and knowledge we have access to in 2021.

[@goddessesstartrekonlinefle3061]

Cudos for sticking with ST development there; Reminded me I've personally not done anything with the ST since contributing to HAtari some years back, seeing your work reminds me of whats possible, good luck completing it! Your demo reminds me inescapably of Out Run, Super Hang On and Space Harrier in various aspects.

[@gridleaderretro]

Thank you! I like working on the ST, and especially the STE with the additional DMA and blitter hardware. It's a surprisingly capable machine. One of the most interesting aspects of modern-day ST development is the fact that we can take advantage of modern tools and techniques (optimising compilers, source control etc...) to streamline the development process and squeeze more out of these machines than would have been practically/economically possible by mere mortals back in the day.

[@jamesfmackenzie]

A lot of sprites for the good ‘ol STE to handle - looks very smooth!

[@nekononiaow]

Technically, they are not sprites (the STE does not have any hardware sprites) but rather Blitter Objects. But you are right, the frame rate is impressive for this amount of pixels drawn.

[@gridleaderretro]

Thanks James! I'll be happy if I can create some kind of game and it ends up being smoother than the original home conversion of Power Drift!

[@JMDAmigaMusic]

@@gridleaderretro well original power drift was a drag ;) but yeah

[@scottelkington7661]

Looking damn cool! Have the viewpoint lower, this would make the logs look better and being closer to the ground will help with sense of speed and be more arcade like. And a wider road (sure you'll fix the horizontal clipping) so the camera can follow the car as it moves across it.. amazing progress so far though!

[@gridleaderretro]

Thanks Scott - I appreciate the continued feedback and I am taking it on board!

[@IntoTheVerticalBlank]

NICE! This is going really well!

[@gridleaderretro]

Thanks man!

[@soviet9922]

super cool

[@Vretrocomputing]

Superb! Go ahead!

[@gridleaderretro]

Thanks! Trying to find more time to work on this as I think it could make a cracker of a game!

[@nekononiaow]

I hope we will eventually see some updates to this engine! In the meantime, here are some optimization ideas to explore: ∙ There is a lot of overlap between the road segments (between 1/3 and 1/2) so it is possible to only draw the vertical sections of each segment that are not overlapped by a closer one, the computation is quick enough and will save you a lot of pixels to blit each time. - Does the blitter have a fast copy mode when it does not need to shift the data? If so, you could take advantage of it for the non-edge sections of each segment by copying them rather than shifting them. The left and right edge of each segment would still need pixel precise shifting but the centers would not. This would require adjusting the graphics but that seems a reasonable constraint. - I suppose you are clearing the entire screen prior to every rendering frame? Instead, it would be worth maintaining a data structure (a quad tree maybe) to keep track of which areas have been drawn to and need clearing and only clear those instead of the whole screen. In this particular example you would probably save at least 30-40% of the clearing time. - The previous concept can be pushed even further: prior to rendering the next frame, precompute the positions of each segments and objects to render and use those to update the abovementioned data structure. This will allow to reduce clearing to sections which are not drawn over by new objects. Looking forward to hearing about your progress!

[@simonebernacchia5724]

I would suggest this to improve: - adaptive display - i mean, increase/decrease the number of object on screen according to CPU power - keep road tiles flat style, might decrease rendering time - smaller cars, max 64px so to have more manuverability, maybe switch on europe/japan city cars - for tracks: the more varied the better: add jumps, forks, other gimmicks - maybe split screen and serial link if can be handled - will NOT be Power drift anymore but a game on its own

[@mattmyers9351]

Super cool! Looks great so far! Keep up the good work!

[@gridleaderretro]

Thanks Matt - appreciate your support!

[@mattmyers9351]

@@gridleaderretro no problem sir, glad to help!

[@mortenera2294]

Yoo! I remember asking if an STe Power Drift was possible months ago, but I didn't expect it to be this smooth lol

[@gridleaderretro]

Cheers! It might slow down a little further once there's gameplay/other cars/position indicators etc, but this is roughly the kind of framerate I'm hoping for when it looks more like a finished game.

[@odlotowy]

wow! Nice game

[@BubblegumCrash332]

Impressive!! That 68000 must be steaming

[@gridleaderretro]

Cheers! A lot of the performance comes from precalculating things, as is often the case! Still quite a lot of optimisation to do. I'm hoping that I'll be able to get a framerate comparable to what's shown here once I have a game in there with moving cars, score overlays and so on.

[@JMDAmigaMusic]

Question: did you consider render the landscape in 160x100 then display the doubled frame in front of the players to gain speed? How faster can be? Big pixels should not be a problem because will look like a real superscaler hardware ;) Amiga version of Driving force did use a similar method

[@gridleaderretro]

Thanks for your feedback. I haven't considered using any pixel doubling techniques yet. I'm hoping that I'd be able to get a reasonably steady 20fps in-game without resorting to such techniques :)

[@JMDAmigaMusic]

@@gridleaderretro hope so too, that would be a slap in the face of those saying it cannot be done ;) maybe just double horizontal might help

[@JMDAmigaMusic]

I did see the twitter feed and have a question about the path mapping: in the original there are several kind of road surfaces: asphalt, gravel, rock, concrete, mixed, bumps AND even jumps; did you figured a way to do that? Are you able to handle some variations that are not in the arcade like forks or shortcuts if you want to do something original?

[@gridleaderretro]

All of those surface types are theoretically possible - the graphics engine just needs to use the appropriate bitmap for the road segment, and the car handling system (which is not yet implemented) would need to adjust the handling accordingly. Similar story with jumps - it's just a matter of drawing an invisible road segment and adjusting the car handling to reflect the fact that the car is airborne. Forks and shortcuts could also be done with the appropriate modifications to the core data structures but I'm looking to keep things simple for now. I'd rather deliver a very basic game in a finished state than a more complex game that I never get to finish!

[@gridleaderretro]

Regular progress updates on this project are available on my Twitter profile at twitter.com/RetroRacing !

[@simonebernacchia5724]

Hey, did you ever progressed in the engine development since last year?

[@JimLeonard]

I'm not STE-savvy; is this pre-optimization, or post-optimization? Asking because the framerate is lower than I was expecting, but that simply might be the result of so many sprites to mimic the Power Drift aesthetics. Also, are you doing full/real 3-D calcs for the track, or faking it? Asking because I see other parts of the track in the distance when turning (nice!).

[@gridleaderretro]

This project is just 4 weeks old at the moment. The high-level algorithmic approach isn't likely to change much but there's some scope for low-level optimisation - mainly around minimising the work done by the Blitter (e.g writing solid graphics blocks directly instead of using and/or passes, reducing bitplanes etc), and optimising the fixed point math. All code apart from the sky gradient and the object blitting code is currently in C so some potential gains there. The Blitter in the STE doesn't have a great deal more raw blitting power than the 68k - it just comes in useful for pixel shifting of graphics, selective bitplane writing and so on. This might explain how what's going on in the video contrasts with your expectations around framerate. All displayed objects have a position in 3D space and are transformed and rotated using what I imagine are rather standard calculations - I'm something of a novice in this area. This is a very deliberate decision - the ability to see other parts of the track as you drive around is one of the things I really love about Power Drift!

[@JimLeonard]

@@gridleaderretro Thanks for the explanations, this all makes perfect sense. Very cool that the base underlying calcs are real 3-D; this is why Test Drive 2 "feels" so good despite it looking like a standard racer. Keep up the great work!

[@gridleaderretro]

Cheers! I didn't know that Test Drive 2 takes place in a "real" 3D universe - I'm going to have to revisit that one.

[@purplehaze2342]

Lol

[@gridleaderretro]

Thanks for your insightful and intelligent comment!