The Amiga original versionAtari ST demosThe Atari ST portQuality ClaimsReverse Engineering - SummarizedReverse Engineering - The Long VersionNow and then somebody speaks of the "game" Shadow of the Beast and uses it as an example of something the Amiga range of computers could do but the Atari ST could never dream to achieve.
This is totally true: Even with all the time and talent of the universe, there is no way a standard Atari 520 ST could compete, in what is after all mostly a technical demo designed to exploit every single feature the Amiga had.
The actual point of contention is regarding if the Atari ST port of Shadow of the Beast was as good as it could possibly have been considering the usual constraints of time, budget, etc...
The Amiga original version
From a technical point of view, it's brilliant, there is a ton of colors, multiple layers of parallax scrollings, large sprites, good moody music, etc...
Still, it's an interesting game from a technical point of view, and that's probably why there's been so many Atari ST demo groups making their own demo versions showing the keypoints of the Amiga game.
And just to illustrate a bit, for the ones who don't know the game, here a few more screenshots1 before I speak of the ST version.
Just go on Moby Games if you want to see more screenshots, you can also see a number of longplays on youtube.
Atari ST demosHere are a few of the "Shadow of the Beast" Atari demo I could remember, if you can think of other, just tell me and I will add them :)
What these demos all have in common is that they run at a fixed 50hz, most of them are using some form of overscan2, they have colorful graphics, but they also did some technical choices about what to display or not.
A good example is that for exemple both Funvision and Pendragons decided to have multicolor mountains, while both Equinox and NeXT used just a black shape for the mountains.
The reasons are simple: The Amiga was able to display more bitplans independently than the ST, so to achieve something similar on the ST would require to do a lot of real time masking and blitting instead of simple changing some memory screen addresses... which is extremely costly.
But we all know that demos can do things that games can't, because demos don't need to be (very) interactive, there are no highscores to maintain, no monsters to handle, etc...
Time to look at the Atari ST version of the game.
The Atari ST port
Since Eldritch the Cat had previously released a very decent action game - Projectyle - featuring some fast and nice multi-directional scrolling, everybody was expecting the Atari ST version of Shadow of the Beast to be in very good hands...
It was not a catastrophe, the graphics were definitely recognizable, the gameplay and layout was mostly the same, most of the elements were there, which is more than what we could say of the ports on 8bit computers.
Still, it was a bit like being told to close your eyes to receive a great surprise, and when you open them all you see is something disapointing:
Let's try to see for a list of the differences:
- The game does not run at 50fps
- There is a big BEAST logo on top of the screen over a black background
- The color changes in the background are wobbling around
- The fast scrolling wall/barrier at the bottom is not there
- The intermediate plan with the small trees is gone
- The center plan elements all share a very bland palette
- The air balloon and the moon in the background are missing
- There is no in-game music
- There is no highcolor intro picture3
- There is no intro with paralax and big logo
That's quite a lot of differences, and it's very common to hear that shortcuts were made in the development of games or ports in general because of budget issues, time pressure, etc...
Quality ClaimsBeing a professional game developer myself, I'm totally aware of this problem, and I know many games on many machines have been impacted by that, but what really niggled my spider senses was some references to an interview of the author that kept popping all over the place (on Facebook, Atari Mania, etc...) leading to his post from dlfrsilver in Atari Forum:
shadow of the beast ST (Mark mc cubbin here)
Postby dlfrsilver » Mon Feb 02, 2009 8:22 am
I have mailed Mark Mc Cubbin about shadow of the beast ST and a game called tentacle. He has given some bits of what happened with beast ST version:
"Good questions, Shadow of the Beast did very well on the ST (it was no.1 two years in a row in the sales charts). As far as the details, happy to share them.
I know some ST demo scene guys thought it could have been done better and in reality there are areas where it could have been better, however, game development is about compromise and this was the case here. The first version of the game I did used all the same art as the Amiga running at 60/50fps, however, it required an ungodly amount of memory since the most obvious tricks were pre-computing the parallax scrolling ( for the underground section, which was only 2 layers ), then, simply movem.l the tiles to the screen as needed. The reality is thought that this wasn't reasonable ( it would have been a 1meg only game versus 512k ).
After several iterations/tickes, it was decided that this version would be launched either as 1 meg only or on the STE (and of course then we could use the HW scrolling too). In the end the version that was used for the underground sections used 1 bit plane for the background layer of parallax and 2 bit planes for the from layer, this allowed each layer to be independently drawn to the screen as fast as possible without having to have a huge pre-compute buffer. Although I still precomputed the shifted blocks, by carefully arranging the palette so that the odd and even colors were the same for the first 8 colors in the palette it meant that I could draw anything into the first bit-plane and it wouldn't affect the front layer. For sprites, due to memory constraints, again I couldn't pre-shift those for speed ( as always the fastest way draw was movem.l ), so I used another trick which was movep.l, which allowed you to write the graphics data on odd boundries across the ST interleaved screen. I had custom sprite routines for odd and even boundries for speed (versions that used movep and versions that were just straight movem).
There were similar compromises for the tree-sections ( the 11 layers of parallax sections ), I wrote a copper emulator on Timer B that heavily modified the palette to get all the colors needed, the large trees were all sprites pre-computed. Although of course, doing this reduced the overall CPU time available but was necessary to get the additional colors to get it looking half-way decent. The reality is, if I didn't actually have to have a game in there yeah, I could have had the nicely pre-computed scrolling doing it's thing, looking like the Amiga version ( I already had this for first prototype ). Psygnosis decided not to do a 1 meg only version or even the STE version, unfortunately. Around the same time frame we ended up doing the ST version of Flimbo's Quest, this was also a bit of a show-case on the Amiga. This time we could actually get two full color layers running because we could pre-compute the parallax.... Still, overall, I was fairly happy with it given the constraints, many of which you don't have for the demo-scene :)"
Based on this email exchange, the conclusions had been drawn: The Atari ST version had been done by an experienced developper who did all he could have possibly done, and the author of the post concluded:
"I guess now why the ST version needs to be powered at 20mhz instead of 8mhz to be smooth :D"
And the same message kept getting repeated again and again4:
Since I did not have enough actual elements to have a good oppinion on the topic, I decided to look inside the actual code.
Reverse Engineering - SummarizedWhat follows was originally posted on Facebook and Atari Forum, while I was digging in the code, I had written a summary on the original Atari Forum thread but this forum does not show any pictures if people are not logged in, so I decided to write this blog post.
I started the disassembly process from the original version of the game in STX (Pasti) format to make sure that the code I would look at had not been tempered/modified during the cracking process, but I also got the DBUG "hdd/falcon compatible" version, as well as two "filed" versions (one from Automation and one from Medway Boys) because games in file format are often easier to work with.
I used a mix of Easy Rider and Steem Boiler 3.9.4 for debugging/tracing, and then applied a bunch of patches to my version to make sure the code did do what I think it was supposed to do.
The bottom line is: NO, Shadow of the Beast is not as good as it could have been, not by a giant margin: The code is as best "good enough" for a prototype, but most of the patterns I've seen in the code suggest a "beginner++" level at best.
Among the issues:
- The coder NEVER use absolute short addressing mode, so all the color changes take way longer than necessary
- All the color changes are done with move.w, he never move.l two consecutive colors, he never (an)+ or movem.l them either
- He uses JSR in many places where he could have used BSR
- He loves to JSR / RTS (instead of JMP)
- The famed "Copper Emulator" is a mess, a lot of time is spent jumping to empty routines
- The code is full of mulu #400 and divu #25
- He often uses clr.l dn instead of moveq #0
Now, from what I've learned:
- The Eldritch the Cat logo is just an IFF/ILBM animation in ANIM format, so whoever feels like doing a SOTB++ can easily change that.
- The code is a mess, but a proper disassembly should probably not be too difficult to understand
- Adding STe palettes is trivial
- There's enough free cpu time in the small things I signaled to probably either add a music (hint: You have three chiptunes from FFT in the Phaleon you can use for that) or put back the missing scrolling barrier at the bottom
You can play with the disassembled "loader source code": Just assemble it with vasm, then copy it over the floppy with the original files (or overwrite the original beast.prg).
You can also use genst/devpac if you want :)
Reverse Engineering - The Long VersionFor this long version, I'm just going to copy-paste the messages I wrote on Facebook when I was digging in the code.
After that I published a summary article on the Atari Forum, and a user named SwapD0 applied some disassembly magic to generate an ever better disassembly, which I looked at and did a final set of checks:
There you go, it's about as complete as it will ever be, I guess having it all on the blog will help future software archeologist more than if it's spread over multiple places.
2. Some software trickery that allows the programmer to extend the display area by disabling some or all of the borders around the screen, thus allowing up to 416x276 pixels to be displayed instead of the usual 320x200↩
3. Doable on the ST with Spectrum 512↩
4. Denis - 21/06/2015: "As the coder explained it, this game was VERY hard to convert on ST, because every trick and hardware effects needed to be converted as software routines, as well as preshift the graphics, this leading to insane memory requirements (2mb!) when the amiga release needed only 512kb to run. The ST to get in software the same result as the Amiga version would need a 68000 running at 20 Mhz...... The STE hardware scroll brings more problems than it solves, because there are no sprites hardware assistance on it. What's the point of having a scroll running at 50 fps when the computer has so many sprites to put on screen at high speed ? the STE (never mind the ST) was not made for that."↩