CustomGraphicsEngine CSBwin)

[Paul Stevens]

Nope. It is started and works very differently and much
less efficiently. You probably should not use it for simple
translations to avoid the 'Multiple of 16' problem. But it
will still be useful for scaling, rotating, and shearing.

[kentaro-k.21]

i have posted a a sample skin data. testSkin20050704.rar
maybe useful to do debug or something.

you need latest CustomGraphicsDemo10 to test it. overwrite demo's csbgraphics.dat with archive's one. it may replace walls in lower dungeon level.

0th skin will be for default skin map.
1st, 2nd and 3rd skins displayed debug wall image.
1st skin includes floor and ceiling images (from DM2). but i'm unaware of method to displaying them.

thanks.

[Paul Stevens]

I tried this and it crashed at the bottom of the stairs.
The code for skin 1 attempted to draw the contentes
of the cell F0 but was missing some parameters and had
a stack underflow. I don't think you included the source
code for skin 1. (graphic 12?) so I cannot look at it to see
if it compiled correctly, etc.

[kentaro-k.21]

ok, some clarification here.
code of skin#1, #2 and #3 is from Skin2Code.bin in your custom graphics package. it is unmodified.

about bin files,

Code: Select all

masks.bin           --- from custom graphics package.
newMask.bin         --- mask for test wall. (ID=11)
newSkinDef.bin      --- test skindef. (ID=1)
picture.bin         --- picture for test wall. (ID=10, 99)
Skin0Code.bin       --- skin code built from Skin0Code.txt in custom graphics package. (ID=24)
Skin2Code.bin       --- from custom graphics package ver10. (ID=12)
SkinDef.bin         --- from custom graphics package ver10.
ViewportPalette.bin --- from custom graphics package ver10. (ID=5)
WallDec_2.bin       --- from custom graphics package ver10. (ID=13)
xceil.bin           --- picture for test ceil. having 224 by 136 to fill entire viewport. (ID=22)
xceilMask.bin       --- mask for test ceil. (ID=23)
xfloor.bin          --- picture for test floor. having 224 by 136 to fill entire viewport. (ID=20)
xfloorMask.bin      --- mask for test floor. (ID=21)

i made a skin def to satisfy following parameters.

Code: Select all

skin#0
floor graphic = 0
floor mask    = 0
middle graphic= 0
middle mask   = 0
ceil graphic  = 0
ceil mask     = 0
wall graphic  = 0
wall mask     = 0
code          = 0

skin#1
floor graphic =20
floor mask    =21
middle graphic= 0
middle mask   = 0
ceil graphic  =22
ceil mask     =23
wall graphic  =10
wall mask     =11
code          =12

skin#2
floor graphic = 0
floor mask    = 0
middle graphic= 0
middle mask   = 0
ceil graphic  = 0
ceil mask     = 0
wall graphic  =10
wall mask     =11
code          =12

skin#3
floor graphic = 0
floor mask    = 0
middle graphic= 0
middle mask   = 0
ceil graphic  = 0
ceil mask     = 0
wall graphic  =10
wall mask     =11
code          =12

xceilMask.bin, xfloorMask.bin:

Code: Select all

mask#0
srcX    = 0
srcY    = 0
destX   = 0
destY   = 0
width   = 224
height  = 136

i'll write spec of newMask.bin if you need.



Make.bat makes modified csbgraphics.dat.
you can modify the image, then try make.bat. it'll reflect your changes to new csbgraphics.dat. YOU REQUIRE CSBgraphics.exe TO BUILD IT.
some image files can be modified:

newMask00.bmp --- wall masks
newMask01.bmp --- wall masks
newMask02.bmp --- wall masks
newMask03.bmp --- wall masks
newMask04.bmp --- wall masks
newMask05.bmp --- wall masks
newMask06.bmp --- wall masks
newMask07.bmp --- wall masks
newMask08.bmp --- wall masks
newMask09.bmp --- wall masks
newMask10.bmp --- wall masks
newMask11.bmp --- wall masks
newMask12.bmp --- wall masks
newMask13.bmp --- wall masks
newMask14.bmp --- wall masks
newMask15.bmp --- wall masks
newMask16.bmp --- wall masks
newMask17.bmp --- wall masks
newMask18.bmp --- wall masks
newMask19.bmp --- wall masks
newMask20.bmp --- wall masks

picture.bmp --- wall image
xceil.bmp --- ceil image
xceilMask.bmp --- ceil mask
xfloor.bmp --- floor image
xfloorMask.bmp --- floor mask

thanks.

EDIT: added ID for some raw, top.

[Paul Stevens]

That skin2code.bin that you had in your CSBgraphics.dat
was compiled wihen the compiler had a bad error in the
IF ELSE THEN processing. I put the new skin2code.bin into your
CSBgraphics.dat and it works just fine.

I posted a CustomGraphicsDemo11.zip with the new
CSBgraphics.dat and the new skin2code.bin. Your demo
now works for me. Thanks.

[Paul Stevens]

Zyx and I have been working together to debug
the Custom Graphics capability of CSBwin. We worked
on several intermediate releases privately. It works
pretty well now and I posted CSBwin98v61.zip. You
probably don't need this.

--NewGraphicEngine - Overlay Palette implemented
--Designer-specified reincarnation penalty
--Fix - Make invisible monters less visible
--NewGraphicEngine - Fetch skin number of any cell
--DSA - Ability to examine monster possessions
--DSA - Fix crash caused by moving missile cell-to-cell
--NewGraphicEngine - Redraw viewport when Overlay Palette changes
--Dynamic expansion of objectlist. Allows more cells to contain objects.
--Default skins by level
--Fix teleporters that teleport objects-only. They were teleporting everything!
--Fix CustomGraphic expansion to allow 0xff in first byte.
--DSA - Modify &Char@ to include pending character damage
--NewGraphicEngine - Provide method of leaving mortar line under text
--Allow designer-specified weight for chests.
--Display character damage caused by DSA
--Fix timer queue expansion for a very special case.
--NewGraphicEngine - allow destination x-coordinate to not be a multiple of 16
--Fix monster move filter trigger for distance > 0x0f
--DSA - Fix &CHAR@ parameters 10-15. They were always '1'.

[Zyx]

In the skin code, is there a command similar to &PICK? and to &DROP?

[Paul Stevens]

Nope. There is hardly anything. I intend that it have the
entire FORTH-79 word-set, except for the words associated
with the compiler (like HERE and ,) and words associated
with the dictionary ( like ' and EMPTY ) and I/O.

I'll try to add a few today for stack manipulation:
Standard: SWAP DUP OVER ROT DROP and ?DUP.
And I'll put in your PICK and ROLL as non-standard.

[Paul Stevens]

CustomGraphicsDemo17 has a demo of the affine
transformation to build 'Virtual' graphics. The wall
at F1 in skin 2 ( wall 17 ) is shown in mirror image.

[Zyx]

First of all, thank you once again for keeping your promises, as stated in your dungeon.
I'm not sure I understood how the virtual engine is meant to be used (assuming it is meant to save diskspace and unnecessary manual copies of pictures, right?

I'm attempting to make a mirrored view for walls.

1) Using the virtualgraphics command, I understand how to make a mirrored copy of the wallset. But the "normal maks" source offsets won't be fit anymore, so:
a) Should I manually make a whole group of masks for mirrored pictures?
b) Should I use a specific affine transformation for each case so I can use the "normal masks" as before?
c) Should I use a specific affine transformation for each case so the virtual picture always starts at offset 0,0, and I use a (kind of) generic group of masks?
d) Should I use a specific affine transformation for each case so the virtual picture always starts at offset 0,0, and you will provide a way to override the source offset for normal masks?
e) Will you provide a way to create virtual masks, so I create a mirrored view, and a mirrored mask with
NewXsource = OriginalPictureWidth - OriginalXsource ?

2) For non symmetrical masks (mask 02 with stalagtites on the left for example...):
a) Should I manually create the masks for the mirrored views?
b) Should I use the 1)e) feature?

3) Are there some 16pixels multiple restrictions on the virtual graphic?

[Paul Stevens]

Well, the most important question ( I think ) is:

e) Will you provide a way to create virtual masks,

I'm tired. It is 94 degrees in the shade here. And dewpoint of 74.
Nevertheless, we will somehow manage to provide a way to
mirror the masks. But I don't know how we should do this.
So . . .

Perhaps you can suggest what would be best for you.

Are there some 16pixels multiple restrictions on the virtual graphic

The same as for any bitmap graphic. They certainly must
be a multiple of 16 pixels wide. They are used in exactly the
same way as a 'real' bitmap. ( They are real once they have
been created internally. )

[Paul Stevens]

One thing comes to mind that might be less than
totally general but nevertheless useful.

I could flip the mask at runtime very easily.
It has to be a multiple of 16 pixels wide and the
flip would have to be such that no shifting takes
place ( The leftmost pixel becomes the rightmost
pixel, etc.). Then you can transform your walls and
such so as to use the flipped mask directly.

I suppose this suffers from the fact that the flipped
mask would not necessarily start at the correct place.
But since you can draw it on the screen at arbitrary
x-coordinate, maybe that would be OK. But you would
have to include two masks in the graphics.dat because
you would need to specify a different destination-x for
the one that is to be used in reverse.

Supply a virtual mask capability would be OK except that
how do you specify all the parameters for the new mask????

[Zyx]

Well, so far you were suggesting the following operations:
1)Take OriginalPicture
2) Apply affine transformation
3) Take OriginalMask
4) Apply affine transformation
5) combine transformed picture and transformed mask
6) put on screen

What about this:
1) Combine original picture with original mask
2) Apply affine transformation
3) Change offset destination
4) put on screen

EDIT: typos

[Paul Stevens]

What about this:

Impossible. The mask is needed because there is
no transparent color.

Code: Select all

result =  ( screen & ~mask ) | ( picture & mask )

Your 6-step approach is exactly what I originally had in
mind. But the mask consists of more than the 'masking bits'.
It has srcX, srcY, dstX, dstY, width, and height. Hosw does
your step 4) construct these values?

One thing we could do is have you, the designer, put in
a mask for the transformed mask but with zero mask bits.
It would only contain the six parameters. Then you would
ask for a transformed mask to be overwrite it. I would
allocate the proper amount of space, apply the transform,
and add the mask bits to your 'empty' mask. But I am open
to any ideas right now.

[Zyx]

I will first make the simple, plain cases work; maybe, with this preliminary insight, I can come up with better solutions.

Could you provide the following functions:

-IsOdd (party's level+x+y+facing % 2)
- CASE statement (with otherwise)

[Paul Stevens]

None of the Standard Forth definitions contains a CASE
statement. Many have been proposed. Many particular
implementations have a CASE statement and they are commonly
different in their details. Like whether the ENCASE does a DROP.
Here is what Leo Brodie writes in 'Thinking Forth'.

"Should all FORTH systems sinclude a case statement? That's
a matter of controversy. The problem is twofold. FIrst, the
instances in which a case statement is actually needed is rare-
rare enough to question its value. If there are only a few
cases, a nested IF ELSE THEN construct will work as well,
though perhaps not as readably. If there are many cases,
a decision table is more flexible.

"Second, many case-like problems are not quite appropriate for
case structure . . . . ."

I, personally, don't like it. Tell me what you are trying
to do. The last time you wanted a case statement, I
talked you out of it rather easily.

[Zyx]

What is a decision table?

I want to make a generic function that would use the same set of masks for mirorred skins, with a lot of exceptions.

If there are only a few cases, a nested IF ELSE THEN construct will work as well, though perhaps not as readably.

A is equivalent to B, except with more drawbacks: I call this a good point against A!
(I'm not discussing your choice of not providing a CASE statement, but the form of the argument, which is illogical...)


BTW, I found a way to handle all the cases with an affine transformation to the masks as well with modified offsets, but this would include negative X destinations. Since it is allowed to put a mask on the viewport that will go beyond the viewport width (I use transparent pixels in this case), a mirrored picture would need the mask to be put at a negative X coordinate.
I was wondering if you could relax this...

[Paul Stevens]

I cannot figure out a way that negative x-coordinates
might be needed. It would be ugly. Moreover, I don't think
it is allowed to go past the right side of the viewport in
general (The last line) and negative would be ok except
for the first line.

Can you tell me why it is necessary? With an example?
Why not simply shift the mask to the left as part of
the transformation?

A is equivalent to B, except with more drawbacks

I think you mis-quoted Mr. Brodie. He named one minor
drawback but thought the alternative had more than one not-
so-minor drawbacks. The readability is almose the same:

Code: Select all

DUP case1 = IF    xxxxxx   ELSE
DUP case2 = IF    yyyyyy   ELSE
DUP case3 = IF    zzzzzz   ELSE
                    default
THEN THEN THEN

           versus

CASE
  case1  OF xxxxxx ENDOF
  case2  OF yyyyyy ENDOF
  case3  OF zzzzzz ENDOF
            default
ENDCASE

Either way is equally INEFFICIENT.

A decision table is an array of whatever is needed
to process one of many different cases. If you wanted
each skin to do something different then you might make
an array of functions (This is EXACTLY what we do in
the skinCode.txt!!!! The table at the end of the code
tells what to do for each cell and cell-type in the dungeon.
Rather than a HUGH case statement it is a simple array
reference.)
So if you wanted each skin to do siomething different:

Code: Select all

: skin-special-process-A
nop        \ skin zero does nothing
use-mirror \ skin 1 uses mirror
use-red    \ skin 2 uses red
use-mirror \ skin 3 uses mirror
use-blue   \ skin 4 uses blue
etc.
;
\
\
 ['] skin-special-process-A  currentSkin +   @ EXECUTE \ Special cases

Now the table is extremely readable, easy to modify, and
separates the special cases from the code in an obvious way.

[Zyx]

I cannot figure out a way that negative x-coordinates
might be needed. It would be ugly. Moreover, I don't think
it is allowed to go past the right side of the viewport in
general (The last line) and negative would be ok except
for the first line.

Can you tell me why it is necessary? With an example?

No, not necessary, but very common, because of the way the wallsets are done.
Let's take the example of wall mask 08 (meant to go to the rightmost part of the viewport)
Let's suppose also that the wall will only be 50 pixels wide.
So the mask needs to be 64pixels wide to comply with the 16pixels multiple requirement.

Usually, the picture containing the wallsets has one single wall for distance 3 that will be cut off using masks 07,08 and 09.
Since the X source of all the masks needs to be a multiple of 16, and since mask 07 cannot have a negative X destination, then the X destination of mask 07 needs to be 0, and it musn't have a strip of transparent pixels on the left.
In this case, since masks 08 and 09 have their X source from the same continuous picture, there will probably be srtips of transparents pixels on the left and on the right of them.
In the case of mask 08, of width 64, with 50 pixels of wall, it could have 5 transparent pixels, 50 wall pixels, and 9 transparent pixels.
So when mask 08 will be put on the right part of the viewport, a strip 9 transparent pixels will go past the rightside.
When automatically mirrored, because of those 9 transparent pixels (now on the left), the X destination should be -9.

Why not simply shift the mask to the left as part of
the transformation?

Because this would require a case by case affine transformation instead of one single, generic mirroring transformation.

Code: Select all

 ['] skin-special-process-A  currentSkin +   @ EXECUTE \ Special cases

Yes, nice way to do. I will definitively use it.
But I don't understand:
1) ['] ... what is it ?
2) why the + sign after the currentskin?
3) @ ... does it fetch a parameter? from where?

[Paul Stevens]

I will quote from 'Starting Forth' by Leo Brodie, FORTH, Inc.
But a Google search for FORTH-79 will bring up many
definitions of the language.

['] ( -- adr ) Used only in a colon-definition, compiles the address of
next word in the definition as a literal.

In other words, it puts the address of the next word on the stack.
In the example, it is the address of the funnction that I
named 'skin-special-process-A'. Then we add the skin number
to that address and fetch ( '@' ) a word from the definition
itself. That word is the address of another function that will do
the special-case work for this particular skin.

It is a one-word read of an array. The array is called
'skin-special-process-A'. The array contains the addresses
of other functions. That is how a FORTH definition works.

For example:

Code: Select all

: abc  a  b  + ;

Defines a function named 'abc'. The function consists of
four addresses:
1) the address of 'a'
2) the address of 'b'
3) the address of '+'
4) the address of ';'

EXECUTE 'calls' the function whose address is on the stack
and throws away the address. Just as if you had written the
name of that word inline.
EXECUTE ( adr -- )

Example:

Code: Select all

['] + EXECUTE

is equivalent to

+

[Paul Stevens]

I have some business to attend to. Her name is Dianne.
I'll be back to study your masking problem later this evening.

[Paul Stevens]

The Masking Problem. I think I get it. Maybe. You cannot
draw the leftmost wall ( wall 7 ) because the leftmost
bit of that wall does not originate at a pixel in the
source image that is on a 16-pixel boundary.

If you had carefully drawn your source bitmap so that
the leftmost pixel of wall 7 was at pixel 64 of the source
(for example) then there would be no problem. You could
also arrange for the mirrored source to have that pixel
at a multiple of 16.

Is that your problem? Well, even if it is not your problem
I can see that it is a problem that could be fixed with
a negative destination-X. I'll see what I can do to allow
a negative number there. It hurts my head to think of it.
Maybe keep me from developing Alzheimer's. Thank
goodness the code does not get confused when doing such
complex things.

[Zyx]

I will work on th virtualgraphic this weekend, but I would need some functions to write my skincode:
a function to retrieve the width of a picture
a function to retrieve the height of a picture

Also, I lost a little the current state of the graphic engine:
Is the IsOdd function already available?
Can I already apply the virtualgraphic engine to a mask?

[Paul Stevens]

Also, I lost a little the current state of the graphic engine:

Me, too. I also took a vacation.

IsOdd ( -- flag )
CreateVirtualMask ( sourceMaskID sourceMaskNumber
virtualMaskID virtualMaskNumber
transformMaskID transformMaskNumber -- )

Neither has been implemented.
How should we do the latter?

One plan......
You must include the new mask in CSBgraphics.dat but
without any maskins bits. That is, [virtualMaskID virtualMaskNumber]
must exist with no mask bits. This will define the sourceX,
sourceY, destinationX, and destinationY that will be used
when the picture is drawn to the viewport. The width and
hieight must be zero.

The transformation mask will determine the width and height
of the virtual mask and will add the masking bits using the
transformation parameters Cxx . . . Cyc.

Any better ( even good? ) ideas about this?

[Paul Stevens]

The latest 'ViewportCompiler' and your private
debug version of CSBwin implement IsOdd ( -- flag ).

[Zyx]

Counterproposal:
Provide functions to set and get the following parameters:

Picture:
Width (Readonly)
Height (Readonly)

Mask:
SourceX (Read & Write)
SourceY (Read & Write)
Width (Read & Write)
Height (Read & Write)
DestX (Read & Write)
DestY (Read & Write)

The affine transformation should create a virtual mask with the following properties:
Parameters: as the original
Pixels: transformed by affine operation.

It's up to the skincode to set the parameters right.

------------------
Example, for a mirroring effect:
VirtualPic is created from Pic with a mirroring affine transformation.
VirtualMask is created from Mask with a mirroring affine transformation.

For the VirtualMask parameters:
VirtualMask.SourceX = Pic.Width - Mask.SourceX
VirtualMask.SourceY = Mask.SourceY (no changes)
VirtualMask.Width = Mask.Width (no changes)
VirtualMask.Height = Mask.Height (no changes)
VirtualMask.DestX = Pic.Width - Mask.DestX - Mask.Width
VirtualMask.DestY = Mask.DestY (no changes)

This solution should work for ALL the cases, when aiming at a mirroring effect. I think. I guess. I hope so.

[Paul Stevens]

I think. I guess. I hope so

I know. This stuff gets confusing.

I think what you said is that the CreateVirtualMask'
should take an existing mask and create an entirely
new mask. It should copy the
-sourceX
-sourceY
-destinationX
-destinationY
-width
-height
Then it should use the affine transform to create
the masking bits from the existing mask.

Code: Select all

CreateVirtualMask ( oldID oldNum newID newNum affineID affineNum . . . )

Or would you rather provide the affine parameters in
the code, also? ( Cxx .. Cyc )

Then we provide a way to read picture parameters
and a way to read/write mask parameters.
We can easily put the two picture parameters on
the stack. The six mask parameters might best
be put into the array.

Code: Select all

GetPictureData ( . . . width height )
GetMaskData ( arrayIndex . . . )
SetMaskData ( arrayIndex . . .)

Note:
The Pictures have no height really. The height is
computed from the size of the picture and its width.

[Zyx]

Or would you rather provide the affine parameters in
the code, also? ( Cxx .. Cyc )

It would be much simpler to provide them in the code, yes.

I agree with your interpretation of what I said. Or so do I infere from my own interpretation.

[Paul Stevens]

OK. We will try to make it work. Stay tuned. Right
now I am going after your Monster-Movement-By-Level-Filter-Location.
AKA 'MMBLFL'. Mumble, mumble.

[beowuuf]

MMBLFL?

Sounds interesting - what is it?