CustomGraphicsEngine CSBwin)

[Paul Stevens]

assumed was some sort of satanic language.....etc

Well that did make me laugh out loud. That's twice now.

What has happened here is that I copied the code from
FTL. I gave names (you may not like them) to the functions
that the FTL code called. I gave names to the particular
parameters that FTL used when they called these functions.
The code you see in Skin0Code.txt is very nearly a word-for-
word translation of the FTL code, rearranged to make it easy
for me to compile. Mostly I changed 'infix' notation to 'postfix'.

Code: Select all

result = DrawObjects(roominfo[2], GetXY(12),12, 0x3421);

becomes

F4L1Contents F4L1xy F4L1 DrawOrder3421 StdDrawRoomObjects

Now down to the nitty gritty. What do these functions ('words')
do? It is simple. First, you asked how this would work:

Code: Select all

: Skin2Stone
   CurrentSkin WallGraphicID CurrentSkin WallMaskID CurrentCell DrawCustomGraphic

Answer: It will cause a compiler error. You forgot the semi-colon
at the end. A definition starts with a colon ( pronounded 'define')
and ends with a semi-colon (pronounced 'end of definition').
The code defines a function named Skin2Stone. It does not
turn Skin into Stone. It defines how to draw a Stone wall in Skin2.
Ie: Draw Skin2 Stone Wall.

The last word in this definition is DrawCustomGraphic. That is the
word you will use to draw floors, Middles, Ceiling, and Walls and
any other things you like to draw. You can draw your Floor and
Wall Decorations, Teleporters, Apples, or anything using this
function. You can draw your mother's left ear on a stairway.
It is the funtion to draw arbitrary things. It is all you need.
Everything else can be done with numbers.

Code: Select all

DrawCustomGraphic ( graphicID maskID mask# . . . )

What are the other variables/functions available

I don't think there are any. You can draw whatever you please
with this one word. What more do you want? I am going to
break now and start a new post to clear up some silly details
that will make things easier for you.

[Paul Stevens]

Let us say that there are only three cells that need custom
drawing. Namely, F1L1, F1, and F1R1. And let us say that
only Stone walls are to be drawn in a 'custom' manner.

In the index at the end of the Skin2Code.txt (in the function
named 'main' ) we would need to replace three entries.
We might call them CustomF1L1Stone, CustomF1Stone,
asnd CustomF1R1Stone. Then we would need to define
the three functions somewhere.

Code: Select all

: CustomF1L1Stone 4 7 2 DrawCustomGraphic ;
: CustomF1Stone    4 7 3 DrawCustomGraphic ;
: CustomF1R1Stone 4 7 4 DrawCustomGraphic ;

And this would work just fine in your Skin2 graphic ID = 4,
your Skin2 masks ID = 5, and the three particular masks
for drawing the F1L1, F1, and F1R1 masks were 2, 3, and 4.

But, being lazy, I discovered a way to make this more
obvious and self-documenting and easier and shorter. I did
all three with a single function. Whoopeee. I used some
nice words to get the Skin graphic ID, the Skin mask ID,
and the particular mask number.

Code: Select all

currentSkin wallGraphicID  // Get Skin2 wall graphic ID
currentSkin wallMaskID  // get Skin2 wall mask ID
currentCell // Get relative cell number of cell being drawn

And then, when I built my masks, I made sure that the
masks had the same numbers as the relative cell numbers
they were intended to draw. It is done!

Now, I lied too about doing everthing with the one word
'DrawCustomGraphic'. We have made provision for
drawing floor and wall decorations with a different word.
But that is not implemented.

[Paul Stevens]

By the way, Your example of drawing a custom floorskin
(The Japanese pronunciation may make that sound like
something else) is not only approximately correct, it
is perfect! You understand more than you admit.

[Zyx]

Replacing the word "Wall" by "Floor" is not a big feat!

Besides, if I try to compile a skin containing the following code:

Code: Select all

: SkinFloor
	CurrentSkin FloorGraphicID CurrentSkin FloorMaskID CurrentCell DrawCustomGraphic;

, I get:

Error during compile at line 119
Undefined word FloorGraphicID

Also, from what I gather, the normal floor is not drawn for each cell, but once for all before everything, right?
So if I want to draw a floor skin, there is nothing to replace in the code, I must insert a line before each case where a piece of floor would be visible. Is it correct?


Another question: sometimes there are block structures IF and THEN.
Is the condition of the IF before the instruction, and the conditional code between the IF and the THEN?

[Paul Stevens]

That is correct. THe normal floor, middle, and ceiling
are drawn before anything else is done. And you are
right that nothing needs to be deleted from the existing
code. You simply draw your floor on top of the existing
floor.

The (IF code-a [ ELSE code-b ] THEN code-c) ( flag . . . )
does the operation:

If flag is non-zero do code-a else do code-b. Then code-c.
The flag is removed from the stack immediately when
the IF is encoiuntered. Like the DSA except that the
code between the keywords can be arbitrarily long and the
structures can be nested:

flag1 flag2 IF IF code THEN THEN

[Paul Stevens]

I will add the missing words for Floor, Middle, and Ceiling
to the compiler and to CSBwin. I did the walls first
and that was all I needed to demonstrate the general
technique. It is my way to do more only when it is
needed. In that way I know that someone has actually
tried it.

[Zyx]

I see. So, I understand the syntax correctly, if this sentence would make sense then, right?

Managing these skins is quite difficult since everything (skin definition, bin files, mask definitions, coordinates, skin code) needs to work simultaneously in order to see a result. I cannot test each part individually.

[Paul Stevens]

Managing these skins is quite difficult

I agree. I think it needs helper utilities. And I am
willing to do my part. Something that takes all the parts
and produces a CSBgraphics.dat. The first thing I think
would be helpful ( and something I could provide)
is a script-driven interface to CSBgraphics.exe.
Like:

Code: Select all

Load file CSBgraphics.dat
Import <filename> as BackgroundGraphic with ID 10.
Import <filename> as BackgroundGraphic with ID 11.
Save file CSBgraphics.dat

and likewise utilities to create the .bin files like the
skin definition and masks. Then you would be able to
make a change to a mask or add a mask and put the
whole thing together with a single batch file and test
it in a few seconds.

For example the masks. The script might look like:
mask 1 file a sx=n sy=n dx=n dy=n width=n height=n
mask 4 file b sx=n sy=n dx=n dy=n width=n height=n
save <filename.bin>

Then each of your masks could be in a separate file
and the utility would convert to bit-plane format, pad
to 16-bit boundaries, and set up the mask.bin file.

But I am just guessing about what would be valuable.
You decide and I will help produce whatever is needed
that nobody else volunteers to do.

[Paul Stevens]

CustomGraphicsDemo5.zip should support the
words 'FloorGraphicID' etc.

[Paul Stevens]

CustomGraphicsDemo6.zip supports a command-line
mode for CSBgraphics.exe. See the .BAT file
for example of how it is used.

Zyx points out that manipulating these graphics and masks
is difficult. I agree. This is the first step to making it
possible to build an entire CSBgraphics.dat using a
Makefile ( or, more simply and less efficiently, a batch
file ). Starting from the source files, whatever they might be.

[kentaro-k.21]

hi.
i checked CSBuild about skin feature and made sense about the association between dungeon levels and csbgraphics. thanks!
next problem will be how to produce CSBwin specific mask/graphic imaages...

i've posted a csbgraffer. it allows you to modify csbgraphics.dat by file unit operations, not logical unit. and it does NOT support for this sequent skin features.
http://dmweb.free.fr/Forum/read.php?f=8&i=331&t=331

i checked CustomGraphicsDemo6.
that automated command-line tool is great to find good result by trial and error.

current csbgraffer won't support skin features forever because its code design is not capable to treat structed data like skin features. i have to reconstruct csbgraffer in full source code scratch. it just takes long period to release next version ...
so, i write tools to build misc file (skin/picture) slowly.

Paul seems to have good sense and skill to supply documents/softwares. so i just continue to follow his footprint and make improved ones about CSBwin.

[Gambit37]

It's still all way too complicated for simpletons like me.

[Paul Stevens]

It's still all way too complicated for simpletons like me.

Bullshit! You ain't that simple.

It is really simple in concept. There are LOTS of necessary
parts. That is numeration, not complication. The parts fit
together is unfamiliar ways.

Basically it is
1 - drawing the pictures ( The hardest part!!!! )
2 - putting the pictures in CSBgraphics.dat Before this is
all over you will probably have some help here in the
form of some utility programs.
3 - Telling which picture to draw (and where) for each
kind of dungeon cell. Zyx is doing this now and his work
will be pretty much useful for anyone.

[Paul Stevens]

By the way, the code that tells where to draw the
pictures is going to be quite standard FORTH language
code. There is a tutorial ( English or French ):

http://www.softsynth.com/pforth/pf_tut.htm

You need to ignore the Inpu/Output and a few other
things that don't apply to us.

If you Google for:

Forth Syntax

You will find a lot of help.

[Paul Stevens]

Zyx has found 3 bugs. One in CSBgraphics.exe,
one in CSBwin.exe, and one in ViewportCompiler.exe.
The repaired versions are in CustomGraphicsDemo7.zip.
You will need to re-compile and re-import any code files.

Zyx has done stupendous work with the custom graphics.
Impressive.

[kentaro-k.21]

Gambit:
in my understand, currently there're 4 usages of csbgraphics.

1) overlay capacity
overlay is a plane lying on dungeon viewport.
overlay completely covers the below dungeon viewport.
overlay has transparency to blend with dungeon viewport.
overlay is turned on/off by DSA.

2) enhanced portrait
you can place new portrait picture in your dungeon.
enhanced portrait is a wall actuator.

3) sound (11kHz, 8 bit, mono)
you can play new sound at any time. it can be done by DSA.

4) skinning feature
to activate this feature, you should work with 4 tasks simultaneously.

4.1) skin your dungeon
Paul is very kind to teach me how to.
Menu->[Edit]->[Skin Map]

each tile in your dungeon is associated with one skin. from skin0 to skin255. there're 256 skins.
if you don't specify skin, skin0 is always selected.

4.2) paint skin image, then convert it to internal image format used by csbwin
you paint 4 pictuures (according to document from Paul): floor picture, ceiling picture, middle part picture, wall picture.
but i don't know what their 4 pictures should be.

you will be able to save the image to windows BMP. but as far as i know, there is no tool to convert BMP to csbwin image formatt (bit-plane fomrat)...
but Zyx seems to have good way to do convert from bitmap to bit-plane format???

4.3) write a code
i don't know this well...

4.4) write a skindef
there can be up to 256 skins.
in logical consideration, each skin has link to 4 pictures (floor/ceil/middle part/wall), code, and so on. the link is represented as raw data number (can be found by CSBgraphics tool).

you have to write skindef to associate your new image with your own skin.

skindef is collection of all skins. therefore skindef is single. but skindef is represented as binary raw data format (documented at Paul's documentation site).



currently skinning feature is in premature stage. it is difficult to show concrete working steps as tutorial.

[Paul Stevens]

overlay has transparency to blend with dungeon viewport.

Quite true. But the design was left open for additional
blending algorithms.

but i don't know what their 4 pictures should be.

There is no rule. Whatever you find convenient. You can use
the floor graphic to draw the ceiling (or roof) if it suits your
fancy. (Anyone for an up-side-down level?)
I imagine that the easiest thing to do for a floor
graphic is to provide a picture of the conplete floor and then
use the masks to select that part of the floor to be displayed
for each cell that can be seen by the party.

4.3) write a code
i don't know this well

I think what Zyx has done is to take the "Standard" code for
Skin 0 and, for each cell seen by the party, he added a single
word to display the floor and ceiling from his Skin. So it was
just a matter of inserting that single word in about 168 places.
(8 cell types times 21 cells).

[Gambit37]

This is all very well, but as they say, a picture is worth a thousand words.

I'm an artist. A visual person. I can't really get my head around this unless I can see:

a) typical images for the skins
b) a typical mask

It's very hard to understand this skinning lark with your examples Paul because it's impossible to view the provided images and masks.

[Paul Stevens]

To draw an entire level with a different floor......

All that is needed is an image of the floor in the Atari
bitplane format. And a single mask that encompases the
entire floor: Like this: (the numbers are not right!!!)

srcx=0 srcy=0 dstx=0 dsty=160 width=224 height=40

And a single line of code to draw it, like this:

10 3 4 DrawCustomGraphic

And that is sufficient to have a different floor on an
entire level of the dungeon.

If you will provide the picture I can set up the rest of
it for you. The picture is the hard part,

Walls are more difficult because you don't want to
draw walls everywhere as you can for the floor.

[Zyx]

I'll post some pictures there to make it clearer

[Zyx]

I'd like to retrieve the skin number of a relative cell of my choice; is there a command for that in the skincode?

[Paul Stevens]

There ain't hardly anything. And there ain't no documentation
either. So I don't know what is available without studying the
code itself. We gotta fix that. I sort of hesitated to start
the documentation because I was afraid that perhaps I had
strayed too far from what would actually work. But it seems
you have made it work pretty well so I will attempt to
document what we have. Well, start to document, anyway.

I'll check it out and add it. Things like that are extrememly
simple but tedious because of the need to synchronize the
compiler and the runtime and get both released.

[rain`]

Paul Stevens, you said yourself you hex edited the graphics, have you made some sort of import/exporter to desired format? I'm curious, I think it might be relatively easy to put an editor for the entire customgraphicsengine directly into ADGE, but i'm not quite sure. All the rects, offsets, images, etc, are all stored in the graphics.dat (and 99% are editable), making a simple GUI for the custom graphics engine and batch exporting masks/images in .bin format to be added to the CSBGraphics.dat file may be possible.

I already looked into masks.bin, and I could easily write an exporter for masks (import X graphics, set the transparent pixel color, batch export all the masks into the masks.bin).

I'm really just not quite sure about the other files, according to the graphics documentation on your website, a graphic file has the format i32 width, then i16 pixels[#pixels/4]? Is this then an array of 4bit values and use the palette for drawing on the viewport?? I looked at skin2graphic in customgraphicsengine7, but couldn't figure the format.

The wall decoration file seems pretty standard, but what does the i16 bitplanes[4]; array represent in the PICTUREGROUP? In your example it is either 0xF00F, 0xFFFF, or 0x0000. 4080, -1, and 0, respectively.

-rain`

[Paul Stevens]

Slow down.........
I can answer all these questions if I can figure out what
the questions are. I will try now. Let me know how it goes.

have you made some sort of import/exporter to desired format?

No. I simply typed in things like 'ff00 0000 00ff'

file has the format i32 width, then i16 pixels[#pixels/4]? Is this then an array of 4bit values and use the palette for drawing on the viewport

I think the answer is Yes and Yes. The digits each represent
4 bits. So in that sense it is an array of 4-bit values. But they
come in groups of 4 digits representing 16-bit values. Each
16-bit value is one bit-plane for 16 pixels. Four bitplanes are
required to represent all four bits for the 16 pixels. This is spelled
out in the documentation. Take four 16-bit values:
0xff0f
0x0ccc
0xf0cf
0x9c11

The first bit of each of these four values is
1, 0, 1, 1 which is hex 0xb which is the value of the first pixel.
The second bit of each of these four values is
1, 0, 1, 0 which is hex 0xa which is the value of the second pixel.


And, indeed, these are the program's internal colors and
use the same palette as the rest of the graphics in the vieport.

does the i16 bitplanes[4]; array represent in the PICTUREGROUP?

It represents the 16 pixels for that group. 4 bits for
each pixel means four bit-planes, each with 16 bits.
See previous answer. The first value is the fist bit for
each of 16 pixels, the second value is the second bit for
each of the 16 pixels, etc. This was pretty much the
standard way of storing pixel data on the PC in 16-color mode.
And the Atari used it, too.

[rain`]

That is exactly the description I am looking for, the bitplane format in 10 lines =]. That is fascinating, you really overdid it this time . If someone asks you for a place to put their stuff, you ask how big. If they don't specify, you seem to make a 90,000 square foot mansion every time. First DSA's, now this. I give you props, you really opened up alot of windows here(see through walls... and walls..and walls...). The only thing you can't do is modify the palette (and no im not asking for it), thats amazing. Just think, if you add some sort of clock variable, one probably could make animations.

I'll be working on an exporter to export images from adge into the picture format for wall graphics, masks, and a wall decorations. Since you can import many graphic formats already, it should come in handy for this project.

Now the fascinating part is (If I do remember this correctly), the palette used to draw the viewport has colors 9 and 10 dependant on the monsters of the level therefor it is possible to make walls, wall decorations, graphics, etc, that include those colors and can change from level to level. Not like it matters, but it allows you to create yellow walls on a scorpion level, purple doors on a worm level, etc. With the fact that you can modify those custom colors in ADGE, you essentially can have hot pink wall decorations. Amazing!

-rain`

[Paul Stevens]

some sort of clock variable, one probably could make animations

Uh....well.....uh....if you look at the overlay demo you
will see that it is animated.

The only thing you can't do is modify the palette

Why not? You just gotta remember there are many palettes
for each level, based on the amount of light. The one thing I
cannot do is provide more than 16 colors at a time. Except
in overlays. As a matter of fact, overlays could be used to
change the palette by using custom overlay functions. But
still only 16 colors at a time. The Atari is only capable of
displaying 512 colors (3 bits per each of R, G, and B). The
overlay could translate these 512 colors arbitrarily using only
16k bytes of lookup space. Then you would not have to worry
about having several palettes for the different light levels.
Of course if you wnat hot pink walls you should be careful
you don't get hot pink bread along with it! But you might
give a level a red cast as if you were in the ready-room at
the airforce base.

[rain`]

I have some intricate questions (one about clearing up confusion, the others about implementation)

1) Skin2code.txt shows, to me, the routine for drawing the entire screen. I don't understand how skin2code works if there is only one cell in the viewport that is of skin2, and the rest are of skin0. Does it pass some sort of variable to the code like "CurrentCell"? I don't see the workings of a passed variable to skin2code, so i'm rather curious on how it knows only to draw the custom graphic at D3L rather then all over the place.

2) When you specify a ceiling, floor, middle, and WALL graphic ID, this grants the user one graphic ID associated with a single picture which you call a wall. But in the game itself, there are many wall graphics from many angles. Was this intended on being a sole-picture variable or perhaps the start of some 'array' where you add offsets to fetch pictures? I suppose since all it is is a number, it is what you make of it from using the WallGrapicID call.

3) Would it be correct to say that the virtual transformation function (CreateVirtualGraphic) is the same function used to scale up/mirror images of monsters, items, decorations, etc inside the game?

-rain`

[Paul Stevens]

1) I will add to the documentation.
2) I will add to the documentation.
3) No.

[Paul Stevens]

Check the New Custom Graphics page and follow the
link to the FAQ.

If I answered the wrong question or it is still not
clear we can try to fix the FAQ to your satisfaction.
When you know something it is sometimes hard to
understand what someone else does not know.

[rain`]

Those answers are perfect, they clear up alot of haziness. I don't think you could have explained it any better!

I'm going to write a full exporter for adge that just dumps an entire set of graphics and masks. Just for testings sake. It should be relatively easy once i hammer down the atari bitplane format. There used to be a graphics.dat file out there that contained custom graphics for all the walls, a green mossy look, By using that, I can test it out perfectly by having some walls with green moss, and some without. This should test out the basic features of the graphics engine. Perhaps once that is in place, it would be relatively easy to make a skin with only custom walls.

You were correct by saying that at some point, there will be helper utilities made for it.

-rain`