graphic error during sprite shrinking on particular systems - Page 1

Today I have tested my game on several systems and have unfortunately found a weird graphic problem on the Neo Geo systems
MV-1FZ (MVS), MV1-ACH (MVS) and NEO-AEC (AES) which not appears on the systems MV-1C (MVS), MV-2F (MVS) and NEO-0 (AES).
(It also does not appear in emulators.)

When the alien boss zooms (or more specifically re-shrinks) into the stage there is a black area visible beneath the boss sprites which expands
according to the actual shrink level. Did anyone else have seen this issue before and if yes, what could be the reason for it?

The shrinking effect has been done with DATlib for any of the 6 boss sprites with this code:

SC234Put (0x8096, zoom_in(shrinkStep));
SC234Put (0x8097, zoom_in(shrinkStep));
SC234Put (0x8098, zoom_in(shrinkStep));
SC234Put (0x8099, zoom_in(shrinkStep));
SC234Put (0x809A, zoom_in(shrinkStep));
SC234Put (0x809B, zoom_in(shrinkStep));

Here are some pics taken from my CRT screen (the regular behavior can be seen in this video from 1:24 https://www.youtube.com/watch?v=vpLtxeDV2EQ ):

Weird one, is the issue bound to a specific chipset revision?

I do not know how DATLIB inits a sprite - be sure to set all unused parts in a sprite to a valid transparent tile. maybe some chipsets or bios revisions inits sprite table different!?

I have just dusted off a second 2-Slot MV2F and this one shows also this strange error which is quite confusing
Contrary to the first 2-Slot MV2F the L0 ROM chip has a slightly different number https://wiki.neogeodev.org/index.php?title=L0_ROM

first 2-Slot MV2F - zoom-in works
------------------------------------------------
TOSHIBA 9240EAI
TC531000CP
000-L0
C554

second 2-Slot MV2F - zoom-in with graphic error
------------------------------------------------
TOSHIBA 9245EAI
TC531000CP
000-L0
C554

1-Slot MV1ACH - zoom-in with graphic error
-----------------------------------------------
TOSHIBA 9537EAI
TC531001CF-12
000-L0
R763

1-Slot MV1FZS - zoom-in with graphic error
------------------------------------------------
TOSHIBA 9509EAI
TC531000CP
000-L0
C554

It's just date codes.

You can dump them if you want to make sure, but they are supposed to be the same.

What's the video chip among systems? LSPC ? LSPC-A2?


Datlib does nothing special with sprite init, wasn't aware of this issue. It just sets the correct sprite height in VRAM.

spriteheight in VRAM is very strange, it's more like a window than a tile-height. in my opinion it's important to set all unused tiles to a valid transparent tile and to clear all autoanim-flags!

Thank you a lot HPMAN and Blastar for your thoughts about this issue. Will post the video chip versions of all
of the Neo Geo systems I own tomorrow (I have to unscrew the system cases to check the boards which takes
a while because three of the MVS boards are consolized).

I have tested Jeff's (NeoBitz) shrinking function from the original video library (change_sprite_zoom(sprite_no, xz, yz, nb); )
and the function causes the same "black box" graphical issue also on the same "problematic" systems.

As blastar wrote, the sprite height in SCB3 really specifies a vertical window.
The height is specified in tiles (16 pixels increments) and is used by the video chip to know if the sprite falls in the raster line being rendered, along with the Y position.

This can be a problem with vertical shrinking if the sprite's tilemap contains garbage after the used zone.
With 0 shrink, the sprite graphics should match the height you specified so no problem.
With shrinking, the video chip will continue rendering forward in the tilemap until it reaches the sprite's height. So if there's garbage in the tilemap, it'll end up being displayed.

The solution in that case is to clear the sprite's unused tiles to a completly transparent tile.

Also, this can cause problems with the 96 sprites per line limit because even if the tiles are transparent, they still count as sprite pixels and count in the limit.
So you can also automatically adjust the sprite's height by computing the value from the real graphics height and the shrink value.

That being said, it's weird that the glitch only occurs on some systems. I thought SNK stuck to the same logic for all video chips.

The MV-1FZ, NEO-AEC and MV1-ACH all have LSPC2. The MV-1C has NEO-GRZ and the MV-2F has the PRO chipset. So anything not based on LSPC2 shows the glitch ?

Now, I have checked the chips of the boards and it seems that not the GPU is responsible for the "black box" glitch.
The two MV2F systems and the two AES systems have the same chip set but act differently when shrinking a sprite.
The only difference is the BIOS (SNK BIOS or UniBios), all systems with SNK BIOS show the glitch and all systems with
UniBios doesn't show the glitch.

MV1-ACH > NEO-GRC,  NEO-MGA,  BIOS: SP2-S2 SNK Bios > shrinking causes graphic glitch 
M1-FSZ  > LSPC2-A3, NEO-B1,   BIOS: SP2-S2 SNK Bios > shrinking causes graphic glitch 
MV-1C   > NEO-GRZ,  NEO-YSA2, BIOS: UniBios         > shrinking works

#1 MV2F > LSPC2-A2, NEO-B1,   BIOS: SP2-S2 SNK Bios > shrinking causes graphic glitch 
#2 MV2F > LSPC2-A2, NEO-B1,   BIOS: UniBios         > shrinking works

NEO-0 	> LSPC2-A2, NEO-B1,   BIOS: Debug SNK Bios  > shrinking causes graphic glitch 
NEO-AEC > LSPC2-A2, NEO-B1,   BIOS: UniBios         > shrinking works

With that conjecture in mind I have replaced the the SP2-S2 bios chip of the MV1-ACH board with an UniBios Chip
and after that the glitch was not visible anymore. Obviously Razoola has improved "something" in his UniBios
what fixes that shinking glitch.

Seems that if I want to be sure that shrinking works also on systems with regular SNK bios, I have to set all unused tiles
of the shinked sprites to transparent and deactivate autoanimation. DATlib provides a function to manipulate SCB1 data
with "SC1Put(addr, size, pal, data);". Would it be possible to do it with this funtion, HPMAN?
If yes, could you please post a sample code for: sprite no. 150 / tile 1 to 6 are used / tile 7 to 32 are unused?

Thanks for the details, quite reassuring

Wait... LSPC2-A3 ?!

Yes, and beside the LSPC2-A3, I have found that mysterious NEO-MGA-T chip on the MV1-ACH MVS board which is surprising (https://wiki.neogeodev.org/index.php?title=NEO-MGA)

Here is a (huge) photo of the MV1-ACH: http://www.neohomebrew.com/forum-pics/2016/MV1ACH.jpg

And this is a photo of the LSPC2-A3 (M1-FSZ MVS board):

NEO-MGA isn't too surprising, it's used as glue in the Neo CD. But LSPC2-A3 is something new to me ! I'm guessing it's a technology or pinout change.

Thanks for the pictures, can I use them for the wiki ? Do you have an overall picture of the M1-FSZ ?

Yes, of course you can use the photos - I am glad that I can give you something back for your hard work on the wiki
Here is a pic of the M1-FSZ: http://www.neohomebrew.com/forum-pics/2016/M1FSZ.jpg

NeoHomeBrew (./9) :
Seems that if I want to be sure that shrinking works also on systems with regular SNK bios, I have to set all unused tiles
of the shinked sprites to transparent and deactivate autoanimation. DATlib provides a function to manipulate SCB1 data
with "SC1Put(addr, size, pal, data);". Would it be possible to do it with this funtion, HPMAN? If yes, could you please post a sample code for: sprite no. 150 / tile 1 to 6 are used / tile 7 to 32 are unused?

Just load a dummy blank 16*512 sprite beforehand I guess?

That's going to be an issue in pooled mode tho.

Great, thanks again Seems LSPC2-A3 has the same pinout as A2, the mystery remains.

About your sprite problem, for CPHD we decided to give a parameter to the sprite setup function, telling how many tiles had to be cleared after the specified height. Clearing all 32 tiles each time was way too slow.
Keeping track of how many tiles are used per sprite to know if/when to clear them for new sprites might be a solution but will need some RAM.

Let's say that at startup, you clear all the sprites tiles to transparent.
Then you set a sprite to display some graphics 7 tiles high, sprite height 7 obvisouly, and no zooming.
In another scene, you re-use that sprite but with graphics only 5 tiles high, sprite height 5, no problem.
But if you shrink it vertically, the 2 remaining tiles from the previous setup will start to show on the bottom: problem.

If you keep a location in RAM for each sprite, you can write the graphics height to it each time you set up a new sprite.
That way, for future setups, you can compare the last height with the new one and just clear enough tiles to avoid the glitch.
No need to do any of that if the sprite won't use vertical shrinking of course.

:3

HPMAN (./14) :
Just load a dummy blank 16*512 sprite beforehand I guess?.

HPMAN, thank you a lot for this idea - it fixes the problem! Loading a 16*512 (or 96*512 in my case ) sprite with all tiles in transparent "pink color" (#FF00FF)
into the respective sprite number (before loading the "intended to be shrinked"-sprite into that sprite number) works perfectly. I have tested it successfully on all
systems with SNK Bios (it also works with UniBios) without seeing any glitches. It is a simple and handy solution - I think it is not really necessary to clear all sprite tiles
all the time in general if it takes too much CPU speed/RAM. I know sprite shrinking was not really implemented into DATlib yet, but for the next update could you maybe
please add a special sprite init function for "shrinkable" sprites?

furrtek (./15) :
Great, thanks again Seems LSPC2-A3 has the same pinout as A2, the mystery remains.

Thank you for your sharing your experiences with that shrinking glitch and your detailed info
If you want that M1-FSZ board to desolder the LSPC2-A3 just send me a PM with your adress, I would send it to you as contribution for the wiki.

How many informations about NG HW I have learned while reading these posts
Very interesting argument, thanks all.

Hi there. HPMAN just pointed me to this thread.

The first thing I can say is the Universe Bios has nothing added to address the problem you describe. Why the Universe bios fixes this issue is a mystery to me also because I have never added code to address the situation. There is a table in all MVS/AES Bios related to zooming from 0xC02000. I always though this table is in relation to X zooming only and I have never really tested if it is ever actually physically used by the hardware. Its one area that can be checked however to see if different bios have a different table here.

Like others have said the solution is to fill unused tiles in the sprite strip to transparent tiles, maybe the unibios is doing this but from memory the bios clears the sprite table before it hands itself over to code on the gamecart. As furrtek says these transparent tiles are going to count towards the 96 tile limitation per line.

It might also be an issue related to timing and the position of the scanline while you are updating sprite attributes. Test to make sure you are updating the sprite attributes for this sprite while you are sure the scanline position is above the position the boss sprite on screen.

Can you try something with unibios?

Load a dark full sized sprite beforehand instead of a transparent one.

See if it still displays ok or not. I think it's just blind luck with how the bios sets things up.

The Universe Bios is based on the bios named 'sp-s2.sp1’ in MAME archive, Can you see if using that bios also addresses the issue? If it does not then its clearly something I have added in the Universe Bios.

Raz

HPMAN (./19) :
Can you try something with unibios? Load a dark full sized sprite beforehand instead of a transparent one.See if it still displays ok or not. I think it's just blind luck with how the bios sets things up.

OK, I have loaded a solid black 96*512 pix sprite into that sprite number before loading the 96 * 96 pix Alien Boss sprite into to it.
The result is an expanding green box beneath the boss sprite. This happens on all real systems with SNK Bios/UniBios
and can even also be seen in emulation (SNK Bios and UniBios act the same). I have made a quick video of it (sorry I couldn't resist to kill the boss):

Razoola (./20) :
The Universe Bios is based on the bios named 'sp-s2.sp1’ in MAME archive, Can you see if using that bios also addresses the issue? If it does not then its clearly something I have added in the Universe Bios.Raz

Hi Raz, thank you for joining the discussion and for adding your detailed info. Seems that now almost all "celebrities" of the Neo Geo development scene are active on Yaronet which is awesome.
I will burn that SP-S2 BIOS and report back soon.

No need to check that SP-S2 BIOS now...

I did a quick investigation comparing the Universe Bios to stock bios and can now give you an answer to this weirdness.

The stock bios writes 0x0000 to all the even tile number LSBs and 0xFFFF to all the odd attributes to SCB1. This means all 4 MSBs tile bits are set when system passed off to game.
The Universe Bios writes 0x0000 to all the even tile number LSBs and 0x0000 to all the odd attributes to SCB1. This means all 4 MSBs tile bits are clear when system passed off to game.

My advice would be for your game to simply clear the sprite table during its standard init sequence. This will mean all tiles in each strip will be tile 0x00 in sprite memory which you should have set to a transparent tile.

For example;


clrspr move.w #$0001,$003c0004
move.w #$0000,$003c0000
moveq #0,d0
move.w #$6fff,D1
bsr.s scloop
move.w #$8000,$003c0000
move.w #$0fff,d0
move.w #$01ff,D1
bsr.s scloop
move.w #$8200,$003c0000
moveq #0,d0
move.w #$01ff,D1
bsr.s scloop
move.w #$be00,d0
move.w #$01ff,D1
move.w #$8400,$003c0000
scloop move.w D0,$003c0002
dbf d1,scloop
rts

Issue demystified Thanks for clearing it up and also for the code snipped.
I will try to integrate your ASM code into the init code.

Sure thing, just remember to kick the watchdog before the routine is called and kick it again once its completed or you may experience resets.

NeoHomeBrew (./16) :
If you want that M1-FSZ board to desolder the LSPC2-A3 just send me a PM with your adress, I would send it to you as contribution for the wiki.

People using the wiki is all we want Thanks for the offer, but I wouldn't be able to know anything more having it in my hands I guess.
Maybe they added a register like the video mode switch in LSPC2-A2 or something that some games might detect and use, or just a minor signal timing fix... I'm able to sleep without knowing so it's alright

Hi Raz !
About $C02000, they call it "METRIC_DATA" in the AOF source code. I also thought it was some X zooming distribution table.
Would have to find a game which uses it (nam1975 title screen doesn't).

Glad the issue was fixed anyways.

Issue isn't quite fixed when reusing sprites among different elements tho, still has to carefully reclear tilemap when planning a scale.

METRIC_DATA is used in alpha mission 2, sub using it at $139d8.

Also used in league bowling @ $4476

Doens't looks scaling related at all, it's used to move some items around (like the "noooooo" text in bowling intro).

It's 2 sets of 64 tables of 64 byte values (c02000 & c03000).


Also used in 2020 super baseball for ball hit detection seemingly. If you mess with the values returned you can't hit the ball