91–100 of 113 posts
Earlier quoted context omitted.
Huge Carmack fan here but I feel the need to defend the latest hi-octane Doom incarnation from 2016 - IMHO great controls, fast old-school gameplay, superbe graphics.
I'd agree. The single-player for the new Doom was excellent, but not groundbreaking. The new Quake I'm not as much of a fan of, since it tries to be Quake 3 with some Overwatch bits tacked on.
Earlier quoted context omitted.
1. Refusing to just use Assembly. Was the reply we got in the old days, when one used C, Pascal, Basic, Amos. Thankfully many ignored that and moved the state of art to such languages. A few years later the reply would be, 1. Refused to use C When devs tried to use C++ or Delphi. State of the art in games development only advances thanks to those that manage to produce entertaining games, while ignoring such advices.
Game developers used Assembly to write games when it was the best tool for the job. They then moved to C when it was feasible and then to C++ when that was feasible. For their engines, they never moved on to anything else, because there still is no better tool for the job, all things (tooling, SDKs, platform support) considered. Unity, Unreal Engine and CryEngine are all written in C/C++. They have sometimes elaborat…
> These languages are not good choices for a game engine
I have seen these words written against C, Turbo Pascal, Modula-2, C++.
Some of the games I saw "written" in C for MS-DOS were like this all over the place:
void my_func(void)
{
asm {
/* 100% of my_func actual code */
}
}
Earlier quoted context omitted.
I refuse to use C/C++. If that's what I have to use to make games, I just won't make games. Fortunately, there are other languages available with a C FFI. I don't think forced memory management teaches anyone much of anything besides how to manage memory manually. It doesn't make programs better. I'm very grateful for garbage collection so that I can spend my cycles thinking about the problem I'm actually trying to s…
Used to have a hard time with C, but after working with it for some time you might get to appreciate what computers do more. I oddly find C pleasing, and choose it to solve many problems by default.
Earlier quoted context omitted.
First of all, I'm talking about game engines , not games. Both Unity and the earlier Unreal Engine (afaik) used GC-ed languages for scripting. However, if you want to make a quality game, you can not afford long GC pauses. I know that lots of people make games with GC pauses in them anyway. It is a value judgement, for sure. It's certainly possible to work around GC pauses, but that effectively means you are manually…
Some of the work done to work around GC feels similar to the work you'd do in C/C++ to work around memory fragmentation issues. Also, depending on the language/runtime, you might be able to influence the GC algorithm, or at least the frequency with which it runs. If you can e.g. run a GC every second for not longer than ~1 frame, then pauses won't be noticeable.
Earlier quoted context omitted.
Game developers used Assembly to write games when it was the best tool for the job. They then moved to C when it was feasible and then to C++ when that was feasible. For their engines, they never moved on to anything else, because there still is no better tool for the job, all things (tooling, SDKs, platform support) considered. Unity, Unreal Engine and CryEngine are all written in C/C++. They have sometimes elaborat…
Usually game developers changed language when the OS or game console's SDK release forced them to do so. > These languages are not good choices for a game engine I have seen these words written against C, Turbo Pascal, Modula-2, C++. Some of the games I saw "written" in C for MS-DOS were like this all over the place: void my_func(void) { asm { /* 100% of my_func actual code */ } } Just as if C was a macro assembler.
"I have seen these words written against C, Turbo Pascal, Modula-2, C++."
So what? Those words probably had a good argument behind them, at the time.
In the MS-DOS days, compilers weren't as good as today, so handwritten ASM paid off.
Earlier quoted context omitted.
I'd agree. The single-player for the new Doom was excellent, but not groundbreaking. The new Quake I'm not as much of a fan of, since it tries to be Quake 3 with some Overwatch bits tacked on.
If tacking on a few Overwatch bits means I'll be able to find matches, let it be. Quake Live has been pretty dead for a while now.
The Overwatch bits I'm talking about are champion abilities, which is against the entire premise of Quake 3 (everyone is equal).
Earlier quoted context omitted.
Unity's multi-platform track record is quite solid at this point in time. I wouldn't bet on exotic Java attempts of "write once run everywhere" though.
Java is actually not that bad – Java with LWJGL gets you within a factor of 1.6 to C++ performance, while actually being "write once run everywhere" (for PC, at least). That’s good enough.
You're not allowed to do JIT on consoles or mobile and you're memory constrained. A PC-only game engine is going to be a tough sell these days.
Also, unless you're bundling a JVM (not sure about the legals here) you have to make your Windows (i.e. primary) customers install the obnoxious Oracle Java runtime.
This can be said about plenty of things. Encryption is probably the most obvious; there's a lot of benefit from reading about and implementing various encryption methods, and absolutely foolish to use any of that work in a setting where it might actually be attacked. The article is pointing out something that should be obvious; if you're making a widget as part of a larger task, your implementation will probably be l…
Earlier quoted context omitted.
Usually game developers changed language when the OS or game console's SDK release forced them to do so. > These languages are not good choices for a game engine I have seen these words written against C, Turbo Pascal, Modula-2, C++. Some of the games I saw "written" in C for MS-DOS were like this all over the place: void my_func(void) { asm { /* 100% of my_func actual code */ } } Just as if C was a macro assembler.
SDKs never forced anybody to move to C or C++, but the opposite is true: C/C++ compilers were either unavailable or limited. "I have seen these words written against C, Turbo Pascal, Modula-2, C++." So what? Those words probably had a good argument behind them, at the time. In the MS-DOS days, compilers weren't as good as today, so handwritten ASM paid off.
> In the MS-DOS days, compilers weren't as good as today, so handwritten ASM paid off.
Just like C compilers had enough money spent into their optimizers, that eventually made them competitive against Assembly, so can C#,Go,D, have enough work placed into them, that eventually they will become competitive against C.
People believed they could make C competitive against Assembly, just like they believe they could make C++ competitive against C.
So it is a matter if one wants to believe and lead, or don't and follow.
Earlier quoted context omitted.
SDKs never forced anybody to move to C or C++, but the opposite is true: C/C++ compilers were either unavailable or limited. "I have seen these words written against C, Turbo Pascal, Modula-2, C++." So what? Those words probably had a good argument behind them, at the time. In the MS-DOS days, compilers weren't as good as today, so handwritten ASM paid off.
> So what? Those words probably had a good argument behind them, at the time. > In the MS-DOS days, compilers weren't as good as today, so handwritten ASM paid off. Just like C compilers had enough money spent into their optimizers, that eventually made them competitive against Assembly, so can C#,Go,D, have enough work placed into them, that eventually they will become competitive against C. People believed they cou…
There are of course languages (like Rust) that have the fundamentals to match C/C++, but then it's still a matter of adoption. C++ also still develops.