Got home a little late tonight, but the fixed camera work has highlighted some small deviations in the movement. I plotted and added an analog -> movement speed curve that matches the original, but it's still a bit off.
I am yeah, but it's increasingly driven by code as I align things with the decomp results.
The brain / virtual camera plumbing is still helping with things like its impulse generators, the combat camera cutaways, and I really like the dolly system they made too.
With yesterday's work being held up by a dumb typo, the fixed camera areas are working pretty closely to the original now. This will help magnify subtle things like slide activation time, general area feel, post-warp orientation etc.
This helps with things like organization, as it encourages me to parent things under the visualizer tool I made to align things with that original quest 64 data.
When moving between areas and comparing to the emulator, my math is still off somewhere for the actual camera constraints though.
Quest's camera modes in general are quite an oddity.
The decomp only recently discovered how the game determines which camera mode to use, with the final discovery being that the mode is assigned to the navmesh's triangles themselves.
#devtober day 4 - using the original fixed camera system.
Dondoran's U-shaped secret room is a good example of this, as the upstairs balcony is actually on the same submap and let me swap between the default camera mode and a fixed one.
This will hopefully replace my sea of indoor virtual cameras.
#devtober day 3 - decal shadows for areas with indirect light.
This was partly in yesterday's, but I'm trying to incorporate a slight decal shadow for actors to use in some lighting conditions. Trying just realtime shadows presented an odd look when moving through patchy shadows like canopies.
Whereas the original Quest 64 system just checks Brian's distance from preset circles in the world, I'd had a ton of trouble working out a sturdy procedural system.
Checking "safe" regions to spawn enemies in the overworld presented quite a challenge, with things like trees using terrain colliders.
Continuing the process of gutting the placeholder systems and replacing them with the decomp results. Today's was getting the random battle check to use the original's circle data.
This neatly (and thankfully) replaces the shaky procedural system I'd attempted.
#devtober day 1 - WIP terrain elevation alignment for the original Quest map data.
I have spent the last few weeks working on tool development to align Unity terrains and geometry with an exported version of the original stuff. Unity's sparse terrain docs mean this is mostly trial and error lol.
The overall goal is to tie these in with a terrain constraint system I shared awhile back (using Sebastian Lague's nice splines) and help the project feel like the original, especially in the subtler aspects of camera and horizon stuff.
Hoping to resume work and the last few commissions soon. o7
The process has also provided some insight into why overworlds have felt so laggy, but caves are relatively smooth.
Large overworlds like West Carmaugh are checked all at once, but the much larger caves like Cull Hazard (with significantly denser navmeshes) use a sophisticated tiling lookup system.
Spent the last few weekends working on a way to export the original map data into a unity-friendly format to reference as I build out each area. This has been surprisingly tedious (impossible without quest's decomp team), but there's a unique feeling when farfetched ideas start to take shape. 🧵
For the implementation, I had a lot of trouble trying to eyeball it with Unity-relevant coordinate math, so I ended up writing a conversion system between Quest 64 space <--> Unity space.
This let me use the decomp code almost verbatim, converting first into Quest units and then out as Unity units.
About a month ago, Mallos matched the Quest 64 combat camera code in the decomp project, which helped explain why my own attempt felt off. The original cuts the arena into slices and applies an angle offset depending on where Brian is.
Oh didn't realize they were on here, model was a commission from @guinreds.bsky.social so feel free to ping them if your own project needs some work done!
Another problem was getting a Dark Souls-style foot placement system on stairs.
I'm currently handling this with a vertical shift to the player model's local position based on a check against an IK-only collider for the feet. Player collision still uses a wedge for smoother motion up stairs.
Been stuck in a motivation slump lately, so I am revisiting old problems that I couldn't solve with the Dive project's demo.
The first was to incorporate a lean similar to 2B's from nier automata. It's still not perfect, but it feels subtle enough to give the polish I wanted.
I spent the weekend trying to make a procedural boundary / cliff system using Sebastian Lague's spline system, which ended up being 30 open tabs to read unity's ProBuilder scripting docs.
It's not perfect and some of the fringe cases don't behave, but we're slowly getting there.
