Quote:

This is the problem. Coding a game to run on msx1, limits the richness of gfx and sound to the same msx1 level with some ( almost not relevant ) small improvement.

Not completely, it depends on the game type and what kind of screen action you are scheduling. If you want to make Montana John, then you need pattern mode. e.g. screen 2 or screen 4. There's simply too much movement on the screen to let screen 5 cope with that. So, if you're choosing pattern mode, and *if* you are not scrolling (e.g. a page-per-page game) then you can as well support MSX1.

Quote:

As nishi said the msx should had a v9938. Even with a similar chip, however was to late. keeping the compatibility also keep bad design and original limitations. (look at the sprite subsystem)

Right! And also because the MSX1 VDP was used in a lot of other computers, while the V9938 was quite MSX specific and very typically (almost) uniquely MSX. That's why I'd like to see more MSX2(+) games as well.

Quote:

Quote: This is the problem. Coding a game to run on msx1, limits the richness of gfx and sound to the same msx1 level with some ( almost not relevant ) small improvement. Not completely, it depends on the game type and what kind of screen action you are scheduling. If you want to make Montana John, then you need pattern mode. e.g. screen 2 or screen 4. There's simply too much movement on the screen to let screen 5 cope with that. So, if you're choosing pattern mode, and *if* you are not scrolling (e.g. a page-per-page game) then you can as well support MSX1.

About montana john. Can you point to more infos? If you do not need scrolling there are more possibilities to use screen 5. May be with sw sprites and page backbuffers the game could be done on screen 5. I see the problem only if you want scroll. Isn't VK pattern mode based? and works in sc5.... Where is the problem in montana john?

VK, Usas, Metal Gear, Solid Snake, etc. etc., are screen 5, and if you look at the screen, you'll notice that the only things moving are the sprites. That's why the enemies of e.g. Manbow 2 are sprites. On screen 5 you can copy about 5kb per int -fast mode-. Let's assume your game has 25FPS screen updates, we have some screens in which we have 3 4x4tile blocks going down/up. that's 32x32 pixels or 3kb pixels, these are 1.5kb vram because 1 byte in screen 5 is 2 pixels, but there's background restore as well, so it's all more or less doubled. Furthermore we have waterfalls that could be nearly as high as the screen and 4 tiles wide, and then more than one of them. Furthermore, we could have many torches and other animating things on screen, we have swords sticking out of the ceiling, waterdrops.. there's no way screen 5 can do all this! No way!

And, c/p'ing what I'd already posted in the Final Nijmegen reminder newspost:

Ah, if you want 25 fps. But hw sprites can move at the vdp refresh rate, other blitted parts at a lower frame rate...

Even then, even then. We could move the whole screen.. e.g. stuff it with tons 'n tons of moving parts. This is not possible in screen 5. And as for the lower framerate: this is not much preferred due irregular performance drops. You don't want the game action to slow down when the whole screen is moving while you gain performance in an empty screen.. that's ugly if you ask me.

Why do you think Nemesis123parosala are using pattern mode? Why -do you think- Space Manbow is using pattern mode? All these games have massive amounts of movement on screen.. just keep that bossmonster of Space Manbow level 1 in mind for a while. The more stuff that moves with irregular paths, the more arguments there are to use pattern mode. And in that case: only 2 situations would make these games impossible for MSX1: (1) a palette that is too far away from the default MSX1 palette, (2) hardware scrolling

Nemesis uses pattern mode because it's the only thing available on msx1 (and nemesis IS for msx1). Anyway it's clear that it's more easy to move 768 bytes on screen or redefina a tilegroup than moving 24kb of screen 5.

However, gfx beauty will suffer from the colour clashed screen 2-4. If those Yamaha people considered a screen5 pattern mode....

Well, *that* is the art of MSXdev, or the art of drawing patterns anyway. Limiting as patterns may be, I think the in-game gfx of Space Manbow are among the best on MSX. When you observe those Space Manbow screens, you tend to forget it's all patterns, the gfx on their own are excellent already. The fact that they're patterns makes it all the more special and intriguing!

Quote:

Nemesis uses pattern mode because it's the only thing available on msx1 (and nemesis IS for msx1)

err right Well, I meant that Konami would've used that screen even if they had been using an MSX2 from the start.

Effectively konami can be considered a tms artist...

True that, but as you can see in MSXdev, each year's top5 games (roughly) are definitely trying to kick Konami from the throne ..

Quote:

I must disagree. It's not true, look at the example of Amstrad CPC. this computer was a 8bit system, comes out after msx2 and got a decent library of sw & games.

I must (strongly) disagree ... Amstrad's CPC464 came out in December 1984, roughly at the same time that MSX1 came out in Europe (I've got a copy of "Your Computer" from 12.1984 filled with ads to prove that).

MSX2 came out in Japan in mid-1985 and we did not see one in Europe until one year later, in mid-1986 (all this can be verified in magazines from that era).

Furthermore, the CPC464 got a (very) decent library not because of its hardware, but because it was successful due to its revolutionnary all-in-1 system (computer, monitor and storage-media).

Quote:

Well, I meant that Konami would've used that screen even if they had been using an MSX2 from the start.

Probably, and they could used r18 to achieve smooth scrolling. In this type of game smooth scroll add a good quality.

About spmanbow, did you notice if konami had the usual ring buffer to make flickering the sprites?
In spmanbow appears as there are not situations where more than 8 sprites, so i suspect they have no flickering routine, that save time and allow for other vram I/O in vblank

Quote:

Quote: I must disagree. It's not true, look at the example of Amstrad CPC. this computer was a 8bit system, comes out after msx2 and got a decent library of sw & games. I must (strongly) disagree ... Amstrad's CPC464 came out in December 1984, roughly at the same time that MSX1 came out in Europe (I've got a copy of "Your Computer" from 12.1984 filled with ads to prove that). MSX2 came out in Japan in mid-1985 and we did not see one in Europe until one year later, in mid-1986 (all this can be verified in magazines from that era). Furthermore, the CPC464 got a (very) decent library not because of its hardware, but because it was successful due to its revolutionnary all-in-1 system (computer, monitor and storage-media).

I apologize i had others data, but the difference of one year does not change nothing. the not so successfull msx2 have it's root in the compatibility with msx1.

I have no data but i think the same problem happened to CPC+ respect to CPC, or i'm wrong?

Quote:

Probably, and they could used r18 to achieve smooth scrolling. In this type of game smooth scroll add a good quality.

Only when pattern enemies move at exactly the same speed as the level, how often does that happen?