Shadow of the Beast on Amstrad CPC+!!

Page 6/10
1 | 2 | 3 | 4 | 5 | | 7 | 8 | 9 | 10

By DarkSchneider

Paladin (869)

DarkSchneider's picture

02-03-2018, 15:47

Grauw wrote:
DarkSchneider wrote:

no command engine for "game mode" AKA SC4, this latter one probably easily implemented, but they did not care at all.

I don’t think the command engine would really be useful in the pattern modes. The V9958 supports it but I’ve never come up with a decent use for it.

True, I miss also a linear copy command. The bitmap paradigm is another point, perfect for applications (copying text fonts and images) as saves you much coding (also smaller programs using less RAM), but leaks functionality for things like sprite handling or other types of data.

For Shadow of the Beast on MSX2+, we have 2 options concerning characters:
- Use magnified sprites like on the CPC+ version.
- Use normal sprites with SAT rotation so some flickering. I think this one is better. As your character is humanoid (taller than wide).

It would be interesting talking about possibilities for a MSX2 version. I always think that for action games an adaptation to SC4 is the best option.

By Grauw

Ascended (8455)

Grauw's picture

02-03-2018, 16:44

Agree, screen 4 is the best option for anything that scrolls horizontally in general. In this specific case especially, because since adjusting r#18 during command execution causes corruption, a screen mode that you can use without using copy commands is advantageous when you need to adjust it so often each frame. To avoid border flipping, covering them with sprites positioned independently for each scrolling band.

Screen 5 will be very tricky, with the multiple bands scrolling at different speeds. The method to scroll in screen 5 (back buffer copies spread out over multiple frames) becomes more complicated, because you do the back buffer copies and page flipping independently for each band. While at the same time the frequent scroll register adjustments make command executing very challenging.

By hit9918

Prophet (2867)

hit9918's picture

02-03-2018, 17:08

the border wobble can be fixed with anti wobble tiles
no need to snip the valuable sprites

By hit9918

Prophet (2867)

hit9918's picture

02-03-2018, 17:36

and instead picking from the list "the amiga game that one cannot do" and whining
one could pick from the list "the things the amiga cannot do"
like wing commander on screen 8!!!

By PingPong

Prophet (3448)

PingPong's picture

02-03-2018, 19:52

hit9918 wrote:

the border wobble can be fixed with anti wobble tiles
no need to snip the valuable sprites

we need a proof of concept of anti-wobble-tiles because of the color spill problem

By DarkSchneider

Paladin (869)

DarkSchneider's picture

02-03-2018, 20:10

Excuse me but for "wobble" means the displacement because the horizontal adjust register? If so, for tiles I say the same than about sprites, I prefer to preserve resources for the game itself instead for masking some defects that are inherent to the hardware behavior.

All the tiles you should use to have them 1-7 pixel displaced with black could be used for animated tiles, much more enriching.

By erpirao

Paladin (944)

erpirao's picture

02-03-2018, 20:14

not MSX2+.. but TurboR give us...
muti-plex
horrible music, but awesome scrolls.

By Grauw

Ascended (8455)

Grauw's picture

02-03-2018, 20:20

Yup, Multi-Plex is a technically very awesome game. Really shows the power of the V9958. Great fast and slow parallax scroll, day and night cycles, I also really like how the water level works. Every level uses different techniques, they were all crafted manually to be unique from the others. Must’ve taken a lot of time to make.

Longer video: https://youtu.be/ZgWxpggY49M

By hit9918

Prophet (2867)

hit9918's picture

02-03-2018, 21:00

pingpong and darkschneider: no more shaking and 8 sprites, you got no chance Big smile

By maxis

Champion (512)

maxis's picture

03-03-2018, 01:12

erpirao wrote:

not MSX2+.. but TurboR give us...
muti-plex
horrible music, but awesome scrolls.

Great game, I was unawave (simply that time I didn't have Turbo-R). Smooth. But the planes clearly spliced horizontally. No overlapping planes and objects (like trees etc).
I'd like simply to understand whether SOTB experience can be recreated. For example we have Turbo-R. We can go as fast as R800 would allow with the memory and as fast as V9958 will let us on the I/O. Likely, things like trees, etc don't use more than 2 colors per scan line. The challenge would be to overload the sprites/pointers precisely just between two line fetch cycles of VDP. I would like to understand whether it's possible (that was the initial discussion subject, not the contest for the best platform where this thread seem to deviate).
Background: IMHO, the line interrupts in the MSX games show some artifacts when the screen is spliced for the score boards on some KONAMI games. Never have seen the back-to-back line spliced screen without any blank lines or artifacts. What I'm trying to point out is due to the variation of the MSX2/2+ architecture (VDP clock is coupled to CPU clock or independent, VDP waitstate machine is custom for every chip vendor etc), that normally designers took a conservative approach taking some design margings. Turbo-R, however, is the unique architecture, which can be well profiled and, hence, the code execution timing can be very tight. Also I wonder how the tighter R800 interrupt timing interacts with the 4us block refresh. Comparing to the 6502 based architectures (C64, Atari, NES) , unlike the 6502 which is running always from the same crystal as the video subsystem and sharing its cycles, Z80 based MSX architecture presents some additional challenges. These challenges are:
- The RAM refresh mechanism and number of additional waitstates per peripheral is not defined and open to the manufacturer.
- There is no standard way in the slot enumeration/autoconfig to supply the software agregator with the timing profile.
From the above, IMHO, every game designer was facing the challenge how to make the game with the great experience but still running accross the large variety of the architectures.
IMHO, if the MSX standard would be tighter or more verbous regarding the real-time extensions, the interrupts could even be better controlled. If it is possible on the AMIGA (68000 is the nightmare for the real-time interrupt based control) why it shouldn't be possible on the MSX?
Another IMHO:
There is a concept of the precise interrupts. Z80 has a large instruction execution time variance, which can't be interrupted (atomic), and hence represents the protential time jitter on the horizontal line interrupt latency. However, IMHO, with a very careful coding and instruction selection, this problem can be overcome.

Page 6/10
1 | 2 | 3 | 4 | 5 | | 7 | 8 | 9 | 10