Shadow of the Beast on Amstrad CPC+!!

Enlighted (4140)

26-02-2018, 20:06

Overflow wrote:

Sure! it has some nice features for a 8bit platform - moreover when compared (injustly) with older older platforms. It can't beat MSX2(+) which was released before - no need (again) to start a flame war. Then? well, MSX2(+) could produce some wonderful fx for a demo - such as this SOTB screen on GX4000. As I wrote in my thread: just missing some motivated guys to turn that "it could" into "yes we did it!"

msx sprites are a lot more limited than those on amstrad....

Por maxis

Champion (512)

26-02-2018, 21:12

Overflow wrote:

@maxis thank you!
I'm the guy behind that "Shadow of the Beast" screen on Amstrad GX4000.

Hello, Overflow,
Welcome to the forum! Great having you here. Thank you for replying.
I'm working on the CPC FPGA HW emulation for quite a while now...
Being very curious about SOTB demo, I'd like to understand whether it's possible to:
1. create a full game? Does it have to be in the cartridge (like PoP for C64) or can be loaded/overlayed from the floppy?
2. is it possible to sustain the sampled sound? Personally, the SOTB sound adaptation in the demo is amazing... On the stock hardware. The sound is as important as good graphics in SOTB.
3. when running on MSX2+ would it be possible to achieve the comparable parallax performance on the main level?
4. Also noticed, that Turbografx doesn't have true two planes in the underground levels (when comparing to Amiga).

BTW have you had a chance looking at the PoP on CPC? Is there any free CPU space in the main loop to add some decent music?

Thank you again!
A+

Por Maggoo

Paragon (1217)

26-02-2018, 22:07

Overflow wrote:

Everyone should know Maggoo's great attempt on SOTB screen. To be fair, it should be compared with my own attempt on stock Amstrad CPC6128. Both screens were made years ago! and OK did not feature that multi-layers thingie (moon+balloon+cloud+tree=4layers). Well! now I'm feeling older and older - I should stop talking about 25+ years old events!

To clarify, I was not the programmer of the SOTB screen. It was made by another IOD / ABYSS member (Mumbly), same person now working on the AGONY V9990 port :)

Quick question about the CPCPlus SOTB screen, how are those multiple layers achieved? Does the CPC plus support multiple layers or is it using the hardware sprites capabilities?

Por keith56

Master (162)

27-02-2018, 05:01

Maggoo wrote:

Quick question about the CPCPlus SOTB screen, how are those multiple layers achieved? Does the CPC plus support multiple layers or is it using the hardware sprites capabilities?

The CPC does not support multiple layers - to my knowledge the effect is done with the 'hardware sprites'

There are 16, but you can move them around as the screen draws with raster interrupts if you are clever and this makes them appear more than once - however it's tough to change them (The C64 could do this i believe by changing the sprite pointer), so it can only really be done if you need the same sprite again (eg tree trunks in Prehistorik - or the status icons in my ChibiAkumas)... The sprites can be scaled to 2x or 4x which is why some of the paralax seems blockier than everything else

Por Grauw

Ascended (10772)

27-02-2018, 11:04

To make a full-screen parallax layer with sprites on MSX2;

With 32 sprites and a limit of 8 sprites per line you can cover an 128x64 area of the screen.
With x2 sprite magnification, this increases to 256x128 and covers the full width of the screen.
With a sprite attribute table split you can exceed the 32 sprites limit and add a second sprite plane below the first for the remaining 84 lines.

Now you’ve covered the entire screen with a layer of fat-pixel sprites.

Por JohnHassink

Ambassador (5672)

27-02-2018, 17:13

That sounds interesting Grauw. Has anything like this ever been done before on MSX2?
And would it also be possible to simulate scrolling by redefining the sprite patterns on-the-fly, as well as saving some horizontal lines (so not fill them up with sprites but put a status bar or something there) so the remainder of the available sprite slots could be used for player and non-player characters? Which maybe could even switch planes (or the 'background' does) to make characters either go behind or in front of stuff?
I'm just theorizing here, but this does tickle my imagination. I think something pretty smoothly moving and nicely looking could be done with this.

Por JohnHassink

Ambassador (5672)

27-02-2018, 14:39

Or in other words: Has anyone really been far even as decided to use even go want to do look more like?

Por syn

Prophet (2123)

27-02-2018, 16:27

I've theorized about this idea a few years a back on #msxdev. I thought it would be a nice idea to use when your background layer is also blocky.

I thought it was a shame screen 3 does not offer msx2 sprite modes even on a v9938. I mean, the lowrez blocky nature of screen 3 would fit a magnified sprites foreground layer perfectly. (iirc the sprites on scr3 are just displayed at their normal 256x212 resolution)

So otherwise, screen 4 maybe and do a paralax scroll there as well so you have a crazy 3 blocky layers for a game ;)

I've always kept this idea of magnified sprites for paralax scrolling in mind, I could imagine some simple platformer with some lowrez gfx but fast smooth gameplay. It is something I wanna do later when im more skilled in coding.

Por Grauw

Ascended (10772)

27-02-2018, 16:57

Note in Overflow’s demo, the trees are also fat pixels, so mixing slim with fat pixels doesn’t necessarily need to look bad. And the trees are also only half a screen wide so the remaining sprites can be used to either add colour detail or for other objects / layers. The player sprite is also made with fat pixels.

IMO the biggest snag is that sprite magnification is a global setting, not a per-sprite one. If it were per-sprite, I think we would’ve seen magnified sprites being used quite a bit more often on MSX.

Por syn

Prophet (2123)

27-02-2018, 17:14

yeah so that is why I feel I need to design a whole game around blockier graphics.

Main hero sprite would also need to be magnified sprites. If background layer was normal graphics, I think ppl would just complain

Making bg also "doublesized pixels" would make it less notable.

(btw this idea was one of the reasons I did my #msxdev compo 2012 entry with magnified sprites, the plan was to add some bg elements with sprites as well but I ran out of time)