Messages

This looks very much like mistake in game saving/restoring code.
What branch you were building from?
I ask because I had this problem just recently in the 'refactory' branch (that was already fixed though, I think).

Out of curiosity, WHAM, did you have this story planned through from the very beginning or you continiously invent it?
Also are there any plans for making an actual computer game of this?

Now, wait wait there, monkey, let's not complicate the matter anymore further for now, ok?
One step at a time, otherwise my head will burst too.

Then maybe I should interpret the '!' as an "opposite-marker" rather than a "simple" 'NOT'

Well, NOT ('!') is a boolean (logical) operand that gives boolean (logical) opposite value.
It works very simple, but you should get used to it.

For bool variables that simply changes them from TRUE to FALSE and back.
For integer (numbers) that work so:
- any number other than 0 (that counts as TRUE) is transformed into FALSE;
- 0 (which counts as FALSE) is transformed into TRUE.
Uh, just to ensure this is clear, that means:
- number 10 is different from 0, this means it is treated as TRUE. Therefore the result of !10 is FALSE.
- number -22 is different from 0, this means it is treated as TRUE. Therefore the result of !(-22) is FALSE.
- number 0 is treated as FALSE. Therefore the result of !0 is TRUE.

In this case "Visible" is an Object's propery of type bool, so it is either TRUE or FALSE. The NOT operator (!) applied to 'Visible' gives opposite value (FALSE for TRUE and TRUE for FALSE).

if I can see obj2 as visible it's because obj1 is not.

This is because the expression has a "right to left" associativity, right?

Well, that too, but I'd say that's because the obj1 visibility is being set first depending only on its own value, and obj2 visibility is being set after that based on obj1 value. So, obj2 visibility depends on obj1 (but obj1 actually do not depend on obj2).

The function may be called with any initial states, it will set object states to properly opposite ones.
That is because the second line will be executed with obj1 visibility already changed.

Maybe I've explained myself wrong, I spoke out of context. I'll try again.
<...>
[many examples here]
<...>
I apologize if I'm overthinking this, or if I'm contradicting myself while trying to learn deeply Please feel free to let me notice of both!

Allright... ugh... my answer was too formal and I was speaking strictly of function execution without any context.
Let's say this: the exact visibilities after the function was executed are ofcourse different depending on what they were before the function call.
What I meant is simply this: as a result of function they will be opposite regardless of initial state. Ofcourse that "opposite" may mean that either first is on and second is off or vice versa depending on preliminary state.

So, to simplify things, set your objects one visible and another not visible, depending on what starting condition you are aiming. Either door is opened or it is closed, no third option, otherwise there will be glitch when the function is called for the very first time, which is unacceptable.

Oh, hopefully that won't complicate things, but I'd just want to note this: if both objects are made initially visible they will be both visible, just one will be drawn afront of other making an illusion that only one is shown. That is defined by so called "Z"-value (the order of drawing), in AGS that's controlled by Object's Baseline property, which I won't discuss here to save our minds, it is a separate question.

//--------------------------------
Now, when (if) that is clear, you may check monkey_05_06's solution which is to use only one object and change it's graphic, which is actually better in my opinion.

Just a small tip: make sure you BOTH sprites are of the same size, possibly "open" state having extra empty space to compensate the differenece, otherwise your door will visually (but not really) change position when changing state.

[ob1]

Anyway I must tell that, even if I get the sense of the code you wrote "as a whole", I would like to see if I get the whole "explanation".

Whenever the function is called, it checks the 2 given parameters' visiblity.
So that:

• If ob1 is not visible, sets it visible
• If ob1 is not visible, sets ob2 visible

If you are seeking an accurate explanation, it would rather be:

• make obj1 visibility opposite to what it is now
• make obj2 visibility opposite to what obj1 visibility became

Or, more formal and expanded:

• If ob1 is visible, make it not visible; otherwise (if it is not visible) make it visible
• If ob1 is NOW visible, make obj2 be not visible; otherwise (if obj1 is not visible) make obj2 be visible

if I can see ob1 as visible, it's because ob2 is not.

No, it's opposite:
if I can see obj2 as visible it's because obj1 is not.

The correct execution of this function, obviously, depends bye the fact that when it's called, one of the two objects has to be not visible.

This is too incorrect. The function may be called with any initial states, it will set object states to properly opposite ones.
That is because the second line will be executed with obj1 visibility already changed.

Nice, let's retest this

Thanks!
I was rewriting drawing code in the engine and needed to be sure I haven't broke anything
Those games mentioned above should be enough for the tests, I think.

Unless, I'm mistaken, if you CTRL + V inside the game, it will show the version. I believe that's a hotkey that can't get removed or something like that.

Ah, something that I've overlooked.
Thanks!

Hi there, I am looking for games which have certain properties for testing AGS engine version that is currently in development.

At the moment I am very interested in finding any 8-bit (256 colors) game.
Also:
- games with excessive use of custom graphics: drawing over surfaces, using dynamic sprites, tinting, lightning, translucency.
- games which use AGSBlend plugin and(or) flashlight plugin.

Thanks in advance.

I have a question: what version of AGS was Resonance made on?
I need this to test how new engine in development works with existing games.

Will you do the auto-formatting also for the Editor? In this case, tzachs changes should be merged in first.

I strongly doubt that's needed, Editor has nice code already. I think only one C++ file of AGS.Native DLL may benefit from autoformatting, namely: agsnative.cpp.

Well, probably reverting one commit was sufficient, but thanks anyway.

I am done with bitmaps for now (that needs heavy testing, but at least I may see them drawn both in engine and editor). I need couple of days more to finish with file streams, then I'll make a branch pull and we may make the auto-formatting.

Also this might be a stupid question but why can't 8bit flc be displayed in the Direct3D driver by blanking the rest of the pallet?

I don't think this question is stupid, in fact that'd be interesting to know if that may be done. I am myself not a big graphics pro, but from looking at the engine source I've got a feeling that's theoretically possible.

And if it's not possible at all shouldn't the Direct3D driver be disabled for games that use 8bit only functions like the flic player?

The problem here is that at the moment when the driver is being set the program has yet no idea of the game contents. Again, in theory, that would be possible, but... checking all game scripts to know if certain functions are present... hmm... If the graphics driver could be updated to draw 8-bit bitmaps it would be better, I guess.

EDIT: Also, I don't think program should crash like that anyway. AGS is very exit-happy, so to say, it loves to exit even if error could be handled.
For example is aforementioned case it could simply display an in-game message that it cannot play video file and skip it.

AND CROWBARS!!!



...ahem. Sorry for that.

E: Or would it merge more easily if you applied the formatting to your branch too?

I have doubts on that.
The problem is not that ALL the code is auto-formatted, the problem is that this formatting could change same lines I did and those two variants will conflict with each other: there will be change that make old code formatted and a change that replaces old code with new one (formatted or not). Git won't know which changes to take and this has to be done by hand... all those hungreds of lines I've changed.... I am not going to do that for second time

I created the master branch based on the current refactory branch. But is also has automatically formatted code and I removed the print_welcome_text() copy protection.

Ouch, erm.... I thought code formatting will be applied a bit later.... I don't know how I will pull my branch there, it will fail to merge.

EDIT: hmm, technically there is a way, but it requires partially reverting commit (only common & engine folders).

I would consider separating as much as possible Allegro from the data structures. For example, all the GUIs are dependent on it because they don't only hold this info, but also draw it.

I just made the first (and big) step towards this by replacing use of raw allegro BITMAP by IBitmap interface throughout the code (class names may be changed later, that's not a big deal).
This also gave me better understanding of how much Allegro is nested in the engine (...quite).
There's yet much work to be done improving drawing code, it is sprawling over engine and also not very safe.

There's a big problem related to plugins. Plugin interface exposes BITMAP type and return allegro bitmap objects on demand. If there are plugins that use BITMAP directly (that is - by reading/writing returned BITMAP objects), changing plugin interface will break compatibility.
For now I left some workarounds there, but they are hacky and very much unsafe.

The code is in my personal repository, I am waiting for JJS to create new master branch based on refactored code before applying such a big change to the central repo.
https://github.com/ivan-mogilko/ags-refactoring/tree/refactory_bitmap

Meanwhile I was also working on replacing FILE ptrs with stream objects.
https://github.com/ivan-mogilko/ags-refactoring/commits/refactory_file

When all this is done I will (probably) turn towards script interpreter. Don't remember if I mentioned that, but it will be nearly impossible to work with game classes without changing the way script interpreter addresses their members.


PS. Oh, right, and still waiting for (dead)monkey's utility classes, *wink, wink*

Okay, I know this is nitpicking (or probably it isn't?) and not related to the question directly, but calling global variables "temp_x" and "temp_y" is a big step on a path to madness. It is strongly recommended to give descriptive names to global (and not only) variables so that you always remember what they are used for. Like "character_temp_x", for example.

Sorry to bother, just a small note FYI.

It's the dreaded "exception 0xC0000005"; maybe somebody who's familiar with the source can take a look (EIP = 0x004140CC)?

In the engine crash message the "program pointer" and "gtags" are more useful, these values are AGS debug helpers, they are being set throughout the code. Specifically program pointer = 3330 is pointing at this section of code:

Spoiler

Code: cpp

        coldept = bitmap_color_depth(spriteset[sppic]);

        // adjust the sppic if mirrored, so it doesn't accidentally
        // cache the mirrored frame as the real one
        if (views[chin->view].loops[chin->loop].frames[chin->frame].flags & VFLG_FLIPSPRITE) {
            isMirrored = 1;
            specialpic = -sppic;
        }

[close]

Well, the issue was resolved without all this info, telling just in case.

The console seem to be bugged. It works well with DirectX 5 renderer, but when I run the game with Direct3D 9 renderer and open the console, following eror occurs:

Error: Mismatched colour depths

The game I tested this has 16-bit color depth.

You guys have really made an atounding work on the source, I feel shamed I haven't finished porting my changes yet

Don't worry, refactored code is practically unused atm anyway, and it will take more time to test it before it may become "official".