Hacker News Reader

Comment by _delirium | Hacker News Reader

Most companies probably can, they just don't care enough to do so, seeing it as money spent on a last-gen engine that results in no new revenue streams.

I think id does it mostly because Carmack personally pushes for it. However it arguably makes some sense for them, relative to other game companies, because they've been particularly identified with the "genius hacks to make stuff work" aura, and every source release produces a new wave of discoveries/press about crazy things id did in the guts of one of their engines, which solidifies that reputation. Plus it's probably good for Carmack getting historical credit to put the techniques out in the open once they're no longer most-recent-gen.

View on HN

Carmack also stated that these open source releases help them in the long run. E.g. they were able to port Wolfenstein 3D and Doom (the old one) to iOS much quicker by basing it on modern versions of those engines, created by the community.

Yes, and it also helps them keep the games alive. If you have the game data (CD, DVD, Steam, whatever), you can play every id FPS game up to Doom 3 in almost any platform you want, today. And you will probably be able to do it 20 years from now. I think it's fantastic.

Yes, this and the ability to build games on an open-source engine gets them a lot of goodwill, building a brand people love.

Yeah, there's a lot of goodwill generated by them, too. I wouldn't be surprised if this also helps them with recruitment. I mean, this helps create more talented game devs by giving them stuff to hack on.

> every source release produces a new wave of discoveries/press about crazy things id did in the guts of one of their engines

wow, that sounds interesting! any links?

http://betterexplained.com/articles/understanding-quakes-fas...

Here's an example:

Carmack's Square Root implementation, which runs four times faster than the assembly language instruction.

http://www.beyond3d.com/content/articles/8/

http://www.codemaestro.com/reviews/9

Bear in mind that this is inverse square root (a misnomer; it's really 1/sqrt, or the reciprocal), not just the square root. Square roots are decently fast as provided by the processor, but not when combined with the division needed for the reciprocal; combining the two is why FastInvSqrt is so fast.

It was faster before 2000, but is it still faster now?

On my computer it is indeed four times faster, but the marvellous method is on its own again four times slower than SSE, using the rsqrtps instruction, with the advantage of a way lower maximum error.

To take the square root of an array of 1024 floats:

Naive sqrtf() CPU cycles used: 48160, error: 0.000000

Vectorized SSE CPU cycles used: 2970, error: 0.000392

Marvellous Carmack method CPU cycles used: 11330, error: 0.002186

No, it's not faster now and it's no longer really used probably (don't know if smartphones, tablets, various consoles, etc. offer access to any equivalent of rsqrtps), but it was brilliant at its time (well, still is, it's just not very useful).

Remember, Quake was released in 1996, SSE came out in 1999.

Would you mind posting your bench framework for this?

I didn't make the code, nor do I want to take credit for it. I only changed a few lines to make it compile. The code explicitly say one can redistribute the code as one wants, so here it is

http://pastebin.com/EnJi86hF

Would you mind posting your results here? I'm quite interested if this has the same pattern everywhere.

Here's what I get:

Input array size is 1024

Naive sqrtf() CPU cycles used: 54514, error: 0.000000

Vectorized SSE CPU cycles used: 900, error: inf

Marvelous CPU cycles used: 21514, error: inf

I'm not sure how to interpret the errors. I had to make a few changes myself for this to compile on my machine.

Hmm, that seems a bit misleading. The SSE implementation will of course be much faster than a non-vectorized implementation... it's working on 4 floats at a time.

A vectorized version of the marvelous method would be a fairer comparison. If your data is not very vectorizable and you don't need high precision, it's still fairly marvelous.

It is your comment that is (mildly) misleading.

The SSE version is 16x faster than the x87 FPU version and almost 4x faster than the marvelous method. Further, the marvelous method is a loop and is much more resource-hungry than an instruction that goes away for 5-10 cycles (reciprocal throughput is now 1 cycle) but leaves you with most of your execution resources to do other useful work.

Vectorizing the marvelous method is very likely to be painful, as it has the treatment of a value as both a float and an int - while the xmm registers are dual-purpose operating on one successively as a int and a float causes some extra latency. The use of bit shifts and float operations require these cross-domain transfers...

Check out "Graphics Programming Black Book" [1] by Michael Abrash [2].

If you have not read his work, you are in for a treat. He has a wonderful writing style that is both engaging and illuminating.

There are a number of chapters [3] in the book that specifically discuss technology and development related to Quake.

[1] PDF: http://www.gamedev.net/page/resources/_/technical/graphics-p...

[2] http://en.wikipedia.org/wiki/Michael_Abrash

[3]

Chapter 64 - Quake's Visible-Surface Determination

Chapter 66 - Quake's Hidden-Surface Removal

Chapter 67 - Sorted Spans in Action

Chapter 68 - Quake's Lighting Model

Chapter 69 - Surface Caching and Quake's Triangle Models

Chapter 70 - Quake: A Post-Mortem and a Glimpse into the Future

Reply on news.ycombinator.com