Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
I used to do motion tracking. The team I worked with was one of the smartest group I've ever worked with. One of the first bugs I found was a mistake they'd made converting between different coordinate systems. It wasn't a big thing and they made the same mistake somewhere else and it all balanced out. But as soon as I did extra stuff in between it all broke. And working it out/explaining it melted my brain, as well as theirs. Coordinate systems are hard. I added a load of unit tests (they were hardware people used to manual tests), and there were loads of simple little edge cases. We used FFTs and it's cyclical so 32 points in one direction was equivalent to 32 points in the other direction but they'd just said it was 32 points one way and 31 the other which is barely noticeable in most cases except for exactly what I was working on.
-
@tosensei A nonvirtual method is a method that isn't marked virtual, abstract or override, and isn't implementing an interface, so it never appears in a vtable and never participates in dynamic dispatch. I borrowed the term from C++ where it makes sense to name these because they are isomorphic to a loose function with the first argument equated to "this", and as such can be safely cast to function pointer.
-
I'm pretty sure C# generates some glue to ensure that any method can be cast to predicate, but it makes sense to distinguish nonvirtual methods exactly because they are always convertible to static methods without removing previously valid use cases, since their only use case is to call them on a value of statically known type.
-
@lorentz technically, you can convert _any_ instance method to a static method with an object as parameter. if you prefix the parameter with "this", you even got an extension method, which _looks_ like an instance method (some syntactic sugar).
does not change the fact that a non-virtual method, as you described, still is an instance-method, and not a static method. -
@tosensei well no, if a method participates in dynamic dispatch then that means that the implementation can be modified by derived classes, so converting it to a static method without loss of functionality involves reimplementing a vtable.
-
@tosensei Extension methods are the perfect example; they read like an instance method, but there's no corresponding vtable entry in the original class so they can't implement interfaces and can't be overridden. The things you can do with an extension method are the same things you can do with a static method, because they're pure syntax sugar over a static method. For instance methods the same category is nonvirtual, which isn't explicit, you just have to not opt into any of the features that require virtual calls.
-
@blindXfish it's what newbies use, so it's what you use if you want to deal with newbies.
-
@blindXfish but I also appreciate that everything, however simple or complex, has meaningful docs. Obvious is subjective.
Me if i was a game dev
Apple rejected my app, because they throught there was a frickin Windows phone on my loading screen.
How inse...
I did a little bit of finger practice in Unity, nothing fancy just two spheres and a capsule-guy under Newtonian gravity and a force-driven player control script that works on spheres.
I will never understand how C# libraries spontaneously decide that some operations will be nonvirtual methods while others will be static methods. It is the exact same thing! You're just ruining intellisense for no conceivable reason!
Also, transform has a right but no left, the float return value of Vector3.SignedAngle is not the same unit as Transform.Rotate(Vector3, float), Transform has LookAt(Vector3 position) but not Look(Vector3 direction), to do that you need to
transform.rotation = Quaternion.LookRotation(Vector3.ProjectOnPlane(transform.up, direction).normalized(), direction)
you can't discover whether a collision encountered sticky or dynamic friction, you need to infer that by calling RigidBody.GetPointVelocity on both RB-s at the collision point, which has its own quirks. Apparently this is to keep the API engine agnostic, but any serious project will have its own physics materials which already specify the sticky friction coefficient. A simulation that works correctly with physics materials but doesn't discover the kind of friction as an intermediate result is not possible.
RigidBody's velocity isn't displayed in the GUI, so you can't give it an initial value without a dedicated script. I have a script on this fucking moon that does nothing but add a force in Start.
Is it just me or does Unity feel cheap somehow? Like a hastily written library for a research project that was never rounded out with the obvious features. I understand that it's a free product that catalyzed the golden age of indie game development, but I think it's seriously struggling to keep up, not with the showy investor bait stuff, but with the standard of comfort modern tooling provides.
rant
c#
gamedev
unity