Messages

I opened a PR if someone wants to test this out the CI server should make the build soon:
https://github.com/adventuregamestudio/ags/pull/1646

I'm using 3.5.1 and i can't find "Enforce object-oriented scripting" anywhere thus i'm stuck with "Undefined token 'RawDrawImageResized'" error.

It's General Settings -> Backwards Compatibility -> Enforce post-2.62 scripting. The option has been renamed to clarify what it means.

Question on cloning. Say in the future somehow is decided that the Graphical property (the sprite id) must be also a writable property, if the Overlay was created using a clone flag, does it mean it should copy on change and not really be a reference in that case? I am wondering if an Overlay should have an additional property for the Overlay type (say textual, graphical clone, graphical... ?)

I see cloning behavior as a historical bit that we are forced to keep for the time being, but may remove later (in ags4). In my opinion that should not be a part of an object's logic (otherwise we should add same to every object), but rather a part of a sprite management. So, if Overlay.Graphic is added at some point, imo that should be non-cloning reference always.

But... 1920x1080 is my screen's resolution. Does it mean that I will be unable to efficiently play the game in windowed mode?

Not sure if relevant in this case, but 3.6.0 supports "borderless fullscreen window" mode, that makes switching in and out simplier and more stable than in regular fullscreen.

on_ events don't happen when something is blocking. Also they are not good when you need to get something continuously, like keep the character walking.

Ok, but so do events for mouse clicks and keys, and yet they exist and are useful.

Skipping text and skippable blocking actions should be done in the engine IMO. In other words, whenever there's an event for mouse or keys there should be a corresponding event for gamepad. If a mouse or keys are checked in the engine, so should gamepad be checked as well, and so on. Well, at least this is how I thought this will be done. Is your goal for the moment to use gamepad to simulate other inputs in rep-exec-always?

About on_gamepad_press, I will at some point, but it's not very useful right now (can't skip text) so I will keep using repeatedly execute always at this time.

Could you elaborate how is this related to skipping text?

IMO it may be useful just as the key presses in on_key_press are useful: to react to button press without having to deal with their on/off states in the rep-exec. Right now it seems in your examples you're trying to use gamepad to simulate mouse cursor and clicks. But gamepads could be used without mouse cursors as well, similar to how keyboard is used in keyboard controlled games.

My meaning in general is not to try to simulate anything with gamepad (this was the plugin's approach, because there was no other way) but instead integrate gamepad as a part of the normal engine input and script. Have events for gamepad similar to how there are events for mouse and keys.

[on_gamepad_press]

I see that the gamepad buttons are used as mouse click simulation, but I assume this is done temporary for a test.

Should the goal be to have gamepad buttons handled similar to keyboard key and mouse clicks, that is to have their own respective callback, like on_gamepad_press?

One optional idea is to have gamepad buttons merged with eKey codes. The benefit of that is that you may assign them to the same variables as keys, both in engine API properties, and script variables.

[p1]

I'm thinking that the most straightforward idea for at least a temporary solution for p1 (graphic sharing) would be to just add a parameter for CreateGraphical that tells "make copy". Make it false by default, as in - make a reference. For example:

Code: ags

Overlay.CreateGraphical(int x, int y, int slot, bool transparent, bool clone = false);

The reason why I think it should "not clone" by default is, to prevent unnecessary resource load without user realizing that.
This would work seamlessly for normal sprites. For dynamic sprites, people might stumble onto this once if they delete the sprite too early, or change it to suddenly see the change in overlay as well. This is solved by learning about the parameter.

The old games run in the new engine would have to "make copy" all the time, as they did not have such param.

Additionally, it would be possible to optimize this by (implicitly) not making copy if we know it's not a dynamic sprite, because normal sprites cannot be changed or deleted.
At first I thought this might be the best approach without extra script parameters. But then I thought that in theory a game may have a collection of generated dynamic sprites applied to overlays, like some kind of a tilesheet or something, in which case making copies would also be not wanted.



UPDATE: Hmm, this appared to be rather promising. At least it works. Even if I'd only make an implicit rule to not make copies of a regular sprites without changing script api - that already should improve perfomance when there's alot of overlays with similar sprites on screen.

but I can't quite understand what you mean by your idea of the dummy character... which seems interesting.

Trying to explain, the basic idea of this is two have two "worlds":
1. an imaginary (not shown on screen) top-down world, where you do all the movement calculation, pathfinding, etc, and get the positions of all objects;
2. a visible isometric world, where you do no calculations but arrange objects and characters.

Between these worlds there's a coordinate conversion. So you calculate movement and new positions for all objects in the first top-down world, where it is easy to do; then pass each object's coordinate through some function that converts them into isometric coordinates. Then use these final isometric coordinates to place objects in AGS room.

About the "by reference or "by value" issue:

How about submitting a pointer to the function and overlays would be created by reference, whereas supplying a sprite slot would result in creating a copy.

Which pointer? If you mean sprite's, there's no Sprite type in AGS to pass a pointer for, only DynamicSprite, but that would limit this to dynamic sprites only. Unless we create Sprite type to address all the sprites.
In general i think such approach would be confusing to people, and inconsistent with the rest of the script commands, where assigning a sprite slot does not create a copy.

Hmm, perhaps the similar thing could be emulated using animation frames? For example, have a sprite with transparent parts, object taking roughly 90% of it. First play animation of an anti-aliased movement within the sprite, then move the real object on screen, and repeat starting with animation again.

But I guess drawing over would save some memory at a cost of some cpu load.

I think image zoom does not work again. When I click x2, x3 etc, the image simply dissapears.

Few years ago I've been answering a similar question. Although the combat system the person was asking about could be different, but the reply was mostly about the approach to coding, so I'd allow myself to citate that old post again: https://www.adventuregamestudio.co.uk/forums/index.php?topic=55643.msg636578340#msg636578340

Coding is not only about knowing the programming language, but first of all about writing algorithms and structuring your program.
Complex algorithms are usually broken into smaller parts, to make it easier to understand and code.

My biggest advice to anyone who begins to learn programming and wants to make something complex, like fighting in this topic:
First, write down what you'd like to have "on paper". At this stage there's no need to go into much details, just rough outline. What objects would you like to have on screen, how these objects act, how player is supposed to act.
Second, try to break the whole scene down to smaller tasks, and learn to make these one by one, separately. After you did, you will be able to combine complex scene out of those pieces.

For example, you want to have QFG-like combat. This involves a picture of a player that swings sword (or does other stuff) by player's command and picture of enemy that does actions by AI command. Essentially this means that there is some visual character that receives commands from a source. Source can be either player or AI script.

Try following: make a simplier scene (perhaps in a test game), where you have a character on screen, that runs animations when player presses a button. Learn how to test when action ends, so that player could not run new actions before that.

Then make another scene where same character is controlled by a script. Learn how to make it launch same actions randomly, by a timer.
It may be important to learn how to "detach" animation script from AI script, to make them independent of each other. This way you will be able to connect same AI script to multiple characters.

Next step: teach AI to react on opponent's actions. You do not have to have actual opponent for that. Implement "imaginary" opponent. For example, remember what opponent is doing (defending, attacking, etc) in a variable, put a text on screen telling that to make it easier for you, and let player change that imaginary action by key press. Make AI react to this variable: when you set it to "attack" - AI should defend, and vice versa (or other variants).

Fourth scene could be where two characters stand face to face. They may be even both controlled by AI. Make them fight with each other using techniques you learnt in previous three scenes.

After you succeed in this, move on to combat rules and GUI part, with health, winning and loosing conditions, and so forth.

One limitation is that (unlike Thimbleweed Park) AGS doesn't do sub-pixel positioning, which means that parallax layers that are supposed to move very slowly can appear "jerky."

Overall a way to improve is to calculate movement (velocity etc) and position in floats, and then convert to pixel pos using "round to nearest" method only when the game object or image itself is repositioned.
This approach helps to create a good enough illusion of smooth movement to human eye.

Also, it's best to do such updates in late_repeatedly_execute_always, as this function is called after game updates itself, but right before it is redrawn.

So, we found that Strings in script are not saved properly.

Here's the fixed build:
https://cirrus-ci.com/task/5389912781357056

[data just disappears.]

Filling up the structs with data works fine when the game first starts up, but if I load a saved game, the data just disappears. Calling the setup functions a second time under "eEventRestoreGame" fixes it, but I feel like this shouldn't be happening in the first place.

Was that save made after you configured these structs in your script or earlier?

Having overlays in rooms was simple enough to make, and it opens many possibilities, so perhaps will be added to 3.6.0, if testing is successful.

I think I won't plan p1 for 3.6.0, because there are more things to consider there (like the dynamic sprite handling that i mentioned). And since it's already in Beta, so perhaps I'm already pushing it a bit too far with new features.

Well, is someone wants to try out the experimental build, here's room overlays support:
https://cirrus-ci.com/task/6659508301725696

Room overlays are created using new pair of functions:

Code: ags

  /// Creates an overlay that displays a sprite inside the room.
  import static Overlay* CreateRoomGraphical(int x, int y, int slot, bool transparent);
  /// Creates an overlay that displays some text inside the room.
  import static Overlay* CreateRoomTextual(int x, int y, int width, FontType, int colour, const string text, ...);

They are same overlays, but drawn and sorted in the room space using their ZOrder property. Unlike characters and objects they don't automatically change their order when moving along Y axis, so if you want them to do that, you have to write something like this in script:

Code: ags

function room_RepExec()
{
	if (roomover)
	{
		roomover.ZOrder = roomover.Y + roomover.Height;
	}
}

Maybe something for future AGS releases to take into account vehicle acceleration switching gears, etc. It's just an image flying over the screen lookin' a bit unfinished atm. 
I guess i'll have to wait for it then, maybe i'll give it a go later, perhaps you guys could use some feedback from the "average user", who knows.

Well, you don't really need future AGS releases to implement acceleration or switching gears, this all may be done in script. You also don't need Character.setwalkspeed, you may always set x,y position yourself, and then implement velocity and acceleration as variables that you change in script.

[The direct 3D plugin by AJA]

and the The direct 3D plugin by AJA, i think i've red somewhere that you should be able to rotate with it, i know it's only available for PC, and i have no plan to do a "multiplattform" release in the future, yet anyway, so i would have liked to try it out, and see what it can do. I mean ofc i could try and rotate the wheel in animation instead, but it's not gonna look pretty. It's none aliased pixelart after all and it's obvious to the eye in Thimbleweed Park forexample that it's a sprite that is rotated with some 3d (probably) trickery or such. I will try what you've wrote out of course, but it sounds like it's not what i'm looking for since the antialias that is most likely is going to happen will ruin the pixelart, Thanks for your reply as always!

This is true, rotating the sprites with dynamic sprites will always be pixelated. D3D plugin should indeed solve this problem.
We also have an experimental version of AGS which supports rotating objects in 3D, but it's a wip version that changes often, and not "official" yet, so idk if i should recommend it.