New Windows 3D Editor

[Ishad Nha]

A new version has been uploaded. The shortcut for reprint last file is Ctrl + P.

Backspace now deletes any selected object, then it reverts to select object mode. Thus you can select objects and delete any you don't want. Just the thing for cycling through a list of items.

I will see if I can broaden selection of objects to enable terrain to be pushed around.

[Celtic Minstrel]

Can you make Del do the same as Backspace? It's not important, just makes sense.

[Niemand]

Quote:

I will see if I can broaden selection of objects to enable terrain to be pushed around.

That doesn't make any sense if you're referring to what I think you are (using arrow keys or similar to 'move' terrains). When you move an object it's clear that what you're doing is changing the position of that instance so that it appears somewhere else. For terrains, though, we have a grid, within which every cell must contain some terrain. So the idea of 'moving' a terrain isn't entirely clear. If I 'move' a terrain out of one space in the grid, it must both replace whatever terrain was in the grid space I moved it into, and some terrain must come into existence in the grid space I moved it out of. You could try things like swapping the terrains in two grid locations, with the effect of turning the zone into a huge slide puzzle, or you could overwrite terrains and leave behind a trail of empty terrains, which would be peculiar and potentially destructive. So, unless I've misunderstood what problem you're trying to solve and how you're trying to solve it, I think that copying and pasting sections of terrain, combined with manual redrawing as needed, is a better answer.

[Ishad Nha]

Backspace originally did the same thing as Delete. The new Backspace option is meant to be a whole new approach to deletion. In particular it enables you to pick through piles of items and delete the ones you don't want, without the need to continually switch from Select to Delete and back again.

Idea is that you would have both cut and copy terrain options. If you cut a terrain type or a rectangle of terrain, it is replaced by type 0, empty terrain. In most towns/ outdoor zones an awful lot of terrain is type 0 anyway.

Copy works the way you suggest.

[Ishad Nha]

It seems that the maximum width for a dialog box is around 610 to 640.

The load new town has a provision for choosing the town from a list. This Choose option needs a display dialog function before it can become active.

Edit:

There is also a glitch in the Creature appearance type in the edit placed monster dialog. The relevant strings need to be added to the end of Blscened.rc

[Ishad Nha]

Title bars can be added to dialog boxes so that they can be moved around the screen. Said bars will be Windows blue, a color that may not agree well with the colors found in G4901.bmp.

I don't know if there is any desire for movable dialog boxes, if so we will need to alter the colors of G4901.

[Celtic Minstrel]

Why would you need to alter the colours of G4901?

[Ishad Nha]

G4901 determines the background color of the dialog boxes.

I thought this bitmap also handled the color of the borders on the dialog boxes, and it seems that this is not the case. Color of borders seems to be hard-coded.

One other issue: the OK, Cancel and other such buttons appear on the bottom border in a way that does not grab me. If you want a solution put a dummy button well below the real buttons.

Edit:

Here is a graphic that shows the buttons after and before I did something. The Record button on the top graphic is just a dummy to keep the border beneath the OK and Cancel buttons.

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

[Celtic Minstrel]

Originally Posted By: Ishad Nha

G4901 determines the background color of the dialog boxes.

You mean G4901 is the one containing all the background patterns used in the game? We don't need to edit that, then.

Originally Posted By: Ishad Nha

I thought this bitmap also handled the color of the borders on the dialog boxes, and it seems that this is not the case. Color of borders seems to be hard-coded.

Of course, I'm pretty sure that's beyond the designer's control. You may be able to customize that on a per-computer basis by right-clicking the desktop and selecting something, or somewhere in the Control Panel, but that'll affect all windows equally, including those not of the game.

Originally Posted By: Ishad Nha

One other issue: the OK, Cancel and other such buttons appear on the bottom border in a way that does not grab me. If you want a solution put a dummy button well below the real buttons.
Edit:
Here is a graphic that shows the buttons after and before I did something. The Record button on the top graphic is just a dummy to keep the border beneath the OK and Cancel buttons.
http://www.freewebs.com/ishadnha/BoA3DEditordialogs.png

Instead of a dummy button, can't you just add a dummy text object with no label? Since it contains no text, it would be invisible and hence would have the desired effect without a negative side-effect.

Better still, try to find a way to make the dialog sizes not depend directly on the size of the elements.

[Ishad Nha]

"Hard-coded" means programmed into the Editor, not into the computer operating system. By contrast, altering 4901 will have an immediate effect on the Editor's color scheme the next time it is run. I will need to track down the relevant lines of source code. Title bar color does seem to be connected to Windows as a whole. If that is the case, it is best to make border and background color agree with title bar color.)

 

(G2.bmp and G4900.bmp seem to do nothing whatsoever. Not quite nothing, the G4900 graphic seems to be used to locate the Editor graphics folder.)

[Niemand]

The editor uses the games graphic files for its look-and-feel. Why on earth would you alter them? The blue border and title bar on the dialog window are due to the appearance settings for Windows as I would imagine you have noticed all your windows look on Windows look that way with the default blue Luna theme.

 

Fixing the window sizes does seem important, but doing the job right might require detecting what OS version or even what theme are in use, since I think it may work correctly as it's currently coded for older versions of Windows, and might look correct on Windows XP set to appear like Windows 98/2000 as well.

[Celtic Minstrel]

Originally Posted By: Ishad Nha

Title bar color does seem to be connected to Windows as a whole. If that is the case, it is best to make border and background color agree with title bar color.

Please no. I don't care about the title bar, but I like the dialog border/background as it is.

[Ishad Nha]

"The editor uses the games graphic files for its look-and-feel. Why on earth would you alter them?" I don't like them that is why, I find them dull and uninspiring.

Themes, forgot about that.

I initially tried an empty label at the bottom of the graphic, it just gouged a hole in the border. That is why I switched to a dummy label.

Individual graphics of G4900 all come from the Mixed.bmp of BoE.

I have just uploaded a new version that has title bars on all dialog boxes. Only the town Area Rectangles dialog has had the dummy button installed.

[Celtic Minstrel]

Originally Posted By: Ishad Nha

"The editor uses the games graphic files for its look-and-feel. Why on earth would you alter them?" I don't like them that is why, I find them dull and uninspiring.

Well, that alone is not a good reason to change them; I for one like them. If you want to program a way to customize them easily, or if you want to replace that graphics file just in your copy, go for it. But don't just change them.

[Ishad Nha]

I made a quick alteration to the town and outdoor lists of Area Rectangles, the top and left coordinates are listed separately from the bottom and right ones, this looks tidier.

[Celtic Minstrel]

It also makes it more clear which coordinate is which.

[Ishad Nha]

One idea, I don't know if it is wanted or not. Enable parts of the terrain and floor to be moved around the screen. You would have copy and cut modes. In the first mode you would select an area, hold down the Control key and drag the selected terrain/floor/height around. In cut mode the floor/terrain/height at the original area would be replaced by default values. Clearly you would need a selection rectangle to show what had been selected. Once you release the mouse button the selected terrain/floor/height is pasted at its current location.

This could be done by copying the floor/terrain/height into a spreadsheet, altering it and then pasting it back into the bas file but writing it into the Editor is better in every way.

[Ishad Nha]

Latest changes:

 

BlA Fileio.cpp:

Scenario Data file: Terrain and floor now have all types listed, even if blank. This leaves writing space for the designer to assign slots.

Outdoor zone numbers are now shown in query files. They may be needed in the scenario script.

 

EdFcns.cpp:

Eyedropper selects either a floor or a terrain type, according to current drawing mode, not both at once.

Terrain script dialog has warning about script length

Ditto creature scripts

F4 duplicates the Space shortcut, while F3 moves backwards through the drawing modes. (This may require clicking on the screen to get it properly redrawn whenever you change mode.)

 

Alphabetical shortcut keys: removing references to selecting terrain when in floor mode and vice versa. (Why are they there in the first place anyway? You can't paste terrain when in floor mode and vice versa.)

 

Click to reveal..

if ((chr >= 97) && (chr <= 122)) {

if (current_drawing_mode == 0) { // use shortcut keys, if editing floor

for (i = 0; i < 256; i++) {

j = current_floor_drawn + i + 1;

j = j % 256;

if ((scen_data.scen_floors[j].shortcut_key < 26) && (scen_data.scen_floors[j].shortcut_key == chr - 97)) {

set_new_floor(j);

return FALSE;

}

}

for (i = 0; i < 512; i++) {

j = current_terrain_type + i + 1;

j = j % 512;

if ((scen_data.scen_ter_types[j].shortcut_key < 26) && (scen_data.scen_ter_types[j].shortcut_key == chr - 97)) {

set_new_terrain(j);

return FALSE;

}

}

}

 

"current_drawing_mode == 0" means that you are in Floor mode.

This code comes from line 2,088... of the original Isaac 3D Windows source code.

[Niemand]

Quote:

Eyedropper selects either a floor or a terrain type, according to current drawing mode, not both at once.

Why? I can see that this might be useful in some situations, but is it really better than the old behavior all that often?

Quote:

F4 duplicates the Space shortcut, while F3 moves backwards through the drawing modes. (This may require clicking on the screen to get it properly redrawn whenever you change mode.)

This is rather different than the Mac editor, and particularly if it doesn't work properly, please don't commit it just yet. For consideration, the way the Mac editor currently switches modes is: space cycles forward by one, Command+1 - Command+5 jump directly to a mode by number. Shortcomings are that I haven't gotten around to making the latter shortcuts into proper menu items, at the moment their, just caught at a low level, and there is no way to cycle back a mode. What if we combine the two schemes, so that Command/Ctrl+Number jumps directly to a mode, space cycles forward, and Shift+Space cycles backward?

Quote:

Alphabetical shortcut keys: removing references to selecting terrain when in floor mode and vice versa. (Why are they there in the first place anyway? You can't paste terrain when in floor mode and vice versa.)

I can see this one as being better justified than the eyedropper change, and I think I'm tentatively in favor (as the old behavior was weird). Still, do you think that it's worth subtly changing part of the user interface from the way its been, probably since the first release? (Unless there's evidence to the contrary, I'd guess that that chunk of code was originally put there by Jeff.)

EDIT: I really need to pay closer attention to the lower email inboxes. . . I struck the phrase above since the code's already committed, although in future it might be best not to to put stuff in that's partially broken.

[Ishad Nha]

With the Eyedropper, if you select both terrain and floor at once, you have to paste the same combination of floor and terrain every time you paste. You may only really care about the terrain. If there is any demand we could have both options available: select a floor and terrain pairing or select only one of them.

F3, F4 at least enables switching back and for the between Floor and Terrain, I might be able to fix it up. Ctrl + Number, Shift + Number would be worth looking at when we have more than three modes in Windows.

Yes, line 1,422 of the original 2D official Spiderweb Editor Windows source code has the interesting code for the shortcut keys.

 

Also, help file was also tidied up, so that it made sense to people who have not read every post in this topic.

 

Edit:

If you use "redraw_screen();", the height numbers on the screen will be properly updated every time you go from Height to Floor (and vice versa), or from Height to Terrain (and vice versa). There will also be a brief flash of about one second duration.

If you use "need_redraw = TRUE;", the height numbers will be updated when you move the view at least one square. There will be no flash.

[Ishad Nha]

Here is a graphic of an intermediate view, it is 16*16 whereas small view is 8*8 and big view is 48*48. It can be improved by replacing the colored squares with the little outdoor icons found at the bottom of all creature graphic sheets.

This graphic is from the Bahssikava scenario by Kelandon.

http://ishadnha.webs.com/AreaView.png

[Celtic Minstrel]

Um. Good idea, bad implementation. Just make a rectangle select tool with which you drag out the desired area and move it around, and use the Cut/Copy/Paste menuitems for more advanced control (such as copying from one map to another).

 

One minor oddity is that you would have to click on the terrain map after choosing Paste in order to specify where to paste it, but that's how the item and creature copy/paste works anyway, so it's not too bad.

[Celtic Minstrel]

Originally Posted By: Niemand

Quote:

Eyedropper selects either a floor or a terrain type, according to current drawing mode, not both at once.

Why? I can see that this might be useful in some situations, but is it really better than the old behavior all that often?

It makes more sense to me that it only selects according to the current drawing mode, actually. I can't see it being better or worse apart from that.

[Ephesos]

GAAAAAHHH!

 

Merge function seems to be broken, so I failed at moving the other threads into here. What follows is what I tried to move. Apologies:

 

Originally Posted By: Ishad Nha

Here is a graphic of an intermediate view, it is 16*16 whereas small view is 8*8 and big view is 48*48. It can be improved by replacing the colored squares with the little outdoor icons found at the bottom of all creature graphic sheets.

This graphic is from the Bahssikava scenario by Kelandon.

http://ishadnha.webs.com/AreaView.png

 

Originally Posted By: Niemand

So, if I understand correctly, you're adding an intermediate zoom level?

 

Originally Posted By: Ephesos

I am merging this and the other thread back into the Windows Editor thread. They make precious little sense as stand-alone threads.

[Ephesos]

...so I don't have to experiment with the merge function any more, can we keep this stuff in the Windows Editor thread? It makes no sense without that context.

 

Also, I think the current copy/paste function that's in the Mac editor would suffice. This just seems excessively fiddly for little utility.

[Niemand]

Quote:

Also, I think the current copy/paste function that's in the Mac editor would suffice.

I agree, we just need to make buttons so the user can use it. (The code should already be in the Windows version, but I really can't figure out how to rearrange the UI to change the function buttons to match the Mac version. )

[Ishad Nha]

If you want to increase the number of palette buttons that is easily done.

Snag is that we are pretty much out of space in the 800 * 600 resolution. Already it is necessary to keep the Taskbar on Windows unlocked if you want to see all five lines of text at the bottom of the screen. We could just squeeze in two extra columns of buttons, making it [10]by [6].

Other than that we will have to put a minimum screen resolution limit on the Editor.

Edit:

Make that six lines of text at the bottom right of the screen.

[Niemand]

The proper solution, I still believe, is to split apart the function buttons from the palette above them. This is what I did in the Mac editor, and it worked very neatly. I've tried three times now to do the same thing with the Windows code, but every time I can't get get the newly added offscreen buffer to blit to the screen properly. I can't figure out what I've done wrong, since the existing code, which works the same way as my added code, has no problems.

[Ishad Nha]

Yes, an intermediate zoom level.

While I am at it I can expand Hintbook mode to have an effect on all three levels of zoom.

Edit:

I have stitched together some body parts and now have a golem. I have taken code from both the 9*9 view and the zoom-out view, and merged it. Code I don't properly understand.

I will need to fix up the borders& So far I have replaced the zoom out view with this 32*32 perspective. This has been done with a private version of my own editor.

[tridash]

It might be interesting to see how the editor would work with a revamped interface, maybe with a more document-based approach, with the actual level in a separate window to the tools (and with options to make that window as big/small , zoomed-in/zoomed-out as you want...). for example, you don't really need icons for two spraypaints and brushes - just have one for each with further options accessible by clicking and holding on them like in photoshop or something.

[Ishad Nha]

If you are going to make the palette of buttons another screen like the floor or terrain palettes that would remove problems with lack of space at lower resolutions.

Variable zoom, all 2D views are based upon the 16*16 editor icons. Thus it is simple enough to program at some point or other.

[Celtic Minstrel]

Tridash, that may not be a bad idea, but it would be a complete rewrite and hence a lot more work. Working with what we have is easier.

 

That said, it could be put on the list of "maybe do eventually".

[Ishad Nha]

The beta, or gamma, can be found here:

http://ishadnha.webs.com/VariantBoA3DEditor.zip

Edit:

Extending hintbook mode to 2D big icons mode, "short cur_viewing_mode = 0;", is easy for monsters and items. The lines seem to be written into the way the graphics display.

Edit:

Creature colors for both zoom-in (viewing mode = 0) and zoom-out (viewing mode = 1). Two different formats are used, one for zoom-in and the other for zoom-out:

RGB = (red,green,blue) color index.

 

Zoom-in (viewing mode = 0)

Friendly = Blue, RGB = (0,0,255)

Neutral = Black, RGB = (0,0,0)

Hostile = Red, RGB = (255,0,0)

Hidden Class, add green, RGB (0,255,0) to the above colors.

 

Zoom-out (viewing mode = 1)

Friendly = Green, RGB =(0,255,0)

Neutral = Blue, RGB = (0,0,255)

Hostile = Red, RGB = (255,0,0)

 

The only quick fix for standardizing the two schemes is to switch the Friendly and Neutral zoom-out colors. For zoom-out you need distinctive colors, the icons are not currently displayed.

 

Edit:

Here is one standardized scheme.

Friendly = Blue, RGB = (0,0,255)

Neutral = Green, RGB = (0,255,0)

Hostile = Red, RGB = (255,0,0)

 

Hidden Class, add green, RGB (0,255,0) to the above colors for Friendly and Hostile. Neutral can just be made black. This would switch the current Neutral color pairing, but Hidden Class is displayed anyway.

 

 

[Ishad Nha]

The Shift key combined with the relevant key on the numeric keypad is meant to move the view 7 spaces in the relevant direction. However, I read a web article that said the Shift key overrides the Numlock. In BoA the Numlock must be on to move anything. Hence the shortcut key never works on Windows. Replace it with the Escape key? It is in the relevant place for use by your left hand while your right uses the numerical keypad.

 

While I am at it, 8 squares is more relevant to a game where all maps are in sizes that are multiples of 8.

The article was here:

http://blogs.msdn.com/oldnewthing/archive/2004/09/06/226045.aspx

Edit:

This idea works. You could use the A key for a replacement to the Shift key using the function

(GetAsyncKeyState( (virtual key code ) & 0x8000) != 0;

Or the Z key too, though you won't be able to use them as shortcut keys for floors and terrain.

 

[Celtic Minstrel]

Don't replace it with Escape; that's not even a modifier key. A better idea is to fix it so that Num Lock doesn't need to be on. It might be difficult, but there must be some way to do it by getting raw key codes or something.

 

As for the choice of 7, I think you're right that 8 makes more sense, but it's not truly important.

[Ephesos]

Again, can we please leave these in the Windows Editor thread?

[Ishad Nha]

I tried to use the main keyboard numbers 1 thru 0, the way they are used in BoE. I could not bring it off. My chances with Numpad are not that good.

No Escape is not a modifier key, but with GetAsyncKeyState any key can be used as a modifier key.

[Kelandon]

Originally Posted By: Ishad Nha

No Escape is not a modifier key, but with GetAsyncKeyState any key can be used as a modifier key.

My impression was that his point was not about what could be done but about what should be done. A system that uses what is not normally a modifier key as a modifier is going to be counterintuitive, and counterintuitive systems should be avoided if possible.

[Ishad Nha]

There is the tilde, virtual key 192. Then there is the Alt key, but it is meant for use with menus.

Who knows we may start a trend in the use of unusual modifier keys.

[Celtic Minstrel]

What Kelandon says. Please limit your modifier keys to Shift, Ctrl, and Alt. I expect it'd be okay to use Alt as a modifier key, provided the sequence as a whole does not conflict with any existing menu shortcut.

 

Don't forget you can also combine modifier keys – so, you could use Shift and Ctrl together, Shift and Alt, Alt and Ctrl, or even all three.

[Celtic Minstrel]

Originally Posted By: Ephesos

Again, can we please leave these in the Windows Editor thread?

I merged both this one and the "moving terrain around" one; if you look back you'll see that the posts from the latter are somewhat interspersed amongst the other posts in the thread, but they're certainly all there.

[Ishad Nha]

As for NumLock, the good feature of both the BoA game and the editor is that they use the Windows default: NumLock is on. Hence no need to turn it off just to play BoA or use the Editor. So I won't mess with that.

Alt key has code 18 and is called "VK_MENU", I can try that and see how it works.

Edit:

This is not working, the result is simply the same as Ctrl + Numpad key:

shft_key = ((GetAsyncKeyState( VK_MENU ) & 0x8000) != 0) +

((GetAsyncKeyState( VK_CONTROL ) & 0x8000) != 0);

Edit:

The Ctrl + Shift is not working either, which is about what I expected.

[Celtic Minstrel]

That seems like an odd construction there. Why do you have the & 0x8000? It might be better to cast around and see if there is a constant with that value which might make it more obvious what is meant. The != 0 is probably unnecessary, since nonzero is true always... but why are you adding boolean values?

 

Then again, I know almost nothing about the Win32 API, so maybe you're doing it right.

[Ishad Nha]

This works for the present modifier keys when you use one key at a time:

ctrl_key = (GetAsyncKeyState( VK_CONTROL ) & 0x8000) != 0;

You can substitute the name of any other virtual key for VK_Control. Why it works I don't properly know.

[Celtic Minstrel]

Okay. Clearly if the Control key is down, the return value of GetAsyncKeyState will return a value with its highest bit set. If you want to check multiple modifier keys, try something like this:

Code:

ctrl_key = (GetAsyncKeyState( VK_CONTROL ) & 0x8000);shift_key = (GetAsyncKeyState( VK_SHIFT ) & 0x8000);alt_key = (GetAsyncKeyState( VK_MENU ) & 0x8000);

Then to check for (example) the Shift and Control keys, you would have an if statement like this:

Code:

if(ctrl_key && shift_key) { ... }

[Ishad Nha]

State of play:

Alt + Shift: nothing happens

Alt + Ctrl: same as for Ctrl by itself

Ctrl + Shift: nothing happens

 

The first two results are what I expected. I rigged a copy of the editor to report the virtual code of any key pressed. Results are shown for Ctrl and Shift but not for Alt.

We can always use the tilde key as a modifier.

[Celtic Minstrel]

Originally Posted By: Ishad Nha

We can always use the tilde key as a modifier.

No.

You could try GetKeyState() instead of GetAsyncKeyState(); this function works in exactly the same way. I have no idea whether it will get a different result though.

Or you could try to do it properly by reading through this page (and the one it links to) and defining an accelerator table.

[Ishad Nha]

I know all about the accelerators for Ctrl + key, I use them all the time. It will take a while for me to read through all the this msdn resource.

Edit:

As for the Medium view, there are still a few issues.

You can only zoom-in by right-click unless you are in a small town.

Issues with Space acting as Insert. Need to use F3, F4 to change drawing mode.

Problems with mouse clicks acting well away from the proper square.

 

[Lilith]

It's a bad idea to use arbitrary keys as modifiers because not all keyboard hardware will recognise multiple non-modifier keys being pressed at once.

[Ishad Nha]

I will have to find the time to read the pages that Thuryl suggested.

 

Problems reported above with the medium zoom have been fixed. There are still problems with hintbook mode. I will now need to integrate medium zoom into the standard 3D Editor, as a third level of zoom-in/zoom-out.

Edit:

Integration done, there is a problem with the hintbook mode.