greebo
-
Posts
16733 -
Joined
-
Days Won
51
Posts posted by greebo
-
-
Hm, ok, I guess I mixed this up. Right now the tokeniser is delivering parts like this (comments are all stripped out, and the strings are trimmed):
dtable1
{ wood diffusemap models/darkmod/props/textures/dtable1_d.tga bumpmap models/darkmod/props/textures/dtable1_local.tga specularmap models/darkmod/props/textures/dtable1_s.tga { if ( parm11 > 0 ) blend gl_dst_color, gl_one map _white.tga rgb 0.40 * parm11 } { if ( parm11 > 0 ) blend add map models/darkmod/props/textures/dtable1_d.tga rgb 0.15 * parm11 } }I understand that a whole block can hardly be understood as an atomic part of the material file, but I have to admit that I find it convenient to feed my parser with parts like this. Is this considered bad programming style?
-
I had this in mind, but looking at the material files I decided to write a separate "MaterialTokeniser.h", as the definitions are a bit differently organised (with many curly braces all through the file). As far as I can tell, a general texture definition (or table) looks like this:
<name> <definition block surrounded by curly braces>
where the definition block may consist of several stages, that (according to my plan) are to be parsed by a seperate tokeniser (a "ShaderTokeniser").
So at the moment I have a working "MaterialTokeniser" that can split a given material file into tokens like in the code above.
These tokens (i.e. either a name or a definition block) are sent to another parser, that analyses the actual stages and calls the existing radiant functions to add them to the shader memory. I'm currently working on this ShaderTokeniser.
Any suggestions? Do you consider this as too cumbersome?
-
I'm just writing the Texture TokenizerFunc and while looking through DefTokeniser.h I discovered this. I'm not sure if this is a bug or not, but I better post this here:
case STAR: // The star may indicate the end of a delimited comment. // This state will // only be entered if we are inside a delimited comment. if (*next == '/') { _state = SEARCHING; continue; } else { continue; // do SEARCHING }In my opinion, this should look like this:
case STAR: // The star may indicate the end of a delimited comment. // This state will // only be entered if we are inside a delimited comment. if (*next == '/') { _state = SEARCHING; continue; } else { _state = COMMENT_DELIM; // ADDED continue; // do SEARCHING }Because otherwise, any star that is found within a delimited comment would cause the loop to switch into SEARCHING mode instead of carrying on with COMMENT_DELIM.
-
I've installed GDB and it's working correctly with those "hello world"-type programs, but it does not with DarkRadiant:
But if it's not that important, I will stick to console outputs (as I've done before when I tried to figure out the problem with freezeTransform()).
-
Is it possible to use Eclipse to set breakpoints and so on? Because at the moment I can compile and run DarkRadiant via Eclipse/scons, but as soon as I want to "debug" it instead of "run" it, it complains that the application is not responding or something. Is this the regular behaviour for GTK+ apps or is there something wrong with my debugger configuration?
-
I use Eclipse with the CDT development tools. However on Windows this is painfully slow, so you might well be better off with a text editor + scons or a lightweight Windows IDE like Dev-C++.
If you want to contribute, perhaps N.H. can set you up as a Programming contributor, so you can see the outstanding Darkradiant tasks list we have in there. Rewriting the material parser is not a priority at the moment, it is just something that would be appropriate some time down the line.
Ok, will try with one of those. I already read that thread as I can see those internal forums (since Wednesday I think). At first I thought I could have a try at Task No. 5 (Addition of "all light volumes" toolbar button), but it may be safer if I tried my marvellous skills at something that's not so mission-critical.
-
By all means, have a go at it if you like, although I haven't looked into this in detail so I can't specify exactly what is required beyond "code improvement" (and I'm pretty sure it won't be a small task). In general a recursive-descent parser that throws a ParseException of some sort is better than a depth-based parser with horrible macros to RETURN_FALSE_IF_FAIL, using a boost-based library is better than homegrown shit (see my libs/parser/DefTokeniser.h which is used in radiant/eclass_doom3.cpp to parse DEF files), and using proper C++ tools better than C-style ones (compare std::string's with a==b rather than string_equal_nocase(const char*, const char*)).
If you need to create a new exeption, just do what I have done with the exceptions in the xmlutil library -- they just inherit from std::runtime_error and pass their "what" argument up to the parent.
Ok, I will have a try, but first I will start reading the code and some documentations, which surely will take some time. As soon as I dare to say that I understand everything that's going on, I will go and create some new parser. What kind of development environment are you using? Just a text editor and scons or are there easier ways that I'm unaware of?
Gah. Are ALL our new coders working on the editor? We have lots of other programming tasks for the next milestone that aren't done yet.I want to take a look at the Dark Mod code as well, but I'm still chewing on sending sparhawk my public key
(I hope I got it right this time 
). Don't expect anything though, as I'm no C++ wizard or anything, but better try and fail than to leave it unattempted. -
In fact this whole section needs a rewrite, I can't believe anyone would use a control-flow macro like RETURN_FALSE_IF_FAIL these days (that's what god invented exceptions for).
Hm. Perhaps this would be a smaller task for me to get my feet wet with coding? What do you think, Orbweaver? Is there already some sort of exception class existant?
-
Thanks for merging. I don't know how fast the code can blend these two (or more) normalmaps, but this could increase the loading time of DR a lot, especially if we had a lot of shaders using this keyword.
If I had the choice I would do this at the point when it's required, i.e. right before switching to rendermode.
-
I recently discovered the addnormals() keyword to merge two normalmaps and applied it to some of my shaders. Firing up DarkRadiant revealed that it doesn't support this kind of bumpmap argument - all of the shaders using addnormals(x,y) appear as "shader not found" (and an error is written to radiant.log).
However, I could at least make the problem a little bit smaller by changing this part in shader.cpp:~444
RETURN_FALSE_IF_FAIL(Tokeniser_parseToken(tokeniser, "(")); RETURN_FALSE_IF_FAIL(Tokeniser_parseTextureName(tokeniser, bump)); RETURN_FALSE_IF_FAIL(Tokeniser_parseToken(tokeniser, ",")); RETURN_FALSE_IF_FAIL(Tokeniser_parseToken(tokeniser, "heightmap")); TextureExpression heightmapName; ShaderValue heightmapScale; RETURN_FALSE_IF_FAIL(Doom3Shader_parseHeightmap(tokeniser, heightmapName, heightmapScale)); RETURN_FALSE_IF_FAIL(Tokeniser_parseToken(tokeniser, ")"));(which is wrong as there is no "heightmap" in the syntax of addnormals()) to this
RETURN_FALSE_IF_FAIL(Tokeniser_parseToken(tokeniser, "(")); RETURN_FALSE_IF_FAIL(Tokeniser_parseTextureName(tokeniser, bump)); RETURN_FALSE_IF_FAIL(Tokeniser_parseToken(tokeniser, ",")); RETURN_FALSE_IF_FAIL(Tokeniser_parseTextureName(tokeniser, bump)); RETURN_FALSE_IF_FAIL(Tokeniser_parseToken(tokeniser, ")"));After changing this, the qer_editorimages are displayed correctly (as the parser goes over the definitions without throwing an error), but when switching to rendermode the normalmaps are still not displayed. This doesn't hurt me too much as I seldom use the rendermode of DarkRadiant, but it may be annoying for others.
According to https://zerowing.idsoftware.com/svn/radiant...iant/trunk/TODO the support for addnormals() is still on the ToDo-List, so perhaps this will be resolved in the future, perhaps not.
I would be grateful if you could merge the code changes above into SVN so that I can continue to use my shaders even after a clean checkout, because I find this keyword rather useful.
-
I get a file conflict during SVN checkout that's probably windows-specific: SVN wants to create a file named libs/gtkutil/GLWidget.cpp, but there is also a file named libs/gtkutil/glwidget.cpp existant in my according folder.
Deleting the lowercase file (I suppose that's the old one) doesn't do the trick, because it's restored by SVN update, I guess both files are still in the repository.
-
Nevermind, as long as this version is working, it should not be a problem.
-
No binary packages to download? It's mentioned in the Wiki article, but the downloadable archives do not contain any binaries. Would I have to compile if I wanted a recent binary?
-
Yes, I got the same problem, but I could resolve it.
Short story: there was a wrong version of libgdkglext-win32-1.0-0.dll or libgtkglext-win32-1.0-0.dll installed in our systems. I overwrote those with the ones in the Darkradiant 0.5.3 package and now it's gone.
Long story: When I first compiled DarkRadiant (that must've been at the beginning of July) those two files were not available and I had to download it from the depths of the internet, as those files are not included in the GTK+ package (strangely enough). DarkRadiant always complained that these files were missing, so I downloaded and stored them in my system32 folder - everything was fine until the model preview was introduced, which seems to rely on exactly those files. I compared the version I downloaded to the version you provided with DR 0.5.3 and they are in fact of different size, although the name and indicated version is completely identical.
Just out of curiosity: where do these files originally come from? They are not included in GTK+ and I could not easily find them on the web.
-
Do you have another version of GTK+ installed or are you using the one that came bundled with DarkRadiant? Have you tried to reinstall DarkRadiant?
-
Yes I thought it might be that too, but what do you use to block vis?? There is no hint texture anymore.
Don't know a thing about a hint texture, but perhaps this is similar to the visportal texture you have to use. Have you seen this tutorial? http://www.iddevnet.com/doom3/visportals.php
-
I personally find it helpful to keep in mind that brushes are in fact defined as planes and not as a bunch of vertices like in modeling applications. The actual form of a brush, its edges and its corners are calculated out of the intersection of these planes.
You often can't just drag around one single vertex of the brushes as it would cause the adjacent planes to twist, which is impossible. Manipulating the edges works indeed far better, as Orbweaver pointed out.
-
As for the tris that show up through other brushes: this may be a problem with your visportals. If your rooms are not properly separated, Doom renders all the brushes in your field of view, even if they are blocked by other brushes. Don't know if this is new to you or not.
Can't say what's with the other brushes being split up in too many tris. Maybe this is due to Doom's light scissors? Also it looks like the bevels may play a role, as the cuts seem to be aligned to the bevel's faces. Like here in the right part of the image. But this should not hurt too much as long as your light- and shadowcount is low enough.
-
Ok, should I post all the missing key definitions here or should I send you the doom3.game file every now and then? Or is it possible to set SVN permissions so that I'm able to commit just this one single file?
-
For ambient sounds (that can be heard all around the level) the s_global key has to be set to 1, but the key definition is missing in doom3.game:
<property name="s_global" type="boolean" />
What's the policy here - should all keys be added to this file as development and testing proceeds or are there other plans regarding this file?
There are several other keys that would be required (for the ingame readables for example), but it may be possible that the Entity Inspector would be flooded with all kinds of optional values that only apply to certain entities.
-
How long have they been working on this?
-
Ok, glad to hear that, I hope I can contribute more in the future. Perhaps I will even be able to add some functionality myself when I'm familiar enough with the source code.
Another question: is there some sort of todo list for DarkRadiant or a list of accepted feature requests apart from the Wishlist thread? I'm just curious about the progress and what is planned.
-
Thanks for your fast responses and updates, it's really appreciated. I feel a little strange about bugging you with these issues, I hope I'm not wasting your time here.
-
It's now possible to create a working readable in DarkRadiant, everything seems ok! Thanks for adding it!
I had another issue while doing a full compile it complained about a missing "entityinspector.h" in groupdialog.cpp:42. After chaning the string to "ui/einspector/entityinspector.h" (i.e. including the relative path) it compiles without errors.
Has this something to do with the sconscript or is this include supposed to happen this way (including the path)?
Edit: Ok, I had some trouble posting this - at first I had the word "g plus plus" within my text, which the forum didn't like at all...
Itches, Glitches & Anything Else...
in DarkRadiant Feedback and Development
Posted
I see. Thanks for explaining!
BIG EDIT: Forget what I posted here before, if you read it. I can see the advantage now - whitespace is the name of the evil...