CSBwin Version 9.51k

[Paul Stevens]

Ooooh! I can feel the excitement in the air. Version
9.51k is released and everyone is happy.

Find it at:
dianneandpaul.net

Fixes the walltext problem. It has been broken for
2-1/2 years. Rearranging some variables caused it
to pop to the surface; but only in the release version.
The debug version still worked fine.

Thanks to the people who pointed out the problem.

[Ulmo]

Well done !

But I have two more requests :

When you fuse Lord Chaos, some delays seem to be missing, as I do not see any explosion/DesEw, I just hear one sound. Ask if you don't see what I mean.

Since version named 951g (but still labeled 951f in the about window), the weight of food is not removed from the total load of the leading champion when it is eaten.


2 requests at once, reaching 951z release will be longer than planned :-)

[Paul Stevens]

Does anyone know that CSBwin behaves differently
from the Atari version? If so, can someone provide a
saved game that I can use with the Atari emulator in
which Chaos is about to be Fused?

You are certainly right about the food. What do you
suppose I did to break that? Nothing in the release
notes seems even remotely connected to food/loads.
Hmmm.

[Ulmo]

DM ending : I didn't plan to complete once again the game, this time on Atari emulator, but I will see what I can do for you.
I saw in the CSBwin code, (file Attack.cpp, function RESTARTABLE _TAG01fefc(void)) things that looked like the growing in power fireballs, but in the game everything happens immediately.

Eating food break : Having noticed your hesitations about allowing "clones", I had accused them. You have confirmed that opinion, but I'm still wondering what a clone can be !

[Paul Stevens]

A clone. What is it?

There are database records that contain information
about the objects in the dungeon. For example,
a potion. The database record for a potion contains
the information for a particular potion. Example:

Kind of potion: FUL BOMB
Strength of potion: 5

Now when the potion is placed in a cell in the dungeon
we don't put the whole database record there.....we just
put a 'Pointer' to the database record.

Suppose on level 3 we put at pointer to a potion.
Then on level 4 we put a pointer to the SAME potion.

That flask of potion has been cloned!

If, on level 3, someone picks up the poition and throws it
at a Giggler, it will destroy the Giggler and the potion's
database record will be discarded. But the pointer on
level 4 still points at it. So what will happen when you
pick up the potion on level 4???? God only knows. It
depends on what other things may have taken place in
dungeon, whether that database record has been used
for something else, etc.

In the latest CSBwin, I put code to search the
entire dungeon to find such clones and mark them.
Then later in the game I refuse to delete any database
records that are so marked. It will cause all cloned items
to never be deleted. But it makes the game's outcome
well-defined.

[beowuuf]

In cloning like that (of items) usually a freezing crash happens when the game is forced to interract with both at once. For example, you could have a cloned potion in your inventory and the dungeon floor, but if you ever threw away the cloned potion, the game freezes.
DM over a long period of time seemed to naturally produce clones, some bug in the code handling.

Cloning, as some of us dungeon designers mean it, is more to do with putting repeated markers to tiles and teleporters. These objects don't interract with the dungeon that much, usually needing party input, and so are quite harmless. Any items that appear on these repeated tiles ontop of the original object cloned only have a pointer to the linked list created, so no multiple references.

Monsters are the snag in this scenario, because of their independant nature. When the engine is constantly interracting with the monsters, it seems fine - so creatures walkign over cloned tiles temporarily appear in all places, but the engine is still handling it entering from the original square, and so there is no harm.
The bad part seems to be when the monster information is generated fom scratc - a saved game seems to lose some of the actions happenign in the dungeon, or an innert/slow moving/different level monster might not have done anything and so now needs fresh instructions. Then, the engine usually crashes with an error message, since its tryign to move the monster which is referenced in two or more places.

[Paul Stevens]

I think there might be a very big problem here.
Monsters on the same level as the party are treated
very differently from monsters on a different level.
They have an additional data record linked to them
when they are on the same level.

When the party changes levels..say from level 4 to
level 5..it searches through the new level (level 5 in
the example), creates this additional record for each
monster, deletes the old timer entry (on level 5), and
creates a new timer (on level 5).

Notice that it did not delete the timer entry for the
'clone' of the monster on level 4. So now the monster
has two timer entries; one on 4 and one on 5. And the
monster has the extra record attached. But the
code that handles monsters on level 4 (where the
party isn't) does not expect this record to be present.
And it will destroy the pointer to the record!!! Because
different information is kept there on the non-party
level. Then the code for the monsters on level 5,
expecting the record to be present, will reference trash.
And that 'trash' could very well be something else that
is important to the well-being of the game's integrity.

The original Atari code had a couple of bugs that did
not keep track of the state of a monster's record exactly
right and it did cause crashes. It happened when unlikely
things occurred like the monster fell through a pit and
landed on the party or some such improbable thing and
it did not take into account that the moster started on a
different level. [This is a make-believe example.....I don't
remember the exact circumstances.]

[Ulmo]

About DM ending (fusing Lord Chaos) and more generally about how CSBwin is programmed :

I looked at the code of attack.cpp, the function TAG01fed6(_7_) should be used to have a delay, but as I don't understand how RESTARTABLEs, RETURN alias, CALL0(n,...) etc work, I can point out what seems to be missing.

[Paul Stevens]

Well, I can find no trace of any delays. TAG01fed6 simply
redraws the viewport, processes any timers that have
expired, and starts any sounds that are queued.

The only thing I can think of is that the original code
somehow would wait for any existing sounds to finish
before starting another.

If I make a version just for you with a 2-second delay
in TAG01fed6(_7_) (or equivalent), would you be
willing to test it?

[Ulmo]

> If I make a version just for you with a 2-second delay
> in TAG01fed6(_7_) (or equivalent), would you be
> willing to test it?

Yes, of course. I'm going to complete DM or CSB each time you release a version :-)

> The only thing I can think of is that the original code
> somehow would wait for any existing sounds to finish
> before starting another.

I have the feeling that you missed something : the swaps between Lord Chaos and Lord Libracasus are faster and faster, which seems to be the sense of the lines 1645-1649.



I also need some explainations about the way RESTARTABLEs, RETURN alias, CALL0(n,...) work. I couldn't open a window with UtilityDialogBox (File Chaos.cpp), I'm confused with all the #define.

[Paul Stevens]

The RESTARTABLE business is my way of turning the
program 'inside-out'. Ther original was a DOS-like
program that asked the operating system for help.
But in Windows, things work the other way around;
a program is supposed to wait for a message from
Windows to do something.

So I built my own dispatcher. When a program wants
to wait for an event, it puts itself and its 'return address'
on a execution stack and returns. The dispatcher notices
that the function has not REALLY returned, it is just waiting.
The dispatcher then goes back to Windows. When a Windows
message arrives, the dispatcher restarts the interrupted
function and the function restarts at the point where
it 'returned'. To make it work, all local variables must
be declared 'static', not allocated on the stack.

The whole result of all of this is rather transparent and
you need not worry about it!!!!! When you reference
one of these 'RESTARTABLE' functions it gets started at
the top as you would suspect and returns when it is
done.....that is REALLY returns (via a RETURN command)
when it really is done. If you don't worry about it then
it will all look like a normal C-program except that:

1) The function reference is to 'funcname' and the function
definition is for '_funcname'

2) The function reference has one additional parameter in
the front to enumerate the return points. The _n_ parameter.
The remaining parameters are passed to the called function
as is usual.

3) The function definition must be declared 'RESTARTABLE',
meaning that it can 'return' in the middle of execution and
can later be restarted at that point. It has a list of return
points (restart points) at the entrace to the functioon.

------------------------------------------------------------------------
Another way of looking at it.

A RESTARTABLE function keeps track of its 'MODE'. When
you call the function if has a 'case' statement at the
top to transfer control to the code that handles that
particular MODE (or state). It calls another function by
setting its MODE properly, placing itself on a stack of
functions that need execution, places the function to
be called on the same stack, and returns to the dispatcher
who always calls the function on the top of the stack.
-----------------------------------------------------------------------

All of this is much too complicated for our purposes. You
can ignore it all. Just assume that when you call a
function with a (_n_,....) that the coressponding
RESTARTABLE function gets called with the first parameter
dropped.

[Paul Stevens]

You say:

I have the feeling that you missed something :
===================================
That I missed something is not new. I missed something
before this. The question is 'WHAT'? I studied the
original code at great length since first receiving your
note. I cannot find it.

I would be happy to ship you the original Atari code
so that you can tell me exactly what it is I missed.
======================================
I will make a test version and post it tomorrow morning.

[Paul Stevens]

Youe say:

(File Chaos.cpp),

=========================================
Oh, boy. You won't get any help from me with that
file. That is the 'Utility'. I never figured any of it
out. Not as bad as the 'help' but nevertheless.....

There is a lot of it that I never implemented. The
original code is not in the source that you see.
So I put my private copy of Chaos.cpp at:

[url]http:\\dianneandpaul.net[/url]

It has the Atari code as comments so you have something
to work with in the non-implemented parts.

[Paul Stevens]

You say:

I have the feeling that you missed something
and
the sense of the lines 1645-1649.
======================================
I think what I missed is that the Atari was a very
slow computer. I think that the call to redraw the
viewport was intended to use time as much as it
was intended to draw!

Your hint at lines 1645-1649 was very insightful.
There is no good reason to be drawing the screen
multiple times except to waste some time.
There is no explicit 'wait'; there is just a lot of
instructions required to do the necessary pixel
operations.

[Ulmo]

> I think what I missed is that the Atari was a very
> slow computer.

This seems to make sense. I should have guessed.
I sensed something, but I couldn't do more than pointing out some clues. Congratulations, You finally solved it.
I find this reason quite amusing, both the fact the useless operations to create delays and the fact that it is canceled on nower computers.

> a version just for you with a 2-second delay
> in TAG01fed6(_7_) (or equivalent)

Waiting until the end of the sound would be a good solution, but you can't do this, can you ?
So I checked the durations of some sounds. It comes from the amiga version, because I didn't succed to extract sounds from STs' or PC's graphics.dat.
Exploding fireball : 0.662 s
Explosing spell : 0.518 s
teleport : 0.251 s
So, delays between explosions sould be just a little more than 0.6s or 0.5s, and delays between monsters exchanges should be from 1s to 1/4s. I do not know how precise CSBwin can be, these are just some ideas.

> RESTARTABLE business

I do not really understand it, but I have now the informations I needed, essentially how to choose a _n_ parameter and how to declare it. I'm now able to open windows !
Thanks for your long answer.

> File Chaos.cpp

Good. Let's see if I can do something of it :)

[Paul Stevens]

I put a file named 'fusion.zip' at

http://dianneandpaul.net

It has a 500 millisecond delay every place the function
to update the screen, sounds, and timers is called from
within the fusion sequence.

It is probably too long in places and too short in places
but we can adjust it to fit your fancy.

[Paul Stevens]

Hi.

I looked at Chaos.cpp and see that some of the
original code never got put into the file. Some
was just marked as 'Not Implemented'. So I
put the original, complete source for Chaos at

http://dianneandpaul.net

in a file called ChaosList.rar.

Good luck.

[Ulmo]

> CSBwin_Fusion

The sound is good, but there is no drawing update. I send you a test dungeon.dat so you can test immediately.

The final fireball explosion's sound is missing (normally associated with a final big fireball and big DesEw).

[Paul Stevens]

I posted another copy of the Fusion test executable.
This one is a lot closer to right.

[Ulmo]

> This one is a lot closer to right.

I agree. I just notice that the final fireball/desEw/teleportation should occur simultaneously.

Atari ST save is following (WinSTon format).