Slashdot Mirror

I believe you're thinking of the Quake 3 engine. The Quake 2 engine was in fact built on the Quake 1 engine -- heavily rewritten, of course (.DLLs as oppposed to QuakeC, different storage systems for textures and models, built-in OpenGL support, etc.), but built on it nevertheless. Quake 3 was pretty much a ground-up project.

No, I'm talking about Quake 2. While I'm sure theCarmack started with some Quake 1 bits, the engine is a major change from Quake 1. The rendering engine was rewritten, the networking engine was rewritting, the file formats were rewritten, etc. In other words, it was all new, unlike Half-Life that tacked on bits like skeletal animation while leaving other bits hardly changed at all. Of course, you can download the Quake 2 source code and Quake 1 source code and see for yourself. Also, theCarmack sometimes reads and posts on Slashdot, so perhaps he can clear this up once and for all.

theCarmack tends to rewrite engines for id games (non-id games like RTCW or the upcoming Q4 don't get brand new engines). This makes sense, because id games have recently existed solely for demonstration purposes (licensing of the Q2 engine, Q3 engine, upcoming Doom 3 engine). Doom was not a modified Wolf3D engine. Quake was not a modified Doom engine. Q2 was not a modified Q1 engine, and so on. This is in contrast to Epic, who are constantly refining rather than rewriting. The current Unreal 2 technology engine is still recognizably similar to the original Unreal engine, and I expect that the upcoming Unreal 3 technology will still have a common thread. Neither way is better or worse than the other. They're just different approaches taken by two different geniuses (theCarmack and Time Sweeney).

On a side note, since theHair's site was posted in the original article, it seems that John Rome"Hair"o is growing out his man-locks again. He was quite the pretty woman when he had his long hair, and many fanboys were disgusted to find out he really was a man when he cut it a few years back (apparently while in depression from the failure that was Daikatana).

• The Gathering - 2002 winners
• The Party - 2001 winners
• Assembly - 2002 winners

• Pouet - Has a big list of demos, intros, and lots of comments.
• 256b.com - If the 2-10 meg demos on pouet are too bloated for you, check these out.
• CFXweb - A community web site with forums and a magazine.

• The Gathering - 2002 winners
• The Party - 2001 winners
• Assembly - 2002 winners

• Pouet - Has a big list of demos, intros, and lots of comments.
• 256b.com - If the 2-10 meg demos on pouet are too bloated for you, check these out.
• CFXweb - A community web site with forums and a magazine.

Yeah man... that's their MASSIVE software. (That's the name, I'm not calling the software REALLY HUGE.) It's really cool stuff... they talk about it in the article referenced as part of this story, in fact :).

True, but the wealth of information available out there is astounding. A simple google search yeilds amazing results.

Then there are demo specific sites:
OJuice
Scene
CFWweb

General game programming sites help aswell:
Flipcode
GameDev
GameTutorials

The information about karman filters isnt what you should learn first. That type of information will come later, once you develop specific skills, different techniques will come to light.

You'd have to tie it to ESP, not EBP, since GCC and other compilers will (with appropriate flags) use EBP as a general-purpose register. (Consider GCC's -fomit-frame-pointer.) And I'm perfectly aware that accessing the stack frame happens with instrs other than push or pop. Indeed, I'd assumed that this "top of stack looks like rename regs" idea applied only to memory references of the form [ESP + constant_offset] as either src or dst to another instruction. (And for simplicity, limit it to 4-byte-aligned offsets and 4-byte wide accesses.)

The shadowing would have to work like a write-through cache, and you *do* run into some sharing issues in a multiprocessor setup. In order to make refs to the top-of-stack eligible for rename aliases, you would need the following conditions:

• The cache line holding top-of-stack is in exclusive state, not shared or invalid. (I think the first 'pushes' would make this line become 'exclusive' fairly quickly, since the caches are write-allocate.)
• No push/pop instructions in progress.
• All push/pop instructions and non-32-bit alignment/width accesses deferred until shadow writethrus occur. (Honor memory dependences relative to the stack-relative-accesses-turned-rename-registers.)
• Any change to ESP invalidates the rename registers.

You still have some issues if you generate ESP-relative addresses into other registers. (For example, generating a pointer to a local value on the stack.) EBP-relative accesses could often overlap ESP-relative accesses if a program uses EBP and ESP for accessing the allocated stack frame. We already need hardware for resolving these memory dependences. Since accesses via these alternate paths are essentially *forced* to go to memory, it's not a big deal. We just need to remember to make them dependent on the writethrus that our top-of-stack shadow provides.

If you think about it, compilers nowadays tend to migrate their stack frame allocation to the top of the function and the stack frame release to the bottom of the function. All spills are converted to ESP or EBP relative addressing, not push/pop. This allows arbitrary access to spills. Thus, the current compilation model already matches well to this rename idea.

I could blather on with more ideas (there's one particularly neat one that I'd like to share), but I think I'd be violating my company's IP to talk about it here. *sigh*

BTW, the original article's content (the software-controlled register-rename-on-steroids-and-acid idea) seems to me pretty typical of a programmer's perspective of the hardware that ignores hardware realities. It essentially ignores the fact that the effect of one instruction on later instructions might be on a pipeline stage other than the execute stages, so there's a pipeline bubble that develops between two such instructions. Register names are resolved for dependence generation many pipeline stages ahead of the execute stage, so you have a gigantic barrier generating effect between anything that changes the naming and the stuff that uses the names. Basically, all name changes will happen in the execute stages, but anything that relies on the naming will be stalled in the earlier dependence tracking stages.

(For those who want a concrete example of "result of instruction A affects a different pipeline stage of instruction B", read up on AGI stalls -- Address Generation Interlock stalls. These occurred on 486s and Pentium I's. On these machines, instructions generated memory addresses for accesses one pipeline stage before the instruction itself executed. So, if you issued, say, "MOV EAX, value" followed by "OP reg, [EAX + offset]", you'd take an AGI stall, because the EAX value would get updated about the same time the second op needed to use it for address generation. Later CPUs hide it better by scheduling out-of-order. this page gives a reasonable explanation of AGI stalls. Google turns up a lot of useful links. This concept is easy to explain w/ a pipeline diagram, but alas, Slashdot would probably eat such a diagram.)

One nice thing about the 'convert ESP-relative accesses to rename-register accesses' idea is that if ever you don't know if it's safe to use the rename-reg aliases, you can always leave these as memory accesses, and it "just works." So, you can eliminate that dependence-ambiguity stall. Just issue the instruction as-is, rather than retargeting it to read/write a rename reg.

Recent productions in the demoscene european demoscene should definitively be an interesting multimedia movement to cover. Demos and the demoscene have been around since the early eighties, and the repertoire of quality productions for every platform you can dream of out there should make for interesting viewing.

For people who've never heard of the demoscene before, it's a movement dedicated to building real-time multimedia production, usually with small memory footprints, with the aim to astound and show off a demo groups coding, graphic and music composition skills. Demos and intros (the main type of production of the movement) vary in size between 6-7 Megs (for recent productions) and 64k, (sometimes even being as small as 4 kilobytes !!) and can be described as the computerized equivalent of a "live performance". The scene has it's roots in the old Commodore 64 game cracking groups. Those groups usually attempted to show off their coding skills by adding small animated musical clips to cracked videogames, often accompanied by colorfull self-complimenting scrolling text.

It has since evolved into a huge European movement. Over 20 huge gatherings called demoparties now take place in different countries troughout europe, where demo groups compete with each others for prizes and recognition. Those parties are often lavish affairs, and are similar to raves with a bit of psychedelic computer trade show thrown in. The bigger parties 24 hours a day for 5 to 6 days non-stop, and are attented by thousands of computer programmers, graphic artists and musicians.

Demos have, over the course of the last few years, seen tremendous improvements, and can usually be described as "mindblowing". (For a good example of this, go download the VIP2 "invtro", it will *redefine* the way you look at realtime 3d rendering.) You can learn more about this whole movement by visiting the following sites: You will find the cream of the crop in demoscene productions at demoo!, where reviews for the most influential demos and intros can be found. For those wishing to learn how to create demos, cfxweb.net is a great place to start, you will find there tons of source code examples for 3d and openGL realtime 3d rendering. error-404.com is the definitive source for music creation using trackers, the scene's favored format (remember .mod and .s3m files?) For scene news and group lists, chat, etc, see pouet.net and ojuice.net. And as a last reference, my site, naid.net, also concerns itself with the demoscene but also covers anything related to the use of new technologies in the arts.

• CFX Web
• Scene.org - especially the viewing tips section
• Assembly 2K

There's not enough space inthis little box for a diatribe, so here's a few links for x86 assembly language programming:-

www.hugi.de Windows based (linux ver on its way) assembly diskmag with plenty of articles on the advantages and disadvantages of ASM vs HLL

www.x86.org loads of info about x86 programming

www.cfxweb.net Loads of articles on assembly programming and HLL too.

Hope that clears a few things up *g*

Here's some links for you interested:
Assembly demoparty
tAAt demogroup (the authors of LeGorso)
General demoscene news and stuff
Site dedicated to scenenews and game/demo development

Those should keep you guys busy for a while ;)
- Mik\tAAt