next »

[qMopey]

By the way you can debug render your inertia tensor. If you diagonalize your tensor's 3x3 matrix you can extract an OBB and render it. This can give you insight into bugs like you had on twitter. Here's a thread for the idea: https://www.gamedev.net/forums/topic/386963-inertial-tensor/. Just look for Stan's posts, as he has some very easy to use diagonalizer functions available for public use.

It can look like this:

Code:

void debug_render_tensor(m33 m, v3 position)
{
    v3 diagonal = diagonalize(m);
    v3 obb_half_extents = diagonal;
    debug_render_obb(position, obb_half_extents);
}

Just make sure to render this thing at your rigid body's center of mass.

I also highly recommend you debug draw your transform hierarchy so you can easily see what is offset from what. This is especially important for setting up a rig with physics and a visual mesh, since they typically reside at different places, and can be parented to different things.

Edit: Actually I found his diagonalizer for 3D or 2D on his github: https://github.com/melax/sandbox/blob/3e267f2db2262a4cc6bf3f576c8c92b3cba79efc/include/geometric.h#L427-L479

You can see in his comment the input matrix must be symmetric. The inertia tensor is by definition symmetric.

[qMopey]

I've been messing with pixel perfect rendering for a while now. I am implementing some basic UI to create some in-game tools. All I wanted to do was render an AABB! Well, I wanted to render an AABB with a 1-pixel thick border color (like a border stroke). I ran into many problems. Here they were, in order:

• Implement d3d9 renderer. Took forever due to lack of debug tools and my misunderstanding of shader constants (uniforms).
• Fix half-pixel offset in d3d9. This also took forever.
• Added in the round() function to my vertex shaders -- I noticed that sometimes the size of geometry could grow or shrink by one pixel as a shape slowly moves across the screen. Constantly rounding has make this pretty much never happen (taking the error down from the range of a pixel to the range of a pretty small float epsilon, which should be good enough).
• Tinker around with d3d9's built in line renderer. Realize it doesn't have adjustable width. Realize it gives inconsistent results across different machines/driver versions. It also has weird fill rules I couldn't figure out. This would cause lines to shrink/grow slightly, or have pixel gaps between lists of connected lines.
• Implement my own line renderer (with adjustable width) by rendering batched quads. Line renderer via quads is consistent across all machines. Success!
• Realize naively drawing line-quads for bordering an AABB is a terrible idea, since as the AABB moves around the line vertices will pop around a 1-pixel radius. Edges of lines don't share vertices either! So I can still have pixel popping gaps between lines, but that's OK for now.
• Got completely distracted by noticing I had flipped the mul() ordering of mvp * vert in my hlsl shaders. Had to re-research matrix vector multiplication orderings along with storage orderings. Good thing is storage can be identical across DirectX and OpenGL, but multiply ordering should be flipped. There seems to be a way to set multiply ordering behavior in HLSL with #pragma pack_matrix(row_major), but I couldn't get it to work. This was affecting my 2d ortho transform. I noticed when I was searching through Dear Imguis's d3d9 renderer example to use as a baseline comparison for pixel-perfect rendering.
• Finally notice that a *way* easier way to render a bordered AABB is to render two AABBs with the back one with a width/height of +2 along the x and y axis!  

So here's proof I got the pixel perfect UI working, and a dumb AABB rendering with a nice edge stroke of 1-pixel wide (adjustable). I'm toggling the border stroke just to try and make sure it never wobbles (it seems fine for now):

In all this work spanned like three months, off and on working in the evenings    but now that the hard rendering API (d3d9) stuff is out of the way, finishing up the UI has been a breeze.

[oahda]

Kinda funny how something that used to be the only option on older hardware can be so difficult to do on modern. Glad to hear you worked it out tho!
 

Nice work! I like the debug rendering. Very smart of you to implement that

Been putting it off for quite a while to JWki's disappointment, but once I finally got around to openly pondering on Twitter how to go about it using ImGui, the author of that lib popped in to suggest Im3d, which is a different library rather than an add-on to ImGui (… which I didn't realise at first, so I had some issues ), but very handy! In addition to drawing stuff, it has gizmos for translating 3D objects with the mouse which will also come in handy!

Personally I have a nice little debug rendering suite for wireframe/solid geometry for all the common shapes, like sphere, capsule, cylinder, box, triangle, line, etc.

Am I misremembering, or was it you who turned that into a small library and posted about it on here?

By the way you can debug render your inertia tensor.

Ah! I'll be honest, the term is completely new to me since yesterday (after coming across the term in the Bullet API) so I'm not quite sure what 'tensor' means in this context, but I understand that it's related to the inertia and in turn the torque on my box that was sent spinning into oblivion, so that sounds useful and I should do some reading up! Thanks for the links. c:

[qMopey]

My personal favorite on inertia tensor is Stan Melax GDC 2013. It’s free to view on YouTube. He’s a real practical guy but also really knows the theory. So he will explain the fairly ridiculous math but also reassure the viewer that it’s just calculus and even he used wolfram alpha to get the result. And the rest is just transcribing to a little C++ function that takes a mesh and outputs a 3x3 matrix (the inertia tensor). The inertia tensor relates angular velocity to angular forces. It’s like the “rotational” version of mass. A “heavy” tensor means hard to rotate. So when you debug render a tensor with an OBB, the fat dimensions of the OBB represent more difficult to rotate axes.

That Im3d library is pretty good code. It’s very similar to some professional code I’ve written. Looks good to me!

And nah, wasn’t me that posted any debug rendering libraries... though I’d be interested to see which one you’re referring to if you come across it again

[oahda]

Ah, that explanation makes sense. Thanks! I'll put the video on my watch list too.

Yeah, it honestly wouldn't have mattered too much if Im3d was a bloated mess as long as it worked since it isn't going in release builds anyway, but it's a nice bonus!

I can't seem to find the library… Maybe it was never posted in is own thread but as a post inside of another. It was 2D only tho, maybe yours isn't?

[JWki]

BTW re debug rendering (I know I'm obsessed about that aren't I), just in case you weren't aware (and not already using it), Bullet itself has a small interface that you can implement to make it output debug viz of colliders, hitpoints, etc etc. The minimal thing you have to implement is basically "DrawLine", most other debug shapes are composed from that internally, but you can override per primitive if you have a nicer solution to render that specific primitive - so you have your "DrawOOBB", "DrawSphere" etc. Since you're already using Im3D, it shouldn't be any trouble to provide Bullet with an implementation so you don't have to do the work of manually figuring out bounding boxes etc for your debug drawing and instead can let Bullet handle that for you.

[oahda]

Oh, yeah! Bullet just keeps proving to be an almost verbatim 3D counterpart to Box2D, haha. Box2D has that too and I've used it in the past. Completely forgot about that. Thanks! I'll look into it. c:

[ThemsAllTook]

After about a month and a half of slowly nibbling away at it, my game now technically meets the definition of "playable". There's a win condition and a lose condition, and you can take actions to influence which of those happens. Milestone!

Hoping to start a devlog and post some screenshots when it's a bit further along. Right now the only way to see what's happening to the state of the game is to read printf output.

[oahda]

Yay! Good luck!

[qMopey]

SDL2 is just the best API I have ever used. Each time I look up their documentation to do something, it is crisp, meets my expectations, and has no extra bloat. Their API is the best example I know of as a case study for "good APIs".

If anyone wants to read something interesting about APIs here's some slides I wrote for a uni guest lecture a year ago. If anyone has any thoughts, please share with us! I think API design is a fun topic to chat about.

[ProgramGamer]

Oh yeah, SDL has the best documentation website of anything I’ve ever used, hands down.

[oahda]

SDL more like YESDL

[ProgramGamer]

Hey, so as it turns out making a homemade tokenizer is actually pretty easy!

About a week or two ago, I set out on a series of experiments to try and make a small programming language, and I was able to implement a tokenizer surprisingly easily. I'd previously tried using tools to generate a grammar for me, but by doing it from scratch I've found that it's actually not as complicated as people make it out to be. Once you know the basic principle behind parsing text and matching patterns, it's actually even easier, at least in my experience, to write your own pattern matching functions than using regular expressions or a parser/lexer generator like bison and yacc. All it does at the moment is translate a source file into a series of tokens, but it's already pretty nice and the source code for it is surprisingly elegant. Here's some random text I fed it along with what it outputted as a result.

Code:

import "text.io";

if someCondition {
	text.io.printLine "Hello world";
}

Code:

[import], ["text.io"], [;], [if], [someCondition], [{], [text], [.], [io], [.], [printLine], ["Hello world"], [;], [}]
Press any key to exit...

Needless to say, I'm pretty happy about this "first" foray into programming language programming. This language doesn't actually implement any behavior yet since it doesn't actually assemble tokens into an AST, but I think it's going to be relatively easy seeing how simple it was implementing text parsing routines

(btw I put "first" in quotes above because I've technically tried a few times to make a programming language, but this is my smoothest attempt so far)

[J-Snake]

Hey, so as it turns out making a homemade tokenizer is actually pretty easy!

About a week or two ago, I set out on a series of experiments to try and make a small programming language, and I was able to implement a tokenizer surprisingly easily. I'd previously tried using tools to generate a grammar for me, but by doing it from scratch I've found that it's actually not as complicated as people make it out to be. Once you know the basic principle behind parsing text and matching patterns, it's actually even easier, at least in my experience, to write your own pattern matching functions than using regular expressions or a parser/lexer generator like bison and yacc. All it does at the moment is translate a source file into a series of tokens, but it's already pretty nice and the source code for it is surprisingly elegant. Here's some random text I fed it along with what it outputted as a result.

That's nice. While you are on this train I strongly encourage you to check out this link:

https://www.nand2tetris.org

It is about a course (or a book "the elements of computing systems" plus software tools to build your computer platform) where you build a basic computer "from scratch" in a virtual environment (you can turn it into real hardware later on, if you wish), including a cpu, a ram and rom chip, and memory mapped I/O for the screen and keyboard. After the computer is designed you build the complete basic software stack typically needed to operate computers in the following order: assembler -> (stack based)virtual machine -> "Jack" programming language -> operating system(pretty basic, no file system etc., just a bunch of helper functions like for allocating memory or drawing text on screen and stuff of this kind) -> Program tetris in Jack and let it run

The computer architecture is not very efficient, but pretty simple and functional. Efficiency considerations are ignored in this book. Therefore, the creation of a complete computer platform, from the bottom to the top, can be achieved in a relatively short time.

Regarding Jack, it is comparable to a bare bones object oriented C variant, but already convenient enough to get some higher level stuff done and is easy to compile, while you are at it. The course won't cover any advanced or involved compiler topics such as bottom up parsing. And it doesn't need to. The course does only make use of recursive descent top down parsers, which are pretty elegant and sufficient for the contents of the course. The main point is that you get a hands on fundamental understanding on how computers work from top to bottom, and it achieves it in a pretty concise manner. So you can start with it right there pretty quickly without prior knowledge.

That should help. Hope you have fun;)

[ProgramGamer]

Oh hey, this looks really neat! Thanks for the resource!

[InfiniteStateMachine]

Are you using a language with pattern matching as a first class feature? I don't recognize the language in your code snippets.

I don't have a lot of experience but I've also found just using regular pattern matching seems to always do the job for me. I probably haven't done anything substantial enough to see the value in lex/yacc/antlr etc

[ProgramGamer]

Oh, the first code sample is just random stuff from no particular language. It’s just the input I was using to test the tokenizer.

Also the language I’m using to make the compiler is C#. It’s surprisingly expressive for this sort of stuff.

[oahda]

@ProgramGamer:
Cool! Maybe you have something better already, but this resource helped me a lot with this sort of stuff, so throwing it out there just in case: https://ruslanspivak.com/lsbasi-part1/

[JWki]

To my knowledge even the big compilers for popular languages (clang etc) don't use parser generators and I even see writing tokenisers and parsers as a relaxing exercise. Parsing small languages is big fun

[ProgramGamer]

That blog series looks pretty nice as well! Hopefully I'll have the time to go through both of your links thoroughly.

And yeah, I heard that big compilers don't tend to generate their grammars for a variety of reasons. I guess if it was that complicated of a topic to begin with, then we wouldn't have come up with high level programming languages in like, the 50s