Show HN: A 2D game engine in under 1000 lines of C
1–10 of 27 posts
Re: Show HN: A 2D game engine in under 1000 lines of C
#2What's with the majority of the code being in header files?
Re: Show HN: A 2D game engine in under 1000 lines of C
#3What's with the majority of the code being in header files?
Good question... (In fact, a small project with a single .c file does not even need include files.)
Re: Show HN: A 2D game engine in under 1000 lines of C
#4Looking at your `init` function, I would refactor it to not be so nested with if statements. Try logically inverting the if checks and returning early up near the top of the method and remove the else branches. Keep repeating this kind of refactoring on all your if statements. Eventually, you'll find that the "happy path" ends up at the bottom of the method and can return a success status without being so far indented. This style makes it easier to reason about what conditions are possible at various points in the method, i.e. you don't have to mentally compose the boolean logic conditions of all the nested if/else statements.
Here's an example I did: https://gist.github.com/JamesDunne/a94782bc39d95515f7dcc8516...
Also, I would generally move all implementation code out of header .h files into standard .c files. Header files are traditionally just meant to contain forward-declarations of types and methods.
Re: Show HN: A 2D game engine in under 1000 lines of C
#5Looking at your `init` function, I would refactor it to not be so nested with if statements. Try logically inverting the if checks and returning early up near the top of the method and remove the else branches. Keep repeating this kind of refactoring on all your if statements. Eventually, you'll find that the "happy path" ends up at the bottom of the method and can return a success status without being so far indente…
nested ifs work here too. i personally don't think cognitive overload is an issue because you are not composing all the conditions at once. in fact, each block should only care about one condition. but you make a good point.
tbh, i have seen nested ifs used in video game programming a lot. and i came to the conclusion that it has to do with the else clause that the return early method doesn't provide. the else clause is always doing something because games are never supposed to fail...
Re: Show HN: A 2D game engine in under 1000 lines of C
#6Looking at your `init` function, I would refactor it to not be so nested with if statements. Try logically inverting the if checks and returning early up near the top of the method and remove the else branches. Keep repeating this kind of refactoring on all your if statements. Eventually, you'll find that the "happy path" ends up at the bottom of the method and can return a success status without being so far indente…
nested ifs work here too. i personally don't think cognitive overload is an issue because you are not composing all the conditions at once. in fact, each block should only care about one condition. but you make a good point. tbh, i have seen nested ifs used in video game programming a lot. and i came to the conclusion that it has to do with the else clause that the return early method doesn't provide. the else clause…
?
If cond return err means everything after is an implicit else block
Re: Show HN: A 2D game engine in under 1000 lines of C
#7Earlier quoted context omitted.
nested ifs work here too. i personally don't think cognitive overload is an issue because you are not composing all the conditions at once. in fact, each block should only care about one condition. but you make a good point. tbh, i have seen nested ifs used in video game programming a lot. and i came to the conclusion that it has to do with the else clause that the return early method doesn't provide. the else clause…
? If cond return err means everything after is an implicit else block
> If cond return err means everything after is an implicit else block
Right, but inverting to get to return early format means that the “else block” that needs to do substantive work becomes the if block, and it needs to be doing something substantive not just “return err”.
Which may be a valid criticism in some cases, but doesn't seem to be in this particular code base, where most of the ifs don't have an else and those that do it's log-error-and-return.
Re: Show HN: A 2D game engine in under 1000 lines of C
#8What's with the majority of the code being in header files?
I think Ryan just wants a single compilation unit, for the time being. I would personally just put all the code in one file if it's this small (though I think some text editors are not good at editing one file from multiple views, so I can see that being annoying for some).
Re: Show HN: A 2D game engine in under 1000 lines of C
#9Looking at your `init` function, I would refactor it to not be so nested with if statements. Try logically inverting the if checks and returning early up near the top of the method and remove the else branches. Keep repeating this kind of refactoring on all your if statements. Eventually, you'll find that the "happy path" ends up at the bottom of the method and can return a success status without being so far indente…
nested ifs work here too. i personally don't think cognitive overload is an issue because you are not composing all the conditions at once. in fact, each block should only care about one condition. but you make a good point. tbh, i have seen nested ifs used in video game programming a lot. and i came to the conclusion that it has to do with the else clause that the return early method doesn't provide. the else clause…
The cognitive overload is not just in having to mentally parse a single complex conditional check on a single if statement. It's more an aggregate effect of having to mentally compose all of the conditions of the outer if/else branches that a line of code is contained within in order to reason about the code within that branch.
I'd also add that it's a good idea to break out complex condition checks to their own independent if statements on separate lines. I'd even go further and decompose the condition expression into individual boolean variables so that if you build in debug mode you have all the evaluated values held in variables for inspection. In release mode the variables should be compiled away.
There are some practical and aesthetic benefits that come from reducing nesting and breaking apart complex if conditions:
* less horizontal scrolling in your editor * no need to parse complex boolean expressions all stuffed into very few `if` statements * easier ability to step through code within a debugger and follow the execution logic more exactly * more distinct line numbers for crash dumps / stack traces to refer to in order to exactly identify which condition or evaluation is causing a failure
That last point is very beneficial when you hand your code off to someone else and they send you back a stack trace to investigate. Your code probably crashed at a complicated line of code full of boolean-combined expressions and any one of them could be at fault. All you know for sure is that something went wrong at that line number. No other hints given as to what went wrong or what the value of all the relevant variables on that line are.
Re: Show HN: A 2D game engine in under 1000 lines of C
#10Looking at your `init` function, I would refactor it to not be so nested with if statements. Try logically inverting the if checks and returning early up near the top of the method and remove the else branches. Keep repeating this kind of refactoring on all your if statements. Eventually, you'll find that the "happy path" ends up at the bottom of the method and can return a success status without being so far indente…
nested ifs work here too. i personally don't think cognitive overload is an issue because you are not composing all the conditions at once. in fact, each block should only care about one condition. but you make a good point. tbh, i have seen nested ifs used in video game programming a lot. and i came to the conclusion that it has to do with the else clause that the return early method doesn't provide. the else clause…
They work here too, but they're unnecessary since explicit short circuits are more readable and result in cleaner code. Apart from the obvious visual improvement, it encourages you to write functions that do one thing. Excessive use of "else" and branching can be a code smell. Over time, I've started using "else" less and less. I don't remember the last time I even used an "else".