Messages

@Crimson Wizard - I am not quite ready to talk about my plugin in detail yet, as would like to use it in a commercial game.

Well, there's no need to go in full detail, but perhaps only mention the general purpose would be possible? If we do not see your code, we cannot "steal" anything anyway.

Of course it's up to you; but as I participate in AGS "tech support" for more than a decade already, I find that quite often people may use overcomplicated methods. So double checking that other methods don't exist may be useful.
For another reason, this helps to learn if AGS itself is missing some features, that could be added in the future for user convenience.

[not overwritten]

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.

I am writing a plugin and as part  of what my plugin needs to do, I basically need to redraw everything on the screen.

Could you please tell, for which purpose do you need to do that? I am asking, because sometimes there may be more convenient ways to achieve what you want. Maybe they already exist, if not, maybe something could be added to the plugin API, or script, to let that happen.
Like eri0o said above, depending on how much "in sync" would you like to keep your drawing, keeping your plugin up-to-date with the engine may become a struggle.

Basically, my Draw() loop is something like:

Code: ags

DrawObjects()
SortCharactersByY()
DrawCharacters()

This is wrong: the objects, and characters, and walk-behinds are all sorted among each other. So you need to gather ALL types of objects together and sort, then draw ALL of them sorted. For example, in AGS this is done by gathering structs of [sprite / order] in one std::vector from all relevant objects, then running std::sort: then you have a list of sprites to draw in a proper order.

What I think the Engine is doing is that it's basically creating the WBs as sprites and then simply sorting the sprites (chars, objects and WBs) in order of Y

It's not always Y.
Characters and Objects use Y by default. But they also have Baseline property: if it's set to 0 (by default), then they use their own Y instead. If Baseline is set to anything besides 0, then they use Baseline explicitly.
Walk-behinds always use Baseline as-is.
GUI and Overlays use ZOrder property for the similar purpose.
Since 3.6.0 Overlays may be drawn "inside" the room if they are created as "room overlays", with a special flag. In which case they use their ZOrder property to sort among characters and objects.

Summed up:
Room Objects: Y; but if Baseline !=0 then use Baseline;
Characters: Y; but if Baseline !=0 then use Baseline;
Walk-behinds: Baseline;
Overlays: ZOrder;
GUI: ZOrder;

BUT there is a mode in there called "DrawOverCharSprite". I think that my plugin could do that, but I am still not 100% how that works?

DrawOverCharSprite mode is a performance optimization done by the Software renderer. Because with the software rendering it may be slow to redraw large images on screen every time, instead every character and room object has an additional intermediate bitmap, consisting of its own sprite, and any parts of walk-behinds it is standing beyond painted over.
In other words: take a separate image size of character's sprite, paint character sprite, then paint over a piece of walk-behind which intersects with it.

Whether that is necessary for your plugin or not, - I cannot tell.

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

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.

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

Well, display of the placeholder sprite could be confusing, but I explained what it means in my very first reply. Both original and following script versions seem to  contain logical mistakes, where overlays kept using a DynamicSprite(s) which went out of its (their) life scope.

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.

[EDIT:]

EDIT: Had to reupload the RC5 update once more, with 1 extra bug fixed. (details under spoiler)

Spoiler

So, there's immediately a new bug that I did not notice in time: the GUIs have few pixels cut off from their top and right edge.
OpenGL has a slight difference: looks like it's cut from top and right edge.
EDIT: hmm, or rather gui elements are shifted up or down. Also, not sure why, but it looks like this only happens to buttons or backgrounds made of sprites.

Easily seen with the iconbar in Sierra template, where buttons are suddenly not centered in Direct3D, or cut from the top in OpenGL.

EDIT: I found an approximate reason, will need to make a quick fix and reupload a release.

EDIT: Ah, so this is a stupid rounding error, which creates a 1 px mistake if the GUI has non-even size.

[close]

I keep hitting a post limit of 30k characters when making Release posts, because I need to put download links, changelog (which may contain a lengthy list of items), and some overview, etc.

I guess the easiest workaround would be to make extra empty post(s) for backup, right after the first one. But in this case I forgot to add one.

Is it possible to somehow add an extra post in the middle, if I'm a local moderator?

Hmm, maybe I should be giving a link to changelog elsewhere instead.

[Editor]

Updated to RC5 (3.6.0.40)
(use download links in the first post)

Editor
- Fixed games built for Linux cannot load AGSSteam plugin.

Engine:
- Fixed GUI controls incorrectly blended with gui background if GUI.Transparency is > 0.
- Optimized memory usage in Direct3D/OpenGL renderers related to plugin raw drawing.
- Fixed Direct3D/OpenGL renderers were displaying plugin's raw drawings in a wrong position in the scrolling rooms, if the drawing was done on AGSE_PRESCREENDRAW or AGSE_POSTROOMDRAW events.

Plugins:
- Fixed SnowRain plugin drawing particles only in 320x200 bounds.


Reported issues remaining:
* Direct3D is said to still be not fully stable when alt+tabbing in exclusive fullscreen mode: https://www.adventuregamestudio.co.uk/forums/ags-engine-editor-releases/ags-3-6-0-release-candidate-rc1/msg636650995/#msg636650995

What I don't get is why all these overlays do not change their sprite as soon as the slot is repopulated with a new sprite, so it looks like the graphical overlay does somehow buffer the sprite even without the clone parameter?*

*I'm still not sure what exactly is happening tbh. But it's pretty safe to say that this is caused by user error, not an engine bug.

Could you clarify this; do you know if it's possible to reproduce this with a simpler code?

Some sprite and texture caching exist in the engine, so it's hypothetically possible that it is not cleared on sprite deletion too. (That happened with room objects before)

If this is what actually happens, then it of course should be considered an engine bug. I would separate solving the bug and workarounds; and I'm mostly interested in the bug details atm. There's a ticket opened about same problem: https://github.com/adventuregamestudio/ags/issues/1879
Ideally we'd need a walkable mask, and an example of starting position / Walk command arguments which causes character to stuck. This would help to reproduce and diagnose the problem.

I had to reverse the logic: rather than manually drawing walkable tiles, I had to make whole room walkable and "drill" nonwalkable tiles in it

Ahh, actually I thought this is what you're doing from the start; I had a wrong idea all this time.

Note: apparenly it's better, for isometric games, not to extend the nonwalkable areas/tiles in all directions, but only downwards.

This makes perfect sense, that amount of "outline" may be different depending on direction. I'm bit concerned about the horizontal corners too, but that's something one may find out by testing.

I'm too not quite certain about the reasons, but there's RunAGSGame function that lets to run another AGS game from the first one (and so forth): https://adventuregamestudio.github.io/ags-manual/Globalfunctions_General.html#runagsgame

The code snippet I pasted above is taken as-is from my script: all rows are one after the other, all inside the same function; moving the declaration out of the function as first line of the script does not help. The sprite IS drawn and it DOES remain there after function ends... but it's the wrong sprite!

This does not sound normal, I expected Khris's code to work.
If the wrong sprite is one with ID = 0, that's a placeholder, which might mean the dynamic sprite was deleted.
Can you post a code that you tried according to the Khris's advice (and which still did not work)?

Can a warning message be added in the editor console? This is an "autonomous behaviour", I would expect a "null pointer error" rather than automatically changing to default pointer, but if the "autonomous behaviour" is designed to prevent game crash, maybe a warning to developer would be enough.

Adding a warning is a good idea. I don't think editor is currently programmed to receive runtime warnings like that (this may be another future feature); but the warnings about potential game mistakes are written into the "warnings.log" file found in Compiled/Windows folder when the game is run with F5 from the editor.
(and also in the general engine log too)

When you assign DynamicSprite to an object, it normally is not copied, but referenced by the sprite ID (this is their Graphic property). Like Khris mentioned above, in AGS script dynamic sprites, like overlays, are deleted when the last pointer to them is removed, which happens when the function ends in your case. This is similar to Overlays. As soon as dynamic sprite is destroyed, the game object looses it and switches to sprite 0, which is historically used as a "placeholder".

Painting the dynamic sprite onto background will stay, as it changes background image, so it no longer depends on a sprite's presence.

But in regards to Overlays, there's another opportunity: CreateOverlay* functions have an optional "clone" argument. It's default value is "false", but if you pass "true", then they will make a copy of an assigned sprite, and the original sprite may get safely deleted after. So, if you do not want to keep the sprite afterwards, you may use this method.

Code: ags

Overlay.CreateRoomGraphical(screenx - tilewidth/2, screeny - 2*tileheight -3,  flipped.Graphic, 0 /*transparency*/, true /*clone*/);

(This is since AGS 3.6.0, previously it was always cloned, even non-dynamic sprites, which could cause lots of redundant sprite copying.)

This behavior is documented in the CreateGraphical's article:
https://adventuregamestudio.github.io/ags-manual/Overlay.html#overlaycreategraphical

This won't work with other game objects though: for them you'd have to save dynamic sprite in a global variable, like you seem to do with Overlays.

Anyway I'll disable mouse and use only keyboard control to override this behaviour.

I might mention that mouse or keyboard (as an input method) do not enforce walking behavior. It's all in the script, how the script reacts to the player's input, which functions it uses. It's possible to call same functions in both cases.

Isn't pathfinder algorithm hardcoded?

The pathfinder is hardcoded, but the reaction to player's input is not. Everything that happens on mouse clicks or keyboard presses is in the game script and may be changed.

If there's a difference in how character walks after mouse click and key press, this means that the game script issues different commands depending on the input event. And it should be possible to alter the script, making them both to produce similar behavior.

What I am trying to say, is that you don't have to drop an input device support only because the original game script causes it to do something that you do not like.

At the moment I do not fully know which walking behavior you are trying to achieve, so I am merely speculating.
If I remember correctly, in the default game template keyboard controls call WalkStraight function, passing relative coordinates instead of absolute ones (like, player.x + X, player.y + Y). It is possible, for example, to do similar thing with the mouse, by converting absolute mouse coords into relative ones.

This is only to clarify existing opportunities.

[* iterating through existing objects using AGS own arrays.* creating your own arrays;]

Like eri0o mentioned, if the objects names have numbers - that does not mean anything, and does not automatically let you iterate through them. Iterating may only be done over arrays, but array is a separate variable, like a list, that has to store references to these objects.

I think it's worth mentioning that there are 2 potential questions here:
* iterating through existing objects using AGS own arrays.
* creating your own arrays;

In AGS many types of objects are already stored inside some array. For instance, room objects are stored inside "object" array (it's literally called - "object"; you may notice it in the autocomplete list when you type).

If objects in question are stored sequentially. have sequential IDs in this room, then you may as well just use that array. In the loop you would iterate starting with the first object's ID and until last object's ID.

Code: ags

int i = FIRST_OBJECT_ID;
while (i <= LAST_OBJECT_ID)
{
    object[i].Visible = false;
    i++;
}

If objects are not sequential, and it is not convenient to remake the room, then you would have to create a custom array and store either their indices or pointers there. Think of this as writing a list of items, which references only a portion of existing ones. This is what eri0o's example is about.

I'd only exclude unnecessary extra "initArray" function to simplify things, and put the initialization directly into Room_Load.
Also, to prevent possible misunderstanding (because you already had a misunderstanding about a number in name): your array's name does not have to be similar to object names. There's no connection at all. You may call it "ImageList", or whatever.

Code: ags

// This is array of object pointers, it will contain pointers to some objects, but not objects themselves
// defining OIMG_COUNT here is not obligatory, and is used only for convenience
// (to avoid hardcoded array sizes in case you would like to change the number of elements in the future)
#define OIMG_COUNT 4
Object* ImageList[OIMG_COUNT];

function Room_Load()
{
    // array indices begin with 0; overall indices have no relation to the object names;
    // that is - object names could be MyObject, MyAnotherObject, and so on, without numbers.
    ImageList[0] = image1;
    ImageList[1] = image2;
    ImageList[2] = image3;
    ImageList[3] = image4;
}

I honestly still do not understand why cannot you make the non-walking area further from their tiles to compensate for character's sprite width? I think that would be the first thing I'd try, if I were experimenting with such setup. Would not the result look approximately as if the character's "blocking area" was working the way you implied? Is there anything that prevents using this method?

Anyway I'll disable mouse and use only keyboard control to override this behaviour.

I might mention that mouse or keyboard (as an input method) do not enforce walking behavior. It's all in the script, how the script reacts to the player's input, which functions it uses. It's possible to call same functions in both cases.

Looking at how character move with debug mode enabled to show walkable area, apparently it seems that check is performed on single pixel on foot of the character versus edges of nonwalkable area. In other words, the "nonwalkable hole" around character's feet can overlap the nonwalkable area, as long as the single pixel at (playerwidth/2 , playerheight) is out of the area.

Can this be considered a bug?

No, this is not a bug, this is an intended behavior of AGS. I tried to explain above, that this "hole" is used only to prevent other characters from walking too close to the "solid" character.

Yes, like you say, when calculating a path, the check is only performed against a single pixel on foot of a character, and not the area around it.
IIRC, this particular character's "hole" is edited out while calculating the path, so it does not block itself.