201–210 of 238 posts
It can still be done today of course, but it is less of a necessity. Teams choose to spend that time working on other aspects of the game instead.
Earlier quoted context omitted.
I may be naïve/out of the loop here, but it’s fun to imagine what would be possible with the same gusto and creativity applied to today’s hardware. I imagine that a significant amount of modern hardware, even in games, is eaten up by several layers of abstraction that make it easier for developers to crank out games faster. What would a 90’s developer do with a 16-core CPU and an RTX3080?
You can check out some demoscene demos [0], which usually do this (albeit to save executable size instead of just to run fast). These days you don't even have to run them yourself; most have YouTube recordings. [0]: https://www.pouet.net/prodlist.php?platform%5B%5D=Windows&pa...
Broadly speaking, modern developers don’t have to deal with resource limitations (neither computing nor financial) so they instead devote that extra energy on completely unnecessary orchestration systems and build toolchains to feel like they’re doing something complex and challenging.
> Broadly speaking, modern developers don’t have to deal with resource limitations (neither computing nor financial) so they instead devote that extra energy on completely unnecessary orchestration systems and build toolchains to feel like they’re doing something complex and challenging. That is massively far from truth. Rendering graphics to the level modern games require is driving even current powerful hardware to…
Earlier quoted context omitted.
Graphics programmer has got to be up there with chef and prostitute for evergreen, recession-proof careers. And the nice thing is, the tech doesn't even change that quickly. People are still using OpenGL, the original version of which was released before DOOM!
Whether it's recession proof or not is a fairly open question, one thing for sure is that it's not layoff proof. Game companies are notorious for doing mass layoffs or shutting down with little to no advance notice and as a game developer you can never be too sure about your job security at any one company, not to mention it's kind just accepted that you will be working longer hours for less pay. As for the notion th…
Sigh. The search for a field where you can learn some stuff once and coast continues....
My old boss was in the video game industry from the late 90's until 2017 or so and would talk about this a lot. It's less about old games being optimised so much as modern non-game software being mind-blowingly wasteful. Modern, well optimised AAA stuff like Doom 2016 or The Last of Us 2 is as much a work of genius design (if not more) as Rollercoaster Tycoon or Warcraft II. If anything, Vulkan is bringing us closer…
An example I like to use is Elite on the BBC Micro computer. They fit 8 galaxies of 250 stars each with a planet with its own economy, and a space station, along with real-time 3D wire-frame space flight with hidden line removal in less than 32KB of RAM on a 2 MHz 8-bit 6502-based system. It was incredible for its time. For me, it was more incredible than DOOM when it came out. I found Quake a lot more impressive than DOOM.
The second version written for the IBM PC was coded by hand in assembly language by the same programmer who coded Rollercoaster Tycoon, mentioned by the OP above.
Write C, get good
At that time PC did not have hardware-accelerated scrolling and sprites like consoles and Amiga, so many PC ports of console games had higher hardware requirements and lower fps.
Windows 95 did not have a reputation of a small OS. It was seen as a complete waste of RAM for MS-DOS games. Microsoft had to invest a lot of effort to turn that around (with DirectX).
It's a matter of perspective. You can already wonder how Portal 2 is so small compared to multi-GB games. In 30 years when GTA 6 comes out with 7TB day-one patch, we're going to marvel how GTA 5 could fit in mere 30GB.
Some of the current game developers have lost that art because most of the games that are developed by these developers are on top of some massive framework.
One classic example of what level of understanding of the platforms earlier game developers had was to look at the very well known function from Quake for inverse square-root: https://en.wikipedia.org/wiki/Fast_inverse_square_root
Earlier quoted context omitted.
> it greatly decreases your time-to-market to do things in a straightforward way I mean, it's hard to disagree when you phrase it this way, but... really? In the old days (mid-'90s) studios like id released many games per year, some of which with completely new technology. Modern studios and indie developers (!) who "do things in a straightforward way" can be happy to release even one game per year, and that's with a…
I have zero information about (due also to little interest for) computer games, so this is just a wild speculation: maybe the visuals in terms of "levels/textures/objects/mesh/characters/voice/audio" dominate the planning, now?
Earlier quoted context omitted.
You could just measure the isolated inner loop with accurate timers and figure out down to the clock how many cycles it was taking. You also basically knew how many cycles each instruction took (add, multiply, bit shift, memory reference, etc.) so you just added up the clock counts. (Though things got a bit harder to predict starting with Pentium as it had separate pipelines called U and V that could sometimes overla…
On the C64 I will change the border color when my frame routine starts and change it back once my routine finishes. This will tell me how much of a fraction of the total frame time I use, in quite literal terms. I wonder if similar tricks were used for VGA. I think you could change color index 0 to the same effect.
Pretty soon after that Operating Systems managed memory and interrupts themselves. The added latency on timers made precision tricks like that impractical.