Sprite "one line" artifact on screen update. Somebody knows why?

Page 1/2
| 2

By hope-hunter

Rookie (22)

hope-hunter's picture

02-06-2022, 23:26

Hi!
I would like to know why this "line artifact" happens. It is in MSX-BASIC, emulated on OpenMSX.
I understood well the top and bottom displacement: The top was renderized using the previous X coordinate and the bottom are using the new X coordinate.
But I can't understand that one line that appears sometimes, between the top and bottom of sprite. :o
Somebody knows how to explain that?

Note: When the cars are going to right, these "line artifacts" are displaced to the right.

Login or register to post comments

By thegeps

Paragon (1068)

thegeps's picture

03-06-2022, 00:37

Maybe we can help you if you paste here your code

By hope-hunter

Rookie (22)

hope-hunter's picture

03-06-2022, 04:51

In the example above I used a technic to update the sprites attribute table using the copy command (VRAM to VRAM). The sprites trejectories are pre-renderized in another page. This whole loop it something is like.

FOR J=0 TO 128:COPY (0,J)-STEP(239,1) TO (0,4),1:NEXT J
* The sprite attribute was previous setup to be at coordinate (0,4) of PAGE 1 and PAGE 0 has 128 setups (positions) for all sprites. So this unique copy command update all sprites and it is very fast.
Note: Is a put a SET SCROLL 0 before the copy command the artifacts did'nt happen because SET SCROLL waits V-SYNC, but I lose Frames Per Second.

I also made another code now to see if this "middle artifact" occours:
10 SCREEN 5,2 : SPRITE$(0)=STRING$(32,255)
20 FOR X=0 TO 255 : FOR I=0 TO 10
30 PUT SPRITE I, (X*8, I*17),10 ,0
40 NEXT I,X : GOTO 20

And i get that:

The artifact is a little different, but I also don't know how to explain this part between the top and bottom frames.
It is also possible to see it on WebMSX.

By hope-hunter

Rookie (22)

hope-hunter's picture

03-06-2022, 04:53

To get these pictures I keep pressing PAUSE many times until I got the glitch. But if you pay attention, it is possible see it during normal run.

By Sandy Brand

Champion (285)

Sandy Brand's picture

03-06-2022, 12:08

I think you may have already identified the reason Smile
If SET SCROLL waits for v-sync and then you issue the copy commands, then the chances are high that these commands will be performed well in time before the VDP actually displays the sprites.

What is probably happening now is that the sprite attribute table is being modified while the VDP accesses it to render the sprites. This leads to undefined behavior. I am not super familiar with the sprite engine in the VDP, but I think it actually processes data 'one line ahead', which might explain some of the artifacts you are seeing.

You could maybe try to put your copy commands on the ON INTERVAL GOSUB function. Or you could make a loop in BASIC checking the TIME variable or directly the "JIFFY" integer that is stored at &HFC9E. These should be updated some time in the V-Blank. However, BASIC is slow, so it might still not give hard guarantees.

By Arjan

Paladin (775)

Arjan's picture

03-06-2022, 12:46

Does this happen because BASIC uses the VDP command type LMMM?

In SCREEN 5 this will do a per-pixel copy which means each 4 bits of the sprite attributes are copied individually. So if you move a sprite from X=128 (1000 0000) to X=127 (0111 1111) the sprite might end up at X=112 (0111 0000) for a short time if the copy of the highest 4 bits happens before the sprite engine access the X location.

By aoineko

Hero (527)

aoineko's picture

03-06-2022, 13:45

As Sandy said, if you modify the SAT (Sprite Attribute Table) during page rendering, the SAT data will be in a undefined stat when the vertical scan will arrive at the point where the VRAM is being modified.
I see 2 solutions to avoid this:
- Update the SAT only during the V-Blank,
- Use 2 SAT and display the screen with one while you modify the other.

By Calindro

Rookie (18)

Calindro's picture

03-06-2022, 17:22

Can you share your rom for investigation?

By hope-hunter

Rookie (22)

hope-hunter's picture

03-06-2022, 23:50

@Sandy Brand You say:

Quote:

"What is probably happening now is that sprite attribute table is being modified while the VDP accesses it to render the sprites. This leads to undefined behavior. I am not super familiar with the sprite engine in the VDP, but I think it actually processes data 'one line ahead'"

Yes, you understood well what I'd like to know: 'Why the sprite engine generates that pattern of image when we update the coordinate X of sprite during the sprite engine access?'

It is important to me specially because I also program in assembly with splitscreens and etc. For this BASIC project I think I can't to improve much more.

Quote:

You could maybe try to put your copy commands on the ON INTERVAL GOSUB function. Or you could make a loop in BASIC checking the TIME variable or directly the "JIFFY" integer that is stored at &HFC9E.

I also use this technics, but how you say above, BASIC is very slow and today, the best way I found to wait V-SYNC is to use SETSCROLL 0 (unfortunately only MSX2+ has this instruction).

By hope-hunter

Rookie (22)

hope-hunter's picture

03-06-2022, 23:44

@Arjan,

Quote:

Does this happen because BASIC uses the VDP command type LMMM? In SCREEN 5 this will do a per-pixel copy which means each 4 bits of the sprite attributes are copied individually. So if you move a sprite from X=128 (1000 0000) to X=127 (0111 1111) the sprite might end up at X=112 (0111 0000) for a short time if the copy of the highest 4 bits happens before the sprite engine access the X location.

Great! Good observation @Arjan! I had forgotten I'm working with nibbles! It seems you solve the question! Smile2 Smile2
Now I'm thinking about that other glitch that happens using only PUTSPRITE like in the sample I post above. Maybe you can help in it too.

By hope-hunter

Rookie (22)

hope-hunter's picture

03-06-2022, 23:51

aoineko wrote:

Use 2 SAT and display the screen with one while you modify the other.

@Aoineko, it is also a good idea to avoid these glitches.

Page 1/2
| 2