Sign in to follow this  
Followers 0

Sprite glitch when hurt

21 posts in this topic

Posted (edited)

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:

s2built_137.png

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.

Edited by redhotsonic
0

Share this post


Link to post
Share on other sites

Posted

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.

0

Share this post


Link to post
Share on other sites

Posted

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?

0

Share this post


Link to post
Share on other sites

Posted (edited)

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:

glitch.png

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:

s2built_168.png

Hope this more information will help.

Edited by redhotsonic
0

Share this post


Link to post
Share on other sites

Posted

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.

0

Share this post


Link to post
Share on other sites

Posted

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?

0

Share this post


Link to post
Share on other sites

Posted

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?

0

Share this post


Link to post
Share on other sites

Posted

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

0

Share this post


Link to post
Share on other sites

Posted

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

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

; 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:
; ---------------------------------------------------------------------------

; 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.

0

Share this post


Link to post
Share on other sites

Posted

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.

1

Share this post


Link to post
Share on other sites

Posted (edited)

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

Edited by redhotsonic
0

Share this post


Link to post
Share on other sites

Posted

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?

0

Share this post


Link to post
Share on other sites

Posted

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

0

Share this post


Link to post
Share on other sites

Posted

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

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:

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.

0

Share this post


Link to post
Share on other sites

Posted

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?

0

Share this post


Link to post
Share on other sites

Posted (edited)

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.

Edited by redhotsonic
0

Share this post


Link to post
Share on other sites

Posted

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.)

0

Share this post


Link to post
Share on other sites

Posted

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.

0

Share this post


Link to post
Share on other sites

Posted

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

0

Share this post


Link to post
Share on other sites

Posted (edited)

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

Edited by redhotsonic
0

Share this post


Link to post
Share on other sites

Posted

Sorry for the double post.

I've finally got the S3K object manager ported in with the help of Module. I then edited it a bit so the level runs smoother (so a more advance version of the S3K manager). And I can tell the difference, my levels do not slow down anymore, I can add a lot more objects in a level, the water ripples do not slow down as much anymore (until you get hurt), and the sprite glitch rarely happens!

That's right, rarely happens. So it still occurs. But it now seems to only happen when you get hurt, and even then, it's rare. Whereas it used to happen at any time (I haven't seen it happen at any time as yet). I took out my edits and it made no difference.

There's only one more thing to try that Module will also help me with, is porting S3K's touch_response. I really hope that fixes things. If not, I have no idea what is causing it.

I will keep you posted.

0

Share this post


Link to post
Share on other sites
This topic is now closed to further replies.
Sign in to follow this  
Followers 0