Jump to content
The Dark Mod Forums

Itches, Glitches & Anything Else...


Recommended Posts

I notice that you have created a number of metawidget classes in gtkutil -- go easy on this, we don't want a class for every possible combination of GTK widgets, only the ones which are very commonly used and occur together (like a scrolled window inside a frame, used for packing TreeViews).

...

http://developer.gnome.org/projects/gup/hi...ols-frames.html

 

Ok, will have to read through this in the near future before I touch another dialog. ;)

 

I must admit that I appreciated moving sequences of gtk_blah() calls into the gtkutil library, because it keeps the "top-level" UI creation code clean and easier to read. I think I used most of these at least twice, but I can't be sure right now.

 

Has this considerable impact on executable size or compile times?

 

However, I will try to keep things down to a necessary level. :)

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

Ok, will have to read through this in the near future before I touch another dialog. ;)

 

Well worth doing, it is an interesting read (and amusing in places as well, they can be quite creative with their "stupid example" dialogs).

 

Has this considerable impact on executable size or compile times?

 

Probably not, because the class will just reduce to the same sequence of gtk_xxx() calls you would have used anyway. However, it does result in a proliferation of classes and class files that will probably be forgotten about (and hence re-invented) in the future, many of which probably perform similar functions. The chances are that in future, you or another developer are not going to check to see whether there is a metawidget for LeftAlignedFrameWithABoldLabel before just doing it straight from GTK.

Link to post
Share on other sites

I reactivated the broken (or half-finished) Entity selection mode to address issue #62. Analogously to Vertex, Edge and FaceSelection it's now possible to toggle an EntitySelection mode, which limits the select operations to entities. I had to add a check to prevent the worldspawn entity from being selected here, as this is the entity.

 

SneaksieDave, does this resolve the issue for you or do you still think a type sorting of the possible selectables is required?

Link to post
Share on other sites

I guess it depends on how far you guys are willing to go. ^_^

 

IMO, having it always prioritize (as with DoomEd) non-brush entity selection first is most desirable. But, assuming this change comes with a hotkey toggle(?), it's definitely a nice and needed stand-in, in the meantime (or in the event that the full support never makes it in).

 

Maybe the 'full' version is another for the suspended pile? Hopefully there's a way to distinguish 'suspendeds' so that they don't get lost with 'closeds'?

Link to post
Share on other sites
IMO, having it always prioritize (as with DoomEd) non-brush entity selection first is most desirable. But, assuming this change comes with a hotkey toggle(?), it's definitely a nice and needed stand-in, in the meantime (or in the event that the full support never makes it in).

It's a command, so its hotkey can be customised via the shortcut editor in no time.

 

Maybe the 'full' version is another for the suspended pile? Hopefully there's a way to distinguish 'suspendeds' so that they don't get lost with 'closeds'?

I'm sorry? What do you mean here?

Link to post
Share on other sites

'Full' was referring to the original request - that entities always have higher selection priority than brushes, as in DoomEd - as opposed to an entity selection mode.

 

Suspended was the suggested state for the original request entry; since it's not really addressed, but may not ever be addressed. Closing it just makes us forget the request, so we need another state. Kind've "closed for the time being" or "suspended indefinitely". If we just close it, it will be buried.

 

I know another entry has been marked 'suspended', but it's also 'closed', so it won't come up in standard searches.

Link to post
Share on other sites
'Full' was referring to the original request - that entities always have higher selection priority than brushes, as in DoomEd - as opposed to an entity selection mode.

I'll look into it, perhaps I can come up with something without having to completely rewrite the selectionpool handling.

Link to post
Share on other sites

I think this cannot be done easily and requires quite some changes. The SelectionPool starts to act strangely if I try to populate it with entities first. I will downgrade this issue to "acknowledged", so that it doesn't get buried.

Link to post
Share on other sites

OrbWeaver, I noticed that the map::countSelectedBrushes() method does not actually count the brushes only, but takes the patches into account too (it checks for Node_isPrimitive == true).

 

This is ok I guess in the context of func_static creation (which can consist of patches as well), but I needed it to set the sensitivity of the "Remove selected Brushes" checkbox in the new patch creation dialog.

 

Can I rename this method to countSelectedPrimitives() so that I can write another walker that only counts the brushes without patches?

Link to post
Share on other sites

Ok, renamed. The new dialog is now on SVN and allows to choose whether the selected brush should be deleted from the scenegraph after patch creation (Is only clickable, if exactly one brush is selected):

 

patchcreatorfa2.th.jpg

Link to post
Share on other sites

I have merged in the refactor of the model plugin which removes the duplicate PicoModel and PicoSurface classes and replaces them with the RenderablePicoModel/Surface classes which are used by the model preview. This is a work in progress, and there may still be problems with model rendering (I know there is something screwy going on with the texture coordinates in lighting mode).

Link to post
Share on other sites

I get a crash on DarkRadiant shutdown at rev. 1006 (I don't know exactly where it crashes). The crash also exists in the head revision.

 

I think it's the erase(i) in the GLTextureManager::getBinding() loop:

// This is explicitly allowed by the std::map iterator invalidation
	// semantics, which specify that erasing an element from a map does not
	// invalidate any other iterators.
	if (i->second.unique()) {
		_textures.erase(i);
	}

Your comment is correct concerning other iterators, but the following i++ in the loop increment statement is still referencing this very iterator that has just been deleted >> crash.

 

Shall I revert the loop to my version or is there a more elegant solution to deleting map elements in a loop?

Link to post
Share on other sites

Yes, it solves the problem. I already ran into this problem a few weeks ago and did some googling about how to circumvent this issue when deleting items in a loop and found this suggested algorithm with the postfix ++ on thescripts.com, I think.

Link to post
Share on other sites

Don't we have a reentrancy issue here?

 

1. checkBindings() is called.

2. Iterator finds a shared_ptr which is unique, and deletes its entry from the map

3. CShader destructor is called

4. checkBindings() is called.

5. Iterator finds a shared_ptr which is unique, and deletes its entry from the map

6. CShader destructor is called

7. checkBindings() is called()

8. ...

9. (all before the first CShader has finished destructing)

Link to post
Share on other sites

This should not happen, because the checkBindings() just checks the TexturePtr's uniqueness and not the ShaderPtr's (CShader).

 

The checkBindings() is called in the CShader::~CShader destructor and is supposed to remove unused Textures from OpenGL. If the GLTextureManager finds anything unused, it destroys the Texture object, not the Shaders, therefore it should not be fired recursively.

 

Does this actually happen or is this a general question?

Link to post
Share on other sites

I've just spent this year's book budget on these two:

 

OpenGL® Programming Guide: The Official Guide to Learning OpenGL®, Version 2

Mathematics for 3D Game Programming & Computer Graphics

 

It will take a while till they've been shipped here from the U.S. but I look forward to them. Hopefully I will have time to read them as well next to writing my diploma. ;-)

Link to post
Share on other sites

It's usually the best thing to start off with a book that introduces all the capabilities of a language. Strangely enough, I've done this only twice so far (one time with PHP3 back in 2000 and with C++ last summer, if reading that zdnet tutorial does count). ;)

 

All the other stuff consisted of learning-by-doing and scraped-together knowledge like I do now with GTK (the tutorial is really covering the very basics only). Sometimes this is sufficient, sometimes not. Given the lack of feedback you get when fiddling around with OpenGL (no compiler, no parser or error display) I thought it was best to buy these, maybe the time reading those will even pay off.

 

Btw, how long have you been coding in C++?

Link to post
Share on other sites
It's usually the best thing to start off with a book that introduces all the capabilities of a language. Strangely enough, I've done this only twice so far (one time with PHP3 back in 2000 and with C++ last summer, if reading that zdnet tutorial does count). ;)

 

I agree, and OpenGL is one API which is certainly not short of capabilities.

 

Btw, how long have you been coding in C++?

 

I started C++ at the same time I took on DarkRadiant, so that would make it about a year I guess.

Link to post
Share on other sites
I started C++ at the same time I took on DarkRadiant, so that would make it about a year I guess.

Now that's surprising for me, I thought you've been coding C++ for a living. :) You've been coding something else before I assume?

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