Earlier quoted context omitted.
For a computer game, if you start out by allocating a large block of memory, then manage it yourself, I don't see how this would be a problem.
You're not using the GC at all then. Why use Go (and praise its GC) in that case?
Why I Write Games in C (yes, C)
271–280 of 556 posts
Re: Why I Write Games in C (yes, C)
#272Earlier quoted context omitted.
This does not meaningfully follow. What you "want" is orthogonal to the responsibility of the vendors of software. The OS should protect where it can. So should software, lest your networked game nuke, say, the parts of your home directory to which it has permissions because without those permissions it can't do something it needs to. This is just defense-in-depth. It's super basic stuff and HN is literally the only…
I suspect GP's point is that a networked game should be limited in access to only parts of one's home directory relevant for that game (that is: the game's own save data or configuration files or what have you). It is absolutely the job of the operating system to provide that sort of sandboxing/isolation.
Defense in depth. Write good, sane, secure, fail-closed code when you want to ship that code to other people--or don't write code.
Re: Why I Write Games in C (yes, C)
#273Earlier quoted context omitted.
With JS the trick is to avoid creating new objects and instead have a pool of objects that are always referenced.
Definitely! Object pools are common in game dev too from what I know. We used them extensively to reduce the amount of GC we needed.
Re: Why I Write Games in C (yes, C)
#274> The strongest thing on my desired, but not required list is simplicity. I find looking up language features, and quirky 'clever' api's incredibly tiring. Indeed. Clever apis are a disease endemic to the JavaScript community. expect(me).to.puke.when(i.see.shit.like.this()); > The ideal language would be one I can memorize, and then never have to look things up. You can't memorize C. The idea that you can "hold C in…
Rewriting software sucks. We usually don't like solving the same problem more than once.
Re: Why I Write Games in C (yes, C)
#275Write C code. Compile with C++ compiler. Catch lots of bugs at compile time.
> Write C code. Compile with C++ compiler. What C only compiler were you thinking of? Most of the ones I can think of are toy compilers. If you're making a game, you're going to be using clang/MSVC/gcc. For catching bugs early, at least as important as the compiler are * Enabling additional compiler warnings and -Werror * Checking for memory leaks with valgrind * checking for Undefined Behavior with UBSan * Using mix…
Re: Why I Write Games in C (yes, C)
#276Earlier quoted context omitted.
Handmadehero started as C but transition to C++ AFAICT ?
I think he is the perfect example of why I don't care what those C (or minimalist subset C++) programmers have to say. When you actually see how he works, how much time he spends debugging his messy code. They are all sooooooo far away from what I would describe as remotely good, clean code. And all so full of themselves too of course. I liked Handmadehero for this reason, he is so arrogant and certain about how to p…
Re: Why I Write Games in C (yes, C)
#277> I am not an OOP convert. I've spent most of my professional life working with classes and objects, but the more time I spend, the less I understand why you'd want to combine code and data so rigidly. I want to handle data as data and write the code that best fits a particular situation.
I've come around to the idea much more that data should be the privileged structure and code should be considered transformations of the data. In some sense, code should be light and interchangeable and let the data is the first class citizen.
Are OOP and "data-centric" approaches at odds with each other? Does OOP only have validity when the data is relatively "small" and can be abstracted away easily?
Re: Why I Write Games in C (yes, C)
#278Earlier quoted context omitted.
> it was generally non-deterministic This is basically it. People who have never worked on actual real-time systems just never seem to get that in those environments determinism often matters more than raw performance. I don't know about "soft" real-time (e.g. games, or audio/video) but in "hard" real-time (e.g. avionics, industrial control) it's pretty routine to do things like disable caches and take a huge perform…
Its not just pauses either. Non-deterministic memory usage is a big deal too.
The software was shipped with a memory map file so you know exactly what each memory address is used for. A lot of test procedures involved reading and writing at specific memory locations.
It was for avionics BTW. As you may have guessed, it was certified code with hard real time constraints. Exceeding the cycle time is equivalent to a crash, causing the watchdog to trigger a reset.
Re: Why I Write Games in C (yes, C)
#279Earlier quoted context omitted.
C is closer to the hardware in the sense that with any given C code, I can pretty much predict what the generated assembly will look like. You cannot say the same for, say, Python.
> pretty much Not really... Not only the generated assembly code heavily depends on the compiler (LLVM, gcc, Intel, MSVC...) and the optimization settings, you cannot be completely sure what the machine code generated by the assembler even looks like these days.
Re: Why I Write Games in C (yes, C)
#280I’m not sure why but programmers like to reject entire languages instead of just rejecting the features they don’t like. A lot of stuff in C++ is entirely avoidable. Protocol-oriented programming is extremely useful for games and I like Objective-C for that reason. (Objective-C doesn’t meet his mentioned goal of portability but this is an example where C++ could be used to gain “light” inheritance without having to o…
Clang implements it, last I checked, meaning that it should be (at least in theory) portable to every platform Clang supports, no?