SoftWire is a run-time x86 assembler. It can be used as a JIT compiler back-end for scripting languages, or for dynamic code generation of optimized inner loops.

This new version adds support for automatic register allocation. This enables you to write an efficient compiler back-end with x86 code as intermediate code! The same concept is successfully being used in the swShader project: sw-shader.sourceforge.net. Check the new section in Readme.html for more details.
Posted on 2003-05-17 15:50:30 by C0D1F1ED
shameless plug eh? ;)
but good job - haven't had the time to look much at it, but it's an interesting piece of code for sure.

btw, the quake3 map viewer based on swshader/softwire looks a bit bland... no lighting? Are you even using the lightmap textures of the levels? I've seen faster software rendering with similar output quality, however that has been rather optimized engines; I guess your speed is quite decent if you're dynamically translating shaders to x86.

Don't take this as a flame, I think you've done quite some neat work!
:alright:
Posted on 2003-05-17 16:03:16 by f0dder
indrukwekkend Nicolas :alright:

oh en Uw verjaardag ook! Gefeliciteerd!
Posted on 2003-05-17 16:22:17 by Hiroshimator
shameless plug eh? ;)

Not really. It's non-commercial and has full source-code. It's more like showing off :grin:
btw, the quake3 map viewer based on swshader/softwire looks a bit bland... no lighting? Are you even using the lightmap textures of the levels?

It certainly uses the lightmaps! You didn't seen any shadows and bright spots from the lights? It has exactly the same lighting as Quake 3, it just doesn't use the animated textures.
I've seen faster software rendering with similar output quality, however that has been rather optimized engines; I guess your speed is quite decent if you're dynamically translating shaders to x86.

Where have you seen similar software rendering? It features bilinear filtering, per-pixel perspective correction and mipmapping, multitexturing and much more. Everything is highly optimized using MMX and SSE and I would be surprised to see even faster renderers with the same features. Can you give me some links?
Posted on 2003-05-18 06:09:32 by C0D1F1ED

indrukwekkend Nicolas :alright:

oh en Uw verjaardag ook! Gefeliciteerd!

Bedankt! Op de goei stemmen vandaag he ;)
Posted on 2003-05-18 06:10:51 by C0D1F1ED

It certainly uses the lightmaps! You didn't seen any shadows and bright spots from the lights? It has exactly the same lighting as Quake 3, it just doesn't use the animated textures.

Took a look again - indeed, certainly has lightmaps. There's still... "something wrong", though. Can't exactly put my finger on it, but textures are a lot lighter, sort of washed out. Probably the easiest spot to compare would be looking at the area near the bridge... it's much "moodier" in quake3. The lava is fullbright in RealVirtuality, darker in q3.


Where have you seen similar software rendering? It features bilinear filtering, per-pixel perspective correction and mipmapping, multitexturing and much more. Everything is highly optimized using MMX and SSE and I would be surprised to see even faster renderers with the same features. Can you give me some links?

Not "the same features" - but similar/better output quality. There's quite a difference! It doesn't take a hell of a lot of advanced features to make something look good, if you're careful about textures etc. And sorry, I should have said "specialized", not "optimized" - I don't doubt your code is pretty optimized. Software renderers used in demos don't usually run direct-x style shaders :)

You work is definitely nice - and fast, especially compared to refrast 0.whatever fps ;)

Btw, RealVirtuality fails on my work box - P4 celeron / win2k / 845GE chipset onboard video. Loads for a while, then bombs to desktop.
Posted on 2003-05-18 07:39:32 by f0dder
Took a look again - indeed, certainly has lightmaps. There's still... "something wrong", though. Can't exactly put my finger on it, but textures are a lot lighter, sort of washed out. Probably the easiest spot to compare would be looking at the area near the bridge... it's much "moodier" in quake3. The lava is fullbright in RealVirtuality, darker in q3.

Maybe you're right. I like playing Quake with a higher gamma than the default. I did use 2.2 in my demo though, since that's the sRGB standard. It's also easier to spot artifacts if it's brighter. But I'll think about making it 'moodier'...
Not "the same features" - but similar/better output quality. There's quite a difference! It doesn't take a hell of a lot of advanced features to make something look good, if you're careful about textures etc.

Could you please give me few links to these software renderers with better quality? I'm always interested in seeing what I could improve in mine.
And sorry, I should have said "specialized", not "optimized" - I don't doubt your code is pretty optimized. Software renderers used in demos don't usually run direct-x style shaders :)

It's not DirectX-style shaders, it is DirectX Pixel Shader 2.0 specifications.
You work is definitely nice - and fast, especially compared to refrast 0.whatever fps ;)

Thanks!
Btw, RealVirtuality fails on my work box - P4 celeron / win2k / 845GE chipset onboard video. Loads for a while, then bombs to desktop.

Did you check if it generates a Debug.txt file? Could it be possible that your graphics chip does not support 32-bit colors?

Thanks!
Posted on 2003-05-18 17:52:34 by C0D1F1ED
It doesn't work for me. DebugLog.txt:



==== Debug Log File ====

Mon May 19 07:44:54 2003


Unable to open file: H:\Temp\RealVirtuality\Quake 3\.jpg
Unable to open file: H:\Temp\RealVirtuality\Quake 3\textures\common\mirror1.jpg
Unable to open file: H:\Temp\RealVirtuality\Quake 3\.jpg
Unable to open file: H:\Temp\RealVirtuality\Quake 3\textures\common\mirror1.jpg
Unable to open file: H:\Temp\RealVirtuality\Quake 3\proto_addition 11\08\99.jpg
Unable to open file: H:\Temp\RealVirtuality\Quake 3\.jpg
Unable to open file: H:\Temp\RealVirtuality\Quake 3\.jpg
Unable to open file: H:\Temp\RealVirtuality\Quake 3\.jpg
Unable to open file: H:\Temp\RealVirtuality\Quake 3\textures\common\invisible.jpg
Unable to open file: H:\Temp\RealVirtuality\Quake 3\.jpg
Unable to open file: H:\Temp\RealVirtuality\Quake 3\proto_addition 11\08\99.jpg
Unable to open file: H:\Temp\RealVirtuality\Quake 3\textures\common\mirror1.jpg
Unable to open file: H:\Temp\RealVirtuality\Quake 3\.jpg
Unable to open file: H:\Temp\RealVirtuality\Quake 3\textures\common\mirror1.jpg
SSE support required



That last line doesn't really make sense though, I'm pretty sure I have the latest SSE extensions.
Posted on 2003-05-19 00:48:24 by Qweerdy
That last line doesn't really make sense though, I'm pretty sure I have the latest SSE extensions.

The missing textures are no problem, but are you sure you have SSE support? The Athlon and Duron with Thunderbird cores do not have support for SSE...
Posted on 2003-05-19 03:59:02 by C0D1F1ED
Ok, I checked and I don't seem to have SSE2. Thunderbird 1.33 gHz, as you said. No chance of a version for us poor sobs? :rolleyes:
Posted on 2003-05-19 12:32:46 by Qweerdy

Ok, I checked and I don't seem to have SSE2. Thunderbird 1.33 gHz, as you said. No chance of a version for us poor sobs? :rolleyes:

You don't need SSE2, that's for processing two double-precision floating-point numbers in parallel and is only featured on a Pentium 4. This is not useful for an application like this. SSE on the other hand processes four single-perecision floating-point numbers in parallel and is used in the whole pixel pipeline. 3DNow!, which is featured on your Athlon Thunderbird only processes two single-precision floating-point numbers in parallel, and does not have it's own register set so it is far inferior to SSE.

SSE has been around for a very long time so sorry to put it this way, but your CPU is old. You can probably upgrade to an Athlon XP or Duron with Morgan core for a bit of pocket money. A 3DNow! version would be interesting (just translate all SSE code in Shader/PS20Assembler.cpp), but performance would be much lower than with SSE and a 2 GHz processor is recommended anyway...
Posted on 2003-05-20 02:16:43 by C0D1F1ED