shadow of the beast ST (Mark mc cubbin here)

[Dbug]

Not bad

Which reminded me that I forgot to post my blog post about the whole thing: http://blog.defence-force.org/index.php ... &ref=ART62 (not that this adds anything to the current thread, it's just a summary)

[Cyprian]

nice article Dbug

[wietze]

I just looked into the disassembled code, and I must say that my eyes are almost bleeding from the abhorring code I saw. I always considered (from talk mainly) that the shadow of the beast game was the pinnacle of ST gaming. But I have to conclude that when looking under the hood, this turns out to be a hoax. Perhaps the ST coder was under tremendous time pressure to get this thing released; but the code clearly indicates that the majority part of it was never seen a second time.

The disassembled source can be very used as a fun test when learning to optimize 68k assembly code

[Hazzardus]

Not bad

Which reminded me that I forgot to post my blog post about the whole thing: http://blog.defence-force.org/index.php ... &ref=ART62 (not that this adds anything to the current thread, it's just a summary)

This was a really interesting read.

I always considered (from talk mainly) that the shadow of the beast game was the pinnacle of ST gaming.

What? The game was garbage when it was first released on the Amiga, although it did look fantastic. It was and always has been a terrible "game". Who were you talking to? Joking aside, it was terrible. I owned the big box version on the Amiga (the one with the T-Shirt), and even knowing the game was pants, I bought the big box ST version too. The only half decent version in my opinion was the LYNX version (3rd time lucky for me, because yeah, I bought that one too).

[joefish]

just impressive
how many memory is needed? 512kB will be ok?
and how %CPU is free?

It runs on a 520. Though you might have to Auto-Run into it.
It takes just over 1 frame to redraw all the scrolling. And it's the full 320 pixels wide. Even the Amiga one is clipped to 288 pixels. That leaves loads of time in the second frame to draw sprites, of which the Amiga only has two on-screen anyway. And the main character actually has twice as many animation frames as the Amiga! In total what you see is taking about 1.5 frames to render.
You could maybe do it one frame by shrinking the view, but then you'd need twice as much pre-shifted scrolling!
I did have some ideas on reducing the memory usage, such as narrowing the background mountain graphic to 256 pixels, and adding a few extra scenic chunks that can be pre-shifted dynamically into one more slot. So as long as they're kept far enough apart so the routine has time to swap them over, you could add one-off features like the well, the Home tree, statues, etc.

[joefish]

One thing I notice in that Facebook thread is that someone said the SotB programmer used playfields, but it can't be. The background is in reduced colours, but the trees are still the 7-colour ones from the Amiga. The sprites seem to be drawn in a limited subset of the trees' palette, but that might just be down to programmer's choice since green and the light brown of the background wouldn't be much use.

Re-reading the first post in this thread, the programmer 'confesses' that the trees were done as software sprites, which is why that section is so slow!