Quote:

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?

I'm only referring to background, of course, like in spmanbow

Quote:

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?

Into platform games this is not a problem, the sprite could have a double speed (rush mode) when the entire screen will move and the pattern enemies would have the normal speed + the speed of the screen moving. This is useful for games that only move the screen when the main character is walking ...

@PinPong
I was going to consider an msx 2 version of our engine....
No commitment on my side, it is just a test...
Could you write and post here a code that, in screen 5, fills a screen in page 0 or 1 of 8x8
blocks taken out 256 blocks in page 2 by reading the block number from a "room" in ram.
The window displayed has to be 32X20 in a room of map_w X map_h.

Quote:

@PinPong I was going to consider an msx 2 version of our engine.... No commitment on my side, it is just a test... Could you write and post here a code that, in screen 5, fills a screen in page 0 or 1 of 8x8 blocks taken out 256 blocks in page 2 by reading the block number from a "room" in ram. The window displayed has to be 32X20 in a room of map_w X map_h.

I'm busy on the moment but, i've already some of this in my 'garage'. please send me an email.

Bruno, could you send me an email ?
my PC has gone few days ago and I've lost all my addresses

Quote:

So msxdev does boost MSX activity. The problem is that all it does boost is MSX1, which is IMHO a step backwards.

When MSXdev contests were concepted there was no MSX(1) activity at all, or just a few. Now we MSX lovers can say we have lots of productions each year. So it is just a step backwards for those who understands the MSX standard as something that started with the MSX2.

Wolf, don't forget that Manbow 2 is not in a pattern mode, but in screen 5. And it's damn smooth and has loads of big stuff as well, including huge enemies.

manuel: what are these large enemies made out of? A group of sprites? Or a large block-copy? In the latter case: is this large block-copy going *over* a textured background? If not: a large enemy is just a big 'screen' which moves because the screen moves.

Like the plane(s) in Aleste 2, area 2 right?

Correct. that large plane was just 'the map', I even guess that the motors that were shooting bullets were technically the actual enemies there, the 'continuity' of the level were those clouds..

Well, even in SM the scroll engine was used to move and animate endlevel bosses.

The large crab in the first level was moving thanks to the horizontal scroll engine.

Anyway, it all comes down to:
- in screen 5 you can move the screen as a whole, and the rest will have to be sprites
- in screen 2/4 you can move any part of the screen in any direction in tile-steps

As for shooters like nemesis, when the map (the 'wall'-tiles) itself changes then you'll be using tiles. E.g. those green plants in nem2level2, the stages/blocks/whiteplatforms in nem2level3, the sun flames in nem3level1, the scars in salamander level1 etc. etc. If nothing of the map is visually and physically changing (Manbow 2, airplane in aleste2level2, etc.) then you can use a bitmap screen.

Anyway more room in rom could allow a true msx2/msx1 game
(even if the competition is going to evaluate only the msx1 specs)
Games like Kings Valley, with no or limited scroll among rooms,
could be easily adapted to have two graphic rendering modes.
Just a matter of doubling the code that builds the screen, the rest
can stay with minimal changes.
Caos Begins, is a clear example: an msx2 version would need only
few touches (and more artwork and a larger ROM natuarlly).

My idea is also the the storage of the gpx can be limited by resorting
to some trick that build the screen5 "tiles" (or 8x8 blocks) as a difference
wrt the screen 2 tiles.

I know, the result is not the best for an msx2, but far better than
simple palette adjustments.

I've thought about building sc5 tiles based on sc2 tiles, but in the end I kinda dropped the idea. Sc2 has 2 bytes per line, sc5 has 4 bytes per line. The difference is thus 2 bytes. Even if you'd be able to somehow add 2 bytes to the sc2 tile to uplift it to bitmap sc5, it'd still double your gfx data. As for KV2: this is one of the few popular games I know where a sc5 version of a sc2 game actually works without concessions..

Draw your graphic in screen 2. Do your best.
Call set 1 the image 256*64 you get.

Now adjust the palette and add details without screen2 limitations.
Call set 2 the image 256*64 you get.

Do the difference diff = set2-set1.

If you worked well on screen2, diff is very sparse, and 80% of it is filled of zeros

Compress set1 using pletter and diff using what you like (RLE ?),
the result should be far less than you would expect.

All depends on how good are your screen 2 artistic skills and how far from the
original graphic you want to go in screen 5.


on msx1 just decompress set1 and put it in VRAM
on msx2 decompress set1 and diff, add them and put the result in VRAM