I think you have some good points, Hrothgar.

On the other hand I'd like to point out that too much flickering can really suck for an action game.

I've seen games that kill you off with bullets you can't even see.

Games like Zanac, Undeadline etc. keep the flickering down to an acceptable level IMO.

Quote:

well you still have 6 left, and that's already 2 more than any MSX1 game such as Nemesis or Zanac

..and you're still 2 sprites short compared to Usas, Vampire Killer, Gryzor, Metal Gear, Metal Gear 2, Goemon etc. We're talking MSX2 here, not MSX1. Besides, Nemesis' enemies are partly tiles anyway.

But you are mainly talking about MSX2 games that are screen 5 anyway, which means border masking is possible without sprites. Sprites are a logical choice for screen 4, which compares favourably with MSX1 screen 2 adding smooth scrolling *and* two extra sprites (which you can use for more colour or more characters).

Indeed the equation turns negative for MSX2 games in screen 4 that make full use of sprites. SM springs to mind.

How come the Psycho World / HyDeFoS screen 4 scroll ain't choppy?
Quite some use of tile-based objects there, but I can't see any masking.
Both games use a screensplit though.

PW/H have border sprites

Quote:

which means border masking is possible without sprites.

You mean drawing a black filled rect over a column of sc5 tiles to partially cover them? That'd require twice the amount of new tiles to be copied, no?

Quote:

You mean drawing a black filled rect over a column of sc5 tiles to partially cover them? That'd require twice the amount of new tiles to be copied, no?

I think that only means drawing a 1 pix wide black column on one side and copying a 1 pix wide column on the other side of each frame. That's 320 pixels for a 160 pixels high playfield.

Quote:

You could define that a certain screen of the map has exactly 4 2-OR-sprite characters on screen, so you won't see any sprite flickering. If the neighboring screen also has 4 sprites then this screen also doesn't have sprite flickering. But what if you're halfway these 2 screens? You may incidentally end up with 8 sprites in your situation.

That's all a matter of game design.
I think this is also something that flip screen doesn't really solve (assuming that sprites can wander from one screen to another).
Other systems that do have H-Scroll registers also have sprite limitations, but that didn't stop them from scrolling anyway did it?

Also remember that for example the original Castlevania and Gryzor were both scrolling games. I believe the flip-screen on MSX was a trade-off not because of sprite limitations but purely because of lacking hardware scroll registers.

Quote:

I believe the flip-screen on MSX was a trade-off not because of sprite limitations but purely because of lacking hardware scroll registers.

Or perceived lack of hardware scroll registers. As C64 games also use only an 8px finescroll mechanism, not a full-screen scrolling IIRC. You only have to be able to update the screen in time for the page swap, which can be done in one frame on C64 or on MSX Screen 4, and in 16 frames on MSX Screen 5.

Quote:

You mean drawing a black filled rect over a column of sc5 tiles to partially cover them? That'd require twice the amount of new tiles to be copied, no?

I'm not really sure what the most common technique is. The leaving column can just be destroyed 1 line at a time by a black line. The entering column is a different story - I guess that one has to be double-buffered and copied over to the active page one line at a time.

The destroyed column from the last page will have to be rebuilt yes, but when using the traditional approach of block-copying a whole page with a 16px offset that doesn't matter. When using differential copying you will have to rebuild that column with one block copy though.


Elaborating on the sprite discussion, I think scrolling games have the huge advantage of introducing new enemy sprites at a suitable distance from the player, whereas flipscreen games either keep introducing new enemies too long (too close to the edge thus lowering your response time to absurd levels) or creating 'safe havens' each flip screen that cover a substantial part of the screen width - at least for the walking direction.

Quote:

Or perceived lack of hardware scroll registers. As C64 games also use only an 8px finescroll mechanism, not a full-screen scrolling IIRC.

It's true that C64 has 8pix finescroll, however on c64 you don't have to 'fix' the borders like on MSX2 using H-Adjust that either needs precious sprites in the case of screen4 or will take more performance like on screen5.
OTOH, on C64 I suspect you *have* to copy the whole screen in one frame by the CPU, while on MSX you have the luxury of off-screen buffering *and* the ability to have the copying done by the VDP in parallel to the CPU to help with the scrolling, right?
So maybe, the difference between scrolling on C64 and MSX2 is not all that great altogether (although more complex and less VRAM efficient on MSX2)?

For the rest I agree 100% with your comments. I think you're right on regarding the sprite discussion.

Quote:

Adjust that [...] will take more performance like on screen5

Not being a game coder myself, I still fail to see how performance hogging two consecutive VDP-commands per frame is for a 1px scroller. I mean: it hardly drains your CPU time and who cares if the VDP is busy 50% or 90% of the time? Parallel processing is what it is designed for
So I'd say the two are completely even in capabilities as well.

Quote:

Not being a game coder myself, I still fail to see how performance hogging two consecutive VDP-commands per frame is for a 1px scroller. I mean: it hardly drains your CPU time and who cares if the VDP is busy 50% or 90% of the time?

Well, you can hardly do anything else with the VDP anymore besides scrolling.

Quote:

Quote: Not being a game coder myself, I still fail to see how performance hogging two consecutive VDP-commands per frame is for a 1px scroller. I mean: it hardly drains your CPU time and who cares if the VDP is busy 50% or 90% of the time? Well, you can hardly do anything else with the VDP anymore besides scrolling.

While the VDP is executing copy you still can do pretty much anything you want. You can even "out" data while the copy is occuring, to update sprite tables or modify colors for instance. The only thing you cannot do is start another copy command. And the Z80 can do plenty in the meantime, like play music, process the game engine...

Quote:

The only thing you cannot do is start another copy command.

That's just what I meant And that is quite a limitation if you were to do something like salamander or anything else with a very dynamic background.

But yes, I do realize that you can do anything else while the VDP is copying.

Quote:

Quote: The only thing you cannot do is start another copy command. That's just what I meant And that is quite a limitation if you were to do something like salamander or anything else with a very dynamic background. But yes, I do realize that you can do anything else while the VDP is copying.

MSX is all about compromises If you want fast scrolling with lots of animated backgrounds, go for Screen 4. If can live with slower scrolling and want fancy GFX without limitations, Screen 5 is the way. The best idea IMO is to combine those two depending on game levels...