mohij

Yes, a nice modular code is the best solution in any aspect.

Nah, I really don't want you to develop for other guys too, that was the mistake of GTK-Radiant. I just said that you shouldn't block the door for others to use DarkRadiant.

Yes, all true for you DarkMod guys, but DarkRadiant is in fact the only alive open source level editor left. If DarkRadiant specializes to much on the DarkMod, it will soon not be able to adapt to other uses anymore. If you are only interested in DarkMod, then the Doom3 engine is surely the best choice, but given that you want DarkRadiant to be able to be used by others too, you shouldn't use a dead engine.

sparhawk: The thought is good, but the advantage with Ogre is that is will evolve, which Doom3 will not. When Doom3 is (some day) open sourced, it is an engine without developers. For other projects (other than DarkMod) the switch to Ogre would surely be more appreciated because Ogre is far more generic than the Doom3 engine. And don't forget that Doom3 is a game, not a grapics engine. So you would still have to pull out the relevant parts once Doom3 is open-sourced, so that would involve far more work.

As it stands now I will work into Ogre a bit more (independent of DarkRadiant) and if everything works out well, who knows, maybe I could give it a try. But we'll see.

Crystal Space is a Game Engine. It features all parts like Network Sound Graphics and so on. But what DarkRadiant needs is only a Graphics engine. The most notable one is Ogre, the only other one I know is openscenegraph, but Ogre is simply the most famous. Feature and code wise Ogre leads the field (yeah I know that this is highly subjective), just don't do the mistake and compare it to a Game Engine, which it simply isn't, it's just a Rendering Engine (OGRE = Object-Oriented Graphics Rendering Engine). I could start listing features and design approaches but I guess that's pointless.

I don't really have any Ogre experience (DR is my first project I looked a bit deeper at). But I queue around in the community a lot. Since I would like to do something with OGE (OGE is a complete Game Engine that uses Ogre as the renderer), I will sooner or later have to have a look at Ogre anyways, but I really can't say how I will brawl. Ogre is written completely in C++, which is a big bonus. And from what I've heard the interface is extremely clean. I don't know whether Namespace has done anything with Ogre. Ask him :-)

In simple words Collada is a standard fileformat for 3d content (originally intended for exchange between apps) Wikipedia Article. The file format change would not be useful for Doom3 mappers (since Doom3 is already supported). But it would make other uses of the Radiant much simpler. So that wouldn't be a DarkRadiant, but just a Radiant task. The second thing with the external renderer would sort of "outsource" the problem. If the Radiant would for example adopt Ogre as the renderer we wouldn't have to care about rendering issues ourselves. Any feature hunt would be out of our hands, since Ogre would have to do the job (for now Ogre has pretty much all the features (with some exceptions) that Doom3 has). Of course there are other alternatives, Ogre is just the one I would prefer. And that's easier than rewriting a renderer from scatch.

I got two quite spontaneous ideas: Change the renderer to an external rendering engine (would be a lot of work, but could be worth it). I know about Namespaces ideas too, so it's just a thought. Second is changing the file structure to some standard (like collada). I guess both of those tasks are probably to hard for me atm, but tell me what you think.

I implemented this with a simple check in the Image MapExpression. According to modwiki.net those keywords could also be used as materials themselves, but that doesn't seem to be used. In fact the only keywords I found in the Doom3 materials in use are _currentRender (quite often), _cubicLight (once), _white (twice) and _flat (once). MapExpression.cpp Of course the _whatever.bmp files need to be existant, I hope someone has some sort of template for those tiled background text images (like "shader not found" or "no clip").

Small programming question: DefaultConstructor d; if (_imgName == "_black") d(GlobalRegistry().get("user/paths/bitmapsPath") + IMAGE_BLACK); else d = DefaultConstructor(_imgName); return d.construct(); This code won't work. It could be done with pointers or a temporary variable, but is there an elegant way to do it? Can I declare a class and construct it later on?

Heya, syncing fixed the bug. :-)

I got the ImagePtr thing done yesterday, it compiles and even runs. But in dynamic lightning mode everything stays black. Was there a bug that could have caused that? (so I don't hunt a bug that wasn't caused by my changes) If you want to have a look: imagePtr.zip

Thinking a bit more about return values, I wonder whether it is better to return more general objects (upcast on return) or the specific object. When returning the specific object won't have to be downcast, since you already have a child object and upcasting would happen from alone. When returning base class objects, the user of the function will perhaps have to downcast (which is generally a bad idea) and in most cases I would have to upcast it inside the functions, so that would be double word. So I'd say that returning objects as specific as possible is best. Perhaps I miss a point, so what do you think?

I guess that's an exhausted answer, thanks.

btw. Should I open a new topic for this?

What is better, Introducing a shared_ptr<Image> and another shared_ptr<RGBAImage> and using the ones I need, or only introducing shared_ptr<Image> and cast to RGBAImage when needed?

Well the DefaultConstructor is used only once (in MapExpression.cpp). The FileLoader is used more widely. So do you mean removing the baseclass and just using the Fileloader directly? When moving MapExpression.cpp over to the FileLoader, then I could also ditch the DefaultConstructor.

Ditch means remove completely? Edit: I just checked, and the FileLoader and DefaultLoader are still used.

I guess I'll get 1.4 as the final score :-) Closed the bug. I think moving this to shared_ptr isn't that complicate, so I'll guess that'll do.

I finished my exams. So I guess I could do some more coding ;-) Are the MapExpressions finished for now? - Then I'd close the bug. And what could I continue to work on then?

I'm looking in here the first time since monday and I see those good news, cool. :-) I rechecked every of those MapExpessions, and all seem to work as they do in Doom3, except the scale expression, which always produces a black texture in Doom3. But as long as nobody knows how this is meant to be used there is probably nothing we can do. Well the only other thing that comes to my mind is this shared_ptr refactoring you talked about. And I don't really know what you mean with shader stages... On Tuesday next week I will have finished my exams and can continue on something (whatsoever it might be).

@greebo: I just looked in viewvc and the closing brace is there. It seems that I somehow deleted it in my local copy, sorry for that.

One small bug in GLTexturemanager.cpp, at the very end there is a } missing.

I cleaned the MapExpression.cpp up, always have y first in for clauses, removing a lot of whitespaces and bring the scaleexpression to a usable state by inserting some error checking. MapExpression.cpp Edit: I tied out all expressions, and all seem to work. I guess I'm finished... or did I miss anything? oh, and btw. next week I won't be able to work on DR, since I will have my oral exams monday in a week and that will probably consume all my time :-(