Add JoltPhysics Vehicle C bindings and Zig wrappers

[agrapine]

Summary

• Add C bindings for JoltPhysics Vehicle system
• Add Zig wrapper types following existing patterns
• Enables wheeled vehicle physics with suspension, steering, drivetrain

New Types

• VehicleConstraint / VehicleConstraintSettings
• WheelSettings / WheelSettingsWV
• WheeledVehicleController / WheeledVehicleControllerSettings
• VehicleCollisionTester (ray and sphere variants)
• Wheel (runtime wheel state)

Key Functions

• Vehicle creation and configuration
• Driver input (throttle, steering, brake, handbrake)
• Wheel world transforms for rendering
• Engine RPM and gear state queries
• Step listener registration

[Srekel]

Skimmed through it and looks fine, but I'm not sure if zig-gamedev has a stance on the use of auto. :)

[agrapine]

Skimmed through it and looks fine, but I'm not sure if zig-gamedev has a stance on the use of auto. :)

are you referring to the c++ "auto" keyword? that would be quite strange

[Copilot]

Pull request overview

This pull request adds comprehensive support for the JoltPhysics vehicle system by introducing C bindings and corresponding Zig wrappers. The implementation enables wheeled vehicle physics with suspension, steering, and drivetrain simulation capabilities.

Changes:

• Added C bindings for vehicle-related types including constraints, controllers, wheels, and collision testers
• Implemented Zig wrapper types following the established patterns for memory management and API design
• Added vehicle-specific step listener registration functions to handle multiple inheritance correctly

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
libs/JoltC/JoltPhysicsC.h	Declares vehicle-related C types, enums, and API functions for the vehicle physics system
libs/JoltC/JoltPhysicsC.cpp	Implements C bindings with type conversions, memory management, and JoltPhysics integration
src/zphysics.zig	Provides idiomatic Zig wrappers for vehicle types with error handling and type safety

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Missing bounds checking before array access. The function directly accesses GetWheels()[in_index] without verifying that in_index is less than the number of wheels. This could lead to out-of-bounds access and undefined behavior if an invalid index is passed. Consider adding a bounds check similar to how other indexed access operations are typically validated, or document that the caller is responsible for ensuring the index is valid.

Suggested change

	return toJpc(toJph(in_constraint)->GetWheels()[in_index]);
	auto *constraint = toJph(in_constraint);
	auto &wheels = constraint->GetWheels();
	if (in_index >= static_cast<uint32_t>(wheels.size()))
	return nullptr;
	return toJpc(wheels[in_index]);

[Copilot]

Unsafe type cast without validation. The function casts the base VehicleController pointer to WheeledVehicleController without checking if the controller is actually of this type. While the current codebase may only use wheeled vehicles, this creates a potential type safety issue. If other vehicle controller types are added in the future, this could lead to undefined behavior. Consider either: 1) Adding runtime type checking before the cast, 2) Renaming the function to indicate it assumes a wheeled vehicle controller, or 3) Documenting this assumption clearly.

Suggested change

	return toJpc(static_cast<JPH::WheeledVehicleController *>(controller));
	if (controller == nullptr)
	return nullptr;
	JPH::WheeledVehicleController *wheeled_controller = dynamic_cast<JPH::WheeledVehicleController *>(controller);
	assert(wheeled_controller != nullptr);
	if (wheeled_controller == nullptr)
	return nullptr;
	return toJpc(wheeled_controller);