Software Rendering Demo

Nick

Veteran
Since I didn't get any response in the General Discussion forum (appears to be used only by war Generals), I'm reposting this here...

I know this board is all about hardware rendering, but I'd like to hear your opinions about my new demo: http://softwire.sourceforge.net/extra.html

Think there's a future for software rendering now CPU's are getting fast enough for things like bilinear filtering? My next project will feature efficient ps 2.0 emulation...[/i]
 
PS 2 emulated on CPU is no way near as fast as having it done through the video card. Same goes for any 3d rendering on the CPU.

While CPUs are getting faster, they are being used more and more on demanding physics such as ragdoll effects, pathfinding and AI.

We most likely will never see a CPU rendering anything in future. All will be done on videocard. We have not even scratched the surface in regards to using real physics in games.
I can't wait to see the chaos effect theory demonstrated. Of course you will need all the CPU cylces you can get your hands on. ;)
 
overclocked said:
Nice, so when will the PS2 demo be ready?
It's not PlayStation 2, it's DirectX Pixel Shader 2.0 emulation ;)

The compiler is nearly finished (just needs lots of testing), the rasterizer is copied from Real Virtuality and the clipper and vertex pipeline are also nearly finished. I'm just glueing it all together now...

I hope to finish a preliminary demo by the end of the month.
 
K.I.L.E.R said:
We most likely will never see a CPU rendering anything in future.
Why not? Games like Quake I/II and Unreal ran perfectly and were just as fun in software mode, they just didn't have extra's like bilinear filtering. Games like Counter-Strike thank part of their popularity to the software renderer which allows them to be played on nearly every system.

The current generation of graphics cards is almost 'only' targeted at playing games, but there's so much more applications that use 3D visualisation. In case of scientific simulations and CAD there's often no hardware acceleration present and 30 FPS is not required. In these situations soft-wiring technology can bring acceptable performance.

Besides, I never intended to beat hardware, only provide a good looking alternative when you don't have any other choice...
 
Nick said:
K.I.L.E.R said:
We most likely will never see a CPU rendering anything in future.
Why not? Games like Quake I/II and Unreal ran perfectly and were just as fun in software mode, they just didn't have extra's like bilinear filtering. Games like Counter-Strike thank part of their popularity to the software renderer which allows them to be played on nearly every system.

The current generation of graphics cards is almost 'only' targeted at playing games, but there's so much more applications that use 3D visualisation. In case of scientific simulations and CAD there's often no hardware acceleration present and 30 FPS is not required. In these situations soft-wiring technology can bring acceptable performance.

Besides, I never intended to beat hardware, only provide a good looking alternative when you don't have any other choice...

Fair enough then. Just don't think that software is the way of the future. I have looked at the shots in the site. If you are the author then I must say that I am impressed with your work.
Games in the past are different than games coming up in the future. Like I said, you can't afford to have the CPU doing rendering in future games as things like physics, AI and pathfinding will get so much more complicated.

You have already accomplished the goal of making a good looknig alternative. If you are capable of emulating PS 2.0 >=30fps minimum on a 1.5GHZ P4, I would say that you have achieved a miracle. I wonder how the framerate would be if you added 12 bots though. ;)

Again, I realise that you are not targeting gamers. :)

BTW: My point is that software rendering is dead in games and will stay that way in future. As for CAD and the like, you do make a valid point.
 
Hey,

Nice work! Although it obviously isn't for gamers, developers who don't have a GPU supporting PS2.0., for example, could benefit from a software engine supporting PS2.0.
Too bad the engine isn't open source, though... Yeah, I know I'm annoying :)

BTW, does anyone know a 3D, triangle-based, open source, *software* renderer? I'd like to test a little idea I had, but implementing a whole engine to test a small change makes no sense at all. Thanks for any help you can provide me :)


Uttar
 
I think your rendering engine is seriously cool (the really, really cool part is Softwire). But a version that didn't require SSE would be nice... (I only have a Tbird :( ). Anyway, I see you already do proper per pixel mipmapping, so, how about extending that to do rip-mapping? That would be kinda neat. :D
 
Uttar said:
BTW, does anyone know a 3D, triangle-based, open source, *software* renderer? I'd like to test a little idea I had, but implementing a whole engine to test a small change makes no sense at all. Thanks for any help you can provide me :)
My next project will be open-source licenced under LGPL. In case you can't wait, I've heard that the Mesa engine is quite good...

Or just whisper your idea to me ;)
 
Thowllly said:
I think your rendering engine is seriously cool (the really, really cool part is Softwire). But a version that didn't require SSE would be nice... (I only have a Tbird :( ).
I have an older version for Pentium II compatible processors, but then you miss all the extra features. I don't have an AMD so I can't code for 3DNow! If anyone's seriously interested I might consider explaining him how to encode the Microcode.dat file. Anyway, 3DNow! is very limited because it re-uses the MMX registers and only processes 2 floats in parallel.
Anyway, I see you already do proper per pixel mipmapping, so, how about extending that to do rip-mapping? That would be kinda neat. :D
I have considered that, and I even thought it would be the perfect way to implement anisotropic filtering. A first problem is that it uses 4 times more memory (although this is often acceptable because you mostly have more system RAM than video RAM). But because of the bigger texture's it will be harder to avoid cache misses and I'll loose some performance. Secondly, I would have to interpolate two mipmap LOD's instead of one (although this is also not a huge problem since SSE offers me plenty of registers). The biggest problem is that it totally doesn't work in the diagonal direction. I think it's bad that in one direction you can see sharp till the horizon and in another direction it looks like ordinary mipmapping.
 
K.I.L.E.R said:
It may actually be interesting to see more older games using this renderer. Any plans on doing that? :)
Quake II is open-source and it's maps are suited for portal clipping so that would indeed be cool. Carmack's style of coding isn't really attractive though ;) I would also have to rewrite a big part because SoftWire requires C++. If my exams are ok I'll consider doing this in summer vacation.
 
btw, rip-mapping only uses three times the memory of mip-mapping (mip-mapping: ~1,33x base map, rip-mapping: 4x base map)
 
Xmas said:
btw, rip-mapping only uses three times the memory of mip-mapping (mip-mapping: ~1,33x base map, rip-mapping: 4x base map)
If you really want to get picky :devilish: ... It depends on the size of the base map. If it's square and you generate all mipmap levels it's indeed nearly 1.33x. If it's not square the common method is to halve width and height till one of the dimensions is 1 and then further resample to 1x1. This results in memory usage between 1.33x and 2x ;)
 
BTW, this demo could also be used for SIMD benchmarking since the whole pixel and vertex pipeline use almost only MMX and SSE instructions.

Who has the highest FPS in the startup position? I get 23.1 FPS on my Celeron 1200 Mhz with all background applications closed...
 
Thowllly said:
I think your rendering engine is seriously cool (the really, really cool part is Softwire). But a version that didn't require SSE would be nice... (I only have a Tbird :( ). Anyway, I see you already do proper per pixel mipmapping, so, how about extending that to do rip-mapping? That would be kinda neat. :D

I thought the athlons supported SSE? or is it only palamino and above (or even none of them) ?
 
Bambers said:
I thought the athlons supported SSE? or is it only palamino and above (or even none of them) ?

AMD CPUs starting with the Palomino's support SSE. It's where the XP rating came into play with the XP 1500+ and up.
 
Back
Top