Code Discussion Thread

[Celtic Minstrel]

I could be wrong, but I think Mixed.bmp isn't where the map graphics are stored anymore...

[Chokboyz]

Originally Posted By: Celtic Minstrel

Indeed, Geneva lacks bold. Fortunately, both Arial and Verdana do have bold.
[...]
By doing this, you'll ensure that most people see Arial (or Verdana), but those who lack that font still see a sans-serif font. (At least, I think SWISS is the sans-serif.)

Your code is right and i'm rightly using wxFont (i pass the facename to the constructor directly), the "problem" is that wxWidgets only loads fonts from the system font folder (as far as i know), so these would have to be installed if needed (i don't know if arial or verdana is present by default under linux).
For information, the font used in Windows's BoE was Times New Roman, which is with serif (hence the need to change the code default values, fonts sans-serif being wider than serif) and it seems that Geneva is sans-serif, so we'd have to agree on a common font ...
As proposed, Arial or Verdana are ok ...

Originally Posted By: Ishad Nha

For an 8*8 zoom display I will need to alter Mixed.bmp to create 8*8 editor icons to replace the present 4*4 variety. This could be done in the BoE Zoom Editor, as soon as I whip up a town with the terrain following the right numerical pattern. Zoom out to 8*8 mode and do a screen capture.

From what i've gathered, you want to implement an intermediate (medium) zoom mode in the Editor, is that right ? If so, i think it would be easier to just use the blit stretch function to enlarge the sprites, negating the need to create 8*8 icons.

Originally Posted By: Celtic Minstrel

I could be wrong, but I think Mixed.bmp isn't where the map graphics are stored anymore...

Mixed.bmp has not been rid of yet, so the map graphics (both versions) are indeed there ...

Chokboyz

[keira]

Why not just eliminate the tiles on mixed.bmp alltofether if we're gonna do this?

[Ishad Nha]

Here and now the zoom-out icons are still stored in Mixed.bmp. I easily proved this when I deleted the icons in this graphic, and replaced them with a lilac fill. Then restarted the Editor, everything was lilac except for the custom graphics. (Yes, I made a back up copy of Mixed.bmp).

Stretching graphics, could be okay but I want them to look good. This should take me ten minutes to whip up.

 

Edit:

After a few misadventures on the way, it is now done and uploaded at the bottom of the Zoom Editor png. Help came from an Excel spreadsheet, the BoE Zoom Editor and a hex editor. The png graphic can be found at:

 

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

[Celtic Minstrel]

Originally Posted By: Chokboyz

Originally Posted By: Celtic Minstrel

Indeed, Geneva lacks bold. Fortunately, both Arial and Verdana do have bold.
[...]
By doing this, you'll ensure that most people see Arial (or Verdana), but those who lack that font still see a sans-serif font. (At least, I think SWISS is the sans-serif.)

Your code is right and i'm rightly using wxFont (i pass the facename to the constructor directly), the "problem" is that wxWidgets only loads fonts from the system font folder (as far as i know), so these would have to be installed if needed (i don't know if arial or verdana is present by default under linux).
For information, the font used in Windows's BoE was Times New Roman, which is with serif (hence the need to change the code default values, fonts sans-serif being wider than serif) and it seems that Geneva is sans-serif, so we'd have to agree on a common font ...
As proposed, Arial or Verdana are ok ...

I'm not too worried about Linux users not having the requested font, really. It would be great if they did, but really, the exact font used is not of great importance.

You say wxWidgets only loads fonts from the system fonts folder? Have you tried loading a font (eg MaidenWord) from the application folder? It might be worth a try; otherwise MaidenWord and/or Dungeon Bold will need to be installed in the system fonts folder for the game to display properly.


By the way, the original Mac version used Dungeon Bold as the font for dialog screens. However, the open source version was distributed with MaidenWord. Which did the Windows version originally use? Which should we use? Or should we give the user a choice?

Originally Posted By: Chokboyz

Originally Posted By: Ishad Nha

For an 8*8 zoom display I will need to alter Mixed.bmp to create 8*8 editor icons to replace the present 4*4 variety. This could be done in the BoE Zoom Editor, as soon as I whip up a town with the terrain following the right numerical pattern. Zoom out to 8*8 mode and do a screen capture.

From what i've gathered, you want to implement an intermediate (medium) zoom mode in the Editor, is that right ? If so, i think it would be easier to just use the blit stretch function to enlarge the sprites, negating the need to create 8*8 icons.

Or perhaps just do what is already done in the terrain palette, and shrink down the full-size graphic.

[Ishad Nha]

I used the lilac version of Mixed.bmp to test the game's automap. The map was lilac except for custom terrain, the game itself does use Mixed.bmp for generating the automap where the terrain on a given square uses one of the standard graphics. (BoA uses the same system, editor icons are used for generating the game's automap.)

I have a complete set of 8*8 icons finished, I can use them to test the new 8*8 view and see if it working properly. After that, simply shrinking the main game graphics may be the route to take.

[Ishad Nha]

The current screen layout uses only a part of the screen. It all depends on the resolution available, the two main rectangles have a fixed area.

RECT terrain_buttons_rect = {0,0,294,410};

this includes the 256 terrain rectangles, the palette, the selected terrain preview and the two printing areas

RECT terrain_rect = {0,0,272,340};

this just includes terrain area and the borders: top and bottom are 8 each, left is 8 and right is 20.

294*410 = 120,540 and 272*340 = 92,480, sum is 213,020.

 

New screen layout update:

"Editing town"/"Editing outdoors" strings have been shifted to the lower right of the screen, and added to the existing "Drawing mode" string.

Town/outdoor name is now in the place originally occupied by the above two strings.

 

[Celtic Minstrel]

No offense, but what you're doing here is rather a waste of time, considering that Chokboyz is completely re-writing the interface.

 

And even if it were not a waste of time, I would disapprove.

 

Originally Posted By: Ishad Nha

"Editing town"/"Editing outdoors" strings have been shifted to the lower right of the screen, and added to the existing "Drawing mode" string.

This is totally illogical; those strings are intended to be a sort of "pseudo-title". I don't understand why you would move the "title" to the lower right.

 

Originally Posted By: Ishad Nha

Town/outdoor name is now in the place originally occupied by the above two strings.

This is perhaps the only change you've made that is actually logical. Good idea. (I may have done something like this already; can't remember.)

 

Originally Posted By: Ishad Nha

"Back to Main Menu" button has been dropped, in the screen shot below it is now palette button 15.

This makes no sense. "Back to the Main Menu" is not a tool. It should not be in the tool palette. Keeping it apart from the other buttons is logical because it has a totally different purpose.

[Ishad Nha]

Ormus had a brilliant interface but work pressures forced him to stop development.

If Chokboyz is totally rewriting everything it should be good but it will take some time to be released. He is rewriting everything in a new format.

"This is totally illogical; those strings are intended to be a sort of "pseudo-title". I don't understand why you would move the "title" to the lower right."

Space considerations, that is why. I am using a 512*512 display as you can see with the graphics. I would like the new interface to be basically useful on 800*600 screen resolution. That leaves little spare space at the bottom for anything.

"This makes no sense. "Back to the Main Menu" is not a tool. It should not be in the tool palette. Keeping it apart from the other buttons is logical because it has a totally different purpose." Treat it as an escape button from the palette. I will probably get around to putting it under the palette at some point.

Currently I am working on a 13*13 large icon display. A larger editor could be made for higher screen resolutions which would have more large icons.

Updated screen shot:

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

[keira]

Would it be possible to dynamically resize the town terrain area based on the size if the window? That way, you aren't wasting a crapton of space if you use a 1280x1024 or you aren't crushed if you use a tiny display.

 

Also, the oppurtunity of spanning a BoE town over two monitors would be too great to let pass.

[Celtic Minstrel]

Originally Posted By: Ishad Nha

"This is totally illogical; those strings are intended to be a sort of "pseudo-title". I don't understand why you would move the "title" to the lower right."
Space considerations, that is why. I am using a 512*512 display as you can see with the graphics.

And yet, it's doubly illogical when you realize that it still says "Editing Town" at the top left.

Originally Posted By: Ishad Nha

I would like the new interface to be basically useful on 800*600 screen resolution. That leaves little spare space at the bottom for anything.

Um... I'm pretty sure the old interface would've fit on that screen size. But why does it matter? Most people have significantly larger screens anyway.

Originally Posted By: Ishad Nha

"This makes no sense. "Back to the Main Menu" is not a tool. It should not be in the tool palette. Keeping it apart from the other buttons is logical because it has a totally different purpose." Treat it as an escape button from the palette. I will probably get around to putting it under the palette at some point.

...what on earth do you mean by an "escape button"?

I'll tell you right now that this will not make it into the final version. I refuse to put the "back to main menu" button in the tool palette. (I'm actually considering removing the "randomly change terrain" button as well.)

Originally Posted By: Ishad Nha

Currently I am working on a 13*13 large icon display. A larger editor could be made for higher screen resolutions which would have more large icons.

...what on earth are you talking about?

Originally Posted By: Taslim

Would it be possible to dynamically resize the town terrain area based on the size if the window? That way, you aren't wasting a crapton of space if you use a 1280x1024 or you aren't crushed if you use a tiny display.

Maybe. A resizable window is something we can consider for a later release. I'd rather work on important functionality first, though; conveniences like that come second.

[Ishad Nha]

"...what on earth are you talking about?"

A larger resolution would enable 15*15 or 17*17 displays in cur_viewing_mode 0 (the large icons mode.)

It would not take long to expand the right rectangle to include a Back to Main Menu button. Right rectangle is the one containing the terrain icons and the palette.

What resolutions do people use anyway? Some Spiderweb fans do have laptops.

[Celtic Minstrel]

Originally Posted By: Ishad Nha

"...what on earth are you talking about?"
A larger resolution would enable 15*15 or 17*17 displays in cur_viewing_mode 0 (the large icons mode.)

15x15 or 17x17 what, now? If you mean tiles, I think it's useful that the terrain area shows exactly as much as you can see in the actual game. I wouldn't want to simply increase the size of the area.

Making the window (and by extension the terrain area) resizable is fine though, but there should be a way to revert to 9x9 tiles.

Originally Posted By: Ishad Nha

It would not take long to expand the right rectangle to include a Back to Main Menu button. Right rectangle is the one containing the terrain icons and the palette.

Why not put Back to Main Menu below the right rectangle rather than expanding it?

To be fair, I don't care where on the screen the button appears, but I would like it if its appearance is the same as in the original editor (the blue button with a label).

Originally Posted By: Ishad Nha

What resolutions do people use anyway? Some Spiderweb fans do have laptops.

I use 1280x800 on my laptop. My desktop is a little larger.

[Kelandon]

I'm hanging out on a 1920 x 1200, and it would be great if I could actually use a decent amount of that screen space in editing any scenarios ever.

[Ishad Nha]

Both the game and the editor use only a fraction of the screen: one half or one quarter, depending on the resolution available on the monitor concerned. CM wants an editor that reflects the display in the game itself. I say the number of tiles in the game is long overdue for an increase, it was after all set at 9*9 back in 1996 or 1997.

As for the Back to Main Menu button, if we are looking at a fairly good resolution then the amount of space in the lower left corner won't be so critical.

[Slawbug]

Having an OPTION to increase the view beyond 9x9 would be great. However, keep in mind that this would (visually) break some old scenarios that assumed the player would never see more than 4 squares away from him.

[Ishad Nha]

Simplest solution would be: default view is 13*13 or whatever. There is also provision to black out all squares outside a base 9*9 core area.

If all else fails we can impose the blackout for all scenarios that have the old format, as indicated by the scenario flags at the start of the exs file.

[keira]

I thought this was just for the editor...whoops. Well, I think the standard gameplay size is good for the game, but in the editor resizable is a good thing.

[Celtic Minstrel]

What Dueck said. We're not going to change the 9x9 tile view in the game because it could affect game mechanics (outdoors, at least), but making the editor resizable is a good idea.

[Ishad Nha]

Slarty wants the option to increase the view beyond 9*9.

On the 26th CM wanted the editor to reflect the game, which will be 9*9. This could be toggled on and off by a blackout hollow rectangle.

[Celtic Minstrel]

Yes, it could, but why would we do it that way?

[Ishad Nha]

Resizing means either having more than 9*9 = 81 terrain tiles in the display or using larger graphics for each tile. CM does not want the former and the latter we can look at.

[Celtic Minstrel]

...can you not put words in my mouth? Using larger graphics for each tile would defeat the whole point of resizing. If/when we make the window resizable, it'll certainly show more than 9x9 tiles. I just suggested that there be a simple way to revert the view to 9x9 tiles.

[The Almighty Doer of Stuff]

The terrain editing area would be expandable or shrinkable in the editor, but NOT the game itself. Whether this is done with a click-and-drag or with a dialogue box, or some other method, can be decided, of course. CM would like a simple "Revert Terrain Editing Area to Default Size" button or menu item, so that it can be done quickly, simply, and automatically; since it will definitely be the most common size to use, as it is the game's viewing size, this makes sense.

[Kelandon]

I'd like a click-and-drag interface, myself. (Snapping to each new row or column as the window expands, if possible.) And a simple button or something to revert back to 9 x 9 sounds like a good idea.

[Ishad Nha]

I was not putting words in the mouth of CM, his various posts left me unclear as to what he actually wanted.

Resizable screens are possibly quite simple, there are some absolute numbers like 4,8,9 that can be replaced by algebraic variables. It would be possible to have separate resizing for both x and y dimensions, for example a display of 16*12 tiles.

Return to default would be simple enough.

Where I have struck trouble is with the code for keypad movement, I am not too sure what the following terrain click numbers mean:

POINT terrain_click[10] = {{150,185},{7,359},{50,359},{270,359},{7,50},{150,206},{270,50},{7,27},{50,27},{275,27}};

(they correspond to: UINT kp[10] = {VK_NUMPAD0,VK_NUMPAD1, VK_NUMPAD2, VK_NUMPAD3, VK_NUMPAD4,VK_NUMPAD5, VK_NUMPAD6, VK_NUMPAD7, VK_NUMPAD8, VK_NUMPAD9}; )

If we are going to have resizable windows we will need the simpler BoA 3D coding for use of the numberpad in 2D mode.

[Celtic Minstrel]

We should definitely not even contemplate resizing at this stage. Once Chokboyz is finished with his wxWidgets port, I suspect adding resizability would be much easier.

[Zalatar]

*yawn*. Sorry. I haven't been on for a long, long, long, long, long, long, long, long, long, long, long, long, long, long, long, long, wait. What am I talking about? Oh yeah! Resizing. I think the resizing in the editor would be great. I am incredibly busy though, and can't help much. My programming has improved : I can now do JAVA. Wait. What about BOEJ? (I may start a forum about this)

[Celtic Minstrel]

BoE is written largely in a procedural paradigm, so porting to Java would not be easy.

 

 

Bumping this thread has reminded me to ask Chokboyz for a status report.

[Chokboyz]

Hello everyone, sorry for the blackout but i just had a busy April month ...

Nonetheless, on with the mixed bag of news :

 

- On the good side, i've been able to finish the new XML dialog engine and subsequently the port of the Character Editor using wxWidgets (which needed much more than the new dialog engine, as Murphy's law could have predicted) ...

 

It's actually fully functionnal (at last, as far as i could test it, don't hesitate to send feedback) on Windows and Linux (Debian Lenny 5.04) with some minor problems on Linux (key shortcuts aren't working because the key_down event doesn't seem to be called at all, and the menu breaks don't either, causing giant items menus; all items are accessible though).

I've rewritten the mian window/dialog engine mostly from scratch, integrating the original code only when it was needed (event handling and such); i've also been able to clean up the ressource file (now an XML file) and some part of the original code (here again i may have missed some, feedback welcome).

 

I've also updated the Character Editor with some of the last features or missing ones such as : displaying of gold, food, day, location (town name or outdoor), scenario (scenario name or "not in a scenario"), item loading from the scenario file (use Bladbase.exs as a backup if can't find the scenario file, lock menus if can't find both), legacy Mac save (or other endianness) compatible loading procedure, ...

 

The new XML-based dialog engine has been largely tested, but is in no way in it's definite state (for example, dialog items should be accessed via their id and not their position in the item vector ; i've made both coincides for now) and comments are welcome.

 

I've uploaded the code in a new branch, entitled "Experimental" and Binaries for both Windows and Linux are available on the Google Site for testing purpose (or use if you new features, should be stable enough for that ... with a backup, of course ) ...

Technicalities : Linux version has been compiled on Debian Lenny 5.04, with gcc 4.3.2 (Debian 4.3.2-1.1); both versions are compiled against the last stable wxWidgets (2.8.11) and Code::Blocks project are available for both platforms.

 

That's it for the good news ...

 

- On the other hand, as Celtic Minstrel mentioned wxWidgets is overkill for Blades of Exile (i should probably fragment the dll for Windows, i'm not really sure how much of it is used) and toying with wxWidgets has confirmed that.

While it is convenient to have all those tools to work with (especially the menus and such, see below what is really needed on each platform), i'm not really sure it's worth the increase in size and memory consumption, for a cross-platformability that is not that great code-wise (must read in "my" implementation of it, of course; i'm not attacking wxWidgets ...).

 

While there's no major problem with the current version of the code, i've been thinking about other possibilities, which would fit Blades of Exile better.

One of such is, of course (and it has already been mentioned), SDL, which (from my testing) is really great when it comes to platform independance and not too intrusive (size, memory consumption, ... as long as you don't mind 10+ dll in your working folder on Windows ).

The main problem we would encounter with SDL is that there's no support for widgets and we would have to either, integrate SDL in a platform dependant window, or create our own set of widgets.

From my experience with the code, here's what, i think, is needed to be taken into account for (graphical) cross-platformability :

• the dialog engine (or ressources in general) : no longer a problem with the XML-based engine. It seems that TinyXML's approach to XML handling is the same as wxWidgets, so convertion should be fairly easy ...
• scroll bars : actually handled by the OS, shouldn't be hard to make our own.
• text input (aka Text Control, aka Text Edit Box, aka White Area Where You Input Text ) : actually handled by the OS. This one's tricky ... I've actually seen implementation of such things in SDL (Widelands, ScummVM, etc), but didn't try yet.
• menus : actually handled by the OS. The big part : if you don't let the OS do the job, we would have to either recreate it or use icon based menus (à la Avernum/Geneforge).
• System Dialogs : Open File, Save File, etc ... actually handled by the OS. I've seen it done in SDL (ScummVM), but that doesn't sound that easy ...

So here we are ... we can choose to go on with wxWidgets (knowing that it's probably too much for the task) or test another way (for example SDL ... we don't need the last 1.3 prerelease though : it would be more practical for programming, but dialogs and such can be done with the old 1.2 ... )

 

Chokboyz

 

P.S : someone asked for a April release of Win32 Classic Blades of Exile, with some of the recent changes, so i've uploaded an updated version of the program.

I remind everyone that wants to compile/fiddle with the code that working (i.e compiling) projects for DevCpp and Code::Blocks are available in the sources.

[Slawbug]

Is there any reason -not- to let the OS handle those things?

[Celtic Minstrel]

Originally Posted By: Chokboyz

So here we are ... we can choose to go on with wxWidgets (knowing that it's probably too much for the task) or test another way (for example SDL ... we don't need the last 1.3 prerelease though : it would be more practical for programming, but dialogs and such can be done with the old 1.2 ... )

I say that since it's done, let's go with it. If we're worried about size, we can compile the game against a nerfed copy of wxWidgets that has only the components we actually use. Personally, I'm not going to bother with that, but once there's a more-or-less stable release anyone else is welcome to try.

[Chokboyz]

Originally Posted By: CRISIS on INFINITE SLARTIES

Is there any reason -not- to let the OS handle those things?

Cross-platformability ... If we let the OS handle these, we'll have to write pieces of code for each platform when we'll introduce some features, say new menu and such (not to mention the fact that we'll have to make a linux (gtk ?) interface from scratch) or when widgets comes into play (wxWidgets makes that unnecessary). I would prefer a code that doesn't rely too much on the platform it's running on, but putting conditional compilation where it's needed would work

Originally Posted By: Celtic Minstrel

I say that since it's done, let's go with it. If we're worried about size, we can compile the game against a nerfed copy of wxWidgets that has only the components we actually use. Personally, I'm not going to bother with that, but once there's a more-or-less stable release anyone else is welcome to try.

Ok, so let's keep and test wxWidgets for now.
I'll keep an eye on SDL in case something official happens (compiling SDL 1.3 on Windows right now is a true nightmare anyway ).

I forgot to mention that if you want to compile the wxWidgets code on Mac, the only mandatory change to the code is to add a conditional compilation at the beginning of the app to load the right font (uses "MS Sans Script" (as in the original Character Editor) for Windows and the "equivalent" Liberation Sans for Linux). The rest of the code, being non-platform dependent, should work the same (in practise, it will probably need some tweaking as the portability is not perfect (cf linux problems)).

Chokboyz

[Celtic Minstrel]

Originally Posted By: Chokboyz

I forgot to mention that if you want to compile the wxWidgets code on Mac, the only mandatory change to the code is to add a conditional compilation at the beginning of the app to load the right font (uses "MS Sans Script" (as in the original Character Editor) for Windows and the "equivalent" Liberation Sans for Linux). The rest of the code, being non-platform dependent, should work the same (in practise, it will probably need some tweaking as the portability is not perfect (cf linux problems)).

This font is used for what? General dialogue text?

[Chokboyz]

Originally Posted By: Celtic Minstrel

This font is used for what? General dialogue text?

Yup ... it's the font used whenever the Maidenword font is not (note that the Maidenword font is not used in the Character Editor).

Chokboyz

[Celtic Minstrel]

So, Geneva in the original Mac version (though I'll probably choose a different yet similar font).

 

By the way, the wxWidgets code appears to only include the character editor. Is this correct?

[Chokboyz]

Originally Posted By: Celtic Minstrel

By the way, the wxWidgets code appears to only include the character editor. Is this correct?

Yes it is : only the Character Editor has been converted for now (mainly for testing purpose) ...

Chokboyz

[Celtic Minstrel]

Alright, we should start on converting the other two programs in the near future, then. If you want to do it, please try to commit a bit more regularly. If not, I'll try to find the time.

 

Alternatively, one of use could focus on the game while the other focuses on the scenario editor.

[Chokboyz]

Originally Posted By: Celtic Minstrel

Alright, we should start on converting the other two programs in the near future, then. If you want to do it, please try to commit a bit more regularly. If not, I'll try to find the time.

Alternatively, one of use could focus on the game while the other focuses on the scenario editor.

It's planned : if there's no negative feedback, i'll probably begin by porting the game ... if you want to give a try at the editor, you're welcome

Chokboyz

[lampshade]

Is it possible to make death less annoying? You know, instead of dropping all your items, it's retained in the PC's inventory.

[Celtic Minstrel]

Possible, I suppose, but I don't see any reason to change it. I want to keep the basic gameplay the same as much as possible (except for fixing bugs).

 

Of course, it's open source, so you could get a copy and make that change for yourself. I'd recommend waiting for a stable release first, which could be awhile.