Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Scet

DOOM.Net

Recommended Posts

Hello fellow DOOMers. I thought I'd let you guys know about a source port I'm working. It's nowhere near done, but I'm determined to finish it.

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 :)







You can find some more screenshots and technical stuff here.

Share this post


Link to post

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...).

Share this post


Link to post
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.

Share this post


Link to post
Scet said:

I have yet to notice any speed problems. If DOOM could run a 486, I don't foresee any problems there...

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



Heh

Share this post


Link to post

You might want to choose a name that doesn't sound quite so much like a web address.

Share this post


Link to post

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.

Share this post


Link to post

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.

And if someone can think up a better name, I'm willing to use it.

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post

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.

Under native I thought it was not meant for D3D from the beginning.

Share this post


Link to post

OK. I didn't take offence, I was more bemused by the terminology you used since the common meanings don't really fit with Doomsday's architecture.

Your explanation makes more sense to me than your original statement.

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.

Share this post


Link to post
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#.

Share this post


Link to post
Scet said:

Hell even the "C++" ports aren't real C++, just C with a few classes.



Who says that the use of classes for everything is mandatory in C++ to get 'real' C++ code? No wonder that far too many software gets utterly bloated with such an attitude.

You use your tools where it fits you, not because you have to use them and large parts of Doom don't benefit from translating the code to classes.

Share this post


Link to post
Scet said:

...aren't real C++, just C with a few classes...


You do realize that the original name for C++ was "C with classes" don't you?

Share this post


Link to post

Well of course it resembles OpenGL, OpenGL is a C API and DOOM is in C.

I think your missing the point here due to the context.

The fact that they are both written in the same language is not relevant to the design of the engine-internal rendering API.

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.

Hence why it made sense to simply use a procedural design for the engine-internal API wrapper.

Share this post


Link to post
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.

Share this post


Link to post

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.

As you stated Graf (and I alluded too), the poor interface makes D3D's OO design pattern rather worthless IMO.

Certainly, at the time Doomsday's D3D renderer was written (for D3D 8.1) there was no real benefit to D3D's OO implementation.

Share this post


Link to post

Easy does it, Scet is rewriting Doom in C#, which is OO exclusively. I don't know about MDX, I presume it's OO and suits C# better than procedural OpenGL.

Share this post


Link to post

Very interesting stuff! I assume this is entirely new code and not based on the original source code.

Share this post


Link to post
rpeter said:

Easy does it, Scet is rewriting Doom in C#, which is OO exclusively. I don't know about MDX, I presume it's OO and suits C# better than procedural OpenGL.


That's pretty much what I was trying to say. I never said anything against OpenGL, just that it doesn't "fit in" with C#. It's the same way DX doesn't "fit in" with C.

fraggle said:

Very interesting stuff! I assume this is entirely new code and not based on the original source code.


Yes the code is all new. So far all I've used is the "unoffical doom specs" and the doom wiki.

Here are some more screenshots. They're the same ones from my journal, but I'll put them here to for the link impaired.





Share this post


Link to post

You still need to adjust for Doom's 1.6 aspect ratio. All the sprites look rather squashed.

Share this post


Link to post

Huh? It is at 1.6. Mabye it's the filter or the camera angle. The camera I have right now is free, it can move/rotate around any axis, unlike DOOM that only rotates on the y axis.

I'm working on the camera class now, one that'll act like the DOOM one. We'll see how it looks with that.

Share this post


Link to post

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).

Share this post


Link to post
myk said:

DOOM on a window has to be 640x480 (or 320x240)


... 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.

Share this post


Link to post

Hmm, I use screenwidth/screenheight for ratio. No wonder other ports look different to me. Looks like I'd better try fix 1.6.

Share this post


Link to post

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.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×