Quote:

The best idea IMO is to combine those two depending on game levels...

Heh, never thought of that

Regarding scrolling speed, I'd say 1 pixel per frame is enough for most games? I think 1 pixel per frame would be perfect for nemesis type games and most other scrolling games. Too slow for racing or Sonic the Hedgehog maybe, but good enough for most other games right?

In many flipscreen games the main character indeed moves at around 1 px per frame, making a 1px scrolling implementation sufficient.

Platform games like the Mario series or horizontal Zanac-like games could benefit from higher or varying scrollspeeds, but these kind of level designs are IMO perfect for differential copying as there may be a lot of pattern repetition in the levels making at least 2px scrolls possible, maybe more. I'm currently fooling around trying to remake Mario levels and trying out the principle of differential copying + smoothscroll in basic (obviously not reaching any decent scrollspeed, but just to demonstrate the principle). Perhaps if I have an example ready, if Artrag feels like it it could be turned into a nice demo.

A little offtopic:Zanac X is in screen 5 and has smooth vertical scroll.Could the same be done for nemesis if it was for msx2?Use screen 5 and scroll horizontal?Is there a difference between horizontal and vertical scroll?

Quote:

A little offtopic:Zanac X is in screen 5 and has smooth vertical scroll.Could the same be done for nemesis if it was for msx2?Use screen 5 and scroll horizontal?Is there a difference between horizontal and vertical scroll?

The horizontal and the vertical scroll is different on V9938 used for MSX2. The vertical one can be done by hardware but the horizontal one can only be done by software, which is definitely slow.

Quote:

In many flipscreen games the main character indeed moves at around 1 px per frame, making a 1px scrolling implementation sufficient. Platform games like the Mario series or horizontal Zanac-like games could benefit from higher or varying scrollspeeds, but these kind of level designs are IMO perfect for differential copying as there may be a lot of pattern repetition in the levels making at least 2px scrolls possible, maybe more. I'm currently fooling around trying to remake Mario levels and trying out the principle of differential copying + smoothscroll in basic (obviously not reaching any decent scrollspeed, but just to demonstrate the principle). Perhaps if I have an example ready, if Artrag feels like it it could be turned into a nice demo.

I pix per frame is kinda slow actually. I'd say you need the speed to be at least 2 pix per frame for a platform game to make it feel a little bit "dynamic". Otherwise you end up with a sluggish feel like when moving in Bubble Bobble for example. For comparaison, in the Vscreen demo, the main character avg speed is 3-4 pix per frame, but sometime goes up to 7-8 when jumping/falling. So for that type of games, screen 5 would be a not go with scrolling.

The screen 5/1 pix per frame is fine for games like Nemesis where the background really does not move very fast. A platform game like the first super mario (only horizonal scroll) might work as well but I do beleive that the speed of the main character was certainly more than 2 pix/frame when running.

Quote:

A little offtopic:Zanac X is in screen 5 and has smooth vertical scroll.Could the same be done for nemesis if it was for msx2?Use screen 5 and scroll horizontal?Is there a difference between horizontal and vertical scroll?

The difference is that you can only kind of 'fake' a smooth horizontal scroll by using the Horizontal Adjust register (which was just meant for positioning the image to the center of the screen), which has the downside that the borders move too. As discussed above, that can be worked around using either sprites or updating the left/right sides of the background each frame.
Space Manbow is a good example of using H-Adjust for smooth scroll, but without masking the borders using sprites (so the borders shake about in quite an ugly way. Note that this is only on MSX2; on MSX2+ this game uses a real horizontal scroll register that is unavailable in MSX2).
Another difference that complicates things a bit is that the vertical scroll register defines a vertical offset with a range of the whole screen, where the H-adjust register only has a range of 16 pixels. A consequence is that if you just have a repeating pattern that is not changed, you can scroll as fast as you want vertically (the start of level 1 in aleste is a good example), which is not possible horizontally unless this repeating pattern is only up to 16 pixels wide.

Also as discussed above, screen5 is too slow to both scroll horizontally *and* do major updates in the background (as what happens a lot in nemesis games). So you'll need screen4 for that, which of course doesn't look as nice as screen5.

Erikd
Borders can be emulated by the VDP itself (line commands and copy line commands) AND sprites
the idea is simple:
The vdp emulate borders
When sprites enter/exit in/from the screen, a black high priority box can be used to emulate the border
also for the sprite. You remove that black block when the sprite is fully into the screen.

About the no-copy scroll, yes the width of the register is 16pixels, but using two pages you can cycle
a pattern of 32 pixels and using 4 pages a pattern of 64 pixels without moving a single byte.
Naturally, for border emulation you will need the VDP and/or the sprites in any case.

Quote:

When sprites enter/exit in/from the screen, a black high priority box can be used to emulate the border also for the sprite. You remove that black block when the sprite is fully into the screen.

I see, so then this only actually costs one sprite for each each sprite that is partly out of the visible area, so it doesn't take up any sprites at all when all sprites are fully in view.

Before I was somehow thinking to cover the full borders with sprites, but you're right this is not necessary, at least not in screen5 if you take care of the borders by drawing/copying lines.

Masking sprites that cross the masked border is really a corner case IMO. Just rechecked Vampire Killer and Contra and they don't have gradually entering and leaving sprites, the whole character just pops in and out of the screen. So it already is a level of perfection not always seen even in quality games.

What is the maximum ammount of sprites that can be displayed on screen on an msx/msx2 ?I know the 4 sprite limit for msx1 and 8 sprite for msx2 per row,but in terms of total sprites how much is that in screen 2 and screen 5?

Also how did the programers of nemesis used tiles and characters as sprites?Was there a special collision detection technique?Because using tiles or characters as sprites certainly allows one to overcome the limit of 4 sprites on msx1 or 8 sprites on msx2.

32 sprites

And as for tile enemies: custom collision routines indeed.

Isn't a custom collision routine needed anyhow in an MSX1 game where you use more player sprites at a single spot? (multi-colour and/or 'options' surrounding the ship.) Or can you disable collision detection for particular sprites or sprite combinations on MSX1 as well?

Talking about maximum number of sprites on screen: the limit of 8 on the entire screen didn't seem to stop C64 developers to fill half of the screen with moving sprites, just using screensplit techniques. What's the state on MSX 2 here? Is it more complex to manage moving sprites than C64 or just something most developers didn't bother as 32 is sufficient for most purposes?

@Hrothgar: the real limits of msx2 sprites are 2:
- Limited multicolor support.
- Sprites/ScanLine.

I do not see a big limit the total n. of sprites on screen. In contrast, this is the only advantage of a VDP sprite system versus the VIC-II sprites:

the ability to have a great number of sprites on screen without screen splits, even *at the cost* of a limited n. /scanline.

Quote:

Isn't a custom collision routine needed anyhow in an MSX1 game where you use more player sprites at a single spot?

Yes, in fact, by far most games don't use the VDP's sprite collision detection at all.

Interesting. C64 has a bit to set for sprite collision detection to also detect collisions with 'foreground graphics'. Just as sprites can move between foreground and background colours, something also impossible on MSX1 (or 2, or 2+, or TurboR...). In fact does any of the new graphics chips currently under development have a simple solution for this, with which I don't mean harshly maintaining two entire layers that you can move or Z-index independently?

Another few "would have been nice to haves"