Deconstruction of Shadow of the Beast on Atari ST

[@genblob]

I really wish WJS design worked on porting this instead of Eldritch the cat since all the games they ported from the Amiga to the ST are fantastic and technically impressive. They were probably rushed to get this one out and it's a shame because the end product is utter shit and it makes the ST look way weaker than it really is.

[@AtariLegend]

If you continue on this path, you are going to become a very famous retro scener! I am so curious now ;-)

[@stunthumb]

Yeah, it's interesting stuff.

[@gridleaderretro]

Maybe between us, we can finally give the ST the recognition it deserves in the retro scene!

[@gridleaderretro]

Thanks!

[@LeGlod]

It will take a survey to find out which ST game deserves a STE version.

[@gridleaderretro]

Every ST game deserves an STE version! All we need now is another 1000 people to do the work!

[@Corsa15DT]

Even the C64 is more advanced than the ST in terms of hardware scrolling, sprites, sound chip. ..

[@gridleaderretro]

Correct - the ST does lack hardware scrolling and hardware sprites, and the SID is generally regarded to be superior to the YM. (Note that the STE does have hardware scrolling but no hardware sprites). However, the combination of a weak CPU plus custom graphics hardware means that the C64 is only able to show its superiority to other platforms in a narrow set of use cases - that being 2D sprite-based scrolling games. I like the C64 but I'd argue that other platforms such as the ST and Amstrad CPC are more rounded platform due to the faster CPU that can partially make up for the lack of dedicated 2D graphics hardware and allows them to excel in other use cases such as 3D - a notable weak point for the C64.

[@Corsa15DT]

@@gridleaderretro if the C64 had at least 128k and 2mhz cpu, it would beat the ST in all of the 2d platform games. Mayhem in Monsterland, Sam's Journey 2017, Sonic the Hedgehog 2021 are phenomenal games, that the ST probably can't match. Sonic need optimization, its still slow. Btw, I think the STE gets the hardware scrolling from the blitter, right?

[@gridleaderretro]

@@Corsa15DT I don't think a 2MHz CPU or 128k memory would make a massive difference - the C64 still wouldn't be able to match the visual fidelity of the ST (i.e. unrestricted 320x200x16 colours). Your point about smoother scrolling on the C64 still stands but the visual fidelity of the C64 graphics would remain weaker due to the constraints of the graphics hardware (most scrolling C64 games are based upon 8x8 tiles with limited colour restrictions I believe). The STE has dedicated hardware scrolling independent of the Blitter, in a very similar fashion to that provided by the Amiga. Very few commercial games used it. I've not verified this independently but I believe Zool and Sleepwalker and two games that do.

[@Corsa15DT]

@@gridleaderretro My bad, I meant the they used the blitter to get sprite support. You are right about the rest.

[@gridleaderretro]

@@Corsa15DT Exactly - no hardware sprites on the ST or STE. The Blitter isn't much faster (and can be slower in certain cases) than the CPU for drawing sprites but avoids the need to chew up memory with preshifted sprites.

[@AtariCrypt]

I think I'm mellowing over the years. Considering the CPU is doing the lot, it's impressive. But still a bad game. Sometimes I do wonder how much better the STe version might have been... But... It'd still be a bad game. Great video. I second what Maarten is getting at too 👍🏻

[@MickeyKnox]

Yeah ... I remember back in the day, I saw the Amiga Version and at first it was like "OMG ... best graphics ever" but then we played the actual game and it became boring very fast. It looks awesome, but lacks fun.

[@AtariCrypt]

@@MickeyKnox basically, it's a demo.. like the ones in Cuddly or European demos for example. Play something else 😂

[@gridleaderretro]

It's really not bad looking as long as you don't put it alongside the Amiga version! I must admit, I'm curious to see what would happen to the framerate if the graphics routines were changed to use the Blitter instead.

[@AtariCrypt]

@@gridleaderretro your quest!!? 😎

[@gridleaderretro]

@@AtariCrypt Too many interesting things to try out, not enough hours in the day!

[@crustycobb8286]

A terrible conversion for us sadly

[@gridleaderretro]

Only to be expected for a game originally made to play to the strengths of the Amiga I guess! I suspect it could be made better on the bog standard ST, but not much better. More memory and/or use of the STE chipset would close the gap, but the fact remains that the game was originally made with the Amiga in mind.

[@crustycobb8286]

@@gridleaderretro the conversion could have been a lot better I remeber an ST disk where someone did a demo of their own version sure it wasn't as good it never was going to be but it was a lot better than what we had and had music decent too

[@s_t_s4846]

@@crustycobb8286 I guess you are thinking of the Phaleon Gigademo that offered 4 different menus, one of them being an overscan version of Shadow Of The Beast. But as the authors mentioned, this is only a demo menu, not a full game. kzbin.info/www/bejne/imjMdZyVqthsatk

[@IntoTheVerticalBlank]

Very interesting!

[@gridleaderretro]

Thanks!

[@kometbomb]

So much overdraw...

[@gridleaderretro]

Indeed! I guess whoever wrote it decided that a brute force approach was quicker than trying to eliminate overdraw. Or maybe they didn't even think about it :)

[@kometbomb]

@@gridleaderretro It would be a challenge to avoid it though! Visibilty check for e.g. "macro tiles" would cost something esp since you can just fill the background with no checks at all.

[@gridleaderretro]

@@kometbomb Exactly. I imagine you could do something with a lot of precalculation, but not many people had 4 meg ST's back in the day :)

[@nekononiaow]

I do not think much pre computations would be needed as there are a few low hanging fruits there: - sprite opaque areas: those are drawn at the same speed as the areas with transparent pixels when they could have been drawn twice faster with a copy eliminating the need to mask them with the background. - that gives us the second optimization: determining rectangular areas where opaque sprites section and background overlap takes very little time compared with the corresponding filling time (twice!) of those areas so they would only have to draw the parts of the background which really need to be visible. These would not necessarily increase frame rate much, rather prevent it from decreasing in the presence of massive objects but given how simple those changes are to implement, the return on investment looks pretty interesting.