I suggest Pro motion 6 by Cosmigo!
NB: It is shareware with some locked functions if you do not buy it.

I have to think about the use of one single list.
The order in which data are stored counts as it is the order you use to render them. Due to borders, I need to render always first columns 14 (going-> or 0 (going <-), thus I need two different ordering....
But I could override the problem reading the same list in reverse order...
I'll think about that....

Coping from the other alternate page ? This would allow larger copies.
Possible, nevertheless ATM it is simpler, for me, coping from the tilepage, as I have one source both for animated and static tiles.
I'll think on that too but it is with lower priority

Yes, my original thought was: if column 74 != 72, then column 72 != 74. So theoretically one delta table, read in reverse order with an offset due to the changed direction, should work.

So you're still copying the deltas from the tilemap instead of from the alternate page? That would make one delta list difficult if not impossible yes as you still have to store the source tile.

I see we still have two mutually exclusive possibilities here:
1) Use the saved CPU/VDP time for more animation;
2) Use the saved CPU/VDP time for faster scrollspeeds than 60 px/s.

I think your approach is a better one for 1, mine might make 2 possible (but then you can forget about any animation!)

I'll try that Pro Motion, thanks for the tip.

I agree that both are very difficult.
Never the less, I agree that a complete algorithm could do both, i.e.
1) scan the existing page looking for large areas to copy
2) add only differences not on the screen from the tileset

not easy, nor in my close plans. Anyone willing ?

BTW renouncing to animations you can just copy the WHOLE screen except the new column.
If you want the VDP make the borders, you can copy the screen in 16 vertical slices, building
from tiles just the new column.

I think SM2 does this. For sure the CPU is free as a bird 15 frames out of 16
and maybe the VDP this could be fast enough to allow a scroll rate higher that 60px/sec... who knows

Think this:
HMMM gives 2880 byte per frame (192 lines + sprites @60Hz)

a frame is 240*176/2 = 21120 bytes

that gives about a new page each 7,3 frames

rounding to 8, this implies that in theory we could scroll at 120px/sec

The 'copy' commands of V9938 are sufficient to do all the effects you may want ... but they are very slow.
Some tricks can sacrifice some ease of programing for some for subjective speed.

If the copy commands were just faster everything would be so simple!
You would program your vdp just like before but could do much more things like emulatin sprites , multilayers, scroll very fast with basic copy commands.

And other limitation is vram size, it can be upgraded to 192kb ( and i did back in '88 ).

This all is very true of course, but fact is that the MSX2 doesn't by default come equipped with a fast video chip (regardless of recent activities to create a new one).

What I would very much like to see is developments to squeeze the horrible limits of the VDP so that we can actually create a smooth-scrolling variable-speed user-controlled platformer or shooter in screen 5 - just with that old VDP. That MSX2 has hardly any such games is a shame, and I think creating a Super Mario Bros 3 in screen 5 on MSX2 is just as much a challenge as creating a whole new chip that's so fast that you could theoretically create such games in Basic.

Increasing VRAM size - what good is that for? Sure, you can store a lot in it and you can probably get a graphical effect or two that can't work with less memory, but as you can't assume anyone else has more than 128 kB you simply can't develop for it except for your own experiments.

The C64 has shown how far you can get when focusing strictly on one single standard without extensions; the VDP hasn't been fully utilized yet to reach such heights.

Artrag's calculations above are interesting; I thought a 1px scroll on 60Hz was already approaching the limits but apparently there is quite some slack in that. With the optimizations mentioned here this could mean fast-action scrolling games are less impossible than was always mentioned.

Quote:

The C64 has shown how far you can get when focusing strictly on one single standard without extensions; the VDP hasn't been fully utilized yet to reach such heights.

@Hrothgar: the c64 had for some aspect a superior hw when compared to msx2; (remember that there is a tiled mode) that's the difference.

However can you make an example of a very squezed use of c64 VIC-II? (not the usual raster effects, please)

Honestly, i think screen5 is a screen mode for almost static games, not (unless you get hw scrolling) scrolling ones.
Strangely, in v9938 there is a screen mode that should never been existed... screen 4, patterned mode, with msx2 sprites.....

this make me suspicious about yamaha engineers. they probably figured that , without scrolling, v9938 was too slow for blitting, and they gave a workaround 'creating' sc4. Otherwise, i cannot see a true reason to have scr4.

c64 VIC-II limits
http://www.youtube.com/watch?v=bB49A5rExOE&feature=related

Now we con do the same, but the 16x16 "tiles", and thus the parallax, is limited to change only once each 16 frames.
If the foreground scrolls at 16pixels per frame the background can scroll at 15pixels per frame (or even 14, but no more than this or we get jumps)

Parallax can be done much better in MSX2 by using screen 4, having layers confined to 8×8 tiles. That way we can use hardware scroll + tile redefinition to approach what the C64 can do (C64 can do better in flowing tiles into each other, which is hardly possible in screen 4 due to colour clash - but that is avoided by careful graphics / level design). Doing parallax in screen 5 is hardly convincing as mentioned by many people, I maintain that the effect looks more like a glitch than an intended effect. Multiple Y-layers with different scrolling might be better possible but is difficult in combination with sprites.

I do not agree that screen 5 is *only* for static games. I think it has been sufficiently demonstrated by now that the superior graphics of screen 5 can be combined with scrolling. It's only that this is only achieved in demos hardly in games.

I don't really understand the opposition to this point of view and the opening of parody threads (no pun intended ;-) as the move from demo effects to actual games was actually achieved on the C64. I do understand that not everybody will be able or willing to make such games (and yes: I'm not capable of doing this myself either) nor do I understand the massive interest in creating new graphics 'solutions' by means of new cards instead of exploring development possibilities for the old standard. Not to discourage those developers at all, but creating *two* new graphics cards for MSX will lead to even more scattered development (if there will be development at all).

It's quite simple; companies like Konami, Falcon and Microcabin have shown what's possible with the 9938. It also displays they've reached pretty much the limit of what's achievable. Many of their screen 5 titles all incorporate delta rendering and all of those games show a huge slowdown when deltas become 'big'. SD-Snatcher is a screen-5 near full-screen scroller, there are plenty areas that slow down to a crawl.

Don't tell me those companies haven't reached the limit

As for the Turrican example posted above: that's only feasible in screen 4 I think if only due to the huge enemies that can't possibly be done by either sprites or block copies in a sufficiently large or fast way. Then again large enemies are also a problem in screen 4 to move smoothly if we don't scroll the whole screen as screen 4 has a fairly horrible colour clash problem when trying to mimic 4 or 2 px horizontal scroll.

We should have had a screen 5 pattern mode for this back in 1985...

@Hrothgar: about the parody threads, only jocking. My parody is not on people but on the V9938 VDP itself. For me, there is *really* no reason to have v9938 with vertical scroll regs and without the horizontal one. Yamaha engineers thought to be in a world with only Y dimension?

And ok, the c64 can do parallax scrolling but it's easy! just you have to move 1000 bytes! compare with the 24KB of a screen 5!
The VDP is far faster than the 6502 in gfx operations, but having 24 times the job to do can hardly balance the difference.

The real problem is that the v9938 can do horizontal scroll very hardly even with 1 layer. You are thinking about to have multilayer... A bit ambitious.

To summarize, a smart use of programming tecniques can do a *REAL* difference between a crappy and a good game (look at YS series, they do chunky scroll in scr5), but limits are always out of the door, waiting...


But let's start to another problem related to msxs vdps, the tecnique used to overcome the max number of sprites/scanline.

On MSX1 it's easy, because all use the circular list of sprites, but on MSX2? It's a pain.
You need also to rotate the 512 bytes of attributes, in a small period of time. Really applicable solutions? NONE.
just hope to have sufficient z80 time to blit the entire attributes+color sprite attributes, otherwise....

Again another big limit of VDP. Do you start to understand what i mean with parody threads addressed to VDP?

Plus do you know that is not possible to modify r18 while a command is in progress? If possible, some things will be possible instead of splitting one single operation in multiple chunks...

* The VDP is an extremely limited chip *, that the problem. The only VDP that reached maturity is the v9958, a bit late... however...

Quote:

We should have had a screen 5 pattern mode for this back in 1985...

I agree, with a such mode games on msx2 changed radically...

Quote:

The only VDP that reached maturity is the v9958, a bit late... however...

Mhoa, plenty o' issues left with the V9958. The first real 'more or less' fault-free videochip was the V9990.