MSX1 vertical smooth scrolling (of text ;-) here
http://msxgamesbox.com/karoshi/index.php?topic=1145.msg15370#msg15370

Thanks for all the examples so far guys. Indeed the GnG demo is quite impressive, would love to see that grow to a full game (or that technique used in more projects in general). Judging with Meisei, this doesn't rotate between predefined tiles but dynamically updates all of them, which seems to contrast with the opinion that there's a (non-gameworthy) limit of what you can update every frame. I must say GnG doesn't look too limited tilewise and I hardly notice flickering (or is a real MSX worse than an emu here?).

Different CPU and VDP timing: bummer. Never knew that, downside of having a standard adopted by more manufacturers I guess.

About the game logic being sliced due to multiple copy instructions: I realize that, but when using the 'traditional' approach (full copy, as probably used in Manbow2, must also be sliced I presume) works will it be much different to do predefined partial copies in - say - max. 30 steps?

Artrag: I would love to continue these things if only I could. I'm just very interested in MSX and like to share and discuss ideas (and tickle you guys who can actually code these things to explore such directions if possible) but the most impressive thing I ever coded myself was a Lingo game in Basic Time to start doing an ASM course I guess. Is that text scroll the same approach as in MoG BTW? I'll try to do it in Basic first and see how slow I can get it

About 'slicing' game logic: In Bombaman, for each new frame all copy commands are computed first and put in a list. After that, at several points in the code checks are made to see if the VDP is ready to execute a new command, and if it is, the next command from the list is started. This approach works really well!

Interesting, so instead of having fixed intervals (line interrupts) to do the copies and then squeeze the code between that, you make the CPU code that has to run anyhow the leading factor and adjust the VDP commands to that. In practice how often can you interrupt the game code to poll the VDP? Are we talking about a large number of times each frame or larger intervals? Depending on the VDP slack time (size of game code blocks) it may even work much better.
Main difference with the idea I had in mind is having a precalculated set of copy instructions so you don't need to compute them in the Z80 (which of course depends on the kind of game), but your approach can accommodate that way even better. Even more space for game code.

Well done, but with this approach you cannot guarantee that the screen is completed within one frame....
I'll think to this solution, BTW, in Total Parody I used a different approach.

All the code is in the interrupt routine.
During VDP commands the z80 does I/O transfer to update the sprite definitions and attributes.
It is quite a lot of data so it fills well the waiting time (and all the sprites gets new colours at each frame !).

The AI is executed after the current I/O has finished (and has to end before the arrival of the next interrupt).
Maybe you solution is time less critical....

Hrothgar
the idea of a pre-calculated list of commands that encodes the differences of the current frame with the next is nice.
An off line optimization could decide non only IF copy a block, but also what size of copy to do at each step, as
larger is the copy better the VDP performance, and often a group of tiles is already there somewhere on the screen,
ready to be copied as it is....
BTW it is quite a complex optimization, with tons of parameters and costs to be decided...

With fixed interrupts, you can precalculate if the copies can be completed within one / 16 frames. (In fact ideally a tool could be used to precalculate how much level variation in the horizontal plane you can afford when assuming an x px scrollspeed.) With variable copy slots depending on game code interruptions and VDP polls this depends on the combination of CPU code block size and VDP code block size and could be a lot more complex. Still, Arjan's solution would IMHO work very well if the polling can be done frequently and the copies are pre-sorted in size (large block copies first, possible 8×8px fill copies later in a frame).

Indeed in your average Gryzor or Vampire Killer or Super Mario Brothers screen, tens of % of the screen can be left completely untouched as it is a plain colour (sky) or a repeating pattern, and by definition the whole screen short of 32px at the sides can be block-copied in large from page 0 or 1. At the worst case you have a fill-strip to be added with 8×8 copies but I guess even then you can mostly work with large copies or none at all (depending on how you mask borders).

If you set S#2 as default VDP status register, you just need 3 instructions to check if the VDP is ready to execute a new command. So yes, polling can be done quite frequently.

Using line interrupts is a good idea too, especially if you know how long each command will take to complete. In Bombaman, variable sized copies are used (e.g. 2x16, 16x16, 16x24) and in theory I could determine how long it would take to complete them, but that would also mean more CPU time has to be used to set everything up. In the end, I think with Bombaman I'm better off with polling the VDP frequently.

If you're also using hardware sprites, you'll need to take into account that the VDP needs more time to complete a command if it also has to process sprites, which means you have to be prepared for the worse case. So in the end, you lose some VDP potential with all approaches, OR you lose CPU potential. Unfortunately the VDP can't generate an interrupt after a command has been completed

MaSaXi wrote:
"Colecovision´s DIG DUG have really good looking sprites, player and all monsters have more than one colour!! That is achieved simply making ALL sprites flicker ALL THE TIME. Of course they flicker, but they still look REALLY FANTASTIC, when compared to crude spectrum like MSX-1 Namcot DIG DUG...... Please take a look at Coleco´s DIG DUG!!! (I haven´t played it on real coleco, but on BlueMSX)


You're right!!! I hope this technique would be implemented in MSX1 games, too!!!

BUMP!

Would a zanac-x scroll be possible on msx1?

Pippols scrolls vertically, so if you spend enough tiles on it, you could also make your Aleste clone scroll vertically on MSX1. But don't expect much fanciness however. You may be better served with an 8-pixel scroll and many spiffy tiles.

If you scroll really fast.

@MäSäXi: Recently i've played with a 4pixel scroller.
I can easily scroll a 256x128 pixels area (color+attributes) at 12.5fps.
Limitations: you can have only 128 distinct patterns per frame on each of the two areas (top 64pixels and center 64pixels).
You can change at maximum of 16 patterns at each 4x8 pixel scroll, by blitting from ram to vram so you do not need to upload all the tiles in an entire level to vram, you can change only the tiles that appear while scrolling.

Because of the fps the perceived speed is about 50pixels/sec. the scroll appear quite smooth

What is this game ?

Quote:

What is this game ?

It's only an experiment of 4pix scroll. not a game.
4pixels because with a little trick it's possibile to have 2 colors x 8pixels area even with scrolling.