Get rid of the Scrollbar

[Ishad Nha]

It should be possible to get rid of the scrollbar connected to the Terrain palette. Idea is to make the palette big enough to hold icons for all 512 terrain types at once. I am looking at 21 lines of 3D terrain icons each with 25 icons in them. 21*25 = 525, last line will be half empty. I have checked this in Paint with screen captures, it should work. There will be 21 lines of 2D icons, occupying a space that is 63 pixels less in height.

Currently there are 19 lines of 3D icons, each line in my version has 15 icons. Each line is 20 pixels in height, thus 19 * 20 = 380. There are 22 lines of straight 2D icons that are 17 pixels in height, 22 * 17 = 374.

Edit:

Idea works, still have yet to get rid of the scrollbar but now the entire terrain palette is visible. Screenshots:

http://www.freewebs.com/ishadnha/Scrollbar.png

With scenarios like Shades of Gray &, they use most of the terrain slots, hence the ability to see the entire terrain palette at once becomes interesting.

 

This is an alpha version, it is basically functional but it lacks some finishing touches.

http://www.freewebs.com/ishadnha/AlphaResizeBoA3DEditor.zip

[Celtic Minstrel]

This is pointless. What's wrong with having a scrollbar?

[Enraged Slith]

Ooooo, I actually really like this. Let me know when there's a nice stable version of the editor that Vista wont regurgitate on the carpet.

 

I don't know if I've said this before, but all you guys still working on improving the editor are just super.

[Ishad Nha]

There is nothing wrong with a scrollbar, it is just no longer necessary. You only need to have one because, at any one time, the terrain palette currently only shows about half of the 512 possible terrain types. Now my latest version has been arranged so that all 512 types can be seen at once, hence scrollbar is no longer needed.

I think this version is basically stable, XP has no problem with it. Vista is reportedly something else...

A third idea borrowed from the BoE Scenario Editor is to show the graphic of the currently-selected floor/terrain in its actual size. This I will have to implement.

 

[Kelandon]

I'd very much like to make the editor bigger (like, a lot bigger) on the screen, because my screen is far, far bigger than the editor was designed for, and finding stuff is annoying.

 

So I'm in favor of this.

[Ishad Nha]

In which case we might want different versions of the Editor for different size screens. Unless you can work out the code for a one-size-fits-all version.

[keira]

Originally Posted By: Ishad Nha

one-size-fits-all version.

This. Give the thing a maximize button and let folks drag to resize. The idea of having different editors for different resolutions is rather terrifying, given the amount of different-sized newfangled screens they're coming up with.

[Niemand]

Quote:

In which case we might want different versions of the Editor for different size screens.

This would be horrible for users and developers.

Quote:

Give the thing a maximize button and let folks drag to resize.

This will be horrible to code, at least in the present Mac codebase. It may be possible, but it will be a rather large undertaking due to the host of hard-coded rectangles, offsets, and sizes scattered through the code.

I have (and I think every every other person who has worked on the code has) wanted to fix this, but it's a big enough job that it always gets put off into that mythical future where the editor is rewritten from the ground up.

[Slawbug]

Custom-resizable windows would clearly be a huge pain, and multiple versions of the application even more painful. But what about having a handful of different window sizes, 100% preset, that the one and only version of the application supports? Say, traditional, large, and gigantic. You could switch between them via a menu item or even, if it would be easier, just make the user pick one at startup.

[Niemand]

My gut feeling it that it would be only slightly easier than making it freely resizable, and if one is going to go to the effort, one might as well do it right.

 

I'll look at the code and think about this a bit more, but unless it turns out to be really easy to do, I'm not going to have time to do it until May or so.

[Kelandon]

Basically, I have always (since BoA was released) had three major dreams for the BoA Editor:

 

* Palettes for floors, terrains, creatures, and items, which are movable and resizable windows (with resizable icons) that can all be open at once (though only one is active at a time, like any other palette), instead of the fixed-to-the-right-side-of-the-editor system clunky system that we have now

 

* Resizable windows for town/outdoor editing, several of which can be open at once and which contain standard cut/copy/past features, with at least one preset: realistic size (what you actually see in-game)

 

* An in-editor script editor: you place a special rectangle and it pulls up the state in the town script that the special rectangle calls, so that you can code it directly without having to switch to a different application, and you can do everything that you can do in AScript (color-coding, run Alint) in it

 

As far as I can tell, we're talking about the first one, and, as far as I know, the reason that none of them have ever been done is that each one would require a complete rebuild of the editor.

[Niemand]

What you describe (with the possible exception of the floating palettes) is exactly what I too had envisioned for the rewrite-to-solve-all-problems.

 

What was being discussed above is not, I think quite like your first point (floating palettes): The idea, as shown in Ishad Nha's screenshots is just to make the single editor window bigger and allocate more space to the palette area inside it. This grew into a wider discussion of making the editor's single window bigger or resizable.

 

---------------------------

 

Separate discussion of why I hate floating palettes:

As the section title says I very much dislike this technique in UI design. Basically it strikes me as a lazy way out for the designer, who doesn't have to bother figuring out how to fit both the data/document and the tools/options on the screen at the same time, and instead pushes the problem off onto me, the user. I usually find that in programs which insist on working this way (Grapher.app, iWork applications, Interface Builder) I have to spend what seems like an inordinate amount of time messing around with trying to figure out where to put the palettes so that they aren't in my way, and then having to mess with the palettes because the commands or options I need are buried somewhere inside them.

 

It's quite possible that this can be done well, Appleworks pulled it off quite nicely. I think that it was able to do so in part because the palette's default sizes and locations were carefully chosen and because the palettes were able to be quite compact (I count 34 items, of which most have a 28 by 28 pixel icon). The situation for the BoA editor isn't quite as nice because we have a lot of stuff that needs to live in our palettes; up to 500 items. Still, it doesn't seem like continuing to try to jam everything into a single editing window makes much sense, particularly if we want to be able to have multiple such windows around.

 

---------------------------

 

Separate discussion of the steps I envision toward the fantastic rewrite-to-solve-all-problems:

The first step is a new codebase for storing, reading, and writing scenario data. (The model) The current editor is hard coded to only be able to hold one town and one (plus neighboring) outdoor sections in memory at a time. To facilitate letting the user editing multiple zones in different windows (a sort of pseudo-document based approach) we would want to be able to hold an entire scenario in memory at once. This isn't a very tall order, since even large scenarios are only of order a few megabytes of data (Exodus is 2.1 MB). This would mean that while we were at it we cold make the editor truly document based, much like IDEs such as Xcode, which can have open multiple projects at the same time and also multiple documents belonging to each project.

 

The BoAEdRemake people (Kernelknowledge primarily, I believe) wrote a library for this called libRemembrance. I looked through it, and it scared the heck out of me with its fancy design. It's put together like a boost library (for those who know what that's like), with directories and subdirectories like algorithm, class, detail, and impl, and it depends heavily on fancy boost stuff (serialization, MPL, phoenix). While I'm a lot more comfortable with fancy C++ code than I used to be, this thing is seriously complicated (I still can't quite tell what the cementer class does) and I'm not sure how easy it will be to work with it and extend it (particularly if we want to be able to do super awesome things in an even more remote future, when we have the actual game source code, like change the scenario format, make town sizes more flexible, and so on).

 

I've also been working, very slowly, on writing an equivalent library myself, but I haven't gotten all that far mainly because it isn't very fun to work on and there wasn't really any immediate need. I still don't have enough done on it for it to be worth showing to anyone.

 

So, where we stand on this point is that libRemembrance exists, and is available under the GPL for us to use. (As an aside, I'm personally not fond of the GPL and general prefer free licenses which entail actual freedom, but since any code Jeff gives to us will be GPL'd we probably aren't ever going to get away from it.) I can keep working on my version, which will likely never be as fancy as Kernelknowledge's approach and which isn't close to ready yet, thus entailing more delay. It might, however, be better suited to future use, although at this time I'm not sure I can really say much for certain about the assumptions written into libRemembrance and how easy they would be to loosen.

 

The second step is to write new drawing code for displaying BoA zones. (The view) The existing Quickdraw code (on Mac OS) is an evolutionary dead end, and the Windows code doesn't seem very different (aside from the library it uses not being deprecated, I think). Ideally this code should be written in a cross-platform manner using something like OpenGL so that it will both have a long useful life and be usable for both Windows and Mac OS programs. (I didn't mention above, but the model component should be cross-platform as well, though this isn't very hard to do since it mostly doesn't need anything external to itself.) The fundamental task of drawing the graphics tiles for the isometric and above views shouldn't be too difficult, but some care would need to go into properly handling all of the picky details like line of sight, wall corners, lighting, and graphical adjusts.

 

The third and largest step would be to write the logic to assemble the preceding components together to form an editor. (The controller, plus a bit more of the view component) This could be done, as the BoAEdRemake group planned, in a cross-platform way, using a library such as WxWidgets or Qt. This method seems attractive, and is what I would have advocated originally as well, but my view has changed somewhat, and I would now be more in favor of doing this separately for each platform. It would mean more programming, in terms of total amount of code written, but gives the flexibility to let the user facing part of the program take full advantage of its environment and 'fit in' properly on the OS on which it runs. For the IDE idea both Kelandon and I have put forward building in a good script editor and integrating Alint would also be done during this phase.

 

I think I've written about this topic before, but there's an idea of what would have to happen, as I see it, to build a really great, really modern editor.

[Ishad Nha]

Interesting ideas. We already have cut, copy and paste for floor/terrain/height.

This will have to be done by Kel and Niemand because they are the only serious BoA programmers. I am more of a scavenger, using other people's code.

[Celtic Minstrel]

Originally Posted By: Ishad Nha

A third idea borrowed from the BoE Scenario Editor is to show the graphic of the currently-selected floor/terrain in its actual size. This I will have to implement.

Now this one, I like.

[Kelandon]

Originally Posted By: Niemand

Separate discussion of why I hate floating palettes:
As the section title says I very much dislike this technique in UI design. Basically it strikes me as a lazy way out for the designer, who doesn't have to bother figuring out how to fit both the data/document and the tools/options on the screen at the same time, and instead pushes the problem off onto me, the user.

You could have a default (fixed) spot for them that could be broken off at the user's discretion. I've seen a lot of programs that have resizable, movable, whatever whatever options for their windows and then just have a reset button to put everything back to a default position that is sensible for most purposes, and I kind of like this. I can customize what I want, but if I screw something up or it gets weird, I can put it back quickly and easily into a sensible position.

I don't really care if the palettes float or not. I just don't want to have to cycle through things to get from terrains back to floors and then over to creatures and then back to floors and then to terrains and then back to floors. I'd rather just click on one thing, place that, click on another thing, place that, and so on, instead of having to cycle.

[tridash]

I had a go at separating out the palettes from the main window with Niemand's most recent code, and making the main window resizable. The code changes I made are not particularly clean, and it's not working perfectly yet, but here's a screenshot: click!. Making the window bigger allows you to see more of the map. I suppose that pressing the "maximise" button in the top left should take you back to default size.

 

I was thinking that maybe the toolbar could go at the top and be more stretched out?, say with just two longer rows rather than 6 short ones.

[Niemand]

Ooh! Pretty. I would be very interested in getting this code into the repository once you think it's fit to show to others. (We could always make a brach to stash it in until the kinks are worked out.)

 

One thing that we do need to keep in mind is giving designers a way to see how much will be visible to the player from a given point, for making cutscenes and the like. Currently we do this in a sort of brute force way, by making the editor's isometric view box the same size as the game's, but we could introduce a frame to mark or mask out the not-visible-to-the-player portion of the view.

 

Quote:

I was thinking that maybe the toolbar could go at the top and be more stretched out?, say with just two longer rows rather than 6 short ones.

Do you mean as a separate window, or within the main window. I assume the former, since the latter would interact badly with the main window's size changing, potentially.

 

EDIT: Just to clarify: What have you done with the chunk of the interface consisting of the text normally shown at the lower left of the window, below the terrain view? If the answer is that you've ignored it because what you have is a prototype, that's fine, but we will need to reincarnate it somewhere. Possibly it should be merged with the tools palette, or possibly we should totally redesign it as a new inspector window. Neither option really grabs me as sounding great, so I'll think about it.

[tridash]

Originally Posted By: Niemand

Quote:

I was thinking that maybe the toolbar could go at the top and be more stretched out?, say with just two longer rows rather than 6 short ones.

Do you mean as a separate window, or within the main window. I assume the former, since the latter would interact badly with the main window's size changing, potentially.

yeah, I meant a separate little window at the top or side, something like the photoshop toolbar.

Originally Posted By: Niemand

EDIT: Just to clarify: What have you done with the chunk of the interface consisting of the text normally shown at the lower left of the window, below the terrain view? If the answer is that you've ignored it because what you have is a prototype, that's fine, but we will need to reincarnate it somewhere. Possibly it should be merged with the tools palette, or possibly we should totally redesign it as a new inspector window. Neither option really grabs me as sounding great, so I'll think about it.

I wasn't too sure what to do with it for now either; I moved the "Now editing *blah*" stuff to the window title, but that doesn't help with the text you get with creatures / encounter rectangles / etc.

EDIT: If we can merge some of the similar buttons (e.g. barriers) into a single button that you hold down to select a sub-button (again similar to photoshop toolbar) that would free up some more toolbar space.

[Niemand]

Quote:

I wasn't too sure what to do with it for now either; I moved the "Now editing *blah*" stuff to the window title, but that doesn't help with the text you get with creatures / encounter rectangles / etc.

Ah. Unfortunately in recent versions I've elevated the importance of this part of the interface.

One thing that we might consider is to take this as an opportunity to do away with the 'Town Details', 'Edit Creature', and such dialogs by making a unified inspector which changes contextually. The trick will be to avoid making it huge, in terms of space taken up on the screen (since the Town Details window, for example, has a lot of junk in it), and also not go too far the other way giving it a zillion annoying tabs that the user needs to constantly switch between (like the inspector windows in Interface Builder, Keynote, and a whole lot of Apple's recent software).

EDIT: Since you mention it in your edit above, I thought I would reverse my decision not to mention trying to simplify the tool palette. My inspiration here is the Acorn tool palette. As you note, something like half of our buttons are types of objects and stains, none of which gets used very frequently. The harder part will be doing a good job with the cluster of random buttons in the second and third rows that do fairly unique things, although a number of these I've been trying to do away with altogether anyway.

[Celtic Minstrel]

Originally Posted By: Niemand

The harder part will be doing a good job with the cluster of random buttons in the second and third rows that do fairly unique things, although a number of these I've been trying to do away with altogether anyway.

Which buttons do you mean?

[Enraged Slith]

I love you guys.

[Kelandon]

Originally Posted By: Enraged Slith

I love you guys.

Allow me to second this sentiment.

[Niemand]

Originally Posted By: Celtic Minstrel

Originally Posted By: Niemand

The harder part will be doing a good job with the cluster of random buttons in the second and third rows that do fairly unique things, although a number of these I've been trying to do away with altogether anyway.

Which buttons do you mean?

I mean buttons like cycle drawing mode, change terrain randomly, erase nav point, edit sign, and so on. Most of them are useful and necessary, but they don't break down into associated group;s quite as obviously as most of the rest.

[Ishad Nha]

This is a very good idea indeed. Ormus was going to do this for the BoE Editor, until work commitments got in the way.

[tridash]

I've put drawing mode controls onto the tiles window, so cycle drawing mode can probably go now. I'll try to get the tiles window resizable, and as a temporary thing stick the text that goes under the map onto the tools window, and then I'll put the messy code on the svn as a branch (I'll try and make it nice and clean after I've finished exams in june).

[Niemand]

Quote:

I've put drawing mode controls onto the tiles window, so cycle drawing mode can probably go now.

Looks like a reasonable first step. To go with this I ought to finally get the keyboard shortcuts properly included in one of the menus as menu items, rather than being secretly hard-coded into the keystroke handling code.

Another thing we should perhaps do (and I'm by no means saying that you should do it now, I'm just thinking out loud) is that maybe the buttons which affect the display mode of the terrain view should be separated from the drawing and object manipulation tools and put into the (now stand-alone) terrain view window. Other buttons/tools which should be eliminated eventually are Delete Waypoint, Clear Space, and Edit Sign. The autohills toggle should probably become some sort of subsidiary of whatever drawing drawing tool (if any) is currently in use, and only be displayed when in terrain drawing mode.

Quote:

I'll try to get the tiles window resizable, and as a temporary thing stick the text that goes under the map onto the tools window, and then I'll put the messy code on the svn as a branch (I'll try and make it nice and clean after I've finished exams in june).

I wouldn't even worry about making the tiles window resizable yet, that should be a relatively simple thing that we can do later once we have the thing working consistently. On the other hand, if you feel like tackling it, by all means go ahead.

[tridash]

you're probably right, I'll just get it into a working condition and then put it on svn soonish.

 

on an only vaguely related note, would it be worth asking about releasing the BoA source again now that Avadon's out and (apparently) doing ok?

[Niemand]

Quote:

would it be worth asking about releasing the BoA source again now that Avadon's out and (apparently) doing ok?

It's getting toward being a good time, yes. Part of the concern is however, that we want to convince Jeff that if granted the source code we'll actually do something with it. As I recall, the last time it was brought up with him he wanted to know what the community had accomplished with the BoE code since its release, and there wasn't much that could be pointed to to impress him. I assume that it's partially about the fact that it does take a bit of effort on his part to get his code all packaged up for the world to see, so he wants to know that the effort would be worthwhile. Also, he has to beleive that the good derived from the community working on the code will in some sense outweigh the small benefit Spiderweb has from holding onto the code and continuing to sell the game now and again. He did hang onto the BoE code for a full decade after the game's release, and while BoA is shading toward that age, it isn't there yet.

I think that when we next request that he consider releasing the code we should be able to point to several concrete accomplishments/strengths of the community. The 3D editor is certainly a highlight, and if in the next version or two we can get ready the interface changes we've been discussing here we'll have good grounds to argue that we have gotten a good deal of value out of access to the code and importantly that we continue to do so. Ideally we should also be able to point to a healthy amount of activity in designing scenarios, which we may not be able to do very well at present. In short, I'd like to be abnle to argue convincingly to jeff that if he hands us the code something interesting will happen.

Finally, we, or at least I, would like to be able to be somewhat ready with ideas of what we want to do with the code once we get it. I have a number of ideas, but none of them is anything like as ready as it could be. Something which might be a good activity for us as a group over the summer would be to draw up a roadmap of what exactly we would do with the code starting the minute we got it. This wouldn't necessarily be for showing directly to jeff, but just so that we could ensure a degree of productive activity and make the project more robust against individual people wandering off or being too busy to contribute. The early parts of the list could be pretty easy like where to put the code (do we want it on Google Code, on Github, or for someone like me to host it?) and which of the known bugs we would tackle and how exactly we would try to resolve them (Items don't stack when given via char_give_item, so let's make 'em stack). It would then get more speculative, but work up from changes we are fairly certain we can make easily (maybe: replace PICT resources with PNG image files) to bigger harder things that would take a substantial amount of work (rewriting the drawing code to use something other than Quickdraw).

--------------------------

Getting back to our earlier topic, shoughts about remaking the tool palette:

Here's a tentative break down of the existing tools into categories:

Click to reveal..

Basic Drawing:

• pencil
• small paintbrush
• large paintbrush
• small spraycan
• large spraycan
• paint bucket

Advanced Drawing:

• Set Height
• Draw Rectangle
• Fill Rectangle
• Bounding Walls
• Swap Walls
• Change Terrain Randomly

Copy and Paste

• copy terrain
• paste terrain

(View modes -> terrain view window)

• switch 2D/3D
• toggle zoom
• toggle realistic

(Drawing mode -> tile window)

• floor mode
• terrain mode
• height mode
• creature mode
• item mode

'Object' creation

• create special encounter
• (create/edit sign?)
• create room rectangle
• place terrain script
• place waypoint
• place spawn point

Town Entrances

• place north entrance
• place west entrance
• place south entrance
• place east entrance

Object and Field Placement

• make space blocked
• place web
• place crate
• place barrel
• place fire barrier
• place force barrier
• place NE/SW mirror
• place NW/SE mirror

Stain Placement

• place small blood stain
• place average blood stain
• place large blood stain
• place small slime puddle
• place large slime puddle
• place dried blood
• place bones
• place rocks

Select Object

Eliminated:

• autohills -> within current drawing tool
• delete waypoint -> within editing details for selected waypoint
• clear space -> make objects, stains, etc slectable and deletable (blockage?)

In the obove listing, the object and Fields category could be reasonably expanded to include stains. This would then leave a space for the eyedropper (more on the eye dropper in a moment), since it works out most nicely to have an even number of categories. Select Object is so importent that it is its own category.

The eyedropper is annoying, since it is rather different than most tools, an sort of doesn't belong with the rest of them. Acorn (from which I'm stealing the entire UI idea I'm building up here) handles this by treating the eyedropper specially, making it a pseudo tool whose icon is associated with the color wells rather than the other tools. We could do something similar by putting the eydropper in the tiles window. We would have to figure out haow to fit it in so that the design would look deliberate, however, and not just like we accidentally put one button off by itself.

For those who haven't used Acorn, here's how its tool palette behaves (See this screenshot): It has two main sections, with the left being the array of tool category buttons, like selection, painting, or cropping. The right section is the details of the current tool or category, and if the category includes mutliple tools there are buttons for selecting among them. Also in this area any settings or details of the current tool are shown. A nice touch that I would like to duplicate is that when a tool is selected within a category the icon for that category changes the the icon of the that tool, instead of matching the first tool in the category. In addition, each category remembers the last tool used within it, so returning to a category which has been used previously returns to the tool last used in that category.

So, finally, here's a mockup I made of a how we could replicate this: Image

The size isn't well determined; I just picked border widths that looked nice and left enough space hozontally in the detials section for eight tool buttons across the width.

One disadvantage of this approach is that it makes the tool palette relatively bulky, particularly since it ends up being close to square, on smaller screens fitting it in with the main view window (we need a clear, consisent name for that thing; maybe just main window) and the tile palette may get tricky. This could be made worse by the fact that we still haven't solved the problem of where to put all of the stuff that's currently in the 'left text lines' which is very necessary for accessing a selected object's properties. One possible path would be to use the toll details space for this when the current tool is the selection tool, but this might be tricky to do without bloating the toll palette window badly (I think that creating some kind of tabbed interface may be necessary to be able to shoehorn in all of the details for complicated objects like creatures, wherever we put them).

In terms of coding, what would these changes require? To start with, the code which draw the tool palette and 'right text lines' would have to be totally rewritten, preferrably with such things as a separate function to render the details section for each tool/tool category. The mechanism for recording which tool is in use currently would need to at least be extended, and preferrably replaced, which would be a big job but would lead to cleaning up some of the worst code in the editor (giant switch statements over arbitray magic numbers representing the various tools, and hideous loops which mix determining which button was clicked with carrying out the button's action).

[Celtic Minstrel]

Stain/object/field placement could also become a new "tab" in the tile window, couldn't it? I think it might be a bit nicer picking from what they actually look like rather than the tiny symbols on the tool buttons.

 

That aside, your suggestions sound very good.

[Niemand]

Quote:

Stain/object/field placement could also become a new "tab" in the tile window, couldn't it?

That is a very good point.

[tridash]

ok, I put the basic stuff on the svn now, it's not exactly pretty, and I'll make it acceptable later.

 

here is a download for a kind-of working version; temporary interface just to make it actually usable etc. etc.

[Niemand]

Cool; I have free time this weekend (I passed my preliminary exam today!), so I'll take a look.

 

Edit: So beautiful.

 

where doing it man

 

where MAKING THIS HAPEN

 

(Making the main window resizable. No hugging is necessary at this time. Fancy OpenGL drawing might be necessary, though, as scrolling this thing eats a frightful amount of CPU cycles.)

[tridash]

i noticed a couple of stupid bugs with text not being cleared from the toolbar, I might as well fix them later

 

one of the problems with scrolling is probably because I quadrupled the area drawn to for the 3d terrain, maybe it should be dependent on screen size (it's doing it to a 1024x1024 thing, before it was 512x512). also the code i did is basically all of the over the place so far, when i clean it up that might help a bit.

 

shifting to openGL's probably a good idea anyway, though, especially if we eventually want to move to a "document-based" approach where you can have multiple towns open at a time.

[Niemand]

Quote:

i noticed a couple of stupid bugs with text not being cleared from the toolbar, I might as well fix them later

This isn't a big deal; I have in mind some changes that will more or less make this irrelevant.

Quote:

one of the problems with scrolling is probably because I quadrupled the area drawn to for the 3d terrain, maybe it should be dependent on screen size (it's doing it to a 1024x1024 thing, before it was 512x512). also the code i did is basically all of the over the place so far, when i clean it up that might help a bit.

The issue is just that the drawing code isn't very efficient and for a bigger view area we end up running it more. I don't think it's a problem yet, at least not for computers less than a few years old.

Quote:

shifting to openGL's probably a good idea anyway, though, especially if we eventually want to move to a "document-based" approach where you can have multiple towns open at a time.

I think that these concerns are orthogonal (and I'm not sure it would be a sane thing to try to stretch the current code to a document based form) but it's definitely something to think about for the future. Luckily, someone here happens to have already started looking into the possibility.


I'm going to take a stab at rearranging the tools window like I described a few posts ago. A few notes about what I'll try to do:

The 'left text lines' are 10 lines, each 240 px long and 12 px high with 5 px of vertical spacing. Stacking them in a single column they would fit into a space 240 px wide and 170 px tall. This is almost exactly the space as in my mockup. The main use for these lines is to show information about the selcted object, which we can just display in the tool palette when using the selection tool.

The 'right text lines' display several different kinds of information: This includes the view center coordinates, the current tool (and type to be drawn for drawing tools), and step-by-step instructions for tools. The first of these makes more sense as part of the main window, for example drawn in the lower margin. The other two kinds of information could be displayed in the tool palette space, which would show whatever is relevant for the current state of the current tool, with the information about the selectyed object being visible only when using the selection tool.

Edit: Ugh. I had forgotten about the horror that lurks in the editor's system of tool modes. Each tool has a mode number, except that there are some tools (as seen by the user) which share the same mode (and are instead distinguished by their 'mode count'), and there are also modes which are effectively tools except that they aren't reached by clicking one of the usual tool buttons. It won't be pretty but I think I can still make this work.

[Celtic Minstrel]

Originally Posted By: Niemand

there are also modes which are effectively tools except that they aren't reached by clicking one of the usual tool buttons.

Which ones are these? Perhaps some of them could be added as tool buttons.

[Niemand]

They are the three rectangle redrawing modes, pasting a copied object, setting town boundaries (which is really another, older rectangle redrawing tool), and placing starting points. (I thought that there were more, but that's all I see on a scan through the list.)

 

(EDIT: The other part of what I meant to say about these is that some of them don't really want to have their own buttons, like the rectangle redrawing tools, since they only make sense in the context of already having an object of the relevant type selected. What they do need, however, is to be able to display details like other tools while they are in use, in spite of the fact that as far as the drawing code is concerned they don't fit in very normally. I think I have this worked out, but I haven't actually gotten around to coding it yet.)

 

There are also tools which I've currently broken by removing their buttons and not providing an alternative means to access (in my working copy, which I'll get checked in very soon), including the eyedropper, delete waypoint, and edit sign. Each of these has or seemed to have some special complication related to it, which is why it's currently out, but needs to one way or another get back in before I'm done. (That is, the eyedropper doesn't seem quite right shoved in with the other tools, although I may just relent and put it there, and the other two seem like they could be more elegantly handled through making the objects in question selectable.)

[Niemand]

(Apologies for the double post, but making this distinct from my last one seems best.)

 

I've checked in my big round of changes. Among a bunch of smaller things I've redone the tool palette window as I planned (it looks almost exactly like the mockup except for its dimensions) and taught the tools and tiles windows to jam themselves to the right edge of the screen filling the available height. As part of doing this I made the tiles window (vertically) resizable.

 

One minor change that I think is pretty important going forward is that I added tooltips for the the tool categories in the new palette. I still need to expand this to show hints for the tools themselves, but I think that it helps a lot for telling what's what. We should keep an eye out in future for places where more tooltips would be appropriate.

 

There are a lot of things broken or inaccessible in this version, so it still needs a good deal of patching up before we can merge it back into trunk (although with all two project developers working on this branch, doing so will be pretty darn simple) and think about a release. Reproduced from the log message the currently broken things are:

• No buttons for switching view modes
• 2D view mode is broken
• No way to toggle autohills
• Currently no way to access the eyedropper
• Details are not drawn for uncategorized tools
• Issues with drawing terrain view larger than 1024 by 1024
• When the tiles window is very tall so that it has extra space at the bottom in some modes there are drawing artifacts when switching from a mode which uses more space to one which uses less (terrains -> creatures)

 

The second to last of these may be a nasty one to deal with, since it has to do with our allocating a single, permanent GWorld for drawing the terrain view offscreen. This was fine when the view never changed size, but now that its size can vary drastically this wastes a lot of memory when the current size is small but we have a buffer large enough for a very large size and imposes an artificial limit on how large the main window can get. The thing to do may be just to reallocate the backing GWorld on every resize, but I've shied away from trying it just yet, since for large window sizes it will end up allocating and deallocating large, but always slightly different, chucks of memory, which doesn't seem very pretty. It may be best just to bite the bullet and do it, though.

 

A couple of other to-do items that I'll record here before I forget are to make sign markers be drawn and probably to make signs and waypoints selectable.

[tridash]

(it's really good)

 

Originally Posted By: Niemand

tooltips

 

excellent! i think the editor's needed these for a while

 

 

Originally Posted By: Niemand

• Issues with drawing terrain view larger than 1024 by 1024
• When the tiles window is very tall so that it has extra space at the bottom in some modes there are drawing artifacts when switching from a mode which uses more space to one which uses less (terrains -> creatures)

 

the second one's just because of the gworld not being quite large enough, I can fix that, as for the first one (although not elegant) it seems (unless I'm missing something) that just shoving:

 

Code:

DisposeGWorld(ter_draw_gworld);NewGWorld(&ter_draw_gworld, 0,&resized_rect, NIL, NIL, kNativeEndianPixMap);

 

into the window resizing bit does the job.

[Niemand]

Originally Posted By: tridash

the second one's just because of the gworld not being quite large enough, I can fix that, as for the first one (although not elegant) it seems (unless I'm missing something) that just shoving:

Code:

DisposeGWorld(ter_draw_gworld);NewGWorld(&ter_draw_gworld, 0,&resized_rect, NIL, NIL, kNativeEndianPixMap);

into the window resizing bit does the job.

Right, I knew this, but I'd been thinking of this as a really costly operation to be avoided. Upon reflection I think I was getting more concerned than there was any need to.

[Celtic Minstrel]

Originally Posted By: Niemand

the three rectangle redrawing modes,

...I'm actually not sure what these are...

[Niemand]

These were something I added a couple of versions back. I noticed that if I drew a special rectangle (or, equivalently, a town entrance or area description) and later decided that I wanted it somewhere else, I had to erase it and then place a new one. This is partially alleviated by allowing such rectangles to be moved just like placed creatures and items, but there still wasn't a way to change their shape. So, I added modes in which the user can choose two new points to redefine a rectangle's extents in the same way as the original placement.