Hi,

Ive been reading abit about screen 4 in the vdp manual.
Please do correct me if Im wrong:

A screen of 256x192 pixels is devided into 8x8 tiles.
So 768 tiles fit in one screen.
256 tiles can be used at a same time, so putting a tile into play is merely putting 1 byte to vram.

when the screensize is 256x192 then 32 tiles fit in one row, and 24 tiles in one column.
If I would translate this to screen 5 (which I AM used to), this would mean that
the 32x24 tiles that fill up screen 4, could be represented as a 32x24 block in screen 5???

Artrag experimented with this:

Can I (at vblank) switch to screen 5, copy a 32x24 block to a place in VRAM that represents the startpoint of screen 4's display.
And then switch back to screen 4 again.
In other words:

Can I put my entire MAP data in page 3 and 4 (screen 5),
and then navigate (scroll) through the map (in screen 4) by copy pasting the map ???

Quote:

Can I (at vblank) switch to screen 5, copy a 32x24 block to a place in VRAM that represents the startpoint of screen 4's display. And then switch back to screen 4 again. In other words: Can I put my entire MAP data in page 3 and 4 (screen 5), and then navigate (scroll) through the map (in screen 4) by copy pasting the map ???

[hint]R#2[/hint]... much faster and it reaches the entire VRAM, with the only small limitation of the base addressing, but that's explained in the manual where R#2 is described for SCREEN4.

Absolutely yes! And you can use much more than page 2&3 to store your map.
Actually you have 128-16= 112Kb free to store the map level.

The method is a bit tricky, let's say that if you need a 8 direction scrolling (like in a platform)
the virtual map size is limited to 128x896 tiles, if you do the fastcopy in scr5
or to 256x448 if you do the fastcopy in scr8

The pros of the method are:
1) for rendering the screen you need only 4/8 VDP commands (fastcopy)
2) during the VDP commands you can use the z80 for other things
3) you save a lot of RAM and use all the VRAM

http://www.msx.org/Vscreen-optimization-test.newspost3412.html

I think that a lot of improvements could be done for game with fixed scrolling direction like SM2.
In this case you could reduce the number of copies to 1 + the rendering of the extra area (1 new column
or 1 new line) and you do not suffer of any limitation on the map size (except the 112Kb limit naturally)

Less copies mean more z80 time to be used for other things

Quote:

Quote: Can I (at vblank) switch to screen 5, copy a 32x24 block to a place in VRAM that represents the startpoint of screen 4's display. And then switch back to screen 4 again. In other words: Can I put my entire MAP data in page 3 and 4 (screen 5), and then navigate (scroll) through the map (in screen 4) by copy pasting the map ??? [hint]R#2[/hint]... much faster and it reaches the entire VRAM, with the only small limitation of the base addressing, but that's explained in the manual where R#2 is described for SCREEN4.

R#2 requires me to write 32x24 bytes to VRAM using the OUT command, right?
Then doing one fastcopy this is much faster, isnt it ? (cpu wise AND Vramspeed wise)

Quote:

Quote: Quote: Can I (at vblank) switch to screen 5, copy a 32x24 block to a place in VRAM that represents the startpoint of screen 4's display. And then switch back to screen 4 again. In other words: Can I put my entire MAP data in page 3 and 4 (screen 5), and then navigate (scroll) through the map (in screen 4) by copy pasting the map ??? [hint]R#2[/hint]... much faster and it reaches the entire VRAM, with the only small limitation of the base addressing, but that's explained in the manual where R#2 is described for SCREEN4. R#2 requires me to write 32x24 bytes to VRAM using the OUT command, right? Then doing one fastcopy this is much faster, isnt it ? (cpu wise AND Vramspeed wise)

R#2 is just the 'pointer' that indicates where the 'map' starts. It means that during VBLANK you'll only need to update that, leaving the rest of the frame so you can build the (next) frame buffer with no rush.

Uhm, I hope you do understand the 'severe limits' imposed on SCREEN4 though. It's almost like using SC2, except that you do have a palette and slightly better sprites. Unless you used to pixel for Konami, I guess you'll find Screen5 a lot easier to use/draw for.

(Sidenote: Why oh why didn't Yamaha include a 'Screen5 pattern mode'? )

If I understand BiFi's hint, using R#2 you can move the pattern name table with steps of 1024 bytes,
thus, you can display in theory max 128 different screens ("frames" ) stored in VRAM
that could cycle by only setting R#2 (the frames are about 112 if we compute the room for defining tiles, sprites etc).

If you have a tile based full screen animation this trick can work very well,
and it can work also for a game where scrolling is in only one direction (X or Y but not both) and
the screen can move only of 112 positions,
but I cannot see how it can be used for a game with more than one scrolling direction (X and Y) or with larger levels
(IMHO hardly a shooter can be limited to a 112+32 wide levelmap).

Moreover if you modify a tile in the map you need to modify 24 or 32 frames (i.e. 24 or 32 write in VRAM)...

Quote:

Uhm, I hope you do understand the 'severe limits' imposed on SCREEN4 though. It's almost like using SC2, except that you do have a palette and slightly better sprites. Unless you used to pixel for Konami, I guess you'll find Screen5 a lot easier to use/draw for. (Sidenote: Why oh why didn't Yamaha include a 'Screen5 pattern mode'? )

For gaming purposes, it was the only thing was missed. with this+horizontal scrolling msx2 will be a very game-oriented machine.

I also think the Yamaha guys realize that sc5-8 grpx was too slow and a last minute resource had implemented sc4+best hw sprites....

pixeling for sc4 seperates the men from the boys ^_^

I want to make a full directional scroll.
So, I guess, R#2 is no option then??
What if i have the map data in page 2 (screen 5)

the pointer is in (0,0)

then at vblank I

1) switch to screen 5
2) copy (0,0)-(32,24),2 to (0,0),0 ;this means copy the map screen the pointer points to, to the map screen of screen 4 currently being displayed.
3) switch back to screen 4

Then when the character moves right, the next frame I:
1) switch to screen 5
2) copy (2,0)-(34,24),2 to (0,0),0 ;this means copy the map screen the pointer points to, to the map.....
3) switch back to screen 4

Then when the character moves down, the next frame I:
1) switch to screen 5
2) copy (2,2)-(34,26),2 to (0,0),0 ;this means copy the map screen the pointer points to, to the map .....
3) switch back to screen 4

This is my thought.
But how do I really realise this for real !???

Do you want a 8 directional scroll or only a "shooter" scrolling
(i.e. up/down are controlled by the player but the horizontal direction has fixed speed) ?


In the first case the ASM code is in VTEST, start from that.

In my example the map is 128 X what_you_like (as I used scr5)
but you can also adapt it to 256 X what_you_like (if you use scr7/8)


BTW, in the case of a "shooter" scroll probably something could be done
to overcame to the 128-256 width limitation,
for exapmte by putting in VRAM the level divided
in strips of 128 X heigth, where the last 32 X heigth part is copied also
at the beginning of the next strip.

When you reach the rigth end of the current strip, the engine can
do a sort of CR, going to the begining of the next strip
This wastes 32 X heigth bytes each strip, but allows maps of any size.
In any case, working in scr7/8, would cut by half the overhead

I was thinking to the R#2 matter:

Think to a platform with pure horizontal scrolling, assume that the main character can move left (or right)
with speed 1 pixel/vblank. At 50Hz this implies a scroll speed of 6,25 screen update per second.

Having 112 frames (i.e.112Kb used), the main character needs about 18 secs
to go from one side to the other of the level. It is not a large level, but can fit
the needs of many arcade/puzzle games.

Actually the same considerations holds for any linear level.

The level could have a "L" shape or a "S" shape for instance,
the only limit is 112 scroll positions!

Quote:

Do you want a 8 directional scroll or only a "shooter" scrolling (i.e. up/down are controlled by the player but the horizontal direction has fixed speed) ?

I was planning on making an 8 directional scroll

so look at the VTEST, tha ASM code is already there

Back again on the R#2 matter…
A full screen scrolling trough a level large 112+32 = 144 X 24 tiles at almost zero CPU cost….

This implies that it is possible to implement a true game that uses high quality digitised audio (using PcmEnc) and a full screen scrolling !!!

http://www.msx.org/PCM-Encoder-0.01.newspost3520.html

I remember that at 11KHz and one channel per sample there was plenty of spare time, or at least, enough time to control 5-6 sprites.
It should be not very difficult to include in the loop of the replayer some code to control the main character, set R#2 and control some enemies.

This could disclose a new audio/video frontier for MSX2

Am I too confident ?