131–140 of 238 posts
Optimizing software means 99% percent of the time to not pessimize it. That is not write code that is not necessary, don't make the CPU run code which isn't needed to accomplish the task. Casey Muratori explains it well: https://youtube.com/watch?v=pgoetgxecw8
YT link doesn't work
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…
Yeah, it's helpful to remember that games in the early 90s at least would have been expected to run on a 486, which were still very widespread, and the 486 was neither superscalar nor out of order. It was pipelined (the main difference between a 486 and a 386) but it was still at that time simple to reason about how long your instructions would take. And there was no speedstep or any of that stuff yet.
Code for the CPU might get optimized beyond recognition, vectorized, executed out of order, ...
The shader code I write these days is translated to a whole list of intermediate formats across different platforms, maybe scheduled in a jobs system, then handed to graphics drivers which translate it to yet another format...
I'm guessing most of those tiles are off-screen, and you're creating a mesh for an entire game level, not just the visible area?
Every abstraction layer is designed to be multi-purpose, meaning not optimized for a single purpose. As these layers accumulate, opportunities for optimization are lost.
A 90s game like Rollercoaster Tycoon was coded in assembly language on bare metal and limited OS services.
A modern game might have game logic coded in Lua, within a game engine framework coded in C++, which calls a graphics API like OpenGL, which all runs in an OS that does a lot more.
These modern layers are still clever and efficient and optimized using tricks as far as they can be, and the increased resource requirements come mostly from the demand for higher resolutions, higher polygon counts, and more graphical special effects.
Earlier quoted context omitted.
Out of curiosity, How did you know how many clock cycles your rendering code took?
You look at the assembly code, grab an Intel Programmer Reference manual (they were about 1000 pages), look up each instruction opcode and that would tell you the clock cycles. For memory operations it is much more difficult due to caching. However, for many hot regions of code, the data is already in the L1s so manual counting is sufficient. (At the time there was a book called The Black Art of ... Assembly? I can't…
Wouldn't this "just" tell you how many "cycles of code" there are, and not how many cycles actually run? Branches etc. will of course cause some cycles to be double-counted and others to be skipped, in the dynamic view.
Just copy and paste the solution but conform it to our networking or state storage system.
The bottlenecks for most apps I work on (not games) are somewhere else, like the network.
So there's a lot of crap code that makes a lot of money.
https://www.quora.com/Why-was-Roller-Coaster-Tycoon-written-... Funny you should mention Rollercoaster Tycoon because it was actually written in Assembly for performance reasons.
For a rube like me who views assembly coders as masters of occult incantations, this is incredibly impressive
I think it helps develop a very good mindset, lean and faithful to base facts.
https://www.lexaloffle.com/pico-8.php
Also JS13k
I know that's not the same but the concepts are similar. The core of most of those games is only a few k, everything else is graphics and/or interfacing with modern OSes.
Older systems had much lower resolutions, they also used languages that were arguably harder to use. In the 80s it was BASIC (no functions, only global variables and "GOSUB"). Variable names generally were 1 or 2 letters making them harder to read. Or they used assembly.
90s (or late 80s) C started doing more but still, most games ran in 320x240, sprites were small, many games used tiles, many hardware only supported tiles and sprites (NES, Sega Master System, SNES, Genesis). It wasn't really until 3DO/PS1 that consoles had non-tiled graphics. PC and Amiga always did had bitmapped graphics but Atari 800, C64, the majority of games used the hardware tiled modes.