New swShader Demo

N

Nick

Veteran
Grab it here: swShader Project Page.

It demonstrates the capabilities of the swShader software renderer as a DirectX 9 compatible DLL. The actual application is an unmodified example from the DirectX 9.0b SDK. So all render calls are handled by this DLL, completely in software. For more information about swShader you can also visit the Main Homepage.

If you have any questions about it, feel free to ask!
 
noticed that resizing the window (dragging from edge or corner) causes error "Could not reset Direct3D device. This sample will now exit" :)

but it's not a real bug is it? (only way this could be prevented is dynamic changing of resolution, right?)
 
Kaotik said:
but it's not a real bug is it? (only way this could be prevented is dynamic changing of resolution, right?)
Click to expand...
It's a bug which I intentionally haven't solved yet. Just don't resize now. ;) If you really want higher resolutions, just recompile the SDK sample.
 
Inane_Dork said:
Can you tell me why you guys made this? Just curious.
Click to expand...
I guys made it as a hobby project. It's fun rendering things yourself instead of letting the graphics card do it. It has some practical uses too but that's quite limited. It's exactly 100 times faster than the reference rasterizer though. More 'reasons' for this project can be found on the website. :)
 
Nick said:
I guys made it as a hobby project. It's fun rendering things yourself instead of letting the graphics card do it. It has some practical uses too but that's quite limited. It's exactly 100 times faster than the reference rasterizer though. More 'reasons' for this project can be found on the website. :)
Click to expand...
Cool. Good luck to you!
 
Scali said:
There seems to be an inaccuracy in either the vertex setup or the rasterizing. See image: http://scali.eu.org/~bohemiq/ShadowVolume.png
I could not recreate the problem using hardware.
Click to expand...
I still haven't found the cause of that. The rasterizer has been tested very intensively, and I can't see a reason why vertices would shift. It's also not the clipper since the clip operation is done with a fixed vertex order.
PS: how is the spheres-demo coming?
Click to expand...
I'm adding features every day, so one day it has to start working. ;)
 
Nick said:
I still haven't found the cause of that. The rasterizer has been tested very intensively, and I can't see a reason why vertices would shift. It's also not the clipper since the clip operation is done with a fixed vertex order.
Click to expand...

I suppose it depends on what you tested. Did you test with a xor-operation and with the zbuffer disabled?
What we're looking at here, could be that certain pixels are drawn twice, rather than never, I believe.
That problem will not show up if you only test whether there are holes in meshes.

Out of curiosity: is this the halfspace-function rasterizer, and does the other rasterizer have the same problem or not? Could rule out one of the two options anyway: rasterizer or vertex setup.
 
Trust me, I tested it thoroughly. I'm not ruling it out, it could be caused for example by really thin polygons (though I tested that too), but I would be surprised if it was the rasterizer. It's mathematically robust, using only integer calculations. It has to be something else.

This demo is not using the new half-spaces rasterizer yet. The pixel pipelines for it aren't finished yet. But that's what I'll focus on next...
 
I got 1.3 FPS full screen 1600x1200, which I find pretty impressive. (Especially on a machine whose 3DMark05 CPU tests FPS is 0.2 :))
 
ET said:
I got 1.3 FPS full screen 1600x1200, which I find pretty impressive. (Especially on a machine whose 3DMark05 CPU tests FPS is 0.2 :))
Click to expand...
Thanks! Disable shadow rendering and you'll get four times that. :LOL:

My new renderer will probably speed up stencil operations significally...
 
I've done something stupid - tried running our own code with this .dll :)

So far:

1. At first Direct3DCreate9 returned NULL, but I found our I have to pass D3D9b_SDK_VERSION instead of D3D_SDK_VERSION.
(I'm using the 9.0c SDK by default.)

2. Seems to be no support for D3DDEVCAPS2_STREAMOFFSET which actually the key feature of a DDI9 driver. I think it's not a hard feature to support. If I have time (unlikely) I'll check to see if I could help implementing it.
So far I commented out the check in our code (excepting a huge crash somwhere later).

3. CreateDevice crashed.
I found out why - CreateDevice caused a WM_SIZE event for the device window... D3D doesn't do this.
Anyway, I was able to work around this.

4. Not many texture formats are supported, but so far so good.

5. CheckDeviceFormat seems to return true for all input when D3DRTYPE_SURFACE is specified.

6. SetVertexShader(NULL) returns D3DERR_INVALIDCALL is that normal? If you don't support fixed T&L (which is fine btw.), if might be better to accept NULL and silently ignore all draw calls.
Same for SetPixelShader.

7. CreatePixelShader failed for a simple PS1.1 shader. Do you support 1.x shaders at all, or only PS2.0?
It will take some time to work around this...
 
Ok, looks like CreatePixelShader returns D3DERR_INVALIDCALL for the following shader.

Code: 
0xFFFF0200,                                                 //   ps_2_0
0x0200001F, 0x80000000, 0xB00F0000,                         //   dcl t0
0x0200001F, 0x90000000, 0xA00F0800,                         //   dcl_2d s0
0x03000042, 0x800F0000, 0xB0E40000, 0xA0E40800,             //   texld r0, t0, s0
0x02000001, 0x800F0800, 0x80E40000,                         //   mov oC0, r0
0x0000FFFF,                                                 //   END

I've got the following message in the debug window (happens during the call)
Code: 
First-chance exception at 0x7c57e592 in editor-debug.exe: Microsoft C++ exception: D3D9::Error @ 0x0012e150.

...

Hehe, I've just read the readme that the .dll is intentionally crippled ;)
:LOL:
 
It does support fixed T&L, at least, to some extent. I ran some of my own stuff aswell, and a gouraud-shaded, textured surface with a material worked properly. In fact, I don't think the example of the shadowvolumes actually used shaders. But I don't have DX9.0b SDK anymore, so I can't check the source (DX9.0c seems to have a slightly fancier shadowvolume example).
Perhaps it's the shader support that's crippled :)
 
Hyp-X said:
1. At first Direct3DCreate9 returned NULL, but I found our I have to pass D3D9b_SDK_VERSION instead of D3D_SDK_VERSION.
(I'm using the 9.0c SDK by default.)
Click to expand...
All the samples like ShadowVolume dissapeared out of the 9.0c SDK, that's why I sticked to 9.0b for now. But I shouldn't have to return NULL when passing the new version number. Thanks for reminding me!
2. Seems to be no support for D3DDEVCAPS2_STREAMOFFSET which actually the key feature of a DDI9 driver. I think it's not a hard feature to support. If I have time (unlikely) I'll check to see if I could help implementing it.
So far I commented out the check in our code (excepting a huge crash somwhere later).
Click to expand...
It is supported, it's just not advertised in the caps. Haven't found an app to test it with yet, but it doesn't seem like a big problem.
3. CreateDevice crashed.
I found out why - CreateDevice caused a WM_SIZE event for the device window... D3D doesn't do this.
Anyway, I was able to work around this.
Click to expand...
Thanks for noting this! I'm doing the following in my DirectDraw windowed mode initialization:
Code: 
	RECT rcWork;
	RECT rc;
	DWORD dwStyle;

	dwStyle = GetWindowStyle(handle);
	dwStyle &= ~WS_POPUP;
	dwStyle |= WS_OVERLAPPED | WS_CAPTION |	WS_THICKFRAME | WS_MINIMIZEBOX;
	SetWindowLong(handle, GWL_STYLE, dwStyle);

	SetRect(&rc, 0, 0, width, height);

	AdjustWindowRectEx(&rc, GetWindowStyle(handle), GetMenu(handle) != 0, GetWindowExStyle(handle));
	SetWindowPos(handle, 0, 0, 0, rc.right - rc.left, rc.bottom - rc.top, SWP_NOMOVE | SWP_NOZORDER | SWP_NOACTIVATE);
	SetWindowPos(handle, HWND_NOTOPMOST, 0, 0, 0, 0, SWP_NOSIZE | SWP_NOMOVE | SWP_NOACTIVATE);

	SystemParametersInfo(SPI_GETWORKAREA, 0, &rcWork, 0);
	GetWindowRect(handle, &rc);
	if(rc.left < rcWork.left) rc.left = rcWork.left;
	if(rc.top < rcWork.top) rc.top = rcWork.top;
	SetWindowPos(handle, 0, rc.left, rc.top, 0, 0, SWP_NOSIZE | SWP_NOZORDER | SWP_NOACTIVATE);
It's been a really long time since I touched this code, but I'm going to look for the right alternative. Probably most of this can be deleted...
4. Not many texture formats are supported, but so far so good.
5. CheckDeviceFormat seems to return true for all input when D3DRTYPE_SURFACE is specified.
Click to expand...
Only 32-bit is actually supported. In my newest version more formats are supported, but having 8-bit per color component is simply the most efficient to use with MMX. A modern CPU has a lot more memory bandwidth than pure processing power.

Although it's an inherent part of a 3D renderer, I hate all pure 2D work. :rolleyes:
6. SetVertexShader(NULL) returns D3DERR_INVALIDCALL is that normal? If you don't support fixed T&L (which is fine btw.), if might be better to accept NULL and silently ignore all draw calls.
Same for SetPixelShader.
Click to expand...
Not supported in this version. I crippled it here on purpose. I'll probably never release a demo with pixel shader support (unless maybe a statically linked library). Marketing purposes, I'm trying to earn some pocket money out of this... ;)
7. CreatePixelShader failed for a simple PS1.1 shader. Do you support 1.x shaders at all, or only PS2.0?
It will take some time to work around this...
Click to expand...
There are only minor differences in the token stream for every shader version. So it's not going to take long before I support every variant. Either way, it's crippled in the demo's DLL. Sorry.
 
Nick said:
Marketing purposes, I'm trying to earn some pocket money out of this... ;)
Click to expand...
Pity. I'm sure you could make some money off this, since you're doing great work, but it's still a pity that it doesn't allow enthusiasts to play with it freely. What kind of market did you have in mind? (Are you planning to sell this as a software rendering engine, to developers or to end users?)
 
ET said:
Pity. I'm sure you could make some money off this, since you're doing great work, but it's still a pity that it doesn't allow enthusiasts to play with it freely. What kind of market did you have in mind? (Are you planning to sell this as a software rendering engine, to developers or to end users?)
Click to expand...
The same market as Pixomatic, the same reasons. I support shaders and the DirectX interface, but I'm willing to sell for less. ;) To be fair the disadvantages of swShader is that I can't provide the same support as long as I'm a student, and it can't run Unreal Tournament 2004 graphics in real-time yet. I'm first focussing on implementing everything correctly, then I can add optimizations that scale the quality down but give superiour performance.

If shader model 4.0 specifications are out soon I might also support it at 'workable' performance before hardware...
 
You must log in or register to reply here.

Similar threads

D
Diligent Engine - A Modern Cross-Platform Graphics Library
Replies
0
Views
4K
diligent
D
L
AMD, FireRender (Corona ) raytracing Engine
Replies
4
Views
3K
Jawed
Jawed
Rys
Subscriptions and Donations
3 4 5
Replies
96
Views
30K
entity279
E
C
  • Locked
Tomb Raider seeks Graphics Software Engineer
Replies
0
Views
4K
Crystal Dynamics
C
NThibieroz
  • Locked
APU Developer Technology Engineer at AMD
Replies
2
Views
5K
Rys
Rys
Back
Top