Speaking as a programmer, a big part of what slowed down PC games compared to games on much less capable systems was the use of high-level languages like Pascal and C/C++. Many more PC programmers were using languages like these instead of writing their programs in assembly and the difference can be quite dramatic. For instance, LineWars II is an assembly-written game that can run at some insane framerates given that it runs SVGA 640x480 256-colour graphics. On a Pentium 120, the game can easily hit over 100 FPS. o_o;

Most commercial-level DOS games have at least a little bit of assembly code embedded into them to handle some of the more time-critical things, or things that would go way too slow being written in a high-level language.

Doom, System Shock and Mechwarrior 2 are three examples of game engines that clearly take full advantage of PC hardware and provide exceptional framerates given the limitations of those older systems. Heck, Mech 2 is one of the extremely few 3D DOS titles that can run higher than 640x480 resolution!

However, optimization isn't necessarily something an end user can pick up on as every game has their own idiosyncracies and sometimes, just because a game runs well, doesn't mean it runs properly. Magic Carpet and Magic Carpet 2 have very powerful engines that can render quite a bit of content, even at high resolution, but they have some serious crash bugs that can crop up seemingly at random. (MC2 worse than MC.)

Also, without looking at the code yourself (and actually knowing what everything does), sometimes a game may indeed be well optimized but runs terribly because it's just trying to do way too much. :P

Programming is an art form in and of itself. ;)

In recent games i'd blame the overreliance on middleware and .NET. There's something seemingly bloaty about stuff compiled in the latest Visual C++...

Assembly isn't rare on handhelds 😀

Wolfenstein 3D running on a 286: http://www.youtube.com/watch?v=7lBHxfsCqWw

I'd say Carmack optimized that pretty well..

I'd even say Carmack optimized everything pretty well, and he was always pushing the technology. Wolfenstein 3D and Doom were already mentioned.
Quake I is (in)famous for being optimized for Intel's Pentium, especially its FPU. It ran much worse on other x86 CPUs clock-by-clock at the time (AMD K5/K6, Cyrix).

Carmack was always pushing technology.

idspispopd wrote:

I'd even say Carmack optimized everything pretty well, and he was always pushing the technology. Wolfenstein 3D and Doom were already mentioned.
Quake I is (in)famous for being optimized for Intel's Pentium, especially its FPU. It ran much worse on other x86 CPUs clock-by-clock at the time (AMD K5/K6, Cyrix).

Carmack was always pushing technology.

I don't think it's a matter of iD optimizing specifically for Pentium FPU's, only that the games require an FPU be present and Intel's FPU in the Pentium was far superior to the competition at the time which is why games from that period run better on Intel chips. You can run Quake on a 386 with 387 co-pro, but it's a slideshow.

I beg to differ. Of course the Pentium had a superior FPU, but iD exploited special properties. For example, on the Pentium you have to pair instructions. A FMUL or FADD might be paired with most integer instructions, but then you still need to wait for the whole execution time of the FMUL/FADD instruction (1-3 cycles).
If you pair it with a FXCHG (exchange top of stack with another element) then you can exploit that the FPU is pipelined so you can issue another FMUL/FADD every cycle. (An IMUL instruction takes much longer, about 10 or 11 cycles. So in this case floating point math is much faster than integer math.)

AMD K5 and K6 CPUs are superscalar in a more general way and they can run instructions out-of-order. An FMUL or FADD takes two cycles on a K6 and it can run with other integer instructions in parallel. So if code is not especially optimized for the Pentium the K6 might be just as fast or even faster for FPU heavy code. The thing is that the FXCH instruction is actually hurting other CPUs, AMD only caught up (and even surpassed Intel on this) with the Athlon.

Indeed. Quake 1 loved the Pentium. They definitely tailored it for that CPU. I remember reading a lot of stuff posted here by swaaye and/or leileilol about how id used the Pentium's FPU.

idspispopd wrote:

Quake I is (in)famous for being optimized for Intel's Pentium, especially its FPU. It ran much worse on other x86 CPUs clock-by-clock at the time (AMD K5/K6, Cyrix).

Michael Abrash did the assembly work. It's hard to parse humanly - i've tried. I wish I could extend the functionality X_X

idspispopd wrote:

I beg to differ. Of course the Pentium had a superior FPU, but iD exploited special properties. For example, on the Pentium you have to pair instructions. A FMUL or FADD might be paired with most integer instructions, but then you still need to wait for the whole execution time of the FMUL/FADD instruction (1-3 cycles).
If you pair it with a FXCHG (exchange top of stack with another element) then you can exploit that the FPU is pipelined so you can issue another FMUL/FADD every cycle. (An IMUL instruction takes much longer, about 10 or 11 cycles. So in this case floating point math is much faster than integer math.)

AMD K5 and K6 CPUs are superscalar in a more general way and they can run instructions out-of-order. An FMUL or FADD takes two cycles on a K6 and it can run with other integer instructions in parallel. So if code is not especially optimized for the Pentium the K6 might be just as fast or even faster for FPU heavy code. The thing is that the FXCH instruction is actually hurting other CPUs, AMD only caught up (and even surpassed Intel on this) with the Athlon.

Why are you bringing features of the integer unit into it? We are supposed to be discussing the Pentium FPU.

FYI for Everyone: Extremely optimized code back in the DOS days typically was extremely difficult or impossible to understand without really digging into it. IE: Optimization leads to messy code. ^_^;

Nowadays, it's true that there's a little more bloat going on with applications written for .NET and whatnot, but that bloat helps such apps run properly regardless of which Windows OS the end-user has. (That's kinda the whole point of .NET.) Plus, modern compilers optimize automagically at code-generation time and can get optimizations done a heck of a lot better than a person could by hand, which also increases the size of an executable if you're optimizing for sheer speed. (Faster code tends to take up more code space.) You can also optimize for size, but no one does this anymore since executable data is simply not large enough in comparison to the sheer amount of space modern computers have. :P

There's also OpenGL optimization factors to take care of in certain cases. Minimal texture switching is a must.

OpenArena tends to be 44% slower than Q3 due to more texture usage (especially with detail textures, which are even abused on models). I learned the lesson the hard way and will be dealing with this issue in the reboot, keeping stages minimal and making models maintain same texture pages with less blending, so it's going to look SLIGHTLY more "dated" than Q3 in some aspects for example (Q3A was also messy - even the rocket had quite a few textures used).

On the bright side, a reboot would allow me to care for the PCX2 by tweaking the engine to add special shader stages for that card 😀

Roller Coaster Tycoon?

x86 asm stuff is cool, but what I find really neat is early console stuff. E.g. on the Atari 2600 where you could get more colour and graphics to appear by changing things mid-scanline. Talk about precise timing.

I tip my hat at the pioneers who wrung out performance like there was no tomorrow by using assembly language, I really do. But there is no need for it any more (at least not in the desktop or enterprise spaces), and I think it's a good thing, it means developers can focus on solving problems, rather than fighting with the system to make it happen.

My first machine was a ZX Spectrum in 1983 with 48K of RAM (which included the video RAM), only supported two colours per 8 x 8 pixel square, no extra hardware to support sprites/scrolling/bitmap block copying/etc, and it's only sound was a beeper built into the case of the machine, that stopped the CPU dead whilst it was making sound. Yet this machine, like all of the successful 8-bits in those days, produced some amazing games and demos ('demos' as in (mostly non-user interactive) programs produced purely to show off the programmers skills at graphics and/or sound , as the programmers learned how to push the machines and do things that even the machines' designers didn't think possible. On the Spectrum, for example, we had games with sprites of all shapes and sizes, smooth scrolling, continuous in-game music, solid filled in polygon graphics in some real-time games, more than two colours in an 8 x 8 pixel block, and so on. And some of the games crammed so much into 48K it was unbelievable.

Much like the C64. Its earliest games from 82-83 looked like Atari 2600 stuff and 10 years later they were SNES-like.

Speaking as a programmer, a big part of what slowed down PC games compared to games on much less capable systems was the use of high-level languages like Pascal and C/C++. Many more PC programmers were using languages like these instead of writing their programs in assembly and the difference can be quite dramatic. For instance, LineWars II is an assembly-written game that can run at some insane framerates given that it runs SVGA 640x480 256-colour graphics. On a Pentium 120, the game can easily hit over 100 FPS. o_o;

Most commercial-level DOS games have at least a little bit of assembly code embedded into them to handle some of the more time-critical things, or things that would go way too slow being written in a high-level language.

If we're talking real mode 8086 games, those were normally written in assembly. HLLs did not become standard until 286+. After that, C/C++ was typically used. It's true that you did not generally have PC games which exploited low-level hardware tricks too much since after 1985 or so, there were scores of clone machines and video cards that weren't necessarily compatible with each other. 8-bit machines were a static, fixed design while PCs were not and also kept continuously evolving.

For instance, LineWars II is an assembly-written game that can run at some insane framerates given that it runs SVGA 640x480 256-colour graphics. On a Pentium 120, the game can easily hit over 100 FPS. o_o;

Compare a game like Total Annihilation that was written in C++ which would produce horrible slowdown on that same P120.

x86 asm stuff is cool, but what I find really neat is early console stuff. E.g. on the Atari 2600 where you could get more colour and graphics to appear by changing things mid-scanline. Talk about precise timing.

One or two PC games did this, for example Frogger. Since there's no raster interrupts like on the C64, the game waits for the vertical retrace and then flips the CGA color register at 3D9h to change the palette upon reaching a certain scanline. This required precise coding and cycle-timing so that it only works on an 8088 PC. Tricks like that became unfeasible once 8088+CGA was no longer the only system configuration that PC games had to run on.

and alley cat?

that game run properly from XT to even modern x86 CPU (boot using freedos) provided that Graphics card/onboard also give somekind Mode4/5 compatibility.

Assembly was key the 8088 era (and beyond), but high level languages weren't rare by any stretch. I believe Digger was written in C (the source is out there), FaceMaker in FORTH, Snipes in PL/M, Round 42 in Turbo Pascal, and so on... though some HLL compilers allowed inline machine code (later inline assembly) and you could link external object code.
Don't know if the very early assemblers available for the PC were all that great, either (I've seen MASM 1.x-2.x described as buggy pieces of crap).

Gemini000 wrote:

Speaking as a programmer, a big part of what slowed down PC games compared to games on much less capable systems was the use of high-level languages like Pascal and C/C++. Many more PC programmers were using languages like these instead of writing their programs in assembly and the difference can be quite dramatic.

back in the XT era I was a little kid with no concept of how programming even works, but when games weren't optimized it was noticeable - for example, slowing to a crawl when too many moving sprites were on the screen. I even imagined that this was some limitation of the PC as a platform, because I rarely saw that in console games, or even on 8-bit computers. take Hard Hat Mack: in the PC version the speed unpredictably jumps all over the place every few seconds (real annoying in a platformer), but somehow the Apple II version manages to be consistent, on a machine without hardware sprites or anything fancy like that.
I suppose some of that was due to high level language abuse, or even 8086 assembly that just wasn't very well-written because many game developers were coming from the 6502 world and still getting their feet wet with the PC.

it was cool to have games that broke the mold like Prohibition (smooth scrolling in CGA on a 8088!), or even just to experience fast and smooth action like in Space Commanders, Night Mission Pinball, Jumpman... and later of course Keen and all the other stuff from id. Those were the games that really stood in contrast and where optimization really showed.

On the extreme other end you had all those freeware compiled BASIC games, the spiritual fathers of the Borland BGI disasters we all know and love... super jerky animation, graphic routines so slow you could see sprites being drawn scanline by scanline, game loops that have to halt completely just to beep at you, etc. The real wonder is that some of them were even quite playable despite all that!

Joey_sw wrote:

and alley cat?

that game run properly from XT to even modern x86 CPU (boot using freedos) provided that Graphics card/onboard also give somekind Mode4/5 compatibility.

Yeah, gonna have to try that sometime for a laugh. I believe that's also true for Orion Software's games (Paratrooper, etc) although they're not as technically impressive.

Assembly was key the 8088 era (and beyond), but high level languages weren't rare by any stretch. I believe Digger was written in C (the source is out there)

Digger could not possibly have been written in C because there were no microcomputer C compilers before 1986 (it was still a mainframe/minicomputer language at that time).

Don't know if the very early assemblers available for the PC were all that great, either (I've seen MASM 1.x-2.x described as buggy pieces of crap).

Programming tools for the PC in the very early days were mainly Microsoft's compiler family (Fortran, COBOL, Pascal, and MASM). Slow, buggy ports of the original Z80 versions that didn't quite adhere to the ANSI standard for those languages.

or even 8086 assembly that just wasn't very well-written because many game developers were coming from the 6502 world and still getting their feet wet with the PC.

According to Lynn Hock (one of the co-developers of PC M.U.L.E), "The IBM was a difficult learning curve for me and my partner. It didn't look or act anything like the Commodore 64 or Atari. Everything we knew about memory addressing schemes, I/O, assembly language, etc was totally out the window."

Probably was one reason for the TI/99-4A being a comparative non-factor. The TMS9900 CPU was extremely different from the 6502s and Z80s that everyone was used to programming.

A typical example of a badly-programmed PC game from the early days was the Atarisoft Pac-Man, which is a slow, flickery piece of junk that draws all the background graphics with INT 10h Function Ch, so it's like wading through cement. Ms. Pac-Man by comparison is very well-made and flicker-free. I also thought that Boulder Dash was quite good.

As I mentioned in a previous thread, 6502 machines dominated game development for the entire decade of the 80s, from the Apple II and Ataris to the C64 and NES, and few devs except Sierra were primarily writing for the PC. Most arcade machines were also Z80 or 68000 based (except for Q*Bert which used an 8086), so again, programmers were more versed in those CPUs.

Yeah, gonna have to try that sometime for a laugh.

Alley Cat does run on any PC, but unless it's an 8088, you can't hear the kewl sampled SFX like the cat screeching if the dog gets him.

kao wrote:

Assembly was key the 8088 era (and beyond), but high level languages weren't rare by any stretch. I believe Digger was written in C (the source is out there)

Digger could not possibly have been written in C because there were no microcomputer C compilers before 1986 (it was still a mainframe/minicomputer language at that time).

Cough, cough

http://en.wikipedia.org/wiki/Lattice_C

"Lattice C (according to its author, Lattice, Incorporated) was the first C compiler for MS-DOS on the IBM PC, in 1982."

What about appplications?. Deluxe Paint 2 comes to mind. I think it's still working.