Messages

@Khris I believe has been using Windows 11 with AGS for a while.

I had an issue with green stripes on Intel in Ubuntu a long while ago, but it affected everything - so not just AGS.

I wonder if exclusive fullscreen and desktop fullscreen makes a difference and the different graphics driver (Direct3D, OpenGL and Software).

AGS characters can walk in two ways, I don't remember right now the right names but it's either non-gliding and gliding.

In non-gliding mode, the character walks a specific number of pixels (the walkspeed in this case) each specific number of frames (it's the delay of the walk animation). So to walk that specific number of pixels the pathfinding is broken in that specific number of steps - so if you change the walkspeed in the middle, which is the length of the step, it has to re-calculate the path to reach destination. This should be possible (at a cpu cost) but the way AGS does right now is it simply won't let you do this (I believe it gives an error saying that you shouldn't do this). So in the non-gliding mode, which is the default, the way to go to speed things up in the middle of the walk is to reduce the delay of the character - which won't alter the path, so it's allowed when the character is walking.

Now, in gliding mode, I don't remember what the walkspeed means right now, but in this mode the character can change the walkspeed mid walking.

Spoiler

Ah, if you are trying one of my previous experiments of the gamepad, I noticed now I never posted the last binary version that got merged in the forums, so in case you are already using ags4, it's better to wait for the next release to be posted in the forums.

[close]

How's that going anyway any progress?

The work for the gamepad has been merged in ags4 and should be in the next alpha release of ags4! There is still work to do in that front, hopefully people play with it a bit there, and we see the things to add on top of the gamepad api, and what has to be improved/clarified then.

The issue is upstream of us, here:

https://github.com/icculus/mojoAL/issues/12

There is an open PR there that adds an extension to mojoAL that would make it possible to do it. The discussion there explain the details.

Could you give at least some specifics of this problem, how large are these compiled scripts? Is it size of bytecode, or size of text that makes them large on disk?

I don't know to break it apart, but in my Sandwalker project the biggest file size is in game28.dta which contains all the scripts.

For instance, I should mention that the way AGS allocates global variables currently is that it writes their whole initialization to the script data. Of course that does not work for arrays, because AGS currently does not support syntax of initializing arrays at compile time, but global arrays are written to script data anyway.
What this means in practice, is that if you have a global array of 1000 ints in script, then script compiler will write 1000 ints into script data.

There is a chance that 20 MB of this is the map code then (there are 16 of these here, with around 1.25 MB each), because it's a very big int array.

There is still other code and things that have unknown relations on how it makes things so big.

I am alright with the game script being duplicated in ram because of decompression if necessary, but my guess is this may either be a thing that matters or not depending on how heavily scripted is the game.

I notice in my either script intensive games, or very lots of dialog games, there is a lot of the size of the game that is mainly due to the size of the scripts - I usually work in low resolution, so the image files get very small already.

I am not sure how to do or proceed with this. On one hand in the past games usually compressed their texts using some strategy - this is really common in very old games that had to fit in a ROM cartridge with very limited storage. This is an strategy, to simply compress only the strings, but I wonder if there is any way to directly compress the entirety of the script objects.

I don't know if this is the best approach or some other approach is best - say have the packaging format itself support compression. I also don't know if it's reasonable to just decompress on game boot and have the uncompressed script objects to work with or if it would need to be streamed from the compressed package.

Anyway, because of the unknowns around this I decided to write it here just to start to think about this.

I think this control is a bit hard to operate, a proper tree like the one we have in the project explorer maybe would be easier to use - but then we need to figure out how it works in terms of the space it occupies and how to be clear about selection and other things.

As an work around, the menu over the properties has a combo box that is easier to find the thing you are trying to reach in the selected category - hotspot, objects, ...

Operating on release is also expected in the Xbox Accessibility Guidelines, I recently noticed that this is how all operating systems works - on release, and they have an additional feature that if you release elsewhere you can cancel the action.

Any game that is equal or more than 200MB will give a poor experience in the browser, it should ideally aim at less and properly mention size if going above 100MB as the mere view of the game may eat the bandwidth of a person on limited data connection.

There isn't any type of multiplayer support, it's the same as regular AGS. If you can support multiplayer through some plugin in your regular desktop ags game, than you will have to port that plugin to the web yourself and rebuild the engine with it.

About dynamically created objects we need to first have either delegates (#1409) or pointer downcast (#2018), so we can pass a function/action object from script to a function/attribute that "links" the necessary interactions. Since any of these will probably be exclusive to the new compiler and ags4 is meant to have both the old and the new compiler for a while, we can't do it there until the old compiler is let go - assuming the new dynamic creation will be the only way. So I don't see this making into ags4 without big changes (possibly breaking).

About AGS dev, I honestly think a lot of the problem is lack of people, for development. See this example from scummvm, there is like 5 people doing tests and trying different code ideas to solve a problem (our old FreeType dependency due to breaking changes in font metrics). A PM would be nice, but they would have trouble scoping with the limited resources - one more senior ags dev would be ideal, as I think only CW is senior among the contributors. Unfortunately I don't know how to get more devs or make the project more approachable.

I really liked Food Wars, it starts really calm and then gets more intense - in the theme of nominating favorite games. We probably need to archive these games...

I always felt slasher games had heart - some terrible graphical choices at times, the non-adventure stuff could be very confusing, but games that didn't take themselves seriously, and that were finished and playable, and that often could make you smile.

Hey, it would be nice if someone could test this and report their findings. 

MAGS without slasher is certainly different. Rest in peace.

PR is merged, in another thread some mentioned reimporting all audio clips and also reporting failures, that is also included in the new feature.

I looked into making the Editor 64-bit but the thing I could not figure out is exactly what is mentioned here, the Gif import uses a NuGet package for ImageMagick but it uses some 32-bit (x86) binary files and some 32-bit bindings between the managed code and these x86 stuff.

I couldn't figure it out how to use a 64-bit version of this package only when building for 64-bit and how to force VS to rebuild - it's not like C++ and preprocessor checks... So I abandoned the AGS Editor 64-bit at that point. The other things that aren't this specific NuGet package are fairly easy though.

Hey, made a PR for this, targeting 3.6.1. (editor binaries here)

I have a module named Arrow Select that could theoretically be used too, it's meant for selecting things using the keyboard but it has a feature that retrieves a list of things on screen that can be interacted with and you can iterate this list to show something graphically for the things you wish too.

I know some old AGS games also did this by simply having a hidden scree sized object where the interesting stuff has hardcoded drawings to point to it and then you can simply show or hide this with a keypress.

I updated the API in the first post and added links to example project file, downloadeable test game, online test game...

There is a chance some really newer controller doesn't work in some way, but once the SDL2 version is upgraded these will probably be fixed (some joy-con stuff, and some steam deck stuff)

Hey, my ImGi module started as using Overlays but it quickly changed to be based to Drawing Surface with it's own hashed-dirty-rects system due to the limitations of Overlays at the time - like, there was no sorting of overlays at the time.

There is still one limitation that makes it rather tricky to rewrite it as hardware accelerated that is there is no clipping in an Overlay, and this makes something like scrolling a bit hard to do - like, I would need to make things hardware accelerated and selectively degenerate things as software drawn when they were clipped, which is a bit hard. If there was some hardware accelerated clipping, than it could be done easier. Alternatively, some sort of Camera system in the GUI space would also work - although much harder to manage from a scripting perspective, "clippable " overlays would be far easier.

Made the feature here: https://github.com/adventuregamestudio/ags/pull/1759

Targeting 4.0 release