Messages

To answer the issue of getting more testers for the game, I will definitely seek out some beta testers once the game can be finished. Right now, though, there are a lot of small, but crucial parts of the game that aren't finished yet that I need to fine-tune.

Honestly, with the game as big as yours, it may make sense to get "alpha" testers too. Not only that will speed things up, but they may give you a first impression of your game, and maybe notice logical mistakes in story and design that you missed.

1. Get more people to help you with testing.
2. Define distinct logical chapters in your story, make GUI for jumping to a chapter, as cat suggested above, and make sure it's possible to test individual chapters separately.

If you combine these two, then testers may also test separate chapters in parallel.

Unfortunately it gives an error in the GlobalScript.asc

"GlobalScript.asc(13): Error (line 13): Nested functions not supported (you may have forgotten a closing brace)"

You put function IsAudioClipPlaying inside game_start. Put them separately instead.

@Snarky the instructions that we have are very low numbers, they don't exceed 100, and this error mentions a weirdly high number. Also, this would not be a random error then.

I have a strong suspicion that this can be the filestream error which I fixed a short while ago. In simple words, it was causing engine to read the game data from incorrect position. The specifics of this error is that adding or removing some data in the game could make it to go away, which happened in Shaneaphone's case.
https://www.adventuregamestudio.co.uk/forums/ags-engine-editor-releases/ags-3-6-0-patch-7/msg636659701/#msg636659701

It was fixed in 3.6.0 Patch 8 (3.6.0.55):

- Fixed a rare bug when the Windows engine could fail loading the game for no good reason.

Shaneaphone is running 3.6.0.52 (from error message).

I recommend updating to the latest 3.6.0 patch:
https://www.adventuregamestudio.co.uk/forums/ags-engine-editor-releases/ags-3-6-0-patch-10/

I suppose that ChatGPT may be used to draft the code, but you cannot use it as-is, you must always check the manual for functions in the code, because ChatGPT is often wrong about how they are used and what they do.

If you look in the manual for Animate function, you would see that ChatGPT is using them incorrectly, and its commentary is also wrong:
https://adventuregamestudio.github.io/ags-manual/Character.html#characteranimate

So, I have tried this. I made a dummy cursor just to test having more cursors, and called it "Bark", inspired by your example in your first reply. However, when I use this code in the globalscript:

 absolutely nothing happens.

The Sniff action will still work if I use the code I posted last time now that I have properly set up the event, but not when I try to use it using AnyClick.

To double check, have you put cEgo_AnyClick function to corresponding AnyClick event in the events table?

Does this mean I can only have two extra verbs? How can I get a newly created cursor to show up in events when I use up both Usermodes?

You don't, like I mentioned, in the case of any more verbs you will have to use "AnyClick" event and check active mode using "mouse.Mode".

Secondly, when I sniff the walkable area hotspot, the game crashes with Error:

Code: ags

RunScriptFunction: error -18 ()trying to run 'hHotspot0_Mode8'  (Room 1)

This error usually means that you have some function name inserted into events table of this given hotspot, but the actual function does not exist, so engine cannot run it.

And lastly, the Sniff action still does not do anything when trying to use it on ego! I followed suit in the global script with this code:

Do you actually connect the functions in the events table, or just type them in the script?

I cannot for the life of my find out where in the scripts verbs/actions are handled, so I cant even cross reference my new cursor with one that already works, like say "LookAt". Any help at ALL would be greatly appreciated, thank you so much!!!!

In AGS there's a built-in verb mechanic, but also you may script your own. Each template presents some starting idea, but it may be changed or expanded.

If you are using built-in verb mechanic, as in Sierra-style template, then for each verb in game there's a "cursor mode" and there's a "event" associated with that cursor. You can find the cursors under "Mouse cursors" in the project tree, and you may edit and add more.
You can see associated events on the event tab of each game object (except for GUI, which have their own events). Refer to this article in the manual, and check out the screenshots:
https://adventuregamestudio.github.io/ags-manual/acintro3.html
Especially this one:
https://adventuregamestudio.github.io/ags-manual/images/acintro3_02.png

As you may notice, there are 2 extra interactions there, called Usermode1 and Usermode2. These are 2 reserved events for custom actions. If you rename an existing cursor type, then these events will be renamed automatically.

The easiest way to connect a script function to the event is by pressing the "..." button after event's name. Then AGS will generate a function for you. If you have already wrote a function yourself, you may copy its name into the event's list. This will connect this function to event.

You may change existing cursors to your needs, or add more cursors, even beyond these 2 extras. But if you make even more cursors than that, I think that you will have to use "Any click" event, because AGS does not create more events. When in the script function you'll have to check for which cursor mode specifically that is.

Example:

Code: ags

function oObject1_AnyClick()
{
    if (mouse.Mode == eModeSniff)
    {
    }
    else if (mouse.Mode == eModeBark)
    {
    }
}

Some templates, like Thumbleweed template for instance, actually use custom verb system, not connected with the AGS own system. AFAIK they lock the mouse cursor to some "pointer" or "interact" mode, and store the active "custom verb" in a variable to know which verb is currently activated. But that's a separate topic.

If your games uses a higher resolution, simply replace the 160 at the start with half your screen width or Game.Camera.Width / 2.

Buttons are placed in screen coordinates, but Camera is in room coordinates, and it tells the size of the view inside room.

The proper screen size is Screen.Width and Screen.Height.

[BUT]

I saw an example in SDL repository they called zero copy, if I understood it's when instead a hardware decoder is used in the GPU and the texture isn't back converted to a bitmap and pushed to a different texture. I guess in this case (hypothetical) the sprite slot would work as a reference to texture and fail dynamic sprites operations (which is fine) but still display in overlays? Just imagining if such thing existed.

I think for AGS, quick possibilities are:
1. Create and buffer textures on the video thread, and return texture along with the bitmap when asked. This will put both sprite's bitmap and texture into the respective caches right away, and save time on converting sprite to texture during game update (and prebuffering will be saving more time overall).
2. Decode directly onto a texture. This will require to hack APEG though, because right now it allocates Allegro BITMAP itself. We'll have to provide either our own "pseudo" BITMAP which has its line pointers assigned to a locked texture buffer, or make APEG work with a raw buffer ptr instead. This will save on bitmap->texture conversion for Direct3D/OpenGL renderers, BUT, indeed, there has to be some mechanism for detecting that a sprite is backed up by a texture, so it should convert reverse if someone wants to raw draw.
There's an alternate approach, where VideoPlayer::Open may accept a flag telling to only create textures to speed things up.

EDIT:
3. Something that I missed, the video frame should be considered an opaque image, so ideally should use slightly faster BitmapToVideoMemOpaque conversion. Problem is that currently "opaque" is not a sprite's or texture's flag, but is applied on individual case basis when drawing stuff. So this may have to be redesigned first.

In regards to the 3.6.1 release progress. Given there's not many serious bugs found recently in 3.6.1, I maybe won't be releasing any more "RC" updates, but wait for 1-2 weeks and release a final 3.6.1 (unless something serious is found in the meantime, of course).

I also get lag and stuttering when playing .ogv cutscenes, but I'm guessing that's related to something else (perhaps just general slowness of the test system involved). I wonder if any of the other new enhancements may help with that at all.

It's difficult to tell without knowing specifics. But in general, firstly, PlayVideo adjusts game's FPS for the duration of video playback. Secondly, iirc there's no buffering implemented at all, meaning it has to decode and prepare a new frame synchronously with the game update. If this is a HD video, that will take roughly as much time as would a full-screen sprite.

I was able to force GIMP to save a 8-bit BMP by adding enough colors to palette. I think you need at least 17 colors to be in the color map for this (because 4-bit index may have values 0-15).
This BMP can be imported by AGS, and assigns correct areas. So I confirm that this method works, except there are couple of annoying nuances. But I never used GIMP in indexed mode, so maybe I am missing easier ways to do what I want.

[EDIT:]

I found how to make a indexed image in GIMP, I found the palette, but I could not make it export as a 8-bit BMP. It always exports as 4-bit BMP for some reason, which AGS does not accept. When I try export as PNG, it exported a 2-bit PNG...

How do I tell GIMP to export 8-bit BMP, or 8-bit PNG exactly?
(I downloaded GIMP 2.10.36)

I suppose AGS could just support any format starting with 8-bit and lower, BMP and PNG, because all of those are indexed formats, so it should not really matter?
EDIT: I did a quick test, and for some reason .NET cannot convert between 4-bit and 8-bit image properly on its own (using Bitmap.Clone to copy image with a different PixelFormat), as it shuffles palette for some reason. Maybe I missed some option, idk. I was able to get a better result by manually copying pixels in the native code.


I think what we need is a "Knowledge base", with explanation for each popular graphic software. How to create a indexed image, how to work with palette, how to save/export for AGS. Then this "knowledge base" could be refered to whenever user is in trouble.

Because I know almost nothing about graphic softwares, and I cannot explain anything to people when they post in tech support channel!

Besides all of that, if you tell me the graphics software I will open a bug in their bug tracker wherever it is telling to not shuffle colors because I haven't seen this behavior in Aseprite, Gimp, Graphics Gale, Krita or Photoshop. Seriously, can't think a graphic Editor that does this. 

I tried MS Paint and Paint.NET.

The new MS Paint is a weird program (it became really strange since Vista or Win7, the original one was at least suitable for pixel art), and when saving 8-bit BMPs it assigns indexes using an unknown rule. E.g. I had 3 colors on bitmap and it assigned indexes like ~150 and ~220.

Paint.NET seems to number colors from 0 up in a sequence, but it looks like remapping colors each time you open, edit and save an image. (It's quite possible that it looses the original palette info upon loading image up.) Indexes are applied to colors met if going from top-left to bottom-right, so if you first draw an area at the bottom, then later another one at the top, then the indexes will swap.

The person on Discord has been using Gimp, and according to him Gimp had similar problem to MS Paint where it would assign way too high color indexes, making bitmap unusable for AGS mask. At least it seemed to keep existing indexes after exporting a mask from AGS.

If the problem is that external software behaves in inconsistent ways, there's no way to avoid the need for a "workaround" to make it work with AGS. You can adapt the way AGS works to this other behavior (for example map the channels based on color value instead of palette index), but that will break existing workflows.

I've been considering the color mapping as an option, which user could enable for their project if they prefer, to match their software (or rather assets).

If you export a mask, open it in an image editor, save without changing the format and import back it should work, no?

Besides format, another problem is shuffling of the color indexes. Not all graphic software seem to keep these, some seem to rebuild palette on each save, and some of those seem to be using absolutely arbitrary numbers instead of starting from zero and going up.

A person whom I mentioned above ended up with painting a bit of each single area color on a mask, and exported it with intent to use it further. This supposedly keeps used indexes locked in his graphic software.

But that's a workaround, and I want there to be a clear solution that just works without strange actions. A person should be able to draw and save an indexed bitmap, and pass it to AGS, knowing that it will be accepted and lead to expected results.

I would expect most people do use the AGS mask editor (supporting that as a higher priority), and that the mask import feature is more of an "advanced option."
<...>
I would suggest an import screen where you could see the mask image and a list of the mask channels. Then with an eye-dropper tool you could assign each color to a channel. A default mapping of colors to channels (if they match) would then be a nice-to-have accelerator feature.

I see that our views on this are complete opposite.

IMO it is a norm in software that data comes first and GUI second. The GUI is another way to edit the data. This approach helps to keep things organized and consistent. GUI also stands in a way of automation. A process cannot be automated (e.g. to run full game compilation from the source assets) if there are steps which may only be accomplished with GUI.

If you look into AGS 4, where rooms are stored in an "open format", you would see that masks are just plain files, and it's only a matter of whether they are edited in a graphic software or within AGS Editor. This means that the "mask import" is no longer a "side feature", but a process that is run always when preparing a room data regardless of how it was created.

For these reasons, I believe that having a mask prepared as an asset for the game compilation, and strict rules of converting this asset to in-game object - are a priority, while any GUI tools to change that mask within the editor come after that.

For the same reasons, having any interactive screen that lets map image colors to areas has to be considered an optional step, and priority is to have this mapping organized in data first, with default settings.

But realize that as soon as you move away from requiring palette-indexed images, you're going to have users who try to use anti-aliased, compressed or otherwise not 100% RGB-accurate masks.

I am not certain about non-indexed images, I'd start with making sure that indexed images work.

Isn't it all documented here? It doesn't explain how to actually create files in the required format, but since that will vary from image editor to image editor, that wouldn't be possible to document in general.

This documents the basic idea, but it does not explain the potential issues. I think it should mention which export settings to use in the contemporary graphic editors, and that some editors may cause area indexes to swap when adding more areas.

What do you mean by "walkable areas" disappearing? They do not normally shown in game at all.

Or are you speaking of working in the room editor? In that case the areas are always drawn behind objects and characters. If you want to see them, then make characters and objects not visible.

Or are you speaking of "walk-behinds" instead?

Frame Rate and Length are not implemented yet (they return 0 for me)

I've missed FrameRate property. But a situation around Length is not clear, as APEG implements it in a seemingly overcomplicated way, reading all video packets until the end. This is why it's disabled in settings. I must investigate if there are easier methods to get length from OGV theora at all. In the worst case we may say that not all formats return a valid value.

It seems Speed affects the CPU usage (I haven't profiled, but I guess it's due to standard gfx BitmapToVideoMem functions)

I wonder, I have SetGameSpeed(60) at game_start, if a video updates a 24 FPS and I put it's graphic directly to the Overlay, will the Overlay update it's graphic (to texture) at 24 fps or 60 fps? (maybe things are more complicated than that too)

So, about that. I implemented the FPS and sprite update similar to my original plan. This means that:
1. Video is played at its own FPS on a separate thread, changing frames whenever it's time.
2. There's a point of synchronization, once per game update (at Game Speed rate) where the game acquires whatever video frame is ready, and replaces the sprite's image, marking it as modified. If no new frame is ready, then it will keep the old image for a while more.
3. If the video's FPS is higher than the game's, then some frames may get replaced before game ever acquires them, causing visual skips.
4. If the video's FPS is lower than the game's, then same video frame may be displayed for more than 1 game update.

Higher video Speed requires it to load and prepare frames faster.
But also, if a low-FPS video begins to run with higher FPS, that means that the game receives a new frame not once in 2 or 3 updates, but once in 1 update. Naturally, that would increase rate at which a texture has to be updated.

For example, 24 FPS video and 60 FPS game means that game updates a sprite roughly once per 2.5 game updates.
If you increase playback speed to x2, making it run at 48 FPS, then game will have to update a sprite once per 1.25 game updates.

An additional note: if you don't need audio, then you may open video with "autoplay = false", and use NextFrame function to advance the frame at your wanted rate. NextFrame updates the sprite immediately, not waiting for sync during game update. This means you may also advance multiple frames in a loop. Something to keep in mind though, this is a synchronous function, and it will slow game down if you do multiple frames in one go.

PS. There still have to be ways to optimize the process, running full HD video seems bit slow atm.

Well you say it's not a problem, yet there is a person on Discord right now who spent 2 days trying and failing. In my eyes this is a horrendous result for this most basic feature.

If the AGS functionality requires using very particular graphic program which supports very particular export methods, and then still keep using workarounds, then that IS a problem with AGS. This means that AGS does not provide a easy solution.

And since I'm at that, I might say that this habit of brushing AGS problems off, preferring to keep the "workarounds" tactic, is probably the reason why there are so many issues in its core functionality still after many years. People just get used to "workarounds" and don't bring problems up. Then every newcomer gets into a trouble.

And of course these nuances are never documented, so I cannot even find a reference when someone asks about a problem.

Maybe we can go forth with the idea of deciding an universal mask palette, and let AGS match those exact colors when importing a non-indexed mask image.

I've been thinking about similar thing, have a "import mask" palette, optionally enabled, which has default color setup for masks. I don't think the regular game palette may be used for this, because it is divided between "game" and "room" colors, which may make using it for masks palette inconvenient.

I think it would be better to make the controls in the editor more useable, either with adding undo (and redo), brushes of different sizes and things like that or adding the polygons there too.

I don't know how useful having a mask drawing tools inside editor would be, besides being able to quickly setup a scene draft. I know that at least a portion of users prefer to be drawing masks over their room backgrounds as layers, because that lets them keep things in sync whenever background changes, and keep everything in a single image document. In the past some people even complained that they cannot update their rooms without launching the editor, wished there was a command-line tool that would do this for them. Such approach may become even more suitable in AGS 4 where room masks and backgrounds are standalone files in game folder, so one may export over them without opening an editor.

In  any case, having one method does not prevent having another.

But fixing the mask import now seems like a higher priority to make things smoother for newcomers, and possibly much easier to implement.

A recent conversation on Discord have reminded that importing masks into AGS (for walkable areas, hotspots, etc) is simply not usable.

Not every graphic software can export into 8-bit bitmap format, and those which can, they not necessarily allow to configure the palette. This means that the image will have colors randomly given palette indexes, making it impossible to predict area numbers. In the best case software will assign indexes starting from 0 and up, but others might choose arbitrary indexes in the full range (0-255), while editor cannot use those above "max area number" limit (16 for walkable areas, for example).

Even if image is "successfully" imported, this means the trouble is only postponed, because any change to the existing image may shuffle these indexes again, in which case reimport will break area indexes, forcing user to reapply all properties and events.

This is a critical problem, in my opinion, and this makes me very confused about how people work with the room masks at all, all these years; and why this problem is not set among the topmost priorities, and not discussed on forums. Because this is a fundamental functionality required to make rooms, and it is not reliable if at all usable.