Jump to content
The Dark Mod Forums

Itches, Glitches & Anything Else...


Recommended Posts

And yet again, another question. I found this global:

 

CPlugInManager g_PlugInMgr;

CPlugInManager& GetPlugInMgr()
{
 return g_PlugInMgr;
}

And the function below returns it, obviously. Is it an improvement doing this with a static like this:

CPlugInManager& GetPlugInMgr()
{
 static CPlugInManager _plugInMgr;
 return _plugInMgr;
}

or is it not worth the hassle? Or should this be done in a completely different way?

Link to post
Share on other sites
  • Replies 1.9k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Since I've stumbled over the same issue (and even tracked a needless bugreport), I've just commited the following:   Index: def/tdm_mover_base.def ===================================================

That's a pretty ambitious project that will require almost every trick in the book. I can sort of envision how you might use fences, skyboxes, and archways to assist with compartmentalization but over

I'd say it is perfectly doable if you make it almost planar, or with only mild height differences. The images below show how I would do it:   See how the mountains and houses always block the view f

Posted Images

This is something I'm thinking about for some days now and I better get it off my chest, so sorry for being off-topic.

 

What about us implementing the current DR ToDo-List and heading off to SDK coding afterwards? Don't get me wrong, I really enjoy coding on DarkRadiant (I'm learning a lot) and I believe the editor to be really important for TDM's success, but if we extrapolate the current Overall MOD Progress™ into the next year or so, I'm afraid we end up having a top-gun editor with the mod staying somewhat behind. What do you (Orbweaver, Crispy) think?

Link to post
Share on other sites
This is something I'm thinking about for some days now and I better get it off my chest, so sorry for being off-topic.

 

What about us implementing the current DR ToDo-List and heading off to SDK coding afterwards? Don't get me wrong, I really enjoy coding on DarkRadiant (I'm learning a lot) and I believe the editor to be really important for TDM's success, but if we extrapolate the current Overall MOD Progress into the next year or so, I'm afraid we end up having a top-gun editor with the mod staying somewhat behind. What do you (Orbweaver, Crispy) think?

 

Spring, Spar and I were discussing this and thought we would ask Crispy to come and do some main Mod coding for the time being. We'll see how things go from there. :) A month from now, we can re-evaluate the situation and see if we need to bring one or both of you guys in. :)

Link to post
Share on other sites

I have no problem with it. I myself will mainly stick with DarkRadiant for the time being (although I could help out at a stretch, particularly with the Linux side of things), as knowing me I would probably want to redesign everything anyway if I tried working on the main mod, but if either you or Crispy wanted to split your time between the two projects that sounds perfectly reasonable to me.

 

I think we should produce a list of absolutely must-have features for 1.0, with other things being "nice-to-haves" that can wait until after the main release.

Link to post
Share on other sites

I can perfectly live with any decision and I agree with having a roadmap to DarkRadiant 1.0, which should be covering all those things to make DarkRadiant the better DoomEdit (and the latter completely obsolete).

 

I'm not sure if I would be much of a help with the main mod, but I will try at some time, probably around the time DarkRadiant 0.9-1.x or a bit earlier. I'm curious how much different SDK coding would be in comparison to the stuff I do now.

 

Thanks for sharing your thoughts though, now I'm off to Eclipse again :)

Link to post
Share on other sites

Sounds good guys.

 

My only request would be to have two coders working on DR at all times, mainly because I think it's good to have two heads working things out. Orb, you and greebo have been batting things out of the park on Dark Radiant left and right. :) I think you guys work splendidly together.

 

That being said, I think it would be fine for you guys to pick at some smaller projects on the main mod, but keep DR as your primary focus. Crispy could switch primary focus to the main mod...and contribute to DR as time permits.

 

I'm still combing the universe for more coders...with very little luck, but if you guys happen to personally know some coders who would like to help, please send them our way. :)

Link to post
Share on other sites
Crispy could switch primary focus to the main mod...and contribute to DR as time permits.

Okay. will do. Guess I should get CVS set up.

 

I'm afraid I haven't been of much use, what with one thing and another... hopefully I can be more productive if I'm not battling template spaghetti. :)

 

What do you guys want to do about the draggable light centre? I've had a few runs at it and I'm no closer to a solution than when I started, so you may want to reassign it. (IMO it's not that important anyway, but then again maybe I'm wrong - I don't know what the DR workflow is like in practice, not having built a map.)

 

I'm still combing the universe for more coders...with very little luck, but if you guys happen to personally know some coders who would like to help, please send them our way. :)

I did have a friend interested, but he lost interest pretty quickly after finding out that all our local stores had no copies of Doom 3. To be honest I think he would have lost interest quite quickly anyway; he's an excellent programmer but he does suffer from a lack of focus, so he tends to abandon most projects half-finished when he's learnt all he can from the experience. It's both his greatest strength (he covers a lot of ground) and his greatest weakness (he never gets anything done)!

 

Next year (when uni starts up again) I might approach some classmates, but I don't think any of the truly capable programmers among them are interested in Thief. We'll see.

My games | Public Service Announcement: TDM is not set in the Thief universe. The city in which it takes place is not the City from Thief. The player character is not called Garrett. Any person who contradicts these facts will be subjected to disapproving stares.
Link to post
Share on other sites
he's learnt all he can from the experience. It's both his greatest strength (he covers a lot of ground) and his greatest weakness (he never gets anything done)!

 

LOL! I was pretty similar when I was younger, and to some extent I still am. On the other hand I had a friend, who was a pretty bad coder, but rather stubborn. So his programms were bloated and slow, but they worked and got finished eventually. :) Ideally a mixture of both would be the best. :)

Gerhard

Link to post
Share on other sites
What do you guys want to do about the draggable light centre? I've had a few runs at it and I'm no closer to a solution than when I started, so you may want to reassign it. (IMO it's not that important anyway, but then again maybe I'm wrong - I don't know what the DR workflow is like in practice, not having built a map.)

 

Don't worry about it for now. Although I found this feature useful in DoomEdit, no other mappers have complained about it so it probably isn't that much of a priority. It is possible (i.e. inevitable) that the light code will be rewritten at some point which might make it a lot easier to add this feature.

Link to post
Share on other sites

I just found a section in selection.cpp, that is responsible for the selection modes (Shift-Click, Alt-Shift-Click and so on) and what happens for each of the these.

 

It's not trivial to change the (hardcoded) modifier flags, as the actual selection behaviour depends on the control structures like switch and if conditions but it would definitely be feasible to alter the controls.

 

This section is quite interesting for me and I will continue to document it. I just thought I should drop a note here, because this reminded me of the "Radiant-style vs. Blender-style controls" discussion we recently had.

Link to post
Share on other sites

The reorganised SelectionSystem has been committed this afternoon, hopefully I didn't miss anything and everything compiles fine. I reorganised quite a bit, removed some unused code, changed some names to better fit the conventions, removed a global and added approx. a megabyte of comments.

Link to post
Share on other sites

I don't fully understand it neither, but at least I could learn a lot about the selection system and how the manipulators are used. The next thing I will document is the file patch.cpp, as the information about how the control vertices are handled will come in handy for the light center.

Link to post
Share on other sites

I'm somehow unable to find the function bool patch_filtered(Patch& patch); anywhere in the codebase.

 

There is this forward declaration in patch.h that refers to this function, but it isn't declared anywhere. Strangely enough, everything is compiling fine, so it has to be somewhere.

 

Same for add_patch_filter. Exactly 1 Match in the whole darkradiant/ source tree.

 

Is there something I missed?

Link to post
Share on other sites

Is it ever used? It is safe to forward declare something that doesn't exist if the object is never actually used.

 

I suspect this is a function that I removed as part of the new filter system. If it is definitely not called, you can remove the forward decl.

Link to post
Share on other sites

Ah, it is used in Patch::updateFiltered() but this function itself is not called anywhere. This explains everything.

 

I thought, the compiler would immediately stop if the actual implementation is missing. Good to know.

Link to post
Share on other sites
I thought, the compiler would immediately stop if the actual implementation is missing. Good to know.

 

The compiler doesn't care about the implementation as long as there is a declaration. It is the linker's job to match up function calls with their implementations, which it will only try to do if the function is actually used.

Link to post
Share on other sites

Just committed the reorganised patch files. I again added tons of comments, some sure will be helpful, some maybe not :)

 

I also removed Quake3 and Wolfenstein stuff from plugins/entity, as I assumed them to be unneccessary.

 

I'm still not entirely sure where to start with the light center, but I'm (slowly) getting there...

Link to post
Share on other sites
  • 2 weeks later...

What's up with those tons of warnings

warning: -fPIC ignored for target (all code is position independent)

I did a quick google on this warning, but received nearly nothing. What's position independent code anyways?

Link to post
Share on other sites

PIC is a way of creating code that doesn't rely on a specific memory location. This means that you can move the assemblycode from one place to another without any changes, because the compiler will use relative addressing instead of taking immediate address operands.

Gerhard

Link to post
Share on other sites

Orbweaver, could you try to open a large map like askave.map or bonehoard.map? My latest build crashes after map load with a singletonmodule assertion error (still referenced at shutdown). Can you reproduce this?

 

It works fine with DR 0.7.1.

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