Glitch when scrolling to the right only. - Page 1

Hi guys;

I am trying to port my game Shadow Gangs to the NeoGeo, I got now to the point where I can start polishing and optimizing the game.
I get a glitch on the background scrolls, when the character is moving right, and not when he is moving left.

On GNGEO it looks like this:
[img][/img]

On Mame, the glitch is still there, but instead of a empty vertical line, it's like white or black small dots or rectangles all over the screen.

It doesn't happen when moving left on both GNGEO and Mame.
Doesn't happen also when the framerate is 60 fps.
Doesn't happen when Idle, only when moving.
Also, If wait for 2 or 3 Vsyncs or more, it doesn't happen. (But then the game is then very slow)

I am not using sticky, and I put the sprites on the correct X position.

The thing that I don't understand, is that it happens only when moving right, not left...

Do you guys have an idea what the issue might be?

hi,
if you look closely then the sprites on the right side are really offset by 2 pixels... this must be due to your code. if this column is not visible when you scroll to the left... is there perhaps a 2pixel overlap?
never ever use any other emulator than the latest version of MAME for development, this is the closest to the real hardware... GNGEO and others emulators are rather optimised for games and do not cover all facets of the hardware.. maybe you can upload a screenshot from MAME!?

Hi Blastar;

Thank you very much for the reply.
I can't see where in my code this is happening, it can be... but looking at it yesterday I couldn't see where the offset is happening.
I have uploaded a video using Mame this time, showing scroll right which shows the issue in the background, and a scroll left that shows no issues.



Mame yes, I found it more accurate, I am using them both.

Horrible tearing (in both directions) , your code is way too slow... something is wrong with your update/scroll routine for the background layers.
how many sprites per layer do you use?
do you update the complete background sprites (2 layers) for every frame?
what happens if you completely deactivate the skyscrapers layer?

I still didn't optimize it, trying first to get everything in place before optimization and polish.

There is 3 layers here, even if I deactive them all and leave the front building background, I still get the same snow issue.
No, I don't update the background, just the sprite positions.
What puzzles me is it happens going right and not left, and I use the same code for both right and left movement.

are you sure that you only update each sprite-position once per frame?

Yes, just verified, only once per frame.
Using sprites 1 to 40.
I put them like this:
one tile 32 pixels is two sprites in width, I set one sprite position and the other half of the tile another sprite at 16 pixels offset. These two tile sprite I don't the gap in them.
The next adjacent tile however at offset 32 pixels, there the empty lines shows randomly:

I did some more tests yesterday, and I think I found out where the issue happens, but not why still.
Is it possible to see the debug log on any emulaor (printfs ?)
or to attach a debugger to an emulator?

I use a hash map with the free list of hardware sprite id, and get them from this hash map in a loop.
It's a templated hash map and I suspect weird behavior from it from the NeoGeo, on pc it looks fine when I look at the values...
If I don't use this hash map, the game has no glitch and is very fast.
And even when it slows down, I didn't see the issue again.

Anyway, some bug in my code somewhere.

Still having this issue, no idea why it is happening.
Will try some test programs next.

shadowgangs (./8) :
I did some more tests yesterday, and I think I found out where the issue happens, but not why still.
Is it possible to see the debug log on any emulaor (printfs ?)
or to attach a debugger to an emulator?

I use a hash map with the free list of hardware sprite id, and get them from this hash map in a loop.
It's a templated hash map and I suspect weird behavior from it from the NeoGeo, on pc it looks fine when I look at the values...
If I don't use this hash map, the game has no glitch and is very fast.
And even when it slows down, I didn't see the issue again.

Anyway, some bug in my code somewhere.

Sorry I can't help with your specific questions there but I think the most efficient way to do horizontal scrolling is to use the same group of hardware sprites in a loop. Then you don't need to look for a free sprite - you just write a new column of tiles directly into the sprite that is currently off the screen and to the right. Just keep track of which sprite is there and when you need to write a new column of tiles.

Hi CosmicR;

Thank you for the reply.

I did some test today, and it seems that doing things fast after the waiting for the vertical sync is making this issue disappear.
I tried chaining sprite using the sticky bit as you suggested, and I didn't get these glitches.
I am trying now another method of multidirectional scrolling using the sticky bit, and no hash lookup.

I am very happy.
I changed the way I scroll to now use the sticky bit, and also to exploit the rolling of the sprites at 512 pixels boundary (on both X and Y)
So hopefully, the main issue that it seems from my tests was mainly lots of data being written to Vram, and some cpu processing while doing so, is fixed. Will need to test to make sure.

( This reminds me of MsDos days, I made a game and I did use double buffering and needed to send the data to the framebuffer as fast as possible, after vblank, and no processing done while doing so. Used rep movesd for that for
that on x86 assembly)

I was wondering is it possible to write tile data while on active display? (probably not, just asking as it would be convenient if possible)
I would like to write tile data on active display, and on vblank set the positions.
Probably a no no, just asking.

Thank you for your help guys;

Great to hear you got it working smoothly shadowgangs 👍

You can write tile data on active display but you will most likely end up with sprite tearing - unless you time the writes until after the raster beam has already passed that point on the display (a lot of effort!). BUT if you are just drawing new tiles to sprites currently displayed off the side of the screen - go for it. You wont get any tearing then obviously

Thank you CosmicR;

Just wondering about timing the write after the raster beam passed the active display, that is the Vsync interval?

If that what it is, it's not difficult to have the writes execute after that, I can detect when the NeoGeo is starting Vsync using the vblank interrupt, and write at that time.
(Issue is preparing the data to be written beforehand, which take up ram)

Or maybe I missunderstood?

shadowgangs (./14) :
Just wondering about timing the write after the raster beam passed the active display, that is the Vsync interval?

The Vsync is different. I was just telling you that because you said you wanted to update sprites during active display. I've never done this myself but I think the best way to do that is to sort all the sprites by y position (previous to the vblank) and the draw the higher sprites first as soon as vblank starts. The idea is the raster beam won't have caught up to the lower sprites by the time those get drawn. I *think* Kraut Buster by NGDEV uses this technique. I remember there is an option for y-sorting in the menu. I think it eliminates sprite tearing at the expense of maybe a little slowdown (not sure has been a while since I played!) You only need to do this if you don't have time to draw all sprites during the vblank.

But yes, like you say - the standard (and simplest) way is always to wait for the the vertical blank and draw all the sprites at that point. And get them all done before the display starts. Usually this works fine. I would recommend you do this.

BTW have you thought of using DatLib by HPMan? I think that automates this process somewhat. I haven't used it myself (just because I like to learn everything myself!) but it's pretty slick. I think Xeno Crisis and Final Vendetta use/are using it. It has great scrolling functions too. It's basically a set of libraries you add to the devkit

topics/189390-datlib-update-03

CosmicR (./15):

shadowgangs (./14) :
Just wondering about timing the write after the raster beam passed the active display, that is the Vsync interval?

The Vsync is different. I was just telling you that because you said you wanted to update sprites during active display. I've never done this myself but I think the best way to do that is to sort all the sprites by y position (previous to the vblank) and the draw the higher sprites first as soon as vblank starts. The idea is the raster beam won't have caught up to the lower sprites by the time those get drawn. I *think* Kraut Buster by NGDEV uses this technique. I remember there is an option for y-sorting in the menu. I think it eliminates sprite tearing at the expense of maybe a little slowdown (not sure has been a while since I played!) You only need to do this if you don't have time to draw all sprites during the vblank.

But yes, like you say - the standard (and simplest) way is always to wait for the the vertical blank and draw all the sprites at that point. And get them all done before the display starts. Usually this works fine. I would recommend you do this.

BTW have you thought of using DatLib by HPMan? I think that automates this process somewhat. I haven't used it myself (just because I like to learn everything myself!) but it's pretty slick. I think Xeno Crisis and Final Vendetta use/are using it. It has great scrolling functions too. It's basically a set of libraries you add to the devkit

topics/189390-datlib-update-03

Sorting and drawing would work fine, might try thank you.
Not using DatLib, I have already multiplatform code for Shadow Gangs, and tried to squeeze that into the NeoGeo.
But thank you for the suggestion, I actually didn't know that DatLib does all this, was thinking it's an image conversion tool