* When building with CMake, dynamic model lists are now generated
* Factored common code out of generate_*_list.js files to deduplicate
* Better separated generated model lists from main game code
`dynamic_asset_data.c` and `dynamic_animated_asset_data.c`
previously #included the corresponding generated headers, and
`dynamic_asset_loader.c` declared externs for the contents.
This messiness was likely done so the generated code would be built
automatically (the Makefile globs all C files under `src/`).
Now, model list data is output to C source files which are built
explicitly. This, with some refactoring, allows the previously
mentioned source files and externs to be removed.
This is a bit hacky in the Makefile but will be automatic under
CMake by using target properties.
* Reorganized some files under `tools/`
This value is set when compiling anyway, but this change makes the value
match for consistency.
Now that the default is the actual intended value, it doesn't need to be
overridden in the Makefile, but since scene scale needs to be passed to
skeletool regardless I'm going to keep the preprocessor define too so
they don't get out of sync.
Libultra include directory and library path are now found dynamically and
saved in a CMake cache variable so they can be overridden by users.
The game now links to libultra. Most linker errors are now due to lack of
integration with generated code dependencies.
With CMake, the game version is stored in a generated header file so
dependencies on it are kept track of automatically.
The game now compiles when using CMake but does not link.
Generated code dependencies are not hooked up yet and corresponding
targets need to be built manually.
Useful for room shapes which cannot be handled by standard visibility
checks.
Normally this can be addressed with additional rooms and doorways, but
sometimes a room is required to be a complex shape (for example, to
accomodate animated static geometry).
These instances should be few and far between, so leaving this as an
opt-in feature that can be used during level authoring.
* Doorway normals now always point toward room A. This was intended
and code was written for it, but typos prevented it from working.
* Consistent doorway directions allowed resurrection of previous
collisionSceneRaycastDoorways() implementation
Standard culling is quite coarse, for performance reasons:
* Only uses axis-aligned bounding boxes
* One visible object in a BVH node will make all others in the same node visible
These properties allow the bounding boxes of rotated objects to clip through
the back of portals to be considered visible, causing improper rendering.
This commit introduces a new optional argument for `@static` level
objects: `precise_culling`. Static geometry marked for precise culling
will be culled based on its exact (i.e., rotated) bounding box, in the
same way dynamic/animated geometry is.
Precise culling is more expensive than standard culling so it is opt-in.
It is intended only for the few situations that can hit the edge cases
described above.
The player's bounding box was not reinitialized on save file load,
causing the collision detection area to include the space between the
level's starting point and their current position.
In large levels (i.e., chamber 15) when far away from the start, this
caused the internal collider limit to be exceeded resulting in a buffer
overflow and crash.
Previously, all activated catchers would reference the same ball
when saving, causing position and signal issues if the referenced
ball's launcher was in use.
Fixes glitchy ball movement in chamber 15 final room.
The previous implementation handled flings in any horizontal direction.
However, this allowed moving against flings by first moving slightly
perpendicularily to them. In other words, the fling direction could be
changed midair allowing free movement relative to the original direction.
One way to solve this is by saving the initial fling direction (direction
of travel while in air and FLING_THRESHOLD_VEL is reached). For simplicity
and to minimize errors, just consider movement axes individually. The
game's levels only permit axis-aligned flings anyway.
* Moved player sound code from scene.c to player.c
* Moved platform position/velocity update to playerUpdateFooting(),
which is where the other related platform code is
* Moved player footstep state update to playerUpdateFooting()
* Created separate function for processing player input
* Created separate functions for movement and acceleration
* Removed some redundant code
With acceleration now separate, movement physics are ready to be
updated.
Dynamic object pairwise collision should be efficient enough to handle
additional objects, since only those with intersecting bounding boxes are
compared further.
Optimized raycasting by only considering dynamic collision objects in
rooms that the ray passes through. Previously, all were checked with
some distance calculations at the very least (to determine if intersection
was impossible). Raycasts are done by player grabs, player footing updates,
and portal HUD/firing.
This should be sufficient. Further optimizations can be investigated if
needed going forward.
Eliminates the two stationary dynamic collision objects that were
previously used.
This change refactors entities.lua and collision_export.lua to support
autogenerated static collision for any object which may need it in the
future.
* started on chamber 15
* fizzler width can now be scaled via blender object's scale.x
* fix fizzler rendering radius (remember, fizzlers are per default 2x2, still their internal width height was 1x1?)
* chamber 15 first room functionally complete
* chamber 15: first room decor
* finished first room of chamber 15
* test chamber 15 second room WIP
* chamber15 hallway from room 2 to room 3 (WIP) and more progress on room 2
* test chamber 15: added observation room to room2, added voice lines add the beginning
* test chamber 15: finishing room 2
* enable "new game" menu entry for chamber 15 & boot into the intro menu again instead of straight into chamber 15
* Start on shamber 15 hazard hallway
Hallway is modeled with collision. No platforms.
* Decals and platform + light cutouts for chamber 15 hazard hallway
* Animate one moving platform in chamber 15 hazard hallway
This one animation is ~19 KB. Look at optimizing.
* Add material for water hazard wall
* Use water hazard wall material in chamber 15
* Start modelling final room of chamber 15
* Chamber 15 final room - side rooms
* Chamber 15 final room - pistons and exit
* Chamber 15 final room - observation room
* Chamber 15 final room - ball launcher and catcher
* Chamber 15 final room - ball trap and indicator lights
* Chamber 15 final room - ball trap doors
* Chamber 15 final room - collision
* Chamber 15 final room - animations and triggers
* Chamber 15 - escape hatch
* Chamber 15 - finish final room
* Chamber 15 - start on room 3
* Chamber 15 - main room 3 layout and collision
* Fix UV translation
Do not translate minimum coordinates, otherwise the translation will be
cancelled out.
* Chamber 15 - room 3 stair room
* Chamber 15 - room 3 dividers and ball launcher/catcher
* Chamber 15 - room 3 finishing touches
* Observation room decor
* Triggers
* Indicator lights
* Decals
* Chamber 15 - merge beginning and end
* Chamber 15 - fix room boundaries
---------
Co-authored-by: Deconimus <pascal.sielski@gmx.de>
Co-authored-by: Deconimus <Deconimus@users.noreply.github.com>
When determining room visibility, the camera's frustum was previously
used for all recursive doorway checks, meaning rooms were considered
visible even if they were occluded. With the right level and camera
angle, all rooms could be considered visible at once.
Now, for each recursive check, a new frustum is created from the previous
doorway's bounds.
This helps significantly in larger levels, but there is still room for
improvement. Each new frustum is not clipped to the previous, and so it
is still possible for unseen rooms to be included.
It's important to consider performance here. Some checks may be too
expensive for realtime. At a minimum, a worthwhile improvement is to
precompute at compile time which rooms are potentially visible from a
given room. At runtime, other rooms can be quickly skipped.
* replace OSTime with Time
* replace osGetTime with timeGetTime
* replace OS_CYCLES_TO_USEC with timeMicroseconds
* replace OS_CYCLES_TO_NSEC with timeNanoseconds
also
* lastReportStart of ProfileData was used to store both cycles and microseconds, now it stores only microseconds
* fix typo: ns instead of us
* Wrap OSTimer usage into sleep function.
* Remove unused gLastTime.
This makes time.h independent from libultra, so let's rename time.c to time_libultra.c.
TODO: should we move time.h and time_libultra.c to the src/system folder?
* Add time unit to macro name.
* Move time initialization call to main function.
* Move time.h and time_libultra.c to src/system folder.
* Decouple controls interface from libultra.
* Use enums instead of defines for constant values.
* Get both controller stick axes with a single function call.
* Move controller .h\.c files to src/system folder and rename controller.c to controller_libultra.c.
* Adhere to enum and struct naming convention of the codebase.
* Fix typo: the N64 controller only has one analog stick.
