game and editor should use the same draw_terrain() function.

[NQNStudios]

I've seen a lot of weird visual bugs in the scenario editor when rendering the terrain view. We ought not to try to catalog, debug, and fix all these in scen.graphics.cpp, when there is already a more working implementation of terrain rendering in the code-base at boe.graphics.cpp.

I think the additional things the scenario editor renders on the terrain view should be added to the boe.graphics.cpp function implementation as optional code paths. This function should be moved to a shared source file, and maybe should be given a structure that contains its various options because there are many relevant ones.

For instance:

• What is the top-left corner of the terrain panel?
• Are we rendering terrain omnisciently, or limited to line-of-sight from an origin tile?
• Are we rendering with light and darkness masking?
• Are we rendering with secret doors labeled/visible, area rectangles visible, etc?
• Are we rendering items on top of container tiles?

By making control of these parameters granular, we can do cool things in the scenario editor such as an LED enabling a WYSIWYG view of the lighting in a dungeon.

If the game's draw_terrain() function is entangled with anything that won't compile in the scenario editor (I'm thinking that animated terrain probably uses timer objects and things that are only declared in the game source files) we could use compiler flags to skip those parts when the editor is the build target. #ifndef SCENEDIT or something.

[NQNStudios]

We can use this to implement #562 rendering a smaller window in a dialogxml to preview a selected location. We could also use this to render a preview of where a party's position is in a save file (I want to make an in-game save file browser).

[CelticMinstrel]

This isn't a bad idea. There are tons of differences though, so it would probably take a lot of work to actually get the game's draw_terrain into a state where it can also be used in the editor without losing anything.

Thus, I have a few more to add to your list:

• What to do beyond the edge of the area?
• Are we hiliting any spaces? (For showing the hovered spaces in the editor)
• What size are we rendering the tiles at?

In the game, if I recall correctly, there are at least 2 possible answers – in town the edge tile is duplicated to infinity, and in combat only blackness is rendered beyond the edge (although, combat arenas are surrounded by the "pit" terrain, so that might reduce to duplicating the edge… but I think it would be better if we can stop using terrain 90 as a magic "edge of combat barrier"… unless I already did away with that? I can't remember). I'm not sure what happens outdoors in-game, but in the editor I believe the current answer is "add one strip of the adjacent section". Also, the editor lets the background bleed through for out-of-bounds, rather than filling with black (you can see this best by zooming out).

The scenario editor has four different zoom levels… and one of those zoom levels is identical to the in-game automap if I recall correctly, so couldn't we also merge in automap rendering here? That adds a few more things to consider:

• Are we rendering monsters (and the party) as squares instead of sprites?
• For that matter, are we rendering monsters at all? (Monsters are only rendered on the automap when the Detect Life spell is active.)
• Should we render invisible monsters or not? (Invisible monsters like the guardian or black shade have an icon which is not used in the game… but it makes sense to use it in the editor so you can see where you placed them!)
• Should we render inactive monsters? (Monsters that exist because a special encounter will place them, but the encounter hasn't been triggered yet.)
• Are we rendering the barrier layer, including special spots?
• Are we rendering vehicles? (Game and editor do, automap doesn't)
• Are we rendering items at all? (Automap doesn't)

By the way, the game and the scenario editor don't quite agree what a "monster" or "item" actually is. That is to say, they each have separate structures representing a "monster" and an "item". So we'd need to account for that too.

And looking at the drawing code in boe.graphics.cpp, I can find even more considerations:

• Do we draw roads? Do we draw terrain frills? Do we round off walkways? (We don't in the editor or on the automap… though maybe we should in the editor, not sure.)
• Do we have text labels to render? (If I recall correctly, this is one of the cutscene functions I added, for showing a text bubble over a character for example.)
• Do we render each PC separately or just the party? (Combat vs non-combat)
• Do we need to render a frame around some space? (For the selected PC / active monster in combat)
• Do we need to render any target icons? (To show the selected target in multi-target spells)
• Do we need to render targeting rectangles? (To show the area that will be affected)
• Do explosion and missile animations factor into this at all?

Some of these may not be relevant to terrain though. I'm not sure.

Are we rendering with secret doors labeled/visible, area rectangles visible, etc?

Isn't this better phrased as two separate elements?

• Are we rendering with small icons visible?
• Are we rendering with area rectangles visible?

Note: there are at least 3 different types of area rectangles: town boundary, named areas, and saved item areas. I don't think the scenario editor shows the 3rd type in any way at the moment, but it would be nice to be able to visualize them as well.

As for small icons, they come from a variety of sources, so using them might require passing in a list of icon locations (but it could automatically add in ones that come directly from the terrain definition, either automatically based on the terrain's properties or because the terrain explicitly requested a specific icon).

By making control of these parameters granular, we can do cool things in the scenario editor such as an LED enabling a WYSIWYG view of the lighting in a dungeon.

That would be awesome – the open-source Blades of Avernum editor added this feature, so it'd be great to see it in Blades of Exile too.

(Which reminds me, I hope he releases Blades of Avernum as open-source soon too…)

If the game's draw_terrain() function is entangled with anything that won't compile in the scenario editor (I'm thinking that animated terrain probably uses timer objects and things that are only declared in the game source files) we could use compiler flags to skip those parts when the editor is the build target.

Hmm, I don't think the animated terrain uses anything like a timer object, but I don't really remember how it works. I do know that we support animated terrain in the dialogs now, though. And it definitely wouldn't hurt to support it in the editor too, either as an option or only when WYSIWYG mode is enabled. (Actually, I guess "preview" mode is a better way to say it.)

So then there's yet another option for the list:

• Are we animating terrain?

Not animating terrain would also mean the magic barrier doesn't get animated, of course. Even though it's not technically a terrain.

We can use this to implement #562 rendering a smaller window in a dialogxml to preview a selected location. We could also use this to render a preview of where a party's position is in a save file (I want to make an in-game save file browser).

Hmm, we could, though I was planning to make that much simpler and only show the base terrain layer (or rather, it's not really showing the map at all, just a 2D grid of icons of the same type). I'm not sure how much point there is in showing the monsters in such a picker?

[NQNStudios]

The scenario editor has four different zoom levels…

Wait, how do I use them? This isn't obvious to me in the UI and I want to use them.

[CelticMinstrel]

In the terrain palette, the icon in the second row from the top and second column from the right. Clicking that button cycles between the levels.