• Advertisement

Archived

This topic is now archived and is closed to further replies.

How can software rendering be fast?

This topic is 5041 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Somtimes i see these oldgames rendering in software, and iv been wondering how it is done? I recently reinstalled halflife on my laptop, and i almost didn''t notice that it ran in software by default. Locking the backbuffer and plotting 640x480 and even higher resolutions aint even fast on todays computers.. And the hardware blitter can only copy rectangles right? So how did games like halflife, tombraider and quake do it?

Share this post


Link to post
Share on other sites
Advertisement
For the most part, by writing hardware-specific functions.

Correct me if I''m wrong though, but didn''t half life use the quake 2 engine (which was OGL based?)

Share this post


Link to post
Share on other sites
Where have the ASM and optimization gurus gone ? *sigh* Sometimes I think that hardware accelerated 3D has finally eradicated this brilliant but oh so rare species (and spoiled the rest)...

Who here remembers the trick to address a texture as separate 4x4 patches, in order to save two opcodes in the rasterizer loop, and to keep it in the first level cache ? Who remembers the ADC trick, using the carry flag to avoid an additional instruction ? Damn, I feel old.

To answer your question: you would be surprised how fast and good software rendering can be, if written by a good coder. The key words are: efficient algorithms, efficient data organization, bloat removal, hand written ASM, and optimization, optimization, optimization. Long forgotten arts, if you ask me.

PS: Watch this, and you''ll know how good SW rendering (well, raytracing in this case) can be.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
it used the quake(1 or 2?)software renderer as well

Share this post


Link to post
Share on other sites
quote:
Original post by ALX
Where have the ASM and optimization gurus gone ? *sigh* Sometimes I think that hardware accelerated 3D has finally eradicated this brilliant but oh so rare species (and spoiled the rest)...

*cough**cough*friggin''awesome*cough*


"Sneftel is correct, if rather vulgar." --Flarelocke

Share this post


Link to post
Share on other sites
Oh, and being an "ASM Guru" may be great on paper, I''d personally rather not wait 10 years for a new game to come out.

Share this post


Link to post
Share on other sites
quote:
Original post by Etnu
For the most part, by writing hardware-specific functions.

Correct me if I''m wrong though, but didn''t half life use the quake 2 engine (which was OGL based?)

Half-Life used the Quake engine as a base, but they modified it very very much. As for Quake 2, it had a software renderer as well as a OpenGL renderer.

Share this post


Link to post
Share on other sites
quote:
Original post by peter_b
So how did games like halflife, tombraider and quake do it?

If you want to know how Quake did it you can download the source code. There''s also a series of articles by Michael Abrash (who wrote the Quake engine along with John Carmack) explaining many of the tricks. I believe they''re linked here somewhere. Quake was designed to run with decent performance in software on a 100MHz Pentium so it''s hardly surprising that you can get good performance in Half Life (based on a heavily modified Quake I engine) on today''s machines which are up to 40x faster.

Share this post


Link to post
Share on other sites
quote:
Original post by Etnu
Oh, and being an "ASM Guru" may be great on paper, I''d personally rather not wait 10 years for a new game to come out.

This is a most ignorant comment.

Share this post


Link to post
Share on other sites
quote:
Original post by Sneftel
*cough**cough*friggin''awesome*cough*


Nice. So they haven''t completely died out yet, good to know

quote:

Oh, and being an "ASM Guru" may be great on paper, I''d personally rather not wait 10 years for a new game to come out.


Noone would ever code a whole game in ASM. But knowing how to write good ASM will make you see your high level code with totally different eyes. It tends to make you avoid bloat, ridiculously inefficient constructs, and other algorithmic optimizations the compiler can''t catch (and those are often found in production quality code nowadays, unfortunately). Knowing ASM and the principles of writing efficient code can definitely make you a better C/C++/C#/Java/* programmer.

Share this post


Link to post
Share on other sites
I was referring to games written entirely in ASM. Yes, I''m well aware of the benefits of ASM optimization, but it''d be stupid to write entire large-scale applications in ASM. It''s a waste of time. There''s a very good reason why high level programming languages were developed.

Share this post


Link to post
Share on other sites
Etnu: Tell Chris Sawyer that (he wrote RollerCoaster Tycoon with about 99% ASM) But I agree, a full scale project with that much ASM isn''t really to recommend.

Share this post


Link to post
Share on other sites
quote:
Original post by Etnu
but it''d be stupid to write entire large-scale applications in ASM. It''s a waste of time.


I can''t see anyone on this thread suggesting that.

The OP talked about "games like halflife, tombraider and quake". All those games use(d) ASM optimized renderers, and that is the trick they used to get decent speeds.

Share this post


Link to post
Share on other sites
Edit: Ignore me, Jolle beat me to it.

Also, those old games had *much* lower polycounts, vastly reducing the actual amount of pixels that has to be rasterised. And they tend to run in much lower colour depths to allow all sorts of crazy optimisations.

[edited by - PouyaCatnip on May 7, 2004 5:12:36 PM]

Share this post


Link to post
Share on other sites
This is more of an optimization thread than a graphics thread, really, so [Moved to: General Programming]

Share this post


Link to post
Share on other sites
A real game company would probably use Pixomatic these days rather than rolling their own software renderer. Software renderers can be fast because computers are fast. Half-life was based mostly on Quake source, but Valve had a Quake 2 license as well.

Everyone with a clue already knows this, but assembly is useful for optimization only in certain situations. Abrash''s book on optimization makes this abundantly clear in the very first chapter: time spent optimizing code that doesn''t need optimization is time that is wasted.

Good software renderers may or may not use assembly, but using assembly won''t necessarily give you a good software renderer. Writing entire games or engines in assembly mostly shows people that you are either a demo scene coder or are living in 1995.

Share this post


Link to post
Share on other sites
I still use a lot of assembly these days, particulary MMX/SSE for image and vector operations. However, writing an entire game in ASM is an overkill. It can be fun if you''re a dedicated programmer.

One of the things I do with my C++ projects is decompile my optimised EXEs with IDA Pro and analyse how my code is structured. You will learn heaps, and as ALX hinted, your high level coding habits will change and end up writing C++ code that favours the optimiser.

Share this post


Link to post
Share on other sites

  • Advertisement