Itches, Glitches & Anything Else...

[OrbWeaver 709]

Having some kind of texture manager is a good idea, because something has to have central responsibility for binding textures to OpenGL and getting the texture numbers for them. It is similar with display lists -- you want something to take responsibility for allocating and deleting them, rather than having every bit of code do the GL calls itself and risk causing mayhem.

 

I don't actually think your implemention is at all bad, now that I understand its purpose is to accept ImageConstructors, bind them to GL and return a GL texture number. Perhaps it should be called the GLTextureManager or something, for clarity, and the interface could be cleaned up a bit, using the split insert/find calls I mentioned, but it does perform the job of texture binding which is best practice for OpenGL programming.

 

If reference counting is required, this can be done using a combination of shared_ptr and weak_ptr (a weak_ptr is a "non-owning" pointer which does not increment the reference count but allows you to tell whether the pointed object has been deleted or not).

[greebo 131]

I got a linker error caused by references to g_FileChooser_nativeGUI, which only applied to Win32 builds, therefore I disabled these lines.

 

What are your plans regarding the file chooser? Will it be replaced in the future by a VFS file chooser? If not, I could imagine that having the native Win32 file dialog had some charm for a lot of Win32 mappers (including me, but I could live with the GTK one as well). Having the Win32 context menu during file open is one of the admittedly few advantages.

[OrbWeaver 709]

Oh damn, I knew there was something I had to check on Windows, and forgot to do it. I removed the Win32-specific dialog during the refactoring because (1) I don't like multiple code paths, and (2) more importantly, I have no idea how to add an extra "All files" option using the Win32 API.

 

The idea is that the GTK file selector should be used (this may suggest another upgrade of GTK on Win32 if the current version is not very good -- they do constantly seem to improve that dialog), but I omitted to actually do the testing to make sure the Windows build would actually work.

[OrbWeaver 709]

I just tried a complete update & recompile in Windows, and although I don't get a link error I do get a runtime assertion failure from a null shared_ptr. Great, an error which I have basically no way of debugging.

 

I might see if I can re-install/upgrade Eclipse, and maybe the GDB integration will magically start working again (for a while at least, before it magically stops working just like everything else in Eclipse).

[greebo 131]

When does it occur? I'll see if I can reproduce it with the latest SVN.

 

edit: Everything seems to work on my end.

[OrbWeaver 709]

It occurs at startup, right after all of the shader stuff gets printed and after the main window has been displayed.

[greebo 131]

Strange, nothing here.

 

I even tried to change the background image, but everything seems ok. Maybe there is an old module residing in your install folder (textures.dll)? I removed that one lately.

[OrbWeaver 709]

No, I tried with a completely fresh checkout (and re-install of Eclipse for good measure) and the behaviour is exactly the same.

 

Oh well, since it only seems to affect me and there is nothing I can do about it anyway (GDB is useless on Windows), I might as well forget about it and hope it goes away with some future change.

[greebo 131]

I will do a full compile on angua's machine and see if it's reproducible there. I assume you cleared the usual suspects (user.xml and consorts)?

[OrbWeaver 709]

I will do a full compile on angua's machine and see if it's reproducible there. I assume you cleared the usual suspects (user.xml and consorts)?

 

Actually I didn't clear out the local copy in Application Data, that would be worth doing as well.

[angua 6]

Everything works fine for me, the only thing that I noticed was that after starting to load bonehoard, it printed this on the console:

 

Open file C:\games\doom3\darkmod\maps\bonehoard.map for read...success

Open file C:/games/doom3/darkmod/ for read...failure

 

The map was loaded and I've had no problems so far.

[OrbWeaver 709]

Deleting the local settings solved the crash. However, I am getting a GTK assertion failure when trying to show the Background Image dialog (something about a theme not being installed). This may be because I have not yet copied all of the right GTK libraries into the installation folder.

[greebo 131]

I get that GTK assertion as well. I thought it was about my specific GTK+ setup, but it seems that there are some non-standard items used here?

[OrbWeaver 709]

The only new widget in this dialog is the file chooser button, perhaps that is not supported in the Windows version of GTK we are using. I will have to investigate.

[OrbWeaver 709]

Well some progress at least -- apparently the Radiant designers decided that GTK Warnings should be raised as fatal assertion failures, which I have corrected. This particular issue now just displays as a warning in the console, but the dialog itself is shown.

 

This now reveals the next problem, a shared_ptr assertion failure when you actually activate the background image. I think this is happening because the first time you enable the option, the image filename is blank which is causing whatever provides the image texture to choke.

[greebo 131]

Ok, this is my part I guess. You say, you have the text entry field empty and tick the option when the shared_ptr assertion arises?

[OrbWeaver 709]

Yes, that's what it looks like. I guess it is just a simple issue of making sure the overlay code can cope with a non-existent image path including the empty string.

[greebo 131]

I will take care of that. Is it urgent?

[OrbWeaver 709]

No, not really.

[OrbWeaver 709]

I have fixed this in my local environment, but not committed anything to SVN in case you are making changes.

[greebo 131]

Please commit it, I'm not yet done with my changes (I'm currently working on the "manipulation cancelling") and therefore haven't looked into the Overlay code.

[greebo 131]

To announce this here as well: Transformation operations can now be cancelled by pressing ESC.

 

I had to add a method to the UndoSystem as well, as UndoOperations are started as soon as the mouse button is clicked (which produced an annoying "empty" operation in the undo stack).

[greebo 131]

The Scale Manipulator is now working again (for brushes, it wasn't broken for patches) - the face normal vectors weren't normalised after the transformation matrix had been applied.

[greebo 131]

I committed another change (resolving issue #102): zero-sized brushes are removed now from the scene and a warning is emitted in the console on this event.

[OrbWeaver 709]

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). Whatever FramedTransientWidget does, I'm not entirely sure it will be something that is used often enough to justify a whole class for it. Some of my own classes in gtkutil are going to need to be merged as well I think, to avoid too much proliferation.

 

There is actually a C++ GTK library, called gtkmm (abbreviation for "GTK--" I think), which might be worth investigating, but it would be some considerable effort to port everything over to use it.

 

Incidentally, bordered frames are best avoided. The GNOME HIG (which I try to follow for GUI design) has a useful explanation of them here:

 

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