S&K Special Stage lag

I found this out on the red-and-white special stage in Sonic 3 when I first played it -- doesn't seem to happen all the time on that one though.

 

Yes. Varion and I noticed this while I worked on my special stage editor. The "perimeter-detection" code seems to be sloppy. Sometimes it might hang up at all, with the music still playing of course since it's on the Z80.

This is probably why most stages don't have groups of blue spheres bigger than 4x4, with rare (if any) exceptions.

 

Oh man, that's freakin' hilarious. Never would've even crossed my mind.

 

Is there a video or something demonstrating this? I've never noticed it before. o.O

 

Huh. How odd.

Still, infinitely less intrusive than the Sonic 1 special stages' hitbox issues, which seem more noticible in Megamix due to their more complicated design. S&K's slot-machine bonus stage obvious doesn't share that problem, since the game has no trouble registering that you're touching more than one block at once.

 

Blue spheres slowdown

 

Ouch.
Are we looking at a for(check_sphere = 0; check_sphere < max_spheres; check_sphere++) code here?
It certainly looks like that. There is nothing wrong with the code itself, but the design of the stage. Miscommunication between programmer and designer.

 

Well yeah but those are the stages in S1&K, so they don't count very much. The main 16 ones go beyond 4x4 in just a couple of places: Sonic_3_%26_Knuckles_Level_Maps#Special_Stages. My guess is that they were aware of this issue, but they didn't bother to change the layouts in Blue Sphere because after all it's just a side game... And players aren't supposed to collect the blue spheres in that way anyway. Once they made sure that this issue wouldn't appear too often in normal S3&K gameplay they called it a day.

 

Is that the last one? The last one is only bluespheres with extra eight in the middle.

Speaking about Blue Sphere. The password generator program on the wiki hasn't been working for quite some time. Does anyone have another or know what the algorythm was?

 

That's not the last one. It's just a random one.

That's not a problem with our wiki, it's just that the website which contained the generator is offline. I have all the files which used to be stored on that website though, and I'm willing to upload them somewhere. NOT my webspace, though.

edit: whatever, I'll host it on my webspace temporarily. I will probably take it down sometimes in the near future.
http://digilander.iol.it/projectchaos2/BS/index.php

Note that all the links are likely to be broken, as I didn't edit the pages in any way. I only renamed index.html to index.php since my ftp is stupid, but aside from that, I uploaded a 1:1 replica of the original thing, and it works. Be grateful.

 

I am grateful. Thank you very much.

 

I explored the lag in the special stage provided above and this is what I got.
I'm quite facinated by it, actually, and what to know if there are ways to make it lag even more, as this was the most I got from this one.

 

It looks like we're looking at a recursive algorithm along the lines of:

1) Put Sonic's position in the stack
2) Take the top position in the stack and check all the positions directly north, south, west and east of it for unmarked red spheres
3) If a red sphere is found, mark it, and put the sphere's position in the stack
4) If the stack is not empty, repeat from step 2

I used a similar algorithm once to program a small minesweeper game. It proved to be insanely slow on large maps due to the associated overhead: in the worst case, there are always three positions around the current one that need to be marked. (All directions except the one the algorithm "came from", if that makes any sense.)

In my game I used it to figure out which spaces should be revealed when you click on an empty square, here it's used to find closed shapes. (If it keeps following the red spheres and finds Sonic again, then it went in a full circle.)

 

It also seems to be looking for just 1 red sphere, else 2x2 groups would turn to rings as well.

 

This might very well be a way for the code to safely bail out when the stack usage overflows.

I did some thinking about it, and this could probably be softened by adding a routine that looks for blue spheres anywhere around a red sphere. It would increase the overhead a bit by having to check 8 positions around the sphere rather than just 3, but if it flagged such red spheres with a "never check this sphere again" flag, on all subsequent visits they would be skipped and make the path-finding algorithm linear again.

I guess what I'm trying to say is this:



The crossed spheres will never turn into rings, so they will never have to be checked again.