I'm making it using C#, .Net 2.0 and Direct3D 9. The point of the project is to fix any compatibility issues with XP and make it so there's no problem when Vista comes out. I'm to try to stay true to the vanilla look, but there's no gaurantee since I'm not using software rendering.

It's not much to look at right now. but here are a few screenshots to get your cursors moving :)

My hats off to you for attempting to port the code to C#, except that .NET languages arent suitable per se for running games at decent speeds while still using an acceptable amount of resources. But if you can pull it off that would rock, if only from a programming standpoint.

Oh and as of the December CTP (build 5270) of Windows Vista the majority of ports, including Chocolate Doom, run more or less fine (just like everything else...).

HobbsTiger1 said:
My hats off to you for attempting to port the code to C#, except that .NET languages arent suitable per se for running games at decent speeds while still using an acceptable amount of resources. But if you can pull it off that would rock, if only from a programming standpoint.

Oh and as of the December CTP (build 5270) of Windows Vista the majority of ports, including Chocolate Doom, run more or less fine (just like everything else...).

I think you underestimate C# and .Net, I have yet to notice any speed problems. If DOOM could run a 486, I don't foresee any problems there. Also all the resources are handled by Direct3D and the GPU.

This is not a simple port, it is more like a rewrite. Everything graphics wise is GPU.

As for Vista support I knew it wasn't just magically going to break everything, but having a port designed for it can't hurt.

Edit: I should add that DOOM.Net will require a fairly decent computer. 1GHz, 256MB RAM and 32MB video RAM will probably be the minimum.

Aha, I knew someone would try a dotnet port, although I thought it would be managed C++ first, like they did with Quake2.

I don't quite understand how you intend to do the rendering. Not polygon based?

Using glnodes it's fairly easy to implement a polygon based D3D renderer, see Doom3D. Sure it's a mix of Direct3D and DirectDraw but the DirectDraw parts (patches, HUD, automap, etc.) can be turned to D3D quite easy. Unfortunately Doom3D is the only port (and fairly old) that has native D3D rendering, not just an OpenGL emulator, like DoomsDay or Vavoom have.

The rendering is triangle based. It's just easier to use triangles so I can render everything that uses a certain patch in one pass. Sure there are a few "cloned" vertices here and there, but it's not like DOOM levels have a huge poly count.

I had some problems using Doom3D. There where a lot of missing floors and a few walls. There's no real problem with the renderer anyway.

Doom3D can only render flats correctly if you supply a gwa file (v1 or v2 glnodes), it has no internal glnodes builder. It can render walls corretly most of the time, I found problems only with some middle textures, like the balcony at the beginning of Doom2.

Anyway, I'd love to see a D3D9 renderer for Doom. I've done a D3D7 (pure 3D) before but I haven't had the heart to upgrade yet.

rpeter said:
Unfortunately Doom3D is the only port (and fairly old) that has native D3D rendering, not just an OpenGL emulator, like DoomsDay or Vavoom have.

What do you mean by that?

Doomsday has both D3D and OpenGL renderers implemented as external libraries accessed via an API. All these libraries do is to provide an absraction layer between the engine and the 3D api so the same functions can be used within the engine regardless of which renderer is in use.

All the rendering algorthims are internal to the engine.

How is that not native? I don't get your comment about it being an emulator either.

No offence was meant, it's just that the internal layer tastes very much like OpenGL. Probably because of the pre-doomsday times, when jHexen had only OpenGL rendering. I recently went through DoomsDay's code and I found myself constanly converting/comparing between OpenGL and D3D. Not that it was a bad excercise, not at all.

DaniJ said:
Personally, I'm glad the internal interface resembles the OpenGL API as opposed to that of D3D since IMO its nicer to use than D3D.

Well of course it resembles OpenGL, OpenGL is a C API and DOOM is in C. Hell even the "C++" ports aren't real C++, just C with a few classes. D3D is more object oriented( with MDX being pure OO ), so it goes nicely with C#.

DaniJ said:
Although D3D is C++ I would hardly say that its interface uses an OO design. Once you have a handle to the device, thats it.

Personally, I find D3D's interface awful. You always have to shove around several pointers to do even the most trivial things. As a result they normally end up in global variables thus negating any potential benefit of an OO approach.

Personally, I find D3D's interface awful. You always have to shove around several pointers to do even the most trivial things. As a result they normally end up in global variables thus negating any potential benefit of an OO approach.

Agreed. Doomsday's D3D renderer does exactly that to hide this complication from the engine... thankfully.

DOOM on a window has to be 640x480 (or 320x240), with a possible additional adjustment for the sprites, depending on how the whole thing is resized. The screen mode used by DOOM stretches all the pixels vertically (being a partial economization of the 320x400 VGA resolution).

... and with a screen size of 1280x1024 it has to be different yet again so that it doesn't look squashed. But for hardware rendering screen size is not an issue as long as the projection matrix is properly set up. It should always account for screen size and never assume a fixed aspect ratio.

Yeah, but the common LCD resolution 1280x1024 is 5:4, and there's an increasing about of widescreens out there (laptops and TVs mainly, although I have a 20'' widescreen for my desktop). Please put in the extra work to do this correctly:) I think ZDoom and Doomsday are the only two ports to support widescreen.