Dolphin has a widescreen hack that makes games render at 16:9 (or any other AR) without stretching, but it doesn't work in every game.
Last time I checked, TTYD was one of the few games that worked really well with the widescreen hack, but this was before the hack was even part of Dolphin and I didn't do nearly enough testing.
I'd MUCH MUCH MUCH rather someone actually start and finish a run of this game than have it forever in limbo while we wait for someone to program a "superswim bot".
That reminds me. There's something I've been curious about in regards to frames spent superswimming vs. velocity. As far as I know, that graph represents the velocity while superswimming. But what about the velocity after superswimming (e.g. a frame or so)? Is it more or less the same? Is it easier to model?
The time the door cancel saves is minimal, but it's so much cooler to spend a lot of time in fadeout, and maybe it'll mean the TAS will get a fadeout-less encode. Even though I doubt it because I don't know how TASVideos handles that situation.
99% sure the default encode here can be one without fadeout. The N64 encodes look way better than those games ought to look due to quite some upscaling, anti-aliasing, etc.
So visual trickery is allowed in encodes.
We're talking about hacking out drawing functions here, not upscaling or AA.
Game app emulation wouldn't be particularly difficult. Stuff like graphics and audio can be handled through HLE of OpenGL/AL calls, from what I can tell.
What is the symbol for door cancel mode? I can't seem to find it myself.
daPy_lk_c::dProcDoorOpen_init() modifies an instance variable (which has no symbol) that contains collision/movement flags for the player. See the code I posted earlier.
I mean, I want to know how you can tell what they do. Like how do you check the code at all. Where is it, what program, etc.
Oh whoops.
Dolphin's debugger and IDA Pro. I'm using the symbol maps (function and static variable names) that the game ships with which makes it significantly easier to figure out what's going on.
Provided you could somehow trigger this type of "large damage" arbitrarily, barrier skip would be trivial.
One thing I want to look into is superswims. The swimming pattern is starting to look like it's based off the animation, which is based off the speed. I'm thinking it's a natural function to create the flow with big and small strokes normally.
I'm not entirely sure how the swim movement code works. There's definitely some vaguely-sinusoidal "stroking" to the velocity though, and the period of the stroking is based on the velocity (faster is shorter).
Also, there are only two functions that enable this "low-collide" mode: door open (of course) and an unknown case of "large damage". Not very promising in the barrier skip department.
A somewhat-forgotten action-sorta-puzzle game released by Natsume in 1990.
I started working on a run, but optimization has proven to be quite difficult with this game. There are different routes you can take to complete a room, but the fastest one isn't obvious. I tried a few different routes and ended up ~60 frames faster than the video I linked.
I would suggest removing the cooler (stock is acceptable), SSD (costly for their size and reliability), sound card (integrated is everywhere), MAYBE the optical drive, and Windows. If you want it to be really affordable, go for less memory.
Turns out the heat shimmer effect is controlled by a class called daYkgr_c, rather than the more obvious dPa_kagero (kagerou = lit. "heat haze"), which is a different particle effect.
daYkgr_c has a static member variable called m_alpha_flag. Setting it to 0 will cause the effect to fade out. Therefore:
(offset is 0x803E9FFA in NTSC-J)
Edit: apparently, this is already on the WW page on the Dolphin wiki. Welp!
The heat shimmer effect in DRC is basically a particle system anchored to the camera. Only way I've found of disabling it so far is by patching JPADraw::drawParticle (0x802690E0 in NTSC-J), but this disables every other particle system as well.
I'm guessing that chest darkness is handled by darkProc() in d_a_tbox.rel (treasure box?). A bit difficult to patch directly since it's in a relocatable module.
(offset is 0x803E9FFA in NTSC-J)
Edit: apparently, this is already on the WW page on the Dolphin wiki. Welp!
