CustomGraphicsEngine CSBwin)

Post by **Gambit37** » Thu Jun 23, 2005 8:06 pm

I have made some mossy walls, but I don't remember ever releasing them. Weird!

rain` · Post by **rain`** » Thu Jun 23, 2005 8:32 pm

Ahhh yes of course you didn't release them, thats right. You sent me that graphics.dat file because it wouldn't load in ADGE. I no longer have it, and I don't believe it is publicly available, but it would be a great start point for custom graphics. I would appreciate it if I could use that graphics.dat file as a basis for the custom engine (i.e. making a skin draw those exact custom walls). If you still have it, would you consider sending it to me again?

-rain`

Post by **Zyx** » Thu Jun 23, 2005 11:14 pm

I assume Currentcell returns a number between 0 and 20.
Is it some kind of CASE statement? If not, how could I test if currentcell is equal to a given number?

Post by **Paul Stevens** » Thu Jun 23, 2005 11:42 pm

I'd like to retrieve the skin number of a relative cell of my choice

I updated the Custom Graphics documentation with a description
of the available words. What you want is not there and I
will add it.

Is it some kind of CASE statement

No. no. CurrentCell is an inter from 0 to 20. But the
runtime performs a 'kind' of CASE statement when
it executes your code. It is actually a table lookup
to find which function to execute but it could be implemented
with:

Code: Select all

switch (celltype)
{
  case PIT:
    switch (CurrentCell)
    {
       case F2R1: xxxxxx; break;
       . . . . 
    };
};

how could I test if currentcell is equal to a given number

Code: Select all

CurrentCell F2R1 = IF a b c d e ... ELSE f g h . . . THEN

[/code]

Post by **Zyx** » Thu Jun 23, 2005 11:46 pm

Ooops, sorry, I meant "Is there some kind of CASE statement?"
Anyway you answered my question.

Thank you for the documentation. It helps a lot.

Post by **Paul Stevens** » Thu Jun 23, 2005 11:56 pm

Thank you for the documentation.

It is a kind of first-pass sort of thing that I threw
together. Most of it will never be used. The new
words will get a better description. And let me know if
there are some old ones that you need to use and cannot
figure out. I will try to figure them out.

Post by **Zyx** » Fri Jun 24, 2005 12:09 am

something similar to &DUP and &DROP would be useful

Post by **Paul Stevens** » Fri Jun 24, 2005 12:13 am

some kind of CASE statement

None of the early Forths had a case statement.
Later versions had various CASE structures.
It is not too hard to implement if you would find it
very useful. Otherwise you need to do DUP IF DROP
ELSE DUP IF DROP ELSE .... THEN THEN THEN kind of thing.

Post by **Zyx** » Fri Jun 24, 2005 12:25 am

What I need to do is something similar to:
switch (CurrentCell)
{
case F2R1: xxxxxx;
. . . .
}

Post by **Paul Stevens** » Fri Jun 24, 2005 1:08 am

Are you sure? This is all sorted out before we call your
code. We call one function for F2R1. We call another
function for F2. Another for F2L1. Etc. We call separate
functions for each celltype, also. 168 different cases.
Could I see an example of a necessity to sort all of this
out again?

If there is common codeA, then particular code, then
common codeB one technique is to write a function for
codeA, a function for codeB and then the code for a cell
would look like:

Code: Select all

: drawF2R1 codeA particularCodeF2R1 codeB ;
: drawF2   codeA particularCodeF2   codeB ;
etc

Forth is VERY good at 'factoring' because the overhead
of calling a 'sub-function' is minimal. By factoring I mean
splitting out phrases and putting them into their own functions.
For example you might want to increment modulo 16:

Code: Select all

1 + 15 AND

but you could easily write instead

: 1+ 1 + ;
: Inc16 1+ 15 AND ;

and then use the word Inc16 instead. In fact, '1+' is a
required word and is commonly defined in exactly this way.

See, for example:
http://forth.sourceforge.net/standard/fst83/

Making your own words in this way makes your code
almose self-documenting. If you are willing to give
things nice self-describing names. Like 'IncrementMod16'.
That looks much better than '1 + 15 AND'.

kentaro-k.21 · Post by **kentaro-k.21** » Fri Jun 24, 2005 4:46 pm

i'll post small command line tools to maake skindef, picture and masks in few days.

thanks.

Post by **Paul Stevens** » Fri Jun 24, 2005 8:31 pm

The other thing I should point out that may not be obvious.
You can use punctuation and all sorts of things when
naming your functions. You can redefine '2' if you choose
(not recommended). Words like ?Empty to ask if something
is empty. 2* to multiply by 2. Putting special characters
and punctuation in your names can make things easier
to understand. For example, a question mark in a name
usually means that it returns a 0 or a 1 as a boolean function
that asks a yes-no question.

rain` · Post by **rain`** » Fri Jun 24, 2005 8:39 pm

Can the sourceX and sourceY value of a mask be negative?

Theres a reason I ask, here are 2 pictures of what is currently being worked on:

http://www.uwm.edu/~pjgross/masktest1.jpg
http://www.uwm.edu/~pjgross/masktest2.jpg

In the first picture, all is well, i create a mask of the graphic, which directly corresponds to the graphic, pixel for pixel. But the problem is i want the image to be displayed... lets say 3 pixels to the right, so I implemented a 'shift' amount (see 2nd picture), to put a number of transparent verticle lines on the left side of the mask. Since you can only specify destinationX's that are multiples of 16, i figured a shifting of 0-15 pixels is required (and of course adding a few pixels on the right to make it a multiple of 16 again). Now that there is a large amount of transparent space on the left side of the image (to move my mask), the actual image i produced the mask with is essentially too far to the left to be copied over directly. If I were allowed to use a negative value for the sourcex, (the negative amount that was shifted), it would align itself correctly.

Or should I just make it so you can export shifted BIN versions of the source graphic as well?

EDIT: If sourceX is also required to be a multiple of 16, this whole post is void, and sourceX is required to be a multiple of 16. You can ignore this post. I'll have to add the ability to shift images =]

-rain`

Post by **Paul Stevens** » Fri Jun 24, 2005 9:09 pm

Yes. Did I post here or just send a private message
to Zyx. I don't remember.

The problem of needing several 'duplicate' graphics in order
to meet the 'multiple of 16' requirement is a bit onerous.
I am going to provide a way, at runtime, to create 'Virtual
Graphics' from 'real' graphics (the ones you supply) by
applying arbitrary affine transformations. The documentation
has a link to this as yet unimplemented capability. It will
also produce Virtual Masks for the same purpose.

Post by **Zyx** » Fri Jun 24, 2005 9:25 pm

Paul Stevens wrote:Are you sure? This is all sorted out before we call your
code.

You're right. I don't need the CASE statement, I came with a bad approach to the problem.

rain` · Post by **rain`** » Fri Jun 24, 2005 10:24 pm

Paul Stevens wrote:The problem of needing several 'duplicate' graphics in order
to meet the 'multiple of 16' requirement is a bit onerous.
I am going to provide a way, at runtime, to create 'Virtual
Graphics' from 'real' graphics (the ones you supply) by
applying arbitrary affine transformations. The documentation
has a link to this as yet unimplemented capability. It will
also produce Virtual Masks for the same purpose.

Hrmm, playing with my own editor, creating masks and such, I've come to the conclusion that at this point in time, if sourceX/destinatinox is required to be a multiple of 16, there is a huge limitation. If every X value has to be a multiple of 16, then 99% of the graphics will be 'un-reusable'...

I'm now just toying with the editors I have created, creating masks of ingame graphics of various sizes/shapes, etc. If, say i want to make a wall appear as a dragon, which is an easy task to accomplish (for instance, change the dragon to a greyscale and draw that as a wall, giving a stone dragon type thing in the middle of a room), I can export one dragon image for the 'front', and use that to draw the wall. But when i want to draw it on the screen, you basically slice the screen up into 16 pixel wide, viewport-pixel tall segments. Since this is the case, I can only draw my custom image at various offsets of 16 on the viewport, and drawing only segments of my image starting at various offsets of 16.

I don't really know how to explain this, maybe you understand already, but here is a REALLY bad ascii picture of what I'm trying to explain:

Code: Select all

<----- x offset of viewport ---->
0  16  32  48  64  80  96  112 128 144 160 176 192
+---+---+---+---+---+---+---+---+---+---+---+---+
|   .   .                .   . <- Cant draw on  |
|   .   .                . <-----  offset 100!  |
|   .   .                .   .                  |
|   +---+  <--- CAN DO   .   .                  |
|   |ABC|  <-- offset of 16  .                  |
|   +---+                +---+ <-- CANT DO      |
|                        |ABC|                  |
|                        +---+                  |
|               +---+                           |
|               |ABC|   <-- CAN DO              |
|               +---+   <-- offset of 16        |
|               .   .                           |
+---+---+---+---+---+---+---+---+---+---+---+---+

Assume the boxes with ABC are 16x16 pixel graphics, no matter what you do atm, you cannot draw a 16x16 pixel graphic at an offset of 100. Infact, a 16x16 pixel graphic can only be drawn in 14 different locations (but anywhere vertically), each being a 16 pixel wide verticle plane.

If say i want to draw that 16x16 pixel graphic at an offset of 100, i would have to create a new graphic that is 32x16, containing 4 lines of transparency on the left side and 12 lines of transparency on the right side, and another mask. Then, again, if I wanted to display that image at an offset of... 92, i would have to create a third image.

Even with allowing for virtual graphics to be created at runtime, if I have quite a few large pictures that are used all over the place, but require 15 virtual graphics to be created for each one just to display the graphics at different locations, that doesnt seem to be very efficient.

I dont suppose there is any way to allow the either the sourcex or destinationx values to not be a multiple of 16 is there?

-rain`

Post by **Paul Stevens** » Fri Jun 24, 2005 11:49 pm

99% of the graphics will be 'un-reusable

I would believe 93.75 percent.

I would be interested to know why a graphic needs
to be displayed in so many places. The backgound
capability was intended to display floors and walls and
they need to be displayed generally in 1 or 2 locations.

I wrote a very long post explaining my reasoning.
But I give up. A graphic that is not on the boundaries
takes twice as long to display. (And lots more code to be
even that efficient). But I will allow it. We probably have
more CPU time available than memory on platforms like
the PocketPC. The affine transforms might still be useful
for mirrors and scaling so I plan to continue that project.

By the Way, Zyx made it work quite well with the 16-pixel
requirement.

rain` · Post by **rain`** » Sat Jun 25, 2005 12:17 am

If its a matter of efficiency, then whichever is more efficient should be used. I guess we have 2 options:

A) Allow for pictures to be displayed in some sort of way not on an offset of 16, which requires extra CPU time, and implementation
B) Don't allow the above, but use 2-3 graphcis instead of one for a few special case scenarios.

If option A requires effort more then that of changing 5 lines of code, I don't think it would be useful to do. I wasn't thinking of anything specific (such as some graphical feature) that would require up to 15 images in various x offsets to function correctly. I think it would probably be best then if we leave the 16 pixel X coordinate limitation then. I think it is something we can easily deal with.

-rain`

Post by **Paul Stevens** » Sat Jun 25, 2005 1:11 am

I guess we have 2 options

If I do allow this, it will be equivalent to 2 options
because the code to do the 16-bit-aligned graphics
will remain and be used for this 'simple' case. I would
add code to do the 'complicated' case.

Someone needs to worry about CPU time on occasion.
You should see Zyx's DSAs. The trace files contain nothing
else almost. And they are inefficient. And we added
the overlay business that takes CPU time. Now the Custom
backgrounds. The new, fast machines will have no difficulty
whatsoever but I always was proud of the fact that CSBwin
could run on very old hardware. So I am sensitive to these
things.

Let me ponder the ramifications of having DstX not being a
multiuple of 16. Sometime attempting to implement something
like that stirs up some cleverness that makes it reasonable.
(Usually another level of indirection!!!) That is essentially what
happened when I implemented the overlay cabability for about
the third time. It wound up costing a lot in complication but
rather little in runtime overhead.

more then that of changing 5 lines of code

Oh, my. 5 lines? ha, ha.

rain` · Post by **rain`** » Sat Jun 25, 2005 1:29 am

Paul Stevens wrote:Let me ponder the ramifications of having DstX not being a
multiuple of 16. Sometime attempting to implement something
like that stirs up some cleverness that makes it reasonable.
(Usually another level of indirection!!!) That is essentially what
happened when I implemented the overlay cabability for about
the third time. It wound up costing a lot in complication but
rather little in runtime overhead.

Sometimes they also cause bugs that lie dormant for a month or two then turn up after someone combines two or three or 8 or 25 of the custom features at once, kinda like the one with &MOVE and monstermovement filter. If I were you, I'd put "DstX not being a multiple of 16" on one of those index cards and put it WAY on the bottom of the pile, as there are many, many steps we must take to get to that point. I think I've jumped way ahead of myself even speaking of such things! After all, I've managed only to accomplish making the CustomGraphics7 demo draw a picture of the DM Dialog box instead of the normal hexedit lines of 'randomness' =]. Although, making a complete skin of custom walls with only clicks of the mouse is only a few 'save routines' away.

-rain`

Post by **Paul Stevens** » Sat Jun 25, 2005 1:36 am

You talked me into it!!!! I'll write it on the
back of the one that says "CE Icon"

kentaro-k.21 · Post by **kentaro-k.21** » Sat Jun 25, 2005 5:28 am

i've posted command line tools at Files Upload Forum in DM Encyclopaedia.
http://dmweb.free.fr/Forum/read.php?f=8&i=335&t=331

EDIT: i forgot attachment on above post. DL is avail at following post.
http://dmweb.free.fr/Forum/read.php?f=8&i=337&t=331

i'll post more in my next free time...
thanks.

kentaro-k.21 · Post by **kentaro-k.21** » Sat Jun 25, 2005 3:40 pm

about how i made sample.

1. plan

replacing a wall image and the mask by skinning feature.

2. wall image

i drew a image with painting software.

i drew in 24-bpp full color image. i had to decrease the color depth to 4-bpp. i decrased color depth of the image by paintshoppro. the palette file was PAL1.pal.

3. mask image

i hoped that i wanted to reuse the mask data distributed with CustomGraphicsDemo7. because i have few knowledge to write a mask data in full scratch.

it was why i had to write other 2 tools (exposeMask, exposeSkinDef). i extracted mask data. and i got 21 mask images in bmp form files.

i didn't have good idea to construct sample data. so i drew the fences as mask images.

4. write batch file to compile images & import to csbgraphics

following command-line converts newWall.bmp to grafic image file. decreasement of color depth is automatically applied. palette file for decreasement process is PAL1.pal.

Code: Select all

newpict newWall.bin newWall.bmp PAL1.pal

following quoted comamnds will generate one mask file. it has 21 mask images in a file.
first one create a new mask file. following 20 ones add mask image in order.

Code: Select all

NewMask newWallMask.bin new "demomask00.bmp" "demomask.pal" 1     0  80     0  80
NewMask newWallMask.bin add "demomask01.bmp" "demomask.pal" 1   192  80   192  80
NewMask newWallMask.bin add "demomask02.bmp" "demomask.pal" 1     0  70     0  30
NewMask newWallMask.bin add "demomask03.bmp" "demomask.pal" 1   176  70   176  30
NewMask newWallMask.bin add "demomask04.bmp" "demomask.pal" 1    16  80    16  80
NewMask newWallMask.bin add "demomask05.bmp" "demomask.pal" 1    96  80    96  80
NewMask newWallMask.bin add "demomask06.bmp" "demomask.pal" 1    48  80    48  80
NewMask newWallMask.bin add "demomask07.bmp" "demomask.pal" 1    16  70    16  30
NewMask newWallMask.bin add "demomask08.bmp" "demomask.pal" 1   144  70   144  30
NewMask newWallMask.bin add "demomask09.bmp" "demomask.pal" 1    80  70    80  30
NewMask newWallMask.bin add "demomask10.bmp" "demomask.pal" 1    32  60    32  20
NewMask newWallMask.bin add "demomask11.bmp" "demomask.pal" 1     0  60     0  20
NewMask newWallMask.bin add "demomask12.bmp" "demomask.pal" 1     0  20     0  20
NewMask newWallMask.bin add "demomask13.bmp" "demomask.pal" 1   160  20   160  20
NewMask newWallMask.bin add "demomask14.bmp" "demomask.pal" 1    80  20    80  20
NewMask newWallMask.bin add "demomask15.bmp" "demomask.pal" 1     0  30     0  20
NewMask newWallMask.bin add "demomask16.bmp" "demomask.pal" 1   176  30   176  20
NewMask newWallMask.bin add "demomask17.bmp" "demomask.pal" 1    48  30    48  10
NewMask newWallMask.bin add "demomask18.bmp" "demomask.pal" 1     0   0     0   0
NewMask newWallMask.bin add "demomask19.bmp" "demomask.pal" 1   176   0   176   0
NewMask newWallMask.bin add "demomask20.bmp" "demomask.pal" 1     0   0     0   0

following quoted ones generate a skindef file. 4 skindefs're in a file.
first one make new skindef file. following ones appends skindef to skindef file in order. skindef doesn't contain any image files.

Code: Select all

newskindef newSkindef.bin new  0  0   0  0   0  0   0  0   0  ( ) ( )
newskindef newSkindef.bin add  0  0   0  0   0  0  10 11  12  ( ) ( )
newskindef newSkindef.bin add  0  0   0  0   0  0  10 11  12  ( ) ( )
newskindef newSkindef.bin add  0  0   0  0   0  0  10 11  12  ( ) ( )

first COPY command is to clear contents in csbgraphics.dat. CSBgraphics seems to have difficulty to extent entity size of exist raw data. so clear the entire contents at first. the ECHO command is to answer "Y" if COPY command asks you whether you overwrite exist CSBgraphics.dat or not.
following 4 commands append bin files to csbgraphics.dat.

Code: Select all

ECHO Y|COPY /B CSBg-empty.dat CSBgraphics.dat
CSBGraphics CSBgraphics.dat Import newSkindef.bin   skindef   Background 1
CSBGraphics CSBgraphics.dat Import newWall.bin      wall      Background 10
CSBGraphics CSBgraphics.dat Import newWallMask.bin  wallmask  Background 11
CSBGraphics CSBgraphics.dat Import skin2Code.bin    skinCode  Background 12

thanks.

Post by **Paul Stevens** » Sat Jun 25, 2005 4:23 pm

CSBgraphics seems to have difficulty to extent entity size

Are you using version 3.9?

If so, I would appreciate specific bug reports. CSBgraphics.exe
needs to be supported.

kentaro-k.21 · Post by **kentaro-k.21** » Fri Jul 01, 2005 3:08 pm

hi.

i have tried csbgraphics version 3.7 (Help->About... to obtain version number)

today i tried latest CustomGraphicsDemo8. it won't perform well to overwrite exist item. butt it performs well if i append new file.

i have a question. if "Import" command is not for overwriting exist item, any commands to do both overwrite/append new file?

Post by **Paul Stevens** » Fri Jul 01, 2005 4:04 pm

if "Import" command is not for overwriting exist item

It should do this properly. I thought I had fixed it.
Let me try a couple things while I am making a few
changes for Zyx. I'll get back to you if I cannot
make it fail.

Post by **Paul Stevens** » Fri Jul 01, 2005 8:54 pm

I just tried making something fail using the version 4.0
in OverlayDemo.zip. I cannot make anything go
wrong. If you can make it fail using 4.0 then I need
you to spell out in very fine detail what it is you are
doing and how you know that it did not work correctly.

kentaro-k.21 · Post by **kentaro-k.21** » Sat Jul 02, 2005 5:12 am

i tried version 3.9 (stand alone), and it works well!
sorry, i didn't notice about newer stand alone versioon out of customGraphics package.

thanks.

Post by **Paul Stevens** » Sat Jul 02, 2005 11:20 pm

there is a huge limitation. If every X value has to be a multiple of 16

I have always agreed with this. So I spent the last three days
putting together the actual code that I think could be used to
allow destination_X to be arbitrary to see if it would be
reasonable to relax this restriction.

Timing tests indicate that a Pentium-100 could paint the
viewport in approximately 2 milliseconds. Times 6 frames
per second = 12 milliseconds which is only 1.2 percent of
the CPU. I think a Pocket PC could probably keep up with this
but I did not test it.

Result: I will debug and install this capability. Note that
source_X and widths must still be multiples of 16. But I think
that relaxing destination_X will make things a lot easier.
The old algorithm will be used in the easy cases so there is
no penalty for existing designs.

If anyone can provide a test case that uses this capability
I would be very appreciative.

P.S. My tests indicate that my Athlon 2000+ (about 1.6 GHz)
executes about 5 instructions while the light from my monitor
is traveling to my eyes. I grew up in the computer
hardware industry in the '60s. Things were different then
and it probably explains my conservatism when it comes to
painting pixels on the screen.

Post by **Zyx** » Sat Jul 02, 2005 11:30 pm

Is the CreateVirtualGraphic already working?