Dungeon Master Forum

I've got it.......!!!!!! The final solution.

You can provide as many graphics and masks as you
please. 500. 1000. 5000. And you define the order
in which they are drawn.

You provide a table that says for each of the 5000 masks:

"Draw this if wall segment n exists (or does not exist) AND
wall segment m exists (or does not exist). For example,
the wall immediately in front of the party might be defined
by three masks (There are other ways to do it!):

Draw the main wall with straight edges if the wall directly
in front exists.

Draw an irregual extension to the left if the front wall
exists and the left wall does not exist.

Draw an irregular extension to the right if the front wall
exists and the right wall does not.

All this information would be in the wall mask graphic.
Then I can start to implement before you decide how you
want the graphics to work. And you can have very simple
cases of straight edges if you so choose. Or you can have
very complicated rules if you so choose.

All I need to do to start the implementation is to number the
walls and I can do that by assuming an extremely conservative
estimate of which wall segments will be of interest. You will
probably not use them all.

OK. Here is what I propose. Each skin will accomodate
an arbitrary number of 'Computation Nodes' which will be
general boolean functions with up to four inputs. Each
floor, middle, ceiling, and wall mask graphic can accomodate
an arbitrary number of masks. Each mask will define which
boolean variable allows it to be drawn. All the masks will
be drawn in the order they appear so that you can decide
the order. The masks will also be able to trigger the
drawing of a cell's contents or a wall's decorations.

I think this will allow us to do things like put the moon in the
southern sky. Or to draw a path in the grassland (like
you see in 'Crusaders of the Dark Savant'). Or to draw
the four sides of a Coke machine (my apologies to purists)
from four directions.

Mostly, it is designed to be a bit open-ended so that it can
accomodate things we have not yet thought of. I am sure
that youse folks will think of something new to challenge it.

This will break Charlatan75's dungeon. But most of his work
will fit right into the new scheme.

Any serious objections? Stupendous suggestions? Cries of
fear? Comparison to DSAs? Too good to be useful? Overkill?
The computation nodes are the only part that I might have to
help you with, I think. But not because of complexity....just
unfamiliarity.

Hello!

Hmmm... I must say that it sounds very interesting!

I would like to ask a (stupid?) question :
If I draw a chair for example, and would like to be able to place it wherever I want, facing the direction I want - will I have to design 4 different skins for this chair (one facing North, one facing East...) or will one skin be sufficient (is there a possibility to say : "this chair is facing East and this one is facing North" for example)?

I thought about this question because of the Coke Machine... (it's right that there should be one in the Hall of Champions, because they often ask for a drink when you re-incarnate them, and it seems that they don't like water... Hmmm... Wine should give good results). ^^

Charlatan75

My plan would force you to have four skins if you want
chairs facing in four directions. Because there is no place
else to put that information (which way the chair is facing)
unless you were to choose the direction based on the location
in the dungeon, perhaps, or some other method.

However, keep in mind that the four skins would share the
same graphic and masks. Only the computations would
change.

Because of my planned ability to add new cmputations to
the set we might initially release, we probably would eventually
find a way to do this with a single skin if it becomes a
common need. Perhaps by putting a disabled actuator in
the cell with the chair and allowing the Computational elements
to examine parameters in that actuator.

Oooooh! What tangled webs we weave!!!! Yummy stuff.

GREAT QUESTION, by the way. Thanks.

I have another GREAT question:

What do we do about the EDGE of the dungeon?
The cell to the left of cell (0,0)? How do we define
its skin number?

1) - Should it always have the same skin
number as the nearest cell within the dungeon?
(-1,0) -> (0,0)
(0,-1) -> (0,0)
(1,-1) -> (1,0)

That won't work well if you want a Coke machine in (0,0).

2) - Should the designer specify an 'edge' skin for each level?
That won't work well if there is water to the south and
forest to the north.

3) - Should it always be skin #0 and the designer avoids the
problem by not using the edges? We have 64 levels.
30x30x64 is still pretty big.

What else could we do? I kinda prefer a combination
of 2) and 3). An edge skin by level and the designer
avoids problem that arise by hiding the edge. Can you
see a dungeon level surrounded by Coke machines?
All facing north?

I vote 2 and 3:
the designer should specify an 'edge' skin for each level, and avoid the problem by not using the edges.

Does the curent version already works with skins for the wallsets?

Does the curent version already works with skins for the wallsets

Your question is well-timed. I have been putting several hours
every day into the wallset graphics. I have written a compiler
that will allow you to draw all the walls, decorations, doors,
teleporters, and so on. I am rewritng the entire viewport
drawing code to use the compiler rather than the C-code that
is currently used. I have gotten as far as drawing only one
location in the viewport, namely the cell one forward and one
to the right of the party. It sounds like very little but that first
one is the tough one because the entire compiler and interpreter
must be pretty much complete before it could work.

Here is the code for cell F1R1 (forward 1 right 1) for a Stone cell:
You will be able to draw anything you please by replacing
these built-in functions.

I have to provide you with a line-ending sequence for text.
The executable I post will contain some of this new
viewport code. There will probably be anomalies.

The wall quadrants picture you put is very useful Cows. Thank you!

Is it a rough estimation or is it exact down to the pixel so I can use this to create my mask zones?

it's not pixel for pixel on the diagnal, however it does show the edges of the walls for vertical and horizontal lines. if you want more precise detail I can do that for you.

I posted CSBwin98v52test2.

It implements the new graphic engine for cell F1L1.

It adds more information to the error messages so
that (hopefully) we can fix most things by just knowing
the error message itself without having to ship game saves.
I test a lot of things but it is hard to test them all. Please
report any problems.

External portraits with number 255 doesn't show.

I think you already warned me about it, but anyway:
I usually get an "unknown display opcode" error message
Doors are not drawn at F1L1.

at F2L1, objects inside walls are drawn.

External portraits with number 255 doesn't show.

I see one place the portrait ordinal was limited to 8 bits.
I fixed that one place in 98v52test3. Let me know if it
still is broken. (There may be no way yo fix it).

at F2L1, objects inside walls are drawn.

Thanks. Get 98v52test3.

98v5test3 also fixes the line breaks in &SAY.

I'm fiddling with the floor masks and I don't see that the masks 5 and 6 (respectively F2L2 and F2R2) correspond to a visible part of the floor. (I didn't test it yet). Can anyone confirm/infirm this?

Those were included because it appeared from someone's
diagrams that a couple pixels were included. I thought it
best to have useless entries rather than missing entries.

But I cannot answer your question authoritatively. In any
case, you can use them for any purpose you like or
ignore them if you choose.

I've been out camping and which explains some delay
in getting some reported problems fixed.

mine?? my first one was not pixel accurate.. as described above. I did do a perfect one for ZYX though.. but I don't think I kept a copy myself.. but perhaps you could post it? or send it to Paul?

moo

No problem. I'm using your second diagram, Cows.
The way Paul did it will be useful for protuberant floors, (like a forest for example) the thing is how to use them. I'll have a try some day.
For now I'll stick with the simplest task: making work a basic floorset.

Debugging this new Viewport Graphics Engine I have
made several errors. Things appear to move about
and disappear when they are drawn in the wrong
locations. Walls, doors, anything and everthing can
be made to appear in the wrong places.

If someone were REALLY clever he might take advantage
of this capability to make a level that is a real HELL.
You cannot believe your eyes. Everything is a nightmare
of unreality. You have to figure out the display problem
and know ( for example ) that when you see something
one square ahead and one to the right that you can pick
it up immediately in front of you on the left side. You have
to back off one cell to Stab that Screamer.

Also, could apples bite you when you pick them up?

Ah!!!! The Apple-Picking Filter! No problem now
that we have Filters so well established that my
fingers can implement them without my knowledge.

Seriously, it would not be hard to implement a
pick/drop/swap filter.

"Pick up a broken apple and watch your friend on the left die
a horrible death!!!" Then only the leftmost party member would
dare to pick it up. Only a Wizard could touch that scroll. Etc.

I'd rather have the party attack filter first.

*whistles*

(30 entries in the todo list related to this filter).

Tell you what. I have the 'internal' portions of the Viewport
Graphic Engine about 80 percent conplete. When I am done with
that part of it I will switch to Party Attack Filter. In that way, the
internal parts can get a bit of testing before I tackle the external
parts. The engine will be used to display the viewport even for
un-modified dungeons like 'Standard DM' and will undoubtedly
have a few bugs to be worked out.

I agree with this strategy. While you're still working on the graphic engine I'm preparing some floorsets.

Should the alternative view of the skins work already for the floors? I put skins 128 and 129, but nothing happens, only skin 128 is displayed on the floor.

I don't know if they work in the most recent versions.
The method will be changed and I may have broken the
original method of displaying the graphics. It may also
be that it never worked for more than one custom skin.
The code was very experimental and not at all complete.

Version9.8test10 ( in BackgroundGraphics.zip ) demonstrates
the old method and works OK for one skin. You should be able
to use it for testing your graphics.

When I finish the Viewport Graphic Engine you will have
to change the way you do things. But all of your graphics
and graphic masks will be usable.

Does that answer your questions for now? The long and
short of it is that this is all a work-in-progress although if
you have no way to test your graphics then we should at
least make testing possible.

Testing and designing more with the floorsets, I stumbled upon the following idea:
the wallsets should be defined by two possible methods:
1) first, a skin on the wall tile.
2) if there's no skin on the tile of the wall, then it will use the skin of floor it is facing.

This would have several advanges:
- allowing standalone walls like columns using method 1.
- allowing tiles with up to 4 wall sets, one for each facing, matching the floor, using method 2.
- halving the time of design since you only have to skin the floors, the wall will automaticly fit

This leaves the problem of putting a standalone wall with the default wallskin in the middle of a new floorskin. Creating a wallskin with no mask, no picture (like the skin 0) will fix this.

I need concept art to visualise this, could you mock something up? Sounds powerful...

I think this sort of thing will be quite possible. But none
of it is going to be really simple. Things like "See Through
Walls" magic make things complicated.

I've posted CSBwin98v53.

It has all the internal Viewport Graphic Engine implemented.
I would appreciate any testing of this version. I am sure there
are bugs in the viewport display.....let me know what you find.
Otherwise it should be at least as good as any previous version.

Zyx and I have been discussing all of this offline.
I have produced a new page of documentation with
my latest ideas on the subject.

http://www.dianneandpaul.net/CSBwin/doc ... phics.html

1) first, a skin on the wall tile.
2) if there's no skin on the tile of the wall, then it will use the skin of floor it is facing.

SInce YOU will write the code, YOU can do this if you choose.
I will provide a function to return the skin number of the tile
that a wall faces.