Jump to content
The Dark Mod Forums
Sign in to follow this  
greebo

Background Image

Recommended Posts

I suggest making an ImageGDK subclass of Image, which has a constructor that accepts a GdkPixbuf* and copies the values. Then you would just do

 

GdkPixbuf* pb = // do something to get a GdkPixbuf
ImageGDK img(pb);
functionThatRequiresAnImage(img); // pass on the Image

Share this post


Link to post
Share on other sites

I somehow need an LoadImageCallback as well to incorporate it into the current TexturesMap class, so this has to be placed somewhere as well.

Share this post


Link to post
Share on other sites

Oh yeah, I see what you mean. The TexturesMap does not store Images, it just stores names and Callbacks which by default are an encapsulation of QER_Load_Image which loads the named image from the VFS.

 

The first thing that comes to my mind is to create your image subclass as its own callback, so it implements both Image and LoadImageCallback. When its loadImage function was called, it would just return itself as an Image pointer.

 

The problem is that the halfwit who implemented LoadImageCallback didn't understand about virtual functions and C++ interfaces, and wrote it using the stupid function pointer style. You would either need to fix this by changing it to an interface with pure virtuals (preferred), or concoct some system of pointers to a static function that would accept your subclass and return an Image* pointing to it (yuk).

Share this post


Link to post
Share on other sites

Ok, I've got a working version of the Overlay module and I would like to merge my changes back together with the TexturesMap refactor.

 

Do you want me to wait until after the bugfix release (0.8.1)?

Share this post


Link to post
Share on other sites
Do you want me to wait until after the bugfix release (0.8.1)?

 

That's probably the best idea.

 

In case you don't already know, when working on a branch you should frequently merge in changes from the trunk, to keep yourself in sync. It is particularly important to do this right before you switch back to the trunk and try to merge in your branch itself.

Share this post


Link to post
Share on other sites

I merged in the changes from the trunk into the overlay_plugin branch. The changes were orthogonal (apart from a small change to user.xml), so this wasn't a problem. However, I'm performing a fresh compile to double-check.

Share this post


Link to post
Share on other sites

I can't get DR to compile. I get the following errors.

 

/usr/include/boost/multi_index/detail/index_iterator.hpp:162: error: ‘node_base_ type’ was not declared in this scope

/usr/include/boost/multi_index/detail/index_iterator.hpp:162: error: ‘bnode’ was not declared in this scope

/usr/include/boost/multi_index/detail/index_iterator.hpp:163: error: ‘serializat ion’ has not been declared

/usr/include/boost/multi_index/detail/index_iterator.hpp:163: error: there are n o arguments to ‘make_nvp’ that depend on a template parameter, so a declaration of ‘make_nvp’ must be available

scons: *** [build/debug/radiant/main.o] Error 1

Share this post


Link to post
Share on other sites

You are compiling under Linux, I guess? Perhaps there is the boost multi_index package missing on your system? I needed this for the MRU menu refactor a few weeks ago.

Share this post


Link to post
Share on other sites
You are compiling under Linux, I guess? Perhaps there is the boost multi_index package missing on your system? I needed this for the MRU menu refactor a few weeks ago.

 

Yup, I'm under linux. I'll look into that, thanks. :)

Share this post


Link to post
Share on other sites

I switched to your branch to test the changes, and here are my comments so far:

 

* This really needs to be more obvious than a page in the Preferences dialog - changing or toggling background images is something the mapper will want to do frequently, so it needs to be more accessible. Do you think it would be possible to add a toolbar to the Ortho window, like you did with the textures view, and have a button that brings up a dedicated dialog for background image settings? Failing that, a dialog accessed through the View menu would be fine.

* Could "fit to window" or "actual size" be selectable options? Mappers may wish to keep the original aspect ratio, rather than scaling the image proportionally to the window.

* I can't figure out the "image offset" sliders at all.

 

All my UI ideas for this are based on the Background Image functionality in Blender, in case you want an example.

Share this post


Link to post
Share on other sites
* This really needs to be more obvious than a page in the Preferences dialog - changing or toggling background images is something the mapper will want to do frequently, so it needs to be more accessible. Do you think it would be possible to add a toolbar to the Ortho window, like you did with the textures view, and have a button that brings up a dedicated dialog for background image settings? Failing that, a dialog accessed through the View menu would be fine.

I would dislike adding a toolbar to the orthoview, because it would decrease the effective working size just for one single icon. I'd rather place it on the top toolbar, there should be enough space left.

 

However, this requires to create a separate dialog, but this should be feasible. I've been thinking several times about creating a new interface to enable plugins to easily create and show dialog windows / message popups / etc.

 

* Could "fit to window" or "actual size" be selectable options? Mappers may wish to keep the original aspect ratio, rather than scaling the image proportionally to the window.

Fit to window is the default right now (scale = 1.0), I will add the other one.

* I can't figure out the "image offset" sliders at all.

The sliders are measured relatively to the image size. An X shift of -1.0 would mean that the texture is completely shifted out of sight to the left. This way every possible position is easily accessible without going into pixels, but I can change it, if you want me to. :)

 

All my UI ideas for this are based on the Background Image functionality in Blender, in case you want an example.

I know that one. Blender is also resizing the image when zooming in/out. Is this wanted behaviour for DarkRadiant? Mr. Mike originally suggested this feature, so what does he say about this?

Share this post


Link to post
Share on other sites
I would dislike adding a toolbar to the orthoview, because it would decrease the effective working size just for one single icon. I'd rather place it on the top toolbar, there should be enough space left.

 

I would agree, except that it won't be the only icon -- the "view models by bounding box" button could also go here, when implemented, as could the "show all light radii", "show light texture overlays" and "show speaker radii" buttons. I suppose these could just go on the top toolbar, but there is a danger it would get too long and be unusable for people with lower resolution displays, unless it was wrapped into two toolbars (creating the same loss of vertical space). I guess it is not important right now, so I guess you can just put it on the top toolbar but be aware we might have to move some icons onto a new orthoview toolbar later on.

 

EDIT: actually, forget it, there's loads of room on the top toolbar. I was thinking of the left toolbar, which has considerably more icons on it.

 

The sliders are measured relatively to the image size. An X shift of -1.0 would mean that the texture is completely shifted out of sight to the left. This way every possible position is easily accessible without going into pixels, but I can change it, if you want me to. :)

 

I don't have a problem with it, it's just not very intuitive and probably won't be used much for that reason. Since you can align the map with the image just by dragging the map with RMB, there probably won't be much need to actually move the image.

 

I know that one. Blender is also resizing the image when zooming in/out. Is this wanted behaviour for DarkRadiant? Mr. Mike originally suggested this feature, so what does he say about this?

 

I think both zooming and not zooming the image could be useful, with a slight preference for zooming it (because you might be using an architectural plan, for example, which needs to stay the same scale as the map). Maybe you should make the image similar to geometry, in that it is specified with a size and position and always maintains its location in 2D space. Is your overlay quad relative to the window, or does it have a definite 3D location?

Share this post


Link to post
Share on other sites
I would agree, except that it won't be the only icon -- the "view models by bounding box" button could also go here, when implemented, as could the "show all light radii", "show light texture overlays" and "show speaker radii" buttons. I suppose these could just go on the top toolbar, but there is a danger it would get too long and be unusable for people with lower resolution displays, unless it was wrapped into two toolbars (creating the same loss of vertical space). I guess it is not important right now, so I guess you can just put it on the top toolbar but be aware we might have to move some icons onto a new orthoview toolbar later on.

No problem, if there are some more useful buttons, this won't be much of a problem. A few changes in the GlobalXYWnd class and the toolbar is there. :)

 

I think both zooming and not zooming the image could be useful, with a slight preference for zooming it (because you might be using an architectural plan, for example, which needs to stay the same scale as the map). Maybe you should make the image similar to geometry, in that it is specified with a size and position and always maintains its location in 2D space. Is your overlay quad relative to the window, or does it have a definite 3D location?

The quad has 3D coordinates, which are being calculated and passed by the XYView render function. If we're going to position the image at absolute map coordinates, this could impose some problems, because the texture it's not draggable or anything, hence you'd have to enter the coordinates by hand (or we find a different solution). Another problem with the absolute position would be that the coordiantes would have to be recalculated everytime the XY viewtype is being changed to XZ or YZ (I think).

 

As for the zooming: each xy view has its own scale variable, which could be passed to the Overlay module. The scaling could be added to the other scaling - I think this would work.

 

BTW, the "Keep Proportions" setting is now on the latest branch SVN. :)

Share this post


Link to post
Share on other sites
However, this requires to create a separate dialog, but this should be feasible. I've been thinking several times about creating a new interface to enable plugins to easily create and show dialog windows / message popups / etc.

 

Just a point about plugins: although I have been keen to split out modules into external DLLs, this doesn't necessarily mean that every single piece of functionality needs its own separate module. Although you seem to be getting on fine in this case, it is perfectly acceptable to put stuff into the main binary if it would be most suitable there -- most GTK and core GUI stuff would fit this category.

Share this post


Link to post
Share on other sites
BTW, the "Keep Proportions" setting is now on the latest branch SVN. :)

 

Just checked it out, that is a big improvement.

 

Incidentally, is the alpha slider supposed to go from 0 to 1.0? Mine only goes up to 0.8 and the "filled in" part of the slider does not reach the "knob".

Share this post


Link to post
Share on other sites
Incidentally, is the alpha slider supposed to go from 0 to 1.0? Mine only goes up to 0.8 and the "filled in" part of the slider does not reach the "knob".

Yep, this was on my end too and it's fixed now.

 

Also on SVN: the image is zoomable together with the orthoviews, just toggle the checkbox in the preferences.

Share this post


Link to post
Share on other sites
I know that one. Blender is also resizing the image when zooming in/out. Is this wanted behaviour for DarkRadiant? Mr. Mike originally suggested this feature, so what does he say about this?

 

I think Orbweaver has already covered this but I'll reiterate; I do think it's important to have image resizing linked to the zoom controls. Infact I'm finding it hard to think of a reason of why you'd want it any other way but I'm sure there are times it's useful, so having the option would be good. I feel it should default to scaling though. Btw, I can't wait to try this out, sounds like an awsome job guys :)

Share this post


Link to post
Share on other sites

I turned the zooming option on by default and increased the maximum image scale, so that the image can be magnified over a large part of the map.

 

The commits from trunk are all merged into the overlay_plugin branch - I will just wait for Orbweaver to wave the flag before I move the new features into the trunk. :)

Share this post


Link to post
Share on other sites

I haven't started on the GUI for this yet, but when I do I will probably look at moving the overlay code into the main binary at the same time. I don't think it makes sense to have a separate module for something which is only ever accessed from the main GUI (not by other modules) and has no requirement to be changed on a per-game basis.

 

If we look at the existing modules, we can see that they generally fall into two main categories. First, there are those blocks of functionality which potentially vary from game to game and may need a different version (such as the mapdoom3 plugin). Secondly, there are those modules which provide services to several other modules, such as the entity class manager or the texture cache.

 

The problem with putting core GUI features into modules, apart from the work involve in defining an interface and hooking up the main GTK components to interact with it, is that it potentially increases the overall size of the package, because each DLL has to have its own copy of the GTK and other libraries linked into it (which is essentially a copying operation).

 

Note that I am talking about "modules" here -- it may be appropriate for the "plugins" to implement GUI features since these are optional components that might not be installed in all DR builds. For instance, I would quite like the Objectives Editor to be a plugin, so that it can simply be omitted for D3-only builds, but for that I think we will need to improve the plugin interface to support more flexibility in installing GUI features.

Share this post


Link to post
Share on other sites
The problem with putting core GUI features into modules, apart from the work involve in defining an interface and hooking up the main GTK components to interact with it, is that it potentially increases the overall size of the package, because each DLL has to have its own copy of the GTK and other libraries linked into it (which is essentially a copying operation).

Ah, didn't know about the package size issue, doesn't make too much sense then to move stuff relying on GTK into the modules.

 

The benefit of having 1) a cleaner interface and 2) a compile time decrease when moving stuff into the modules does still apply, doesn't it?

 

Moving the Overlay module into the main codebase won't be much of a problem, as its code is quite isolated.

Share this post


Link to post
Share on other sites
Ah, didn't know about the package size issue, doesn't make too much sense then to move stuff relying on GTK into the modules.

 

The package size is not a HUGE problem, but it is not really one worth introducing for no particular gain (sometimes a module does need GTK, such as the mapdoom3 plugin to display the progress dialog).

 

The benefit of having 1) a cleaner interface and 2) a compile time decrease when moving stuff into the modules does still apply, doesn't it?

 

Using a module and having a clean interface are two separate things -- the module could have either a good or a bad interface, depending on how it was written (*cough*, qerplugin, *cough*). You can just as easily have a clean object-oriented interface while having things in the main binary, which is what I have attempted to do with all of the ui stuff (entityinspector etc).

 

The compile time decrease is certainly relevant, but in the case of the overlay plugin there is probably so little code involved that the reduced time to compile the main binary is almost certainly negligible (and possibly outweighed by the increased time to link in GTK and other libs into a new module). Moving stuff like TextureCache or SceneGraph into separate modules probably would have a positive effect on build times (although the last two attempts I made to move scenegraph failed miserably with assertion failures about the typesystem).

Share this post


Link to post
Share on other sites

While implementing the dialog, I noticed that you don't actually have to call the show() method and siblings, instead you just set the registry key and it happens automatically, which I think is pretty cool.

 

I guess this means that the other functions don't really need to be part of the public interface, because they are called automatically in response to a registry key change -- or are they used for something else besides?

Share this post


Link to post
Share on other sites

No, they're just there in case you don't want to set the parameters directly and not via the RegistryKeys. It's your choice if you want to keep or remove them. :)

Share this post


Link to post
Share on other sites

I think I screwed up the Overlay image handling by introducing the TexturePtr, so it's not possible to change the background image (possibly because the TexturePtr are not properly released). I will look into it soon. :)

Share this post


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.

Sign in to follow this  

×
×
  • Create New...