Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Felipe wrote:
Marzojr, is possible that your LUA sonic_hud.lua can show information of Sonic 2 Heroes? Speed, Time, etc. As is the principal function. It will be essential for that I can create it future TAS planned. You can do it?
Like I said in the thread: when I release the next version, I will do it; before then, it is just a waste of time (since I redid the entire RAM layout to consolidate free RAM, as well as the entire object layout to reduce lag).
OmegaWatcher wrote:
I don't think a rom hacks that only removes the impossible rings will be accepted. see that romhack that removes all rings and was promptly rejected
The particular ROM hack we are talking about does a lot more than simply remove the rings; the primary thing it does is allow simultaneous 3 players with Sonic, Tails and Knuckles.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
My hack helps a bit more than that -- it removes unreachable rings, so that a perfect bonus is possible in all levels. If you wait for the next version (and I really recommend you do), you can also get perfects on S1 levels and I finish removing unreachable rings.
There is the downside that you can only grab rings that are minimally off-screen -- it uses the S3&K ring manager to reduce lag and free RAM for other purposes.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Lets see: fewer bits for color means fewer wires and simpler (thus cheaper) chips; it means less RAM needs to be used for palettes (and less color RAM), which means a cheaper console; and so on.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
In theory it should be possible; in practice, it is nowhere nearly as simple as you think it would be. Here is how Gens does it:
If CamHack is not needed (object in question is offscreen), then just update the screen and do nothing else;
otherwise: it the camera is currently more than 640 pixels away horizontally, force it to be this value;
likewise, if the camera is currently more than 448 pixels away vertically, force it to be this value. The camera is also forced to be above the target;
compute how many frames it will take the camera to scroll to the selected object from the position computed above;
save the entire object RAM;
emulate (without redrawing) the number of frames obtained in (4) above, setting some RAM flags to prevent the game from updating as much as possible and copying the object RAM over the emulation results;
emulate one last frame to redraw.
Doing all of this is needed because the camera has a speed limit on how fast it can scroll (and the image will be all wrong), as well as to prevent objects from loading due to the new camera position.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
So... because of this video showing a new glitch by 5688gamble, I may have to redo Flying Battery 1. And check to see where else I can try this.
Edit: Yep: some 6 seconds faster at least.
Edit 2: I still have to redo the boss fight, and act 2 will be an enormous pain to redo, but here is the new FBZ1. The previous version hit the Gapsule switch at 0:28::12; the new one does it at 0:17::45. Considering that the previous version was already an improvement of 0:01::33 over the published run, the total for this act is expected to be an improvement of exactly 12 seconds over the published run.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
You mean showing Tails offscreen and multi-track recording? It is already there -- the versions of Gens I offer precompiled can do that already. The code is not mine, it is Upthorn's and Nitsujas.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
DDRKhat wrote:
@Pr. Pwnage - Are you certain of this? Have you seen a "Perfect" bonus in a special stage? either way I think it'd be entertaining for the viewer to see both characters with exactly the same rings, but knowing that there is additional time for the "perfect" to countdown is helpful.
The "perfect" bonus is a 50000 point countdown, plus the time it takes for the other countdowns to leave the screen and the time it takes for the perfect countdown itself to enter the screen.
Derakon wrote:
In any event, it's not possible to get perfects on all bonus stages, even with control of two characters, as one of the last two emeralds has a segment where rings and bombs show up in basically random positions at high speed.
Only for the last emerald, and only the rings; but yeah, it is not possible to get a perfect bonus there.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Nach wrote:
marzojr wrote:
Windows is not involved at all here. Things are being compiled on RHEL5 and running on RHEL5.
Basically the same OS. Again, having paid more attention to what you wrote would have told me that. This rules out different exception models, so this would be a false lead. Sorry for that.
You said it is not a problem with functions declared with "throw(...)", and that the exception type in question is being caught in the catch block; so this leaves the constructor for the exception itself and the destructor of any objects that gets called when the exception is thrown. A difference in security policies could be responsible for the differences between the machines.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Static linking libstdc++ and libgcc might fix the problem, but I would not recommend it. And yes, passing a constructor that throws through libstdc++ might cause the problem.
Out of curiosity: would you be on Linux and cross compiling to Windows?
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
If you are sending a binary to your client (instead of code to compile), and it works on other systems, then it is likely that it is a difference in the exception handling style between your machine and the clients (I should have paid slightly more attention to what you said). You can try running this:
gcc -dumpspecs | grep -o --color 'dwarf[1-4]'
and ask the client to do the same; if nothing is printed, then the exception style is sjlj. If there is a mismatch, this may cause the problem you describe if the exception is being thrown across one of the shared libraries (e.g., your code calls library code which calls your code which throws the exception).
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Are the functions declared with "throw()" or "throw(stuff)"? If the latter, can the type of the exception being thrown be converted to any of the types specified in 'stuff'? Also, what type of exception is the program being compiled with, sjlj or dw3?
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
HHS wrote:
I was going to wait until the current run was done, but since it's been over a month, I'm going to ask anyway. Is there any place where it is possible to use the electric shield to get enough rings on screen to trigger the sprite loading bug? Perhaps in one of the levels that wrap, since the rings can get enough vertical speed to pass Sonic without hitting him?
Uff, this is shaping to be a much bigger pain than I thought I would be. Of the 4 vertically looping levels (MGZ1, ICZ1, SOZ2, SSZ2), the best shot at this is, by far, MGZ1 -- at least in theory, this level has enough rings in the initial descent for the trick. The problems:
it is impossible to go down without grabbing a few on the places you need to touch the slopes to jump off (not much of a problem);
dodging these many rings is very hard, particularly since they don't share the same starting position;
dodging these many rings while preventing them from being deleted due to them being out of range is extremely hard;
that damn drill makes you wait for far too long, having to dodge the rings on a limited space.
I won't give this a priority, so anyone else is welcome to try.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Bobo the King wrote:
Say Marzo, what kind of central force potential (if any) do rings follow with the lightning shield? I'm just curious.
For the horizontal coordinate:
if the ring is to the left of Sonic and is moving right, the ring accelerates $30 subpixels/frame/frame;
if the ring is to the right of Sonic and is moving left, the ring accelerates at -$30 subpixels/frame/frame;
if the ring is to the left of Sonic and is moving left, the ring accelerates at $C0 subpixels/frame/frame;
if the ring is to the right of Sonic and is moving right, the ring accelerates at -$C0 subpixels/frame/frame.
The vertical coordinate works the same, changing "left" and "right" into either ("above" and "below") or ("up" and "down") as appropriate (as well as anything else needed to make the sentences make sense).
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Lets see: there are 90 slots for dynamic objects in S3&K; so if we assume some braking dust from Tails (easy to get 3-6 objects by doing 1-frame brakes), plus 4 objects for lightning shield sparks, we would need around 80 rings (considering there are other objects on-screen) to fill all slots. There are around that many rings on the initial descent in MGZ1, with a lightning shield conveniently at the start. Dodging those rings for long enough is liable to be a pain, but I will try it.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
WST wrote:
I saw your finished run on youtube, and I have to ask: why didn’t you submit it? It’s extremely enjoyable to see…
I would guess because it is terribly unoptimized? I did some work on that hack (using rev 8), and I haven't optimized it thoroughly, but I got much better times than that:
Green Hill 1 0:24:44
Green Hill 2 0:12:53
Green Hill 3 0:31:14
Marble 1 0:15:04
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
skychase wrote:
I must go to the red dot, then spindash and jump to get through the floor in a jumping state, then fly to the wall and jump to the right to fall behind the rings.
Now, why didn't I think of that? I basically invented the trick... Anyway, the zip I posted earlier is much faster, so you may consider using it instead.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Felipe wrote:
This is the first
I tried that as well. Sadly, the ejection routines start by trying to eject the character to the right, as you probably saw in this case.
For what is worth, it is actually possible to get to the zip point faster by entering a wall through the nearby 10-ring monitor; but since it requires taking it to enter the wall, it isn't suitable for the no-rings run.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
WST wrote:
And even if there was an enemy, you should avoid getting harmed if you are making a no rings run.
He can get a shield for that.
WST wrote:
I think you should look deeper for ability to zip through walls to left to be directed to the end of the level…
That is what I have been trying more recently; everything place I have been trying had come to nought; until I found this. As far as I can tell, there is no faster zip for Knuckles in MTZ3.
Mr. Pwnage wrote:
Metropolis 3 is a vertically wrapping level. Can't you just scroll the screen and pass the rings when they're not in memory?
The rings only work like that in Sonic 1; in Sonic 2 and 3, they are maintained in a separate list which is ordered from left to right, then from top to bottom. If the ring is horizontally offscreen you can't grab it; but if it is vertically offscreen, you can still grab it.
