Some questions

[cowsmanaut]

since you offered to give up some of your vast knowledge

here are some questions related to things on screen

1. do you know, code wise, which characters have been picked and which order they are in at the top?
2. if yes do you know their health, mana, what's in their hands etc?
3. do you know at any point the hero placement (again in code not visually) (the four hero icons is what I mean)
4. Do you know what level they are on
5. do you know the location value for their position in the level (ie X 10,Z 3)
6. do you know anything about the current on screen text? Names, messages, wall text, at any given time as far as the code goes.. again not a visual represntation.

That's all for now.. just want to be clear about how much is just cut and paste VS what you know is going on behind the screen.

moo

[Paul Stevens]

1) Know? In what sense? The code certainly knows their
names. "Halk gains a fighter level". It knows what
portrait to put in each spot. There is an internal record
for each of the four champions that describes their state.

2) I think I do not understand. Of course the code has access
to these things. It draws them on the screen for you to see
about 6 times every second. It decides if you have enough
mana to cast a spell. It decides if you are starving to death.
It knows how much the item in your hand weighs when you
throw it.

3) Something wrong with my interpretation of your question.
It is the code that causes the front line to be able to attack,
for example. It must have access to that information.

4) They are on d.PartyLevel. That is the name of the variable
that holds the party's current level.

5) Of course. How else would it know whether they have stepped
on the pressure pad at (10,3)?

6) Once the text is placed there it is only pixels that are moved
up the screen. The wall text is always available and comes from
an internal database record each time the screen is drawn.

Perhaps I don't quite know where you are coming from here.

[cowsmanaut]

I know the atari code does this.. I meant *YOUR* code.. Sorry for the confusion.

To be more clear.. I should say that what I'm getting at is if you could intercept any of this information and do something about it mainly in a visual sense.

An example would be.. if you knew that they were on level 2 you could put some kind of filter over the dunegon port to make it look like everything had a red hue. based on a little override provided with the dungeon. So say in this case we used all the traditional colours but wanted to shift things to a redish hue just in the view port to simulate say a lava flow.. In the same category.. say we had a section that was filled with lava but the rest of the level was not we could shift red in those areas and away from red in others.

There are others in relation to the other elements but I'll not bother getting into them untill I know for sure.

moo

[cowsmanaut]

oh and in annother instance of this.. I'm guessing you could record all information from keys and screen while the player is playing to collect data such as what spell was being cast.

Again in the idea of a colour over the dungeon view.. you could do lighting effects based on casting a spell and time. Thus making smoother transitions of light in the dungeon view port. Setting up the internal clock to read time and set a point at which the light level reaches zero from it's highest point.. then over time instead of it suddenly jumping to a shade darker.. it would be gradual.. almost inperceptable.

this would of course then require that in the dungeon all levels were set to infinite light like the hero level so it could be done through your code.

moo

[Paul Stevens]

know the atari code does this.. I meant *YOUR* code.. Sorry for the confusion

Well, there is no Atari code in this program. Except as comments.
What is there is my code which is designed to accomplish exactly
the same thing that the Atari code accomplished. And in the same
way for the most part. The algorithms used are the same algorithms
used by the Atari program (again, for the most part).

I have added a layer between the internal screen representation
created by the original algorithms and the PC screen. The reasons
I did this:

1) The internal video data is in a different format. Actually,
not too different from the 16-color 4-plane format of the VGA.

2) I was not about to try and change the algorithms that created
that internal format. They were simply too complex and tied
up with the internal workings of the program as a whole.

So I added the layer that takes pixels from the internal screen
and moves them to the external screen. Your questions appear
to be asking about that piece of my program. The one that moves
the pixels from the internal to the external representation.

That layer of 'code' can certainly look into any of the data
in the program. Right now it looks at very little. The current
palette to be used is one thing it must know. If you wanted a
different palette to be used depending on the party's level then
we could do that. In fact, I offered to do that, people thought it
was a good idea, and I have started implementation.

you could record all information from keys and screen while the player is playing

I could do this. In fact it is very common. It is the 'Misc/Record'
menu option. It records everything so perfectly that the
game can be replayed in its entirety with the 'Misc/Playback' option.

Changing the palette when a spell is cast? And then slowly
backing it off. Are you talking about making the dungeon brighter
when Lord Chaos casts a particular spell? Or are you
talking about the ordinary 'light level' that is already implemented
in three or four steps and making it less 'quantized'. Both these
things could be done with a lot of work. But the price/benefit
ratio is much too low IMHO. The current light level is in a variable
and it has many more than the three or four values that actually
get displayed. We could make the dungeon get dimmer in very
small increments by doing the dimming at the time the pixels are
being moved from the internal screen to the external screen
instead of at the time the internal screen is being drawn. It could
be less quantized because at that point we have 5 bits per color
component instead of 3. But why? Who cares?

[cowsmanaut]

they say a picture is worth a thousand words. If that's so then I hopefully have built a somewhat successfull essay for you here.

What I'm trying to illustrate here are sort of filters. Images blended over top of the dungeon view not a pallete shift. (don't wory that the caustics does not loop correctly.. it was done fast so you could just get an idea ) they are all ambient effects. You could have the effect of a torch the sort of 'bouncing' effect from a flame in the wind where it gets lighter and darker over and over. haze or fog can be put in in this way. Rain effects with lightning flashes. All I did here was to apply it as either opaque or as a 'multiply' layer in photoshop. Additive blending could also be used.

anyway here are the visuals:
http://dmweb.free.fr/Stuff/images/underwater.gif
http://dmweb.free.fr/Stuff/images/light.gif

as for finding out what the text is on screen at any given time is again a request to just do the text last on screen and use a windows or mac or linux font. If you know what it says using a font should be able to appear over top without copying the sourinding space and thus blocking the imagery below it.

All the rest of it was simply related to my replacement imagry such as the character icons etc.

moo

[Paul Stevens]

Verrrrrry interesting.

The problem is how to implement such 'filters' and when
to implement such filters.

Do you have the algorithm for your first example? Is
it typical? Can you tell it to me? If there are multiple
methods do you have estimates of their price (cpu time)?

[cowsmanaut]

yes the procedure is fairly common. How it works in theory for the water is that "multiply" adds the darkness as well as the hue to the underlying image were 'screen" adds the hue and the lightness to the image. Then there is overlay which is supposed to be additive blending where it takes the value of the over pixel and the value of the under pixel and adds them somehow stopping at white..

I will illustrate with the same colour values to show you how they operate.

RED.GRN.BLU
203.084.084 colour 1 (red)
063.122.150 colour 2 (blue)

multiply = 050.040.049
screen = 216.166.185
overlay = 100.080.114

colours in reverse order (meaning the blue is on top and the red underneath.

multiply = 050.040.049
screen = 216.166.185
overlay = 177.080.099

you will notice the overlay is dependant on what is on top. the others are not.

if you can see how they are calculated let me know.. I'll look up some code as there is likley some on www.gamedev.net or elsewhere that explains it better. I've got to get to the post office now before it closes.

moo

[Paul Stevens]

The Multiply and Screen are relatively straightforward. See

http://gimp-savvy.com/BOOK/index.html?node55.html

Overlay blending is a combination of the two.

The Color-Blending is a bit more complex.

All verrrrry interesting. And rather expensive in cpu
I imagine. But perhaps there are some clever shortcuts
when there are only 16 colors to worry about. If one could
limit the overlay to 16 colors then there would only be
256 possible combinations and a quick table lookup would
eliminate all the multiplies, additions, and divisions and the
result would be inexpensive because each of the pixels
passes through the cpu once anyway to be translated according
to the palette. We would simply have 16 palettes (one for each
overlay color). Everything would stay exactly the same except
for the initial computation of the 16 palettes. If the overlay had
32 colors we would need 32 palettes but it would cost no more
in cpu time.
Etc.

So overlays are essentially free if we limit the number of colors.

Verrrry interesting.