@Magoo
Correct!!
I was thinking about the use of my routine in this way
(view from the top).

Actually I was fascinated by the possibility of having a
light effects, which put in shadows all the scene outside
a sfere around my character...

Something like advanced dungeon & dragons for intellivision

could i be able to use this sprite in Vscreens? the original dimensions are 24x24 pixels..... 4 colors a black outline, blue, light blue,white,skin color......
the animation has 4 frames its walking...

@Artrag: I am not talking about multilayer scroll (that is not even possible on gfx9000 other than using
p1 mode). Just a simple one-layer scroll wich does not scroll to the right when I move left after
innitialy moving right. That it can be done in sc4 is shown in Vscreen, but how about sc5? And how
about hardware scrolling and using software sprites?
btw Is there gonna be a Vscreen9000 in the near future? (p1 mode of course) That will solve a lot
of problems.

No way in sc5 on a simple msx2; nevertheless, reducing the area
of the screen, you can try to get a page swap each 4 steps and a
second layer that scrolls of 3 pixels each 4 pixels of the main layer.

You get a very smooth scroll and a very visible parallax, but the
result is only for demo or intro....

Quote:

could i be able to use this sprite in Vscreens? the original dimensions are 24x24 pixels..... 4 colors a black outline, blue, light blue,white,skin color...... the animation has 4 frames its walking...

24 pixels means 2 sprites. 4 colors means at least 3 sprites. So that's 6 sprites on one horizontal...

As MSX 2 only allows 8 sprites on an horizontal, you'd only have room for 1 extra enemy (using 2 sprites/3colors) OR sprites to mask borders... So yeah it's possible but that doesn't leave room for much more (without flickering) or nasty effects.

Quote:

@norakomi: Sprites will deffinitely become a problem since they are also affected by the adjust register.

there is an option for v9958 that makes sprite not be affected by the hor. adjust register, right??
So for a T-R it would be possible???

Let say we use 1 screensplt at y=100
The screen above the split scrolls with 1 pixel per frame
The screen below the split scrolls with 4 pixels per frame

What about have 2 sprite tables, one for above, one for below.
The sprites in both tables are the same, exept the horizontal positioning.

Then at the split you merely change the spritetable address.

Result:

Whenever the sprites cross the borders at the screensplit, they are not visible affected....

what do you think???

@norakomi

Quote:

What about have 2 sprite tables, one for above, one for below. The sprites in both tables are the same, exept the horizontal positioning.

Very hard to be done!!
You need at least two attribute tables and a very accurate syncronization.

The true problem with sprites is that they are traced not at the same time
of the raster scan but one or two line after it.
This imply that if you do a split at the middle of the image, the new attribute table
become active one or two lines before the line where actually you have set the split.

Look at TNI for more details about this "feature" of our VDP....

being a great programmer requires being a crazy magician and a great puzzler !!!

so at the splitline:

wait HBLANK begin
wait HBLANK start
wait HBLANK begin
change the sprite table address
change r#18 (scroll screen)

thats it, right?? doesnt seem too difficult???

Look at
http://map.tni.nl/articles/split_guide.php#vscrollsplit
If this is correct (and I need some experiments to test it) with a simple screen split,
you cannot have a sprite that pass the boundary without having at least one line distorted.
The solution could be to implement a very tricky sequence of table swap and vdp 18 move
while the raster is in the horizontal retrace of the split line, but I my opinion z80 isn't fast enough for doing all the things that should be done during the HR of the split line....

If you do

wait HBLANK begin
wait HBLANK start
wait HBLANK begin
change the sprite table address
change r#18 (scroll screen)

The new sprite table will affect the sprites on the line previous
to the one where you splitted and set the new r18,

In the previous line (where sprites changed) you have the old r18 value!!

do you see the point?

Quote:

there is an option for v9958 that makes sprite not be affected by the hor. adjust register, right??

In case of using the hardware scroll.

@norakomi

I am no more convinced about what I told you!!
I need more "in vitro" experiments but I feel that
something could be done to cope with the problem
of the "previous line"....
Also with a poor z80...

ok, lets talk about a spritesplit first.

Tip: Spritesplit
If you are creating a spritesplit, you should keep the entries of the sprites which are displayed on the line of the split unchanged in both the pattern and the attribute table (or duplicate them if you change table addresses). This MUST be done, making a spritesplit will otherwise be a hard if not impossible job, which will certainly not work on every type of MSX. Oh, and remember, the spritedata is read one line BEFORE the actual display line. So if you change sprite tables on the split line, the first line with sprites will be one line lower.Thanks to Patriek Lesparre for the info.

this means that if we switch the spritetable address (with the new x value) at y=100
the sprites will have the new x value at y=99 allready.....

true?

If you split at the end of line 100, in order to have at line 101 a new value at
r18, and you swap also sprite tables, the change in sprites should appear
from line 100 !!

The strategy to avoid this is complex but feasible (free ideas not tested),
split at 100 and change r18 in HR between 100 and 101, but NOT swap the
sprite tables now!!!
Wait till end of line 101, change the sprite tables in the HR between 101 and 102.

In this way sprites on line 100 and 101 are correctly displayed and you have plenty of time !!
as you need to do only ONE vdp set in each HR, (that is very short for two VDP changes
with the poor z80)

If it works it coul be a superb effect for MSX2 !!
Multilayer horizzontal scroll with plenty of sprites!!!