Jump to content
The Dark Mod Forums

compilation with Visual C++ 2008 Express Edition and other stuff


Recommended Posts

Hello everybody,

 

this is my first post in this forum. I'm the lead coder of the XreaL project and I just want to say that I really like your work on the DarkRadiant. The coding style is very good and some of the new features like the model previewer are really handy. It's really nice to see that you put so much effort into this level editor to give people a useful tool.

I worked most of the time with a GtkRadiant 1.5 codebase with a very few hacks. As you might now I use the Q3A engine and I compile Doom3 .map format maps into the Q3A BSP format. The Doom3 .map format is the standard format for our project and my XMap1 compiler can convert any Quake .map ranging from Quake2 - 4 to the Doom3 .map format.

So a Doom3 .map format only editor is the only thing I need.

 

I just want to let you know that I could compile the latest DarkRadiant SVN code with the VC 9 express edition and I can offer a few patches in the future if you don't mind.

I use your win32 deps and a separate complete build of boost 1.35. It works fine with that and I'm glad that STLPort is not necessary anymore.

However I had to add the OGG Vorbis source to the sound plugin because the binary libs for linking are too old. (oh well libraries and win32 .. always crap)

 

Well I don't have much time this semester but I could provide a few fixes because I'm almost done with XreaL's renderer.

I'm going to try to use DarkRadiant as the main editor for XreaL when I'm done with some necessary plugins like a XMap2 compiler observer plugin.

Do you accept some non-darkmod specific plugins? I already backported PNG image support and changed the mediabrowser to display Doom3 materials with a case-insensitive lexicographic comparison, so materials with Textures/foo/bar and textures/foo/bar don't create extra trees.

 

The only downside with the DarkRadiant is that it is about 3 times slower than the old GtkRadiant 1.5. I haven't profiled it yet. I just noticed that it gets really slow when there are many brushes and patches visible in the 2D view.

I haven't looked much into the renderer yet.

Do you render all brushes individually? Maybe that can be improved with dynamic VBOs where you merge the geometry by material every few frames with all brushes that haven't changed. I use a lot of tricky optimizations in my engine like that and maybe I can improve the renderer speed in DarkRadiant once I found the bottlenecks.

 

Well that's it for now.

Link to post
Share on other sites
this is my first post in this forum. I'm the lead coder of the XreaL project and I just want to say that I really like your work on the DarkRadiant. The coding style is very good and some of the new features like the model previewer are really handy. It's really nice to see that you put so much effort into this level editor to give people a useful tool.

Hello and welcome to the forums then! Glad to hear that you like DarkRadiant. :)

 

I just want to let you know that I could compile the latest DarkRadiant SVN code with the VC 9 express edition and I can offer a few patches in the future if you don't mind.

I use your win32 deps and a separate complete build of boost 1.35. It works fine with that and I'm glad that STLPort is not necessary anymore.

That's really an incident, because I just committed the new boost 1.35 headers to the repository. I'm also working on the VC++ 9.0 Express compatibility - this should be done till the weekend, I just need to add the static libs to the w32deps folder.

 

However I had to add the OGG Vorbis source to the sound plugin because the binary libs for linking are too old. (oh well libraries and win32 .. always crap)

If you have a .vcproj file and the sources available, maybe you could send that to me? If the current .lib files are too old (which target are you compiling for? XP/Vista?), I can try to add another vcproj which compiles the Vorbis library along with the other sources, just as I did with libxml2 recently.

 

Well I don't have much time this semester but I could provide a few fixes because I'm almost done with XreaL's renderer.

Any improvement suggestions are welcome, of course. We are planning to rewrite the renderer at some point and we had a few consulting members on these forums in the past, but we are not exactly an OpenGL Competence Centre around here.

 

Do you accept some non-darkmod specific plugins? I already backported PNG image support and changed the mediabrowser to display Doom3 materials with a case-insensitive lexicographic comparison, so materials with Textures/foo/bar and textures/foo/bar don't create extra trees.

I haven't checked yet whether Doom3 materials are case-insensitive. Can you confirm that or is it your engine which treats them case-insensitively? If D3 is also ignoring the case, that fix can go into the codebase, imo.

 

As for non-darkmod plugins: that depends on what they do. I'm not the only one to decide that, but I'd like to keep the trunk/darkradiant repository rather focused on Doom3/Darkmod in terms of code. However, I think we can find a way to incorporate your plugins in a separate folder, perhaps (similar to the trunk/w32deps/ folder, maybe some trunk/extraplugins folder or something like that? OrbWeaver, what do you think?

 

The only downside with the DarkRadiant is that it is about 3 times slower than the old GtkRadiant 1.5. I haven't profiled it yet. I just noticed that it gets really slow when there are many brushes and patches visible in the 2D view.

Really, three times slower? That kind of surprises me, but I'm inclined to believe it, as we hardly checked in any render performance improvements.

 

I haven't looked much into the renderer yet.

Us neither. As said above, we have somewhat limited OpenGL experience.

 

Do you render all brushes individually? Maybe that can be improved with dynamic VBOs where you merge the geometry by material every few frames with all brushes that haven't changed. I use a lot of tricky optimizations in my engine like that and maybe I can improve the renderer speed in DarkRadiant once I found the bottlenecks.

We already discussed VBOs a while back in the internal forums and were not sure whether it was appropriate for rendering a lot of brushes with different shaders. At any rate, it sounds like you got more experience anyway.

 

Would you be interested in some sort of joint-venture when we start to rewrite the renderer? I'm not asking that you write a renderer for us, but maybe we can create some sort of win-win-situation (we'll try to make the editor more open towards your engine and you help us trying to get the renderer straight).

 

I must admit that I don't know anything about XreaL (I'll have to do some googling about it) - theoretically spoken, would the XreaL renderer appropriate for rendering vanilla Doom 3/Darkmod shaders and maps?

Link to post
Share on other sites
which target are you compiling for? XP/Vista?

 

I haven't checked yet whether Doom3 materials are case-insensitive. Can you confirm that or is it your engine which treats them case-insensitively? If D3 is also ignoring the case, that fix can go into the codebase, imo.

 

I must admit that I don't know anything about XreaL (I'll have to do some googling about it) - theoretically spoken, would the XreaL renderer appropriate for rendering vanilla Doom 3/Darkmod shaders and maps?

 

I compile with Vista 32 bit.

 

Doom3 material names are definitely case-insesitive. I just checked that with the media browser of d3radiant.

I'm going to provide a patch for that soon.

 

Well XreaL is basically the Q3A engine with a Doom3 style renderer and new artwork to make it a standalone funny thing. But it is a very specific solution. I still use the Q3A BSP for rendering but with static VBOs and dynamic IBOs. I use Doom3 style lights and have almost full support for the entire Doom3 .mtr language.

The renderer is written on top of Carmack's Q3A trinity renderer so everything is written in C. It's not suitable to grab the renderer and make it work for other programs because it heavily relies on the Q3A framework and architecture.

 

I have a lot experience with OpenGL. XreaL's renderer is even better than the Doom3 one in a few areas. However the DarkRadiant code is something completely different. GtkRadiant 1.5 uses my old .cg shaders for the light preview mode but I haven't coded the renderer implementation. That was SPoG's work.

 

I only have time for coding at the weekends so I can't promise too much. I think I will try to improve DarkRadiant's renderer after I'm done with the XMap2 observer. I guess even that plugin will take a few weekends.

Link to post
Share on other sites
Doom3 material names are definitely case-insesitive. I just checked that with the media browser of d3radiant.

I'm going to provide a patch for that soon.

That's cool then, looking forward to that patch. I always wrote my shader names lowercase, so I never noticed about Doom 3 being case-insensitive. :)

 

Well XreaL is basically the Q3A engine with a Doom3 style renderer and new artwork to make it a standalone funny thing. But it is a very specific solution. I still use the Q3A BSP for rendering but with static VBOs and dynamic IBOs. I use Doom3 style lights and have almost full support for the entire Doom3 .mtr language.

The renderer is written on top of Carmack's Q3A trinity renderer so everything is written in C. It's not suitable to grab the renderer and make it work for other programs because it heavily relies on the Q3A framework and architecture.

Wow, almost full support for Doom 3 materials? Sounds impressive - although it's a shame that it's C-based and that it can't be adapted for DarkRadiant. Still kudos to you for getting the materials to work. :)

 

I have a lot experience with OpenGL. XreaL's renderer is even better than the Doom3 one in a few areas. However the DarkRadiant code is something completely different. GtkRadiant 1.5 uses my old .cg shaders for the light preview mode but I haven't coded the renderer implementation. That was SPoG's work.

Were you involved in GtkRadiant or did they just use your shaders? I'm only asking out of curiosity.

 

I only have time for coding at the weekends so I can't promise too much. I think I will try to improve DarkRadiant's renderer after I'm done with the XMap2 observer. I guess even that plugin will take a few weekends.

I know exactly where you're coming from. I can perfectly understand if you cannot devote much time for DarkRadiant - in any event, even if you just consult me a bit and point me in the right direction, give me tips and such, I'd greatly appreciate that. I'll try to do my best to help you with DarkRadiant issues in return. The focus of DarkRadiant must stay on the Doom 3 engine, but I'll be happy to help with modularising code/exposing interfaces to make non-darkmod plugins possible and powerful.

Link to post
Share on other sites

I've been watching the xreal project for quite some time now. :) Awhile ago I suggested we look into potentially switching to it since it was open source and could free us from the shackles of not having the full D3 SDK. Sadly, I didn't realize it was in C at the time, nor did I fully understand the consequences of converting our work from C++ to C. Not viable in the end, but I'm really quite hopeful that Dark Radiant can help us bridge the two projects and see larger benefits for both. :) An improved Dark Radiant Renderer and making the whole thing faster would be absolutely amazing.

Link to post
Share on other sites

I only wrote smaller fixes for the GtkRadiant 1.5 tree a long time ago and helped SPoG with Doom3 tech questions.

 

Ok I created a patch for the shader names. The patch is not perfect with the functor solution but I don't know another way to do this in C++.

 

I used the same technique in my previous C++ based engine. Maybe you have a better solution. This is just a suggestion as a result of a short code review. You really changed almost everything ..

I have to start from the beginning :)

I left out the shaders.vcproj because VC9 changed it a bit more.

 

Here is the patch generated with TortoiseSVN:

http://xreal.sourceforge.net/files/darkrad...ive_r3395.patch

Link to post
Share on other sites

Thanks for the patch. I probably would have chosen to convert all incoming shadernames to lowercase before inserting them or using them for querying the ShaderLibrary, but your approach is just as fine. Getting the ShaderLibrary to react case-insensitively is probably the more elegant solution.

 

I'll do a quick check and commit the patch to SVN. :)

Link to post
Share on other sites

Whoops, got distracted. The patch is in SVN now, thanks a bunch. :)

 

Let me know about your experience and issues when working with DarkRadiant. On a related note, is there a mapping team in XreaL, who will be using DarkRadiant for their regular work?

Link to post
Share on other sites
As for non-darkmod plugins: that depends on what they do. I'm not the only one to decide that, but I'd like to keep the trunk/darkradiant repository rather focused on Doom3/Darkmod in terms of code. However, I think we can find a way to incorporate your plugins in a separate folder, perhaps (similar to the trunk/w32deps/ folder, maybe some trunk/extraplugins folder or something like that? OrbWeaver, what do you think?

 

I have never had a problem in theory with having non D3/TDM-specific plugins in the main trunk (since maintaining a separate SVN branch would be extra work) provided that:

 

1. Absolutely everything game-specific is separated into separate plugins, for example eclassmgr.d3 and eclassmgr.xreal (or whatever). We definitely don't want any GtkRadiant-style "if (gametype == DOOM3) { ... }" stuff.

2. The build system is configured to allow only the plugins needed for the current game to be compiled, so that you could run "scons GAME=doom3" and only get the Doom 3 versions of plugins.

 

This ensures that the built product would not become bloated with unused code relating to other games.

Link to post
Share on other sites
I have never had a problem in theory with having non D3/TDM-specific plugins in the main trunk (since maintaining a separate SVN branch would be extra work) provided that:

 

1. Absolutely everything game-specific is separated into separate plugins, for example eclassmgr.d3 and eclassmgr.xreal (or whatever). We definitely don't want any GtkRadiant-style "if (gametype == DOOM3) { ... }" stuff.

2. The build system is configured to allow only the plugins needed for the current game to be compiled, so that you could run "scons GAME=doom3" and only get the Doom 3 versions of plugins.

 

This ensures that the built product would not become bloated with unused code relating to other games.

 

That sounds good. I think I only need very few changes or extra stuff like PNG image support that already works.

Concerning the XMap2 observer .. well I think we don't need that because most mappers use an extra GUI frontend for XMap2 (Q3Map2) anyway.

I wrote a bunch of .def files to get the DarkRadiant to work with XreaL. However it contains only a few entity defintions by now.

I think I can handle basic XreaL support even without extra plugins.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...