Can't flip sprite

[Snarky]

But warnings regarding missing sprites should be added of course, imo that's an oversight that there was none at least printed to warnings log.

I'm not convinced. Consider something like:

Code: ags

DynamicSprite* dsFluid;

  // ...
  for(int i=0; i<simulationSteps; i++)
  {
    fluidSimulation.AdvanceSteps(1);
    dsFluid = fluidSimulation.Render();
    btnDisplay.NormalGraphic = dsFluid.Graphic;
    Wait(1);
  }

In other words, a button displays a dynamic sprite, and this sprite is updated to do some animation (by switching the pointer to a new dynamic sprite rather than by redrawing onto its drawing surface). In this case, the old dynamic sprite no longer "exists" (refcount==0) as soon as dsFluid is reassigned, and so btnDisplay.NormalGraphic is invalid at that point. Of course, we're just about to update it in the next line.

Should AGS throw a warning (or actually, simulationSteps warnings) about that? Seems like it would clutter up the logs.

[Crimson Wizard]

Should AGS throw a warning (or actually, simulationSteps warnings) about that? Seems like it would clutter up the logs.

Yes, that's a valid point. This would require a somewhat different approach then, but I'm not sure which at the moment.

For example, engine could only save the information, but process it only when updating/redrawing the game - for the objects that still don't reference anything,

Anyway, that's completely separate topic, and I would not want to clutter this forum thread. There was already a ticket opened regarding this: https://github.com/adventuregamestudio/ags/issues/1880

[jumpjack]

I think the main issue is that the engine should not go on with an arbitrary value for the sprite: a program should never act "on its own", inventing a pointer!

It's not an "arbitrary value," it's 0, aka null.

[/quote]
If 0 and null are considered "the same", we have a serious problem here.
Anyway I leave the discussion to AGS experts, because I found the solution for my script.

[Crimson Wizard]

It's not an "arbitrary value," it's 0, aka null.

If 0 and null are considered "the same", we have a serious problem here.

Hmm. I have no idea why Snarky even mentioned "null" in this context, as the sprites in Overlays and other game objects are referenced not by a pointer, but by an integer (sprite ID).

No, "null" is not the same as "0" in AGS script; even though it was originally based on C programming language, but it ended up something like a mix of C and C#. "Null" may be only applied to pointers. Other variables cannot be assigned "null", and pointers cannot be assigned "0" and other numbers.

In AGS script non-pointers cannot be nullified (or "undefined"), like in javascript, for example, - they always have a value.

[eri0o]

I don't like excessive log messages and checks that are not necessary that will only reduce performance. There's no need for it. This will only reduce log usefulness.

Also 0 was used in place of null in optional parameters - before some change in the compiler. Not sure if it was zero instead of null a long time ago somewhere.

0 is not a blue cup, it's the 0 sprite, which is ignored in some cases (GUI background and button graphics), and has a special meaning. It happens in the sierra template the sprite 0 is a blue cup.

[Snarky]

Hmm. I have no idea why Snarky even mentioned "null" in this context, as the sprites in Overlays and other game objects are referenced not by a pointer, but by an integer (sprite ID).

Just that "null" literally means zero, and null pointers are typically implemented under the hood as a pointer with a value of zero. So while they apply to different types, there is a fundamental connection between null and 0. Setting references to nonexistent sprite IDs to 0 is therefore loosely analogous to setting a pointer to null (of course with the important difference that 0 is in fact a valid sprite ID for an existing sprite, unlike null pointers, which have no existing referent).

Also 0 was used in place of null in optional parameters - before some change in the compiler.

As of the current official release I'm fairly sure it still is, though that's not why I made the comment.

[Crimson Wizard]

[DELETED] because I should not continue discussing unrelated things here.

[jumpjack]

I added further info and a screenshot in the issue, but it is closed and discussion should continue here:

https://github.com/adventuregamestudio/ags/issues/1882#issuecomment-1374435160

[Khris]

I'm sorry, but can you clarify what you're asking for exactly?
The solution to this issue is to either
a) create an array of dynamic sprites so each overlay has its own
b) use the clone option so each overlay has its own

The github post seems to just restate the original problem, which in my book is thoroughly analyzed and solved already?

[Crimson Wizard]

The solution to this issue is to either
a) create an array of dynamic sprites so each overlay has its own
b) use the clone option so each overlay has its own

I might add, that you also may assign same dynamic sprite to multiple overlays, so long as you keep that dynamic sprite saved somewhere (in a global variable, or inside a global array) and not overwritten.

Since you are generating maps using same "tiles library", you may also use a slightly different approach.
Make an array of dynamic sprites, containing only necessary variants. You may precreate it once at the game start. Then, when you are creating overlays on a map, simply use dynamic sprites from that array.
Such approach should improve performance too.

[jumpjack]

I'm sorry, but can you clarify what you're asking for exactly?
The solution to this issue is to either
a) create an array of dynamic sprites so each overlay has its own
b) use the clone option so each overlay has its own

The github post seems to just restate the original problem, which in my book is thoroughly analyzed and solved already?

my script is working fine, I don't need any further help, thanks.