Lightnews — Scholar-powered news

schooliedee.bsky.social @schooliedee.bsky.social · 8h

#devtober day 13 - part 1 of the follow camera conversion

Spent most of the day off on working through the decomp site for the default / follow camera, then started the process of going from C -> unity.

As usual, the first stab did not work at all, but it gives me something to noodle on at work.

2 1 8

schooliedee.bsky.social @schooliedee.bsky.social · 1d

#devtober day 12 - adjusting the cloak shawl

I was feeling pretty good about this until I opened unity and realized I'd given him an airplane pillow. Will table this and resume camera work tomorrow.

If anyone with some modeling XP wants to take a stab at this, ping me on discord @schooliedee

6 54

schooliedee.bsky.social @schooliedee.bsky.social · 2d

#devtober day 11 - part 4 of movement parity

I have a rough version of the Quest 64 movement system being simulated at the original 30 fps (reusing the projectile sim approach), and it's starting to feel a little closer.

Was a big relief to finally see the walking + spin behavior for slow U-turns.

3 16 100

schooliedee.bsky.social @schooliedee.bsky.social · 3d

#devtober day 10 - part 3 of movement parity

In normal gamedev fashion, what seemed simple has spiraled outward as Quest 64 apparently uses a goofy little state machine for its movement.

Piecing it together has been a bit tedious, so good timing for a 3-day weekend.

3 16

schooliedee.bsky.social @schooliedee.bsky.social · 4d

#devtober day 9 - day 2 of movement parity work

After some confusion, the Quest64 code seems to have 3 distinct movement functions for a player and we were looking at the wrong one?

Realized this pretty late, so I just recorded test data and will work the unity side tomorrow.

2 14

schooliedee.bsky.social @schooliedee.bsky.social · 5d

The input curve itself is piecewise linear, but a lot of the quest code has awkward easing / dampening coefficients designed for a 30 fps runtime.

1 5

schooliedee.bsky.social @schooliedee.bsky.social · 5d

#devtober day 8 - part 1 of movement parity

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.

1 5 24

schooliedee.bsky.social @schooliedee.bsky.social · 5d

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.

1 1

schooliedee.bsky.social @schooliedee.bsky.social · 6d

#devtober day 7 - part 2 of fixed camera parity

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.

4 30 120

schooliedee.bsky.social @schooliedee.bsky.social · 7d

#devtober day 6, step 1 of fixed camera parity

Unglamourous afternoon of porting the original code for the Fixed camera mode into unity to replace my placeholder approach with spherical coords.

Big highlight of the day was Rain from the quest64 discord matching the function so quickly.

decomp.me

3 9

schooliedee.bsky.social @schooliedee.bsky.social · 8d

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.

1 8

schooliedee.bsky.social @schooliedee.bsky.social · 8d

#devtober day 5, sub evaluators

While I could poll the original map + camera data from an area, I could not do this with multiple sources.

Today's work was to add support for an evaluator to have "sub evaluators" which will help with interiors like dondoran and the monastery.

7 41 220

schooliedee.bsky.social @schooliedee.bsky.social · 9d

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.

Here, Blue triangles are Fixed. red are Follow.

1 2 14

schooliedee.bsky.social @schooliedee.bsky.social · 9d

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

4 34 180

schooliedee.bsky.social @schooliedee.bsky.social · 10d

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

8 54 300

schooliedee.bsky.social @schooliedee.bsky.social · 11d

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.

1 3 17

schooliedee.bsky.social @schooliedee.bsky.social · 11d

#devtober day 2, circle alignment.

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.

7 23 140

schooliedee.bsky.social @schooliedee.bsky.social · 12d

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

1 4 11

schooliedee.bsky.social @schooliedee.bsky.social · Aug 11

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

1 4

schooliedee.bsky.social @schooliedee.bsky.social · Aug 11

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.

1 1 5

schooliedee.bsky.social @schooliedee.bsky.social · Aug 11

The memory layout for much of this was found during the usual decomp / manip work, but the heightmap and camera components were pretty elusive.

Certain areas like Dondoran have 4 distinct camera configurations, which the game maps to individual faces on the navmesh:

1 1 3

schooliedee.bsky.social @schooliedee.bsky.social · Aug 11

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

2 2 9

schooliedee.bsky.social @schooliedee.bsky.social · Jul 26

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.

1 11

schooliedee.bsky.social @schooliedee.bsky.social · Jul 26

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.

4 25 120

schooliedee.bsky.social @schooliedee.bsky.social · Jun 29

Been working over the last few weekends to have the camera system more closely match what we're finding in the Quest 64 decomp effort.

I'd originally built the camera system with a spherical coordinate system, but the original project uses something closer to cylindrical coordinates.

5 46 190