Code Discussion Thread

[Ishad Nha]

Choice of shortcuts may be changed as new functions are developed. This list is only provisional.

Ctrl + Shift + (Char) is beyond me currently. Blscened.rc just lists the shortcuts as "^(Char)". At some point I could experiment with "^a", "^b" and "^!", "^@"...

[Ishad Nha]

Town report now lists all special nodes and dialog nodes. along with the relevant text messages. Irrelevant lines have been removed. The special nodes listings can be extended to scenario and outdoor reports.

Using lower case and upper case letters did not create any new shortcuts. Ctrl + Shift + (Char) still is beyond me. Now I will have to wade through the Microsoft Knowledge Base or Google it.

[Ishad Nha]

Scenario and town timers have been added to reports.

Tables have been included in scenario, outdoor and town reports showing the lengths of the relevant strings. (For some reason the last 40 outdoor strings caused a crash of the Editor.)

Now all three types of report show the full details for special nodes.

[Celtic Minstrel]

Originally Posted By: Ishad Nha

On a side note, help file says there are 20 Events, the Editor says 10 then the Global.h file shows " short key_times[100];".

So, there's actually space for 100 events? Nice. The next step is to check the event-handling nodes and the area of the code where NPC key events and town key events are checked, and verify that there is no check for < 20.

[Chokboyz]

Originally Posted By: Celtic Minstrel

So, there's actually space for 100 events?

Yup, another unnecessary large array

Originally Posted By: Celtic Minstre

The next step is to check the event-handling nodes and the area of the code where NPC key events and town key events are checked, and verify that there is no check for < 20.

The event-handling nodes checks the key_times[monster_start.time_code] index (monster_start.time_code is between 0 and 9), so no problem here.
During the initialization of the game, the 20 first values of key_times are initialized (to 30000) though.

Hope it helps,
Chokboyz

[Celtic Minstrel]

Well, since we have the space, we might as well use it!

 

Originally Posted By: Chokboyz

The event-handling nodes checks the key_times[monster_start.time_code] index (monster_start.time_code is between 0 and 9), so no problem here.

So, you could change that to check < 100.

 

Originally Posted By: Chokboyz

During the initialization of the game, the 20 first values of key_times are initialized (to 30000) though.

And this could be changed to initialize all 100 of them.

 

 

 

...unless of course the others are used anywhere else in the game.

[Ishad Nha]

Searching all files for "key_times" shows no apparent use of the other eighty Events. This is common in the BoE game, the last 6 horses, the last 6 boats and ten of the 20 scenario timers are not supported by the game yet they are included in the Scenario data structure.

[Chokboyz]

Originally Posted By: Celtic Minstrel

So, you could change that to check < 100.

Then, it must be changed in the editor (i'd suggest to replace the 11 events button (0-10 + none) by a text-field), the code already supporting up to 100 events (minus some check adjustment in one function).

Originally Posted By: Celtic Minstrel

And this could be changed to initialize all 100 of them.

Done.

Originally Posted By: Celtic Minstrel

...unless of course the others are used anywhere else in the game.

As Ishad Nha said, nope, they're not (in fact, only the 10 first events are even used).

Chokboyz

[Ishad Nha]

I am now tidying up the dialogs in the Character Editor. I pasted the Blscened.rc file dialog contents into a spare version of the game, so I am using this to check all boxes.

[Celtic Minstrel]

I was just wondering whether anyone has looked at the code at all recently? I know I haven't, though I might get back to it again in the next few months.

 

---

 

I was also looking around for multiple-window support in SDL, and it turns out SDL 1.3 has it. The only problem is that, according to the official statement, it's still a prerelease version; but I did find at least one person claiming it to be ready for use.

 

It would be perfect for our needs here, though to convert the game to SDL we would need to write or find functions to perform the various blending operations the game uses (unless SDL 1.3 also adds these) and also write code to manually handle a scrollable pane (since it currently uses the native Carbon/Win32 scrolling pane to handle the transcript, inventory, and a number of other things).

 

The only two questions are:

• Should we wait until it's no longer labelled "prerelease"? That could easily be quite a long time, though.
• Is it better to merge the Mac and Windows sources before doing something like this, or would it be better to do them simultaneously?

 

(Note: I did find one example of multiple windows in SDL pre-1.3, but it involved creating child processes which I decided wouldn't really work well for just creating dialogs.)

[keira]

I'd say go for it. After all, if it doesn't work we have old revisions, right?

[Chokboyz]

Originally Posted By: Celtic Minstrel

I was just wondering whether anyone has looked at the code at all recently? I know I haven't, though I might get back to it again in the next few months.

Yup, i've been fiddling with the code on and off, when i find some time, mainly trying to produce multi-platform code ... Which leads to the next question :

Originally Posted By: Celtic Minstrel

I was also looking around for multiple-window support in SDL, and it turns out SDL 1.3 has it. The only problem is that, according to the official statement, it's still a prerelease version; but I did find at least one person claiming it to be ready for use.

I found the same thing, SDL doesn't have multiple-window support (except for the child process method you mention, which would be overkill in my opinion) but it's planned for the next version.
Searching a little more, i found SFML that has such support but decided, after much fiddling, that the windowing support was too much of a burden to do without some sort of canvas (not only scrolling, but menus, etc. Not to mention the integrated XML-like ressource management).
Then i tried classic frameworks (GTK+, wxWidget, QT (a bit)) and found that wxWidget (2.8.10) has everything that BoE needs, to be easily ported (QT may have too, i didn't dwelve too much in it, having some problems with the integrated IDE).
So, i rewrote the main graphical functions (screen drawing, patterns, frames, strings drawing, ...) and i'm currently in the process of finishing to port the character editor (as a test, since the code is pretty straight forward for this one).

Problems found so far :

• wxWidget documentation is really hard to come by (except the official one. That's not such a problem since the basic functions are now done)
• wxWidget uses width and height instead of right and bottom for rectangles (defined a BoERect class that mainly solved that)
• wxWidget handling of custom fonts is non-existent (i may have missed something here) and i've not been able to use the maidfont.ttf font. Possible solution : use freetype for this font.

Originally Posted By: Celtic Minstrel

The only two questions are:

Should we wait until it's no longer labelled "prerelease"? That could easily be quite a long time, though.

From the look of it, that will not probably be anytime soon. The SVN is said (mailing list, etc) to be pretty stable, but i've not tested it.

Originally Posted By: Celtic Minstrel

Is it better to merge the Mac and Windows sources before doing something like this, or would it be better to do them simultaneously?

I'd say it's probably better to have some kind of common platform before merging codes ...
For information : apart from the roads and trims (and specials ?) drawing method (which can easily be integrated while porting), on what does the Mac code differs from the Windows code one ?

Chokboyz

[Celtic Minstrel]

Originally Posted By: Chokboyz

Then i tried classic frameworks (GTK+, wxWidget, QT (a bit)) and found that wxWidget (2.8.10) has everything that BoE needs, to be easily ported (QT may have too, i didn't dwelve too much in it, having some problems with the integrated IDE).
So, i rewrote the main graphical functions (screen drawing, patterns, frames, strings drawing, ...) and i'm currently in the process of finishing to port the character editor (as a test, since the code is pretty straight forward for this one).

Problems found so far :

• wxWidget documentation is really hard to come by (except the official one. That's not such a problem since the basic functions are now done)
• wxWidget uses width and height instead of right and bottom for rectangles (defined a BoERect class that mainly solved that)
• wxWidget handling of custom fonts is non-existent (i may have missed something here) and i've not been able to use the maidfont.ttf font. Possible solution : use freetype for this font.

Oh my. Well, the only reason I was reluctant to use wxWidgets is because it's rather overkill for the job. We would only be using a tiny fraction of its capabilities. SDL, on the other hand, is just perfect. All we really need to a place to draw to; the only thing lacking in SDL was the multiple window support for creating dialog windows, which was why I was reluctant to port to SDL.

That said, wxWidgets might be fine. I wouldn't worry about the use of width and height rather than right and bottom (it's actually much better that way, and my XML format for dialogs does the same thing). Just don't use any of the actual widgets (apart from a scrolled pane), because we aren't going for a native dialog and window appearance; we want the custom BoE appearance.

I'd quite like to see something of what you've done on this.

Originally Posted By: Chokboyz

Originally Posted By: Celtic Minstrel

The only two questions are:

Should we wait until it's no longer labelled "prerelease"? That could easily be quite a long time, though.

From the look of it, that will not probably be anytime soon. The SVN is said (mailing list, etc) to be pretty stable, but i've not tested it.

Yeah, this is why I came up with this. Now that you've started porting to wxWidgets, though, I'm wondering whether we should just go with that so as not to let all your hard work go to waste.

Originally Posted By: Chokboyz

Originally Posted By: Celtic Minstrel

Is it better to merge the Mac and Windows sources before doing something like this, or would it be better to do them simultaneously?

I'd say it's probably better to have some kind of common platform before merging codes ...
For information : apart from the roads and trims (and specials ?) drawing method (which can easily be integrated while porting), on what does the Mac code differs from the Windows code one ?

There are some fairly minor features added in the Mac version that (as far as I know) didn't make it into the Windows version, but I'd say the main differences are overarching structural changes that Ormus and I did. The main trouble is that he did them one way, and I did them in a different way. Naturally I prefer my way.

Take a look at the class files, in particular, to see what I mean.



...I'm hoping someone else (Niemand, maybe) will chip in with their opinion.

[Chokboyz]

Originally Posted By: Celtic Minstrel

Well, the only reason I was reluctant to use wxWidgets is because it's rather overkill for the job.

Agreed, that's the main reason why i hesitated to switch to wxWidget (i had done a semi-functionnal (no dialog) character editor with SFML but wasn't pleased with the final result (strayed too much from the original BoE, although it's probably my implementation)).

Originally Posted By: Celtic Minstrel

I wouldn't worry about the use of width and height rather than right and bottom.

No problem; i've even wrote convenient methods to safely switch between those two concepts (mainly for quick code conversion)).

Originally Posted By: Celtic Minstrel

Just don't use any of the actual widgets (apart from a scrolled pane), because we aren't going for a native dialog and window appearance; we want the custom BoE appearance.

Main window and dialogs drawing is handled by adapted BoE functions, so the apparence is exactly the same as BoE (same background pattern, same cyan dialog frame, ...) . The only "widgets" i use are open file dialogs, menus and, of course, frame and dialog windows (which makes the use of wxWidget even more overkill, i must admit ... ).

Originally Posted By: Celtic Minstrel

I'd quite like to see something of what you've done on this.

I'll have to fiddle a little more with the basic editor code and the ressource management (dialog building) and i'll probably be able to upload a snippet of it looks like.

Originally Posted By: Celtic Minstrel

There are some fairly minor features added in the Mac version that (as far as I know) didn't make it into the Windows version, but I'd say the main differences are overarching structural changes that Ormus and I did. The main trouble is that he did them one way, and I did them in a different way. Naturally I prefer my way.

Take a look at the class files, in particular, to see what I mean.

Ok, i'll look at that.
On Ormus "boe_sounds.dll", i think reverting back to original BoE sound playing won't be hard using wxWidget sound management.

Originally Posted By: Celtic Minstrel

...I'm hoping someone else (Niemand, maybe) will chip in with their opinion.

Would be nice indeed

Chokboyz

[Celtic Minstrel]

Originally Posted By: Chokboyz

Originally Posted By: Celtic Minstrel

Just don't use any of the actual widgets (apart from a scrolled pane), because we aren't going for a native dialog and window appearance; we want the custom BoE appearance.

Main window and dialogs drawing is handled by adapted BoE functions, so the apparence is exactly the same as BoE (same background pattern, same cyan dialog frame, ...) . The only "widgets" i use are open file dialogs, menus and, of course, frame and dialog windows (which makes the use of wxWidget even more overkill, i must admit ... ).

Actually, by "widget" I meant an object that you place in a window; the only such object required is a scrolled pane (probably a wxPane or wxPanel with vertical scrollbar?).

[Chokboyz]

Originally Posted By: Celtic Minstrel

Actually, by "widget" I meant an object that you place in a window; the only such object required is a scrolled pane (probably a wxPane or wxPanel with vertical scrollbar?).

Oh, my bad ... then I don't plan on using any extra widgets.
Speaking of which, won't text edit boxes (white text areas where user can write in) be needed too ?

Chokboyz

[Celtic Minstrel]

Oh yeah, you might need those too. I forgot about that. But no buttons or anything, since we're handling those ourselves. (Unless you actually want to make a new class extending the basic wxWidgets classes.)

[Ishad Nha]

Changing the topic, the new zoom mode is working for the BoA Editor, apart from issues with hintbook mode.

BoE really could do with a larger zoom mode, even on 800*600 resolution there is some spare space. Maybe 8*8 icons instead of the present 4*4?

[Celtic Minstrel]

A new zoom mode isn't exactly high priority right now, but it can be considered.

[Ishad Nha]

I have a screen capture of the Editor at 800*600 resolution. There seems to be a fair amount of room for rearrangement.

BoA can handle 64*64 displays of 8*8 pixel icons, 32*32 displays of 16*16 icons and 9*9 displays of 48*48 icons.

All you need to do is give the BoE Editor the same format as the BoA variety. That should not take long. I can look into it when I am finished with the new zoom level on the BoA editor.

[Celtic Minstrel]

I would advise against trying to add new features at this stage. As the above discussion indicates, there is some movement towards developing a cross-platform source, and any new features would have to be ported to the new API anyway. It would be better to simply write them in the new API to begin with.

[Niemand]

Quote:

Should we wait until it's no longer labelled "prerelease"? That could easily be quite a long time, though.

If you want to give it a try, I'd say go ahead in spite of the 'prerelease' status. It'll take some time, so they may et to a full release version before the port is anything like done anyway. Also, if it turns out that the prerelease doesn't work for what's needed, you can just wait, or maybe even file reports to the the SDL people concerning problems or missing features. (Obviously the first they may well address quickly while the second would likely be addressed more slowly, if at all, but you never know.)

Quote:

Is it better to merge the Mac and Windows sources before doing something like this, or would it be better to do them simultaneously?

I'd think that the best way to go might be to do the merging and porting at the same time. Since the whole point would be that you would be introducing a nice platform abstraction layer, you would ideally be able to take either existing codebase, replace the platform specific stuff, and end up with a result that would pretty much handle both platforms. Realistically you would need to be looking at both and possibly be sticking in some bits of platform specifics here and there, but hopefully not much of that would be needed.

Basically, I think the bottom line is that it's a lot of work, but any of several possible methods, like using wxWidgets instead of SDL can be successful if some person or people want to take the plunge and do it. I regret that I can't realistically, contribute much time to this, but I'd certainly like to keep a hand in and help out.

[Ishad Nha]

I can release a private version with the new zoom levels and see how people like it. Then it can be added to the code source later on.

[Celtic Minstrel]

Niemand, thanks for your thoughts.

 

Ishad, if you want to modify the code to add a new zoom level, I can't really stop you. I just don't think this is a good time. But if you really want to, go right ahead.

 

Chokboyz, if you're still listening... what do you think? Just how much work have you done with wxWidgets, and does it seem to work well?

[Chokboyz]

Originally Posted By: Celtic Minstrel

Chokboyz, if you're still listening... what do you think? Just how much work have you done with wxWidgets, and does it seem to work well?

I'm in the process of finishing to port character editor; in practical, only remains to implement the new dialog construction engine (the one that read xml) which won't be long since all the needed features are already present in wxWidgets.
The only remaining problem is the maiden font handling, as i didn't find a way to have wxWidget use custom fonts (the character editor doesn't use it, but the game does). One workaround would be to use freetype or similar library ...
So far, the main window of the editor is fully functional (i.e file loading, party member selecting, info displaying, item fiddling, etc ...). Last time i checked, i was able to build it on linux (last Lenny Debian 5.04) without an hitch.
Of course, having rewritten (and really simplified) some part of the code (like sound playing), the code is a little rough on the edge (the xml handling is a little crude, but working) but all basic functionnalities are here (except dialogs construction which i will probably finish on my spare time this week-end) and can be improved if the need arise.
(for info, i've rewritten the character editor from scratch, because the code was in need of some cleaning )

Concerning the merging/porting process, once the main objects (windows, dialogs,) will be available (and they all nearly are), all that would be needed is a list of differences between Mac and Windows to smoother.

Chokboyz

[Celtic Minstrel]

If we were using SDL, I think the fonts wouldn't be much of a problem... but if you want to use freetype that's fine.

 

I'm still not sure that wxWidgets is the best choice though, which is why I wanted to take a look at the code. I'm sure it'll work, but I'm still thinking SDL would have been better.

[Chokboyz]

Originally Posted By: Celtic Minstrel

I'm still not sure that wxWidgets is the best choice though, which is why I wanted to take a look at the code. I'm sure it'll work, but I'm still thinking SDL would have been better.

No problem, we can use SDL instead ...
The only downfalls are : no menus or "widgets" supports (meaning we'll have to create menus and text edit area ourselves) and fragmentated libraries (for example, using SDL_ttf for loading the maiden font). Graphical-wise, it's one of the best choice though, because we don't need anything more than blitting (and not at light-speed with that).
The multiple windows problem being (partially ?) solved, we're free to go ...

Chokboyz

[Celtic Minstrel]

Actually, we do need a bit more than just straight blitting; the Mac code uses a few different blending modes (four or five, or maybe three, I think). No widgets in SDL is not a problem, because we don't need them (except for the scrollbars, which hopefully could be implemented fairly simply). No menus is not a problem either, because the Windows version already uses menus (hence no work really needed), and the Mac version of SDL includes a way to use a .nib file for menus. I wouldn't have any problem with fragmented libraries.

 

I suppose we could try both ways (SDL and wxWidgets) and see which works better... if we're careful it could be set up so that the game code simply hooks into one or the other.

 

...one other thing I just thought of is cursors. I'm not sure if SDL has a way to set the cursor, so that might need to be relegated to the native Cocoa/Win32 interfaces as well (I have already altered the code to use the Cocoa interface for changing cursors rather than the Carbon interface, so that's not a problem).

[Chokboyz]

Hum, from what i understand you want to use the native API and integrate an SDL surface on which all the drawing will be done, hence solving the menus problems ... Would work, but we'll have to build an (GTK ?) interface for the linux platform in that case. Or i'm completely missing the point

 

Anyway, i'll finish the dialog construction engine and post the execs and sources (then we'll deal with them or not)

 

Originally Posted By: Celtic Minstrel

if we're careful it could be set up so that the game code simply hooks into one or the other

I'm trying to isolate the platform dependant code as much as possible, but that's pretty hard given the initial code (and the fact i'm rewriting it ).

 

Don't know about the possible cursor problem, but i'd suppose SDL have a way to manage that (loading a small bitmap or whatever) ...

 

Chokboyz

[Celtic Minstrel]

Ooh, I'd forgotten about the Linux issue. In that case, maybe it would be better to stick with wxWidgets. Does it have a way to change the cursor though? If not we may still need to use the native API for changing the cursor.

 

If the wxWidgets version turns out to work really well, we might as well stick with that, particularly since you've apparently put so much work into it.

[Kelandon]

Um, dumb question. When you do your cross-platform stuff, will that solve the age-old problem that Win-BoE can display more text in dialogue than Mac-BoE could, so Windows designers sometimes overflowed the dialogue box and we couldn't actually read everything they wrote?

 

Or has that problem already been solved? I haven't been paying close enough attention.

[Celtic Minstrel]

I have no idea whether it will solve that problem; however, I have been toying with the idea of adding a scrollbar to the dialogue screen, which would solve the problem.

 

Unless the problem is that the strings can only be 256 characters. That I believe is already no longer the case.

[Chokboyz]

Sorry about the delay, lots of things to do ...

 

Originally Posted By: Celtic Minstrel

Does it have a way to change the cursor though?

Yes, there is (but i haven't done it yet).

 

Originally Posted By: Kelandon

When you do your cross-platform stuff, will that solve the age-old problem that Win-BoE can display more text in dialogue than Mac-BoE could, so Windows designers sometimes overflowed the dialogue box and we couldn't actually read everything they wrote?

It all depends on wxWidget well handling of the cross-platformability (if this word even exists ) ... but even if it doesn't (i.e fonts size differs from platform to another), a simple conditional compilation with different sizes would solve the problem.

I don't exactly know when the problem occurs, but if it's in dialogs then it would be solved with the new dialog construction, if it's while talking, the above solution would do the job.

 

Originally Posted By: Celtic Minstrel

I have been toying with the idea of adding a scrollbar to the dialogue screen, which would solve the problem.

That's definitely another possibility ...

 

Chokboyz

[Kelandon]

It's while talking. Win-BoE can display a full 256 + 256. Mac-BoE can display significantly less (256 + something like 100 — I forget, since it's been maybe 9 years since I last designed for BoE).

 

A scrollbar would be great, especially if the 256 character limit has been removed.

[Slawbug]

Or just get rid of that obnoxious giant font. That had to be my least favourite change introduced in E3.

[Cryolemon]

I'm not sure there is any reason for the 256 + 256 character limit, assuming it hasn't been removed already.

[Celtic Minstrel]

Originally Posted By: CRISIS on INFINITE SLARTIES

Or just get rid of that obnoxious giant font. That had to be my least favourite change introduced in E3.

I'm definitely not going to get rid of the font, but decreasing the font size is a possibility. There's also the question of whether to use Dungeon Bold or MaidenWord... or to somehow use both...

[Slawbug]

Theldrow FTW

[Celtic Minstrel]

...I have no idea what you are talking about. Sorry.

[Kelandon]

Apparently this. Before my time.

[Slawbug]

More specifically, Fantasoft extracted a font from the Theldrow game, which they called Theldrow, and used it in Realmz.

[Chokboyz]

Following some requests/reports here : http://www.ironycentral.com/forum/ubbthreads.php?ubb=showflat&Number=179512&page=5 (see Taslim) and on the Google Code site, i've uploaded a quick revision of the Classic Blades of Exile code.

 

Changelog :

 

Blades of Exile :

• Corrected the Skill and Giant Strength abilities handling so that they actually

  increase the chances of hitting instead of decreasing it (damages were correctly

  handled).

• Now trying to enter a blocked space multiple times won't produce a lot of

  message but add a (xX) suffix to the "blocked:" message (X number of tries to

  enter the space)

Minor Editor changes :

• When opening a new town or assigning a new town to a town entry on outdoor map,

  the input field is already selected (extended the basic function for

  flexibility).

Code-wise :

• Added a custom makefile for DevCpp which solves the ressources multiple-

  definitions problem (only Game and Editor, the Character Editor wasn't affected).

• Readded legacy monster skill constants to CONSTS.h, to make the original code

  easier to understand for newcomers.

Chokboyz

[Celtic Minstrel]

So, what of the wxWidgets stuff? How's that coming?

[Chokboyz]

Originally Posted By: Celtic Minstrel

So, what of the wxWidgets stuff? How's that coming?

The basic dialog creation (size, text via xml) is done, but i ran into some trouble : first the Windows dialog creation variables (width, length) are somewhat off (easy to fix) but more important, wxWidget text handling has proved lacking (may be my fault, i don't put the blame on wxWidgets), as for example the text size is not consistant from one platform to another.
I'm now planning to use freetype to handle all font creation and text drawing.

Chokboyz

[Celtic Minstrel]

Can you give more details about the text problem? For example, what font are you using? The Mac version uses Geneva Bold 9, 10, and 12 (and Geneva Plain 9) if I recall correctly. Since Windows doesn't have that, you could try Arial or Verdana. (Or might the problem be that a font is not being specified and wxWidgets is using the default system font?)

 

Using freetype is an acceptable choice, in any case.

[Chokboyz]

Originally Posted By: Celtic Minstrel

Can you give more details about the text problem? For example, what font are you using?
[...]
(Or might the problem be that a font is not being specified and wxWidgets is using the default system font?)

That's the problem, wxWidgets uses its own font mananagement (i didn't find a way to load a font from a ttf file) and it seems not consistant between platforms (will read about these to make sure, maybe i'm missing something after all). So, i'm actually using the default wxWidget fonts.
Apart from this font/size problem the text displaying functions are done.

Chokboyz

[Niemand]

Quote:

The Mac version uses Geneva Bold 9, 10, and 12 (and Geneva Plain 9) if I recall correctly.

This sounds correct from what I remember, and also in conjunction with what's in the BoA editor. You might want to give up on trying to use that exact set of fonts anyway, as I discovered, to my significant annoyance, that there's actually no such thing as Geneva Bold[^1], at least installed normally on Mac OS. It appears that Quickdraw will synthesize bold fonts on demand, but newer text rendering mechanisms won't.

[^1]: I did find something (likely of questionable legality) on the internet labeled as 'Geneva Bold', but now that I look closely at it it doesn't appear to quite be Geneva at all; 'Q', 'G', 'K', and 'k' in particular are strikingly wrong, although most of the basic look is preserved. I'll have to try comparing it with what Quickdraw gives for 'bold' Geneva.

[Slawbug]

Oh, Quickdraw. And Hyperscript. And the Macintosh Toolkit, and all of their friends... where have you all gone?

[Celtic Minstrel]

Indeed, Geneva lacks bold. Fortunately, both Arial and Verdana do have bold.

 

If you're using wxFont, I think you'd pass wxFONTFAMILY_SWISS to the constructor as the font family, then call the member function SetFaceName(_T("Arial")). (Or Verdana.)

 

(Note: Above code snipper probably needs tweaking to work.)

 

 

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.)

[Ishad Nha]

Back to the idea of a BoE Scenario Editor that has better zoom-out displays. This topic, like all topics, is one-directional, it is all up and down. What we need is a way to branch off in an x - direction.

It looks straightforward, no problems that I can see. 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.