161–170 of 238 posts
The gist of programming console games of that period is I suspect somewhere between an Arduino and a Raspberry Pi.
These tricks are things that you could still pull off today. The difference is, outside of competitions or the demoscene, nobody _needs_ to pull them off - it greatly decreases your time-to-market to do things in a straightforward way, rather than a novel way. That wasn't true 20+ years ago - the straightforward way often brought you up against hardware limitations.
I'd actually like to link the YouTube channel of a person who is writing their own game engine and game at the same time: https://www.youtube.com/c/RandallThomas/videos
You can see how using Godot, Unity or Unreal (or most other engines) would have been much faster in regards to time to market.
Similar differences show up when you try to build the same project, once while using an engine and another without it, the performance can be much better if you write your own optimized code (supposing that you can do so in the first place), however the development still takes much longer, for example: https://www.youtube.com/watch?v=tInaI3pU19Y
Now, whether that matters to you or not is a different matter entirely: some care about learning a lot more about the lower level stuff, others just want to develop games and care more about the art/story/etc., while others care about selling them ASAP.
Earlier quoted context omitted.
Then you just calculate them all. If Branch A is taken ... total X clock-cycles. If Branch B is taken ... total X clock-cycles. If Branch C is taken ... total X clock-cycles. And so on. And then make sure that the "longest" branch fits into the clock-cycle budget.
Were games at this point of low enough complexity that the combinatorial explosion of branches could be contained and reasoned about by humans? Or did you have software doing this?
Proceed from the other direction: you have those resources, what creatively can you do with them?
I think the three big differences are:
- nothing was "responsive", everything targeted a (pretty small) fixed resolution. Fonts were bitmap, ASCII, and fixed-width. No need to run a constraint solver to do layout.
- object orientation was rare. Data would be kept in big arrays. No virtual dispatch, minimal pointer-chasing (this is bad for pipelines), no reflection, no JITs, no GC pauses.
- immediate-mode GUIs rendering on a single thread. Draw everything in order, once. If something's off screen, ignore it as much as possible.
You can see all these in play in the Windows 3.0 -> 95 era. Classic "Windows Forms" apps render in response to a WM_PAINT message, in the (immediate) thread of the message loop, directly into the framebuffer. This could be seen by moving a window on top of a crashed app or part thereof - moving it away would leave a white space. Classic Windows apps are also not responsive - all the positions for controls are fixed pixel locations by the designer, so they look stupidly tiny on high resolution monitors. ( https://docs.microsoft.com/en-us/previous-versions/windows/d... )
Microsoft tried to supercede this with WPF/XAML and the compositing window manager Aero, but it's not been entirely successful as you can see by the number of obvious Forms dialogs you can find from Control Panel.
> Dwarf Fortress and Rimworld eventually both suffer from the same problem: CPU death.
Simulation games tend to expand to fill the space available. It's very easy to have complexity runaway of O(n^2) if you're not careful, which gets much worse at high numbers of objects. The trick there is to constrain the range of interactions; both what interactions are possible and over what range, so you can keep them in a quadtree/octree/chunk system and reduce the N input to each tick of the simulation.
Further reading: not just Masters of Doom, but Racing The Beam.
You could do the same thing today but spend at least 4-5 more time developing your software.
For example, I was a kid and used to fill the screen using Look up tables fo colors, you had access to the frame buffer and do things like displace the elements in the table, as a cycle, the entire image will change giving a movement impression. The work was done by the electronics of the framebuffer.
In the past the people that had access to real terminals did the same, change the information of the text on screen and the hardware will render it beautifully(even prettier that today's terminals). But those terminals were super expensive and proprietary(tens of thousands of dollars). Today shells are standardized, free and open source(and usually use much ugly fonts)with fonts from all over the world(terminals have very limited character sets).
Also game consoles did the same. The hardware did draw tiles that were previously drawn. You told the console what tiles to draw and the hardware did most of the work.
>Is it possible to recreate this level of efficiency on modern systems?
Of course you just need to pay the price: Development is so slow and painful. Low level programming is prone to very hard to find bugs.
Programming things like FPGAs or GPUs is hell in life. You work super hard, you get little reward.
I built games in the 90s. Graphics was obviously the hardest part. We thought about things in terms of how many instructions per pixel per frame we could afford to spend. Before the 90s it was hard to even update all pixels on a 320x200x8bit (i.e. mode 13h) display at 30 fps. So you had to do stuff like only redraw the part of the screen that moved. The led to games like donkey kong where there was a static world and…
That being said, better art is also very expensive. Consider expensive it is to display a 4k screen versus a vga screen with 256 colors.
Computers aren't that much faster if we consider there's only an order of a magnitude difference between 300mhz and 3ghz. In order to benefit from the full speed of our modern ~3ghz processors your problem needs to fit into about 32kb of memory, due to physics and locality. So size of RAM today is kind of a red herring. I think if you compare the sheer size and scale of what a Factorio game looks like once it turns i…
I don't know about that. I grew up in the 80's and was always trying to make games, first in BASIC, then in Turbo Pascal, and it was always a struggle to get the required speed. You always had to resort to ridiculous assembly language hacks, etc. At some point in the early 90s, I kind of quit trying to make games. Then in 2007, I was thinking about how much faster computers were "now", and it occurred to me to try to make a game. And so I wrote a little game kind of like Williams Defender in C[1], and I didn't have to do anything special to make it fast enough. I just wrote it in a straightforward way. No weird assembly language hacks, no opengl, nothing but just plain old GTK. "Only" an order of magnitude faster is a lot faster.
And you haven't even considered the GPU. If you start using OpenGL, suddenly you can do so much more. I think you're underestimating how hard it was just to even get the simplest thing to be fast enough back in the days of the 8086 or even a 486DX.
For instance checking if a mouse button is pressed on the Amiga is one assembly instruction to test a bit in a memory-mapped register. Compare that to all the code that's executed today between the physical mouse button and some event handler in the game code.
On 8-bit home computers like the C64, the video hardware was basically a realtime image decompressor which decoded a single byte into an 8x8 pixel graphics block, without CPU intervention. Scrolling involved just setting a hardware registers to tell the video hardware where the framebuffer starts instead of 'physically' moving bytes around. For audio output the CPU just had to write some register values to control how the sound chip creates audio samples.
On the PC the video and sound hardware is much more generic, much less integrated with the CPU, and there's a driver layer to hide hardware differences and mediate hardware access between different processes and on top of that are even more operating system and game engine layers, and that's how we got to where we are today :)