V9990 write mask

Página 6/7
1 | 2 | 3 | 4 | 5 | | 7

Por Juan Luis

Expert (105)

imagem de Juan Luis

09-01-2020, 23:54

Of course Manel46, in Bitmap modes B1, B2, B3, etc. all commands work without problems, but I was trying to flip patterns and sprites in P1 mode. Many people in this forum is trying to flip sprites in P1 mode without success, as far as I know. This topic is about WM mask. Perhaps the mask could solve the problem, but I see the answer is no.

Sprite-Test2.rom shows that this is possible. First pose of Rygar is shown with all possible flip combinations. The problem is the dirty pixels we have on Plane B. I think it could be a side effect of the command or a visualization of the sprite stored in linear mode. I would like to find out if the cause is the BMXLs commands or "call upload_sprite_linear" source code line.

One thing more. Your character looks quite colorful. Are you developing a game with these sprites?

Por Juan Luis

Expert (105)

imagem de Juan Luis

09-01-2020, 23:58

Juan Luis wrote:

Of course Manel46, in Bitmap modes B1, B2, B3, etc. all commands work without problems, but I was trying to flip patterns and sprites in P1 mode. Many people in this forum is trying to flip sprites in P1 mode without success, as far as I know. This topic is about WM mask. Perhaps the mask could solve the problem, but I see the answer is no.

Sprite-Test2.rom shows that this is possible. First pose of Rygar is shown with all possible flip combinations. The problem is the dirty pixels we have on Plane B. I think it could be a side effect of the command or a visualization of the sprite stored in linear mode. I would like to find out if the cause is the BMXLs commands or "call upload_sprite_linear" source code line.

One thing more. Your character looks quite colorful. Are you developing a game with these sprites?

Now I'm remembering that the developer of Ghost'n Gobling for MSX+V9990+Moonsound told that he was able to flip sprites with blitter. I don't remember exactly, but he told that it was possible flipping from linear memory in P1 mode.

Por Manel46

Hero (562)

imagem de Manel46

10-01-2020, 01:42

This sprite is actually a tile of the game recently published:
MSX IN A ROW!
https://www.msx.org/news/software/en/msx-in-a-row-by-mapax-r...
Yes, vdp comados, I understand that they are somewhat more complex, when we are in a pattern mode. Tomorrow I try what you say in the mail.

Por hit9918

Prophet (2895)

imagem de hit9918

10-01-2020, 17:06

Manel46 wrote:

Yes, vdp comados, I understand that they are somewhat more complex, when we are in a pattern mode.

but the LMMM goes in the charset which simply is a plain screen 5, no?

Juan Luis wrote:

The problem is the dirty pixels we have on Plane B

how about this: "byte acess goes with simply every second byte in the other layer"? is it that?
to the other layer in the same offset
you need to reserve a region in both layers to have byte business

Por Manel46

Hero (562)

imagem de Manel46

10-01-2020, 18:25

No hit9918. On the visible screen, we represent a sprite by its number and coordinates. The BMXL, will have to be applied in the attribute table, in any case, with the added difficulty that this sprint is 32x32 pixels, that is, it consists of 4 sprites of 16x16, which is the standard of the sprites in the V9990 P1.
Juan Luis, I understand that if you invest a sprite, you do it by creating another (4). If not, what you do is, draw a graph, and then you represent it inverted, not a HW sprite.

Por Juan Luis

Expert (105)

imagem de Juan Luis

10-01-2020, 19:11

hit9918 wrote:
Manel46 wrote:

Yes, vdp comados, I understand that they are somewhat more complex, when we are in a pattern mode.

but the LMMM goes in the charset which simply is a plain screen 5, no?

Juan Luis wrote:

The problem is the dirty pixels we have on Plane B

how about this: "byte acess goes with simply every second byte in the other layer"? is it that?
to the other layer in the same offset
you need to reserve a region in both layers to have byte business

Teorically yes, V9990 blitter sees PGT A and PGT B like a 16 colors bitmap (like plain screen 5 as you say). The problem we have found is the real hardware has a different behaviour compared to OpenMSX. I have tried LMMM in P1 mode with many different parameters. I wasn't able to get a good copy. Anyway, LMMM command only allow copying rectangular areas, but not flipping. DIY and DIX reverse the order of the pixel transfer for source and origin. So, the BMXL command is most interesting because you can do flipping if you have source image in lineal format.

About "byte acess goes with simply every second byte in the other layer" is true. I have uploaded even bytes to PGT A memory and odd bytes to PGT B, but there must be an additional. Real HW is not equal to OpenMSX V9990 emulation. Most of things are replicated correctly, but there are some details different. Hit9918, if you have the real HW you can test .rom files we are uploaded and see the differences.

Por Juan Luis

Expert (105)

imagem de Juan Luis

10-01-2020, 19:22

Manel46 wrote:

No hit9918. On the visible screen, we represent a sprite by its number and coordinates. The BMXL, will have to be applied in the attribute table, in any case, with the added difficulty that this sprint is 32x32 pixels, that is, it consists of 4 sprites of 16x16, which is the standard of the sprites in the V9990 P1.
Juan Luis, I understand that if you invest a sprite, you do it by creating another (4). If not, what you do is, draw a graph, and then you represent it inverted, not a HW sprite.

Yes, Rygar is a 32x32 or 4 16x16 sprites patterns. The 4 sprite patterns are flipped with just one BMXL command. Doing things in this way you can reverse objects or compound sprites much more bigger.

The idea was, if there is just one instance of a character like Rygar, we can flip directly its sprite patterns. If there are several instances of same character (like enemies) then it will be needed two sprite pattern sets for them.

Por GhostwriterP

Hero (528)

imagem de GhostwriterP

11-01-2020, 16:32

Today, I finally got myself to unbox and dust off the good old TR and GFX9000 module and do some testing on the BMXL in P1 mode subject myself and actually managed to get it working Smile. Although it is no 100% guarantee, I did not notice any corruption either.

There are a few tricky things to it though, which I simply did not realise back then.

As the memory is interleaved in P1 (and BMXL thinks and treats it as linear (as in bitmap mode)) the sprite data needs to be stored divided over two locations in vram. The odd bytes go in vram 00000h to 3ffffh and the even bytes go in specified vram address + 40000h (i.e. in 40000h to 7ffffh). To set the source address one should roll this to the left once (x2). For the designation the DX should be byte aligned, otherwise (in case of xflip) the nybles will not get swapped correctly. But this also results in that the sprite frame shifts one pixel to the right (or left) when flipped in x and the most right or most (left) pixel will actually fall outside your sprite, hence, this require some special considerations.

But in principle it seems to work.

PS: as a bonus BMXL is about 25% faster than LMMM in P1 (7.8kb vs 6.1kb /60Hz frame). Wink

Por PingPong

Prophet (3529)

imagem de PingPong

11-01-2020, 20:38

What do these things relate to the write mask? Is it possible to move a block without affecting plane b when working with plane a and vice versa?

Por Juan Luis

Expert (105)

imagem de Juan Luis

11-01-2020, 21:36

GhostwriterP wrote:

Today, I finally got myself to unbox and dust off the good old TR and GFX9000 module and do some testing on the BMXL in P1 mode subject myself and actually managed to get it working Smile. Although it is no 100% guarantee, I did not notice any corruption either.

There are a few tricky things to it though, which I simply did not realise back then.

As the memory is interleaved in P1 (and BMXL thinks and treats it as linear (as in bitmap mode)) the sprite data needs to be stored divided over two locations in vram. The odd bytes go in vram 00000h to 3ffffh and the even bytes go in specified vram address + 40000h (i.e. in 40000h to 7ffffh). To set the source address one should roll this to the left once (x2). For the designation the DX should be byte aligned, otherwise (in case of xflip) the nybles will not get swapped correctly. But this also results in that the sprite frame shifts one pixel to the right (or left) when flipped in x and the most right or most (left) pixel will actually fall outside your sprite, hence, this require some special considerations.

But in principle it seems to work.

PS: as a bonus BMXL is about 25% faster than LMMM in P1 (7.8kb vs 6.1kb /60Hz frame). Wink

Then, is your test free of dirty pixels?

Please GhostwriterP, share your code.

Thanks in advance.

Página 6/7
1 | 2 | 3 | 4 | 5 | | 7