Sprite glitch when hurt

Has anyone else ever experienced this when hacking and knows a solution?


Normally happens when you get hurt (but it can happen at anytime), but a random sprite just glitches somewhere randomly on the screen for a split second.


For example, if I jump on some spikes and get hurt, a little part of a starpost sprite would just suddenly flash on the side of the screen. It won't neccessarily be a starpost all the time, it could be a badnik, more spikes, or even Sonic himself.


I'd say this only happens 10% of the time when you get hurt, and only 1% of the time when doing anything, but why does it do it?


I tried looking into the hurt code and cleared up as much as I can, as I figured out maybe it's too much for the (Megadrive) processor. I also tried removing so many sprites on the screen but that doesn't do help either. If it was just Sonic and some spikes on the screen, it may still happen.


Now, it's very hard to get a screenshot of this happening, because if I paused it or anything, it would sort itself out anyway (so, you can't pause the glitch). So this is the best way I could explain it:





If Sonic ran into that fish, there may be a flash of a random sprite, anywhere on the screen.


Also, this only happens when "Sonic and Tails" or "Sonic and Knuckles" (but not "Knuckles and Tails") so maybe Sonic is the problem. But it doesn't happen when it's "Sonic Alone"


If anyone knows a solution, I would be grateful. If you need mroe information, just ask.


Cheers,


redhotsonic


EDIT: Also, this happens with the emulator REGEN, but doesn't seem to in Gens emulator.

 

There are a few things that do come to mind that I can think of, the first one that immediately sprang was (as you mentioned) too much data being processed (a.k.a. lag), if you have a lot of code processing before the "BuildSprites" routine is run, and the "BuildSprites" routine is interrupted half way through due to V-blank, it is possible that V-blank will flush the sprite table off with only half the sprites accounted for and it "Might" leave things looking out of place. (I haven't seen such a situation occur, usually because the "BuildSprites" routine is ran before v-blank occurs).


Another theory is that one of your objects has a mapping list or map ID set to read incorrect map data (this often results in random sprites being mapped everywhere), however, this is a lot more extreme than the way you've phrased your bug.


In all honesty, I don't know, I'd need more information myself I'm afraid.

 

It's indeed really difficult to figure out what's happening here.


Is the sprite appearing on screen always a well mapped sprite and does the object exist in RAM?


You say it happens more often when Sonic's hit by an enemy, does that mean "when Sonic loses rings" or does it also happen more often if Sonic had a shield or is invincible?


When you say you can't pause it, you mean in game pause, or emulator pause?

 

Yeah, it's the lag that's causing it. I think Sonic's burst is the biggest problem to it (It can still happen when he's not bursting).


I had a re-look at the hurt routine "Touch_ChkHurt" and "Obj01_Hurt" and "Obj02_Hurt" and there was 1 or 2 jsr's that I was able to change to bsr.w, and there was one that was the same for the scattered rings object. This has actually helped and put the problem down, but it can still happen.


I managed to get a video if it. Will upload that later. It was Sonic running along then landing on the spikes getting hurt.


I then slowed the video down and got a screenshot of it:





It actually glitched a bit of Tails and Sonic, but like said, it can be any sprite, anywhere. As usual, only lasts a split second. As you can see, it even has a tiny bit of sprite on the far right of the "back" logo that is only found right at the beginning of the level:





Hope this more information will help.

 

It looks to me like the art transfering and the sprite mapping transfering are both out of sync, so yes, it's more or less lag, the only advice I can give to you is tone down on how much heavy code you put into your hack (or rather try using optimisation techniques if possible). Another recommendation would be that you could rewrite how the art/sprites are updated, but that may require breaking into things you probably wouldn't want to.

 

I would also check the dplc codes personally, maybe there's a conflict between them.


Just in case, what's the number of the "hurt" frame?

 

The hurt animation is number 19 (and hurt2 is 1A) but I don't think it's that as like said, it can happen anytime, it's just more common when he get's hurt. I've only changed the hurt code by adding one or two lines in their, so I do not think it's that.


I beleive like said that Sonic's burts is the biggest problem, but I've tried optimising it the best I can. I would post that here to let anyone else have a go, but then again, I don't want to share it otherwise everyone will have it. Unless someone doesn't mind me sending it via PM?

 

I don't mind trying, but I can't swear I'll find the solution

 

I took the burst out, and it's still doing it, but I did realise something:

Code:

; ---------------------------------------------------------------------------

; Start of Subroutine checking and activating Sonic's burst mode

; ---------------------------------------------------------------------------

Obj01_Chkburst: ; Start of Sonic's burst checking

 even

I noticed that the first thing it does is "even" I tried putting it above the label instead:

Code:

; ---------------------------------------------------------------------------

; Start of Subroutine checking and activating Sonic's burst mode

; ---------------------------------------------------------------------------

 even

Obj01_Chkburst: ; Start of Sonic's burst checking

And funnily enough, that helped. So I search through my whole ASM. Most "even"s were above the label, but there were a few that weren't. Does this really matter? All the ones I found underneath the label, I have put above, and the glitch hasn't happened again since.

 

It does matter.


I'm sure some savant Jester would explain it way better, but to give you an idea, even fills the ROM with 0's until the next even address. And those 0's will be read as instructions if the machine is supposed to read instructions there.


Remember your labels are actually addresses in the ROM, if the machine has to read data, have some data right after it, if the machine has to read the program, have the program there immediately after the label.

 

I always thought "even" just started whatever you're about to put underneath start on an even byte, instead of an odd?


EDIT: Forgot to mention, glitch still occurs, but it has got less frequent since I've moved them "even"s

 

That's what it does, but it has to put something between the last data and the one following it in order to achieve this.


Now about your glitch, it's still hard to tell. Does it happen in all levels, or only one of them?

 

This happens in S3K iirc, usually when there's lag. (Usually caused by messing around with debug)

 

It can happen in any level, at any time, with any Character (even with Knuckles and Tails now). It happens mainly when about to be hurt, but not neccessarily.


As for the evens, I've took many of them out to see if it helps, and it has. It still happens, but it's getting less frequent. So I think the evens are to blame. Also, I would liek to point something out:

Code:

Touch_Hurt:

 nop

 tst.w invulnerable_time(a0)

 bne.s Touch_NoHurt

 movea.l a1,a2

I thought I should take that "nop" out to see if it can help and the hurt rouinte still works fine. Seriously, why is that instruction there? I thought it literally did nothing.

 

Nop only wastes processing cycles, the only real use for it is synchronisation with other components (for example to read from a port, wait for data to be transferred or also in s3k to waste a few processor cycles to update only one palette line per horizontal line displayed).


In this case it's probably useless, but it's in the original and shouldn't make anything go wrong.


Did you try with debug mode off?

 

So far, taking the nop out has made no difference.


As for debug mode off, do you mean to see if the glitch happens with it off? If so, yes.


I'm getting rid of (or moving) more evens so that it can clear it up more, I think that's been the problem.


EDIT: Okay, there's something I do not understand. I have removed some evens and everything works fine and the glitch happens less frequently, although the ROM has grew in size from 2,600KB to 3,100KB. How does that make sense?


EDIT2: It's because I moved the soundriver.asm to a different location within the ASM. How that makes the ROM bigger by just moving it to a different place in the ASM I do not know.

 

I suppose you moved the sounds as well. I think it's because the beginning of the sound driver is aligned to the beginning of a 32kB bank (align $8000), there's probably a hole now in your ROM where it was.


Remember, you shouldn't have any even in the program itself, but you'd better have some at the end of every array of data (things such as graphics, mappings, animations, level layouts, deformation data arrays, etc.)

 

I found out the reason for the lag!


You know when you see an object and you run to the right? The object "Deletes" itself. When you go back, it respawns. Everyone knows that.


But it doesn't do it when you go up and down, the objects do not delete themself and stay there. In my hack, there are many routes in my levels (above, middle and below). Meaning there are objects above and below, and quite a lot. Because none of them have been deleted, they're all running, stressing the processor. And then when you get hurt, because it's about to spawn rings everywhere, making more objects, stressing the processor more, causing the "sprite" glitch.


I could just get rid of some of the objects, but then some routes will start to look bare.

 

Maybe you could port S3K's object manager, which takes the Y positions into account as well?

 

If you know how then let me in =P


I followed a guide to port in S3K's Ring manager in. There was nothing to be found about S3K's object manager. I knew they had a different system, and that explains why it runs more smoothly and that you can have underwater effects when Tails is following (I have underwater effects in my hack but it's auto-disabled if you have the sidekick following as it can go terribly slow).


EDIT: I found a guide for it, but I'm slowly failing at porting it in =P