what about an utility to edit *.imageset files

[baxissimo]

@Martignasse: If you hit rock ground with this, let me know. This is a loose end I would like to see tied up properly some day. Don't go python if you can make solid c++

@centipede, why do you say that? Personally I think if the tool can get done faster using Python, why not use python? wxPython is quite mature, and you can use OpenGL in it too, via python OpenGL bindings. So the result could look exactly like it would using C++ wxWidgets + OpenGL. I doubt speed of execution will ever be a bottleneck for this kind of tool.

Anyway, just curious, since it was tinkering with your python imageset editor that originally sold me on the idea of writing tools in Python.

[centipede]

True, true. Half the reason for saying so was probably pure encouragement. The other half originates in the fact that GTK may have been a bad choice. When I zoom in a couple of times on the image, the utility gets heavy. My guess is that GTK (or actually GDK) uses some sort of resize algorithm which is clearly too overambituous, e.g. filtered rescale using pure ansi-C. Had I chosen to use OpenGL for handling images, it would have had wings for sure, Python or C++.

If I were to make it now, I would stick to FalagardLook as the only supported look and made a much more generic approach.

[centipede]

unfortunatly, my computer just dead last week
should be fixed this week... i hope

Alive? I'm hacking on a little utility - this time in CEGUI - that you could perhaps be implemented in some other utility.

[centipede]

Are you working in CEGUI?

Here's the first few stabs at something akin to a skin tool...
http://artcamilla.dk/centipede/vaultage ... or-0.2.zip

Executable is in Debug. Don't expect anything, I have only a few hours of experience with cegui.

Could end up in Testaskin too, I suppose.

EDIT: Try scaling and moving with the middle button / mousewheel

[lindquist]

I love it

[centipede]

Starting to save simple xml imageset files using tinyxml.. http://artcamilla.dk/centipede/vaultage ... -0.2.1.zip

Who said c++/cegui wasn't for rapid coding.

[centipede]

Hmm. Before I do something really idiotic:

I need a dataformat for working live on the Falagard element setting. I guess - under the circumstances - that a slightly more ingenious solution than making my own structures would be to use the ones... in the Falagard source! How much credit do I get for such an inspired idea?

Is there a quick-and-dirty way to read/write a Falagard... "world"? And how much would that tie me into the codebase of CEGUI?

[baxissimo]

The other half originates in the fact that GTK may have been a bad choice. When I zoom in a couple of times on the image, the utility gets heavy. My guess is that GTK (or actually GDK) uses some sort of resize algorithm which is clearly too overambituous, e.g. filtered rescale using pure ansi-C.

Hmm. I find it hard to believe that GTK wouldn't have a function for nearest-neighbor resize, since it's butt-simple to implement. But I suspect the real problem is perhaps zooming then entire image when only a portion of it is actually visible. The complexity of zoomed display should always be O(number of pixels on screen) not O(number of pixels in full zoomed image). But that requires you use something like a stretch-blit rather than a complete image zoom followed by a 1:1 blit. Dunno how to do that in GTK, but I have to believe it's possible since stretch-blit is supported by just about every low-level graphics system known to man.

Anyway, it's irrelevant since I don't really like GTK either.

[centipede]

The problem with GNU coders: You just can't tell. I respect their goals and zealousness (really) but not how they programmingwise have become the equivalent of M$.

http://artcamilla.dk/centipede/vaultage ... -0.2.2.zip

Refactored the code, moved gui-instantiation to Layout file and started to prepare for a Project, Imagery and a Look'n'feel section of the program.

As you know, I have other projects that I'm keen on. Now I'll let this one go for a few days. In the meantime, if somebody else wants to play with it, by all means have fun (or perhaps suck it up into some other CEGUI-based project). I have a good angle at how to handle the setup of look'n'feel properties in a userfriendly way but that must wait.

[martignasse]

hi centipede,

wow, i'll look into that

[centipede]

I have a bit of time today, so if you post any changes, I'll take it from there

[martignasse]

Are you working in CEGUI?

i use wxwidget and cegui.
it's not ready yet, but here is a screenshot to give you the idea.

cegui is used in the glcanvas and manage the imageset, all the rect and the pos/zoom.

[centipede]

Then you ARE working on the editor
Is it ready for tryout somewhere? Is your cegui part going well, or would it make some sense to use the ImageryEditControl class in your editor? It's got mouse zoom and pan and is generally smooth.
If so, then perhaps I should start to fool around with the LooknfeelEditControl class.

Now it's my turn to be curious. Why didn't you decide to use pure cegui?

[martignasse]

Then you ARE working on the editor

well, at least, i try too

Is it ready for tryout somewhere?

euuh... not really, it's not usuable yet, but if you want to have a look on my bad coding

Is your cegui part going well, or would it make some sense to use the ImageryEditControl class in your editor? It's got mouse zoom and pan and is generally smooth.

it manage the same, but it intercepte some event before cegui (at wx level ). have to look deeply in you'r class to see if it could be merged, but it's a good idea.

then perhaps I should start to fool around with the LooknfeelEditControl class

it's the most complex part, i think, depending of what fonctionnality you want to have. by the way, can you tell me more about this part (what you plan).

Now it's my turn to be curious. Why didn't you decide to use pure cegui?

mainly because wxwidget give solid fundation for all load/save dialogs, and also because i believe the coherence with the layout editor is a good thing (can be merged later... if a make something good )

[centipede]

My idea for the workflow was roughly this:

No matter if you work with imagery or look'n'feel, the user works with not just single image parts but "grids" of imageparts. As stated before, in 90% of the work, graphics will be done handled with 1x1, 3x1, 1x3, 3x3 cell-arrays which are connected both in the raw theme-image (because that's how graphics artists work) and on the screen. So...

1) The user selects a widget in 'project'

2) She adds a number of image-grids, e.g. a single 3x3 grid, which she adapts to the imagery that the artist had made

3) She turns to the look'n'feel page and sees a black screen with a single gui-element on it - or more precisely all the image-arrays that was added in step two, unscaled when compared to how they appeared in step two and positioned in the upper left corner.

3.1) She starts to move them about and stretch them. For instance a 3x3 grid can be moved at stretched/dragged at each horizontal or vertical guide-line. Now comes the scoop: If she right-click on the guide-line, a menu pops up. This menu contains a computed list of obvious interpretations of the current position. The editor chooses a default interpretation, but she can change it all the time. Ok, right-click on the second vertical line of a 3x3 imagery-grid. Then you get:

Code: Select all

Choose how to calculate the position of the x-coordinate:
1) Unified-dim: 0*width + 25
2) Unified-dim: 0.3*width + 0
3) Custom

4) Once content with the result, the user clicks a 'test' button, where she can scale the final widget and see how everything drags along

... Oh, and ofcourse it is also in look'n'feel mode that auxiliary areas can be edited, e.g. the text-area of a textbox etc.