AGS 3.02 Wishlist

[lemmy101]

Thanks again for 3.0.1 CJ, it's fabbo! Since there was no suggestions thread yet and I had one I thought I'd make this, hope that's okay!

A few times I've buggered up the game slightly as I've now become reliant on the source control feature,  but the acsprset.spr file and alike aren't handled under source control so if I try and save after adding sprites, at best the changes don't happen and I have views pointing at invalid sprite numbers. If when I edited the sprite folders in any way it requested I checked out the relevant files that would be fab.

Also, and low priority one this, if there was a way to block out the DX5 option in games that rely on the DX9 interface, that would be great. A couple of times team members have been getting broken versions of the game and it has turned out their settings have somehow ended up on DX5. No biggie for now but for release it could cause a lot of problems.

Thanks again!

lemmy

[Mr.T]

Is there any way to know which sprite is used or not?
If it's possible it could be a nice feature for size/optimization 

[DoorKnobHandle]

Also, and low priority one this, if there was a way to block out the DX5 option in games that rely on the DX9 interface, that would be great. A couple of times team members have been getting broken versions of the game and it has turned out their settings have somehow ended up on DX5. No biggie for now but for release it could cause a lot of problems.

I just started out with AGS plugin-development (and I'm not writing a .NET but a "normal" one), but can you not use GetGraphicsDriverID ( ) and then compare the returned string (pointer to const chars), strcmp ( ) it and then - if the user is running the DirectDraw 5 driver - abort using AbortGame ( ) and tell the user to use the D9D one instead?

EDIT: Oh, and there's a thread already... It's HERE... :p

[lemmy101]

Nice catch thanks I'll add that! though being able to disable DX5 option totally would be the better option I guess this makes it even lower priority

[Pumaman]

A few times I've buggered up the game slightly as I've now become reliant on the source control feature,  but the acsprset.spr file and alike aren't handled under source control so if I try and save after adding sprites, at best the changes don't happen and I have views pointing at invalid sprite numbers. If when I edited the sprite folders in any way it requested I checked out the relevant files that would be fab.

The problem is that the acsprset.spr file is large, and can easily be over 100 MB in bigger games. Most source control systems have trouble with files that big, and could become extremely slow.

However, I guess I could add an option to add the sprite file to source control and then you could use it if you wanted to.

Is there any way to know which sprite is used or not?
If it's possible it could be a nice feature for size/optimization 

You can use the "Show Usage" option on the sprite for a start -- but it's not really possible for AGS to check all your scripts and work out whether the sprite might be used in them or not, so it's impossilbe to verify this for certain.

though being able to disable DX5 option totally would be the better option I guess this makes it even lower priority

I take your point -- but there are easy workarounds like coding the plugin as suggested by dkh, or even just putting a line in your game_start to check System.HardwareAcceleration.

[lemmy101]

That's cool, thanks CJ!

[skuttleman]

I gotta say, really high on my wish list is the ability to change custom property values during runtime.

Or, if that's too hard/not happening any time soon, maybe we could get something along the lines of a built-in String property on everything (like character[].flag, object[].flag, etc.) that we could use for whatever.

I would fall in love with that feature.

EDIT: Second highest on my list would be to have a dialog.GetOptionText function.

[Dualnames]

Well actually what i wanted in my wishlist is already there. So thanks CJ.

[Joseph DiPerla]

Just moving my suggestion from my old list... Also SSH is running a voting poll for most wanted features. Should all check out his blog site...

Anyway, not sure if these are  3.0.2 or 3.0.3 or a 3.1 suggestions, but I would love to see this happen: From Rulaman:
- multiple speech.vox (or music.vox)
i.e. speech.en, speech.de, speech.es (or german.spf english.spf, ...)

- sprite-en.pack ( contains some sprites, shown in-game that was translated )
i.e. in-game a sign shows "Le Bakery" and in the translated version "Bäckerei" [graphical translation]

My suggestions: 1024x768x32 resolution. - Not having to resize images and keeping it at this resolution would make it a crisp looking background. Its easier for me to make a background in a 3d editor (That I made myself) and save it in that resolution.

And the next and last for now:
Regarding dialogues, can there be an option when you add a dialog option that says "show on all dialogs"?  In other words, we have a "say" option and a "show" option in the editor. But this option would allow that line to be displayed on all dialogs at the bottom. Is that possible?

Another script function I was hoping to get... Actually a few... Are:

AddDialog(DialogName)
AddDialogOption(DialogNameToAddTo, Dialog String, ScriptToRun)
And is there a way to check what the current dialog option is?

These are some crucial items for this particular project I am working on. And it SEEMS (But I know its not as easy as it sounds) that this is not too difficult to add, I hope. The first option is really for convenience, but this can be done, with a lot of coding by just using the script functions I Requested. But at least it would be possible, unless this is possible already.

[Shane 'ProgZmax' Stevens]

I'd rather see the way dialogs work be overhauled than to keep adding functions to the existing system.  Being able to command dialogs from a regular scripting interface that allows you to make function calls and modify data without hopping to another script would be far more powerful and useful!

[naltimari]

The problem is that the acsprset.spr file is large, and can easily be over 100 MB in bigger games. Most source control systems have trouble with files that big, and could become extremely slow.

acsprset.set being this big black monolith not only complicates versioning, but it somewhat undermines team work, beacuse it prevents two guys from working on different parts of the game at the same time.

Since it's a binary file, changes can't be easily 'merged'. Well, some can, but some can not. OTOH, Game.agf, being a text file, can be automatically merged, or manually, since it's human-readable, so we can always copy&paste on it. But acsprset.spr is binary, so we can not do this.

I would dare to say that the real solution to this would be to stop depending on acsprset.spr altogether, and start building the sprite index based on the filesystem. After all, the sprite files themselves could be added to version control.

I know there would be many consequences to the engine/editor, but that would be the right way to go. Maybe there is a 'in-between' solution, making acsprset.spr just a 'pointer' to files on the filesystem...   

[SSH]

I'd like to be able to export CHA files easily from my walkcycle generator. I can see two ways of doing this:

1. A Character.Export(String filename) function
2. AGS editor can import some kind of new CHA-like format that is easy to generate by concatenating some dumped BMP files or something

[Vince Twelve]

I'm still jonesin' for a sound and music overhaul.

-At least two music channels.
-Playing music or sound returns the channel the sound is being played on.
-Ability to change the volume of each channel individually from 0 (silent! which we can't currently do with music!) to whatever the max volume is (100 or 255).
-Ability to get the volume and current music/sound number playing on each channel.
-Ability to get the current millisecond of the track playing on each channel and the remaining number of milliseconds, if possible.
-Ability to start playing a track at a certain millisecond without a loud hiccup (if possible)

Aside from the track volume, the volume modifiers need to be fixed.
-Room sound/music volume (from 0 to 100).  This plays all channels at x percent of the channel volume.  So a room volume of 0 would make all channels silent, and a room volume of 100 would play them all normally.  Only affects channel volume when player is in this room.  (it could go over 100 too, i suppose)
-Global sound/music volume (from 0 to 100).  Same as room volume, but for the whole game.  This would likely only be set by a slider in the game's options, for example.

[GarageGothic]

I second Vince's suggestions. The volume functionality is confusing and definitely needs an overhaul, and I'm glad that someone else also saw the use of millisecond (and remaing) timings of other sounds than music.

With the risk of sounding obsessive, I'd also like to restate my wishes for widescreen support and a DynamicSprite.CreateFromDrawingSurface(DrawingSurface*, int x, int y, int width, int height) function. The latter may seem like a minor issue to most users, but it's very important to me so that I can convert my RawDraw scripts to DrawingSurface routines.

As for the widescreen support, the sooner this issue is cleared up, the better. Currently I'm holding back on importing more art until I know if I should continue developing in 640x480 or need to switch to 640x400 if I want my game to look nice on widescreen laptops.

[Pumaman]

I gotta say, really high on my wish list is the ability to change custom property values during runtime.

This has been asked for in the past, but I've steered away from it because saving the state of all the custom properties could bloat the save game sizes. But I'll take another look at it.

Or, if that's too hard/not happening any time soon, maybe we could get something along the lines of a built-in String property on everything (like character[].flag, object[].flag, etc.) that we could use for whatever.

Well, you could use extender functions to add your own character[].GetFlag/SetFlag methods, so I'm not sure how necessary this is?

- sprite-en.pack ( contains some sprites, shown in-game that was translated )
i.e. in-game a sign shows "Le Bakery" and in the translated version "Bäckerei"

I'd rather see the way dialogs work be overhauled than to keep adding functions to the existing system.

I'm still jonesin' for a sound and music overhaul.

As for the widescreen support, the sooner this issue is cleared up, the better. Currently I'm holding back on importing more art until I know if I should continue developing in 640x480 or need to switch to 640x400 if I want my game to look nice on widescreen laptops.

I agree with the need for all these things, but obviously they are all fairly major changes and realistically there won't be time to do all of them over the next year or so. So I guess the question is, which of these things are relatively easy to work around, and which really needs to be implemented into AGS?

Also, 3.0.2 is going to be a minor release so please don't expect any major overhauls like these to be in it.

acsprset.set being this big black monolith not only complicates versioning, but it somewhat undermines team work, beacuse it prevents two guys from working on different parts of the game at the same time.

I'm starting to agree. Potentially the acsprset file could be the "compiled" result which is generated by the editor by merging together the various image files when you compile the game. The problem with that though is that it could really slow the compilation down if it was having to reconstruct the file all the time.
So I do see your point, but I haven't thought of a better alternative yet. Perhaps simply adding the right-click "update this sprite" option to re-import it from its source image would be a reasonable workaround.

I'd like to be able to export CHA files easily from my walkcycle generator. I can see two ways of doing this:

1. A Character.Export(String filename) function
2. AGS editor can import some kind of new CHA-like format that is easy to generate by concatenating some dumped BMP files or something

Well, I don't want to bloat the engine with code to export CHA files, since this is quite a specialized request. Perhaps the best option here would be for the walkcycle generator to dump some set of BMP files (or whatever) and then have an editor plugin that could import them and make a character.

[SSH]

Would an option to have everything in native co-ordinates (i.e. a 640x400 coordinate system rather than 320x200 when you use 640x400 mode) be a major or a minor thing?

Surely all you need to do is take out a few "x/=2; y/=2;" statements

And yes, my request is a bit specialised. You never get if you don't ask, though...

[naltimari]

I'm starting to agree [...] The problem with that though is that it could really slow the compilation down if it was having to reconstruct the file all the time.

A solution would be to cache the acsprset file, and recompile it only if one of the sprite files is modified (or 'full build' option is chosen). This is done with .h headers in C/C++ compilers (and the feature is known as 'pre-compiled headers')

Perhaps simply adding the right-click "update this sprite" option to re-import it from its source image would be a reasonable workaround.

That would be very nice to have, but as long the above one is implemented, this one is unnecessary.

This feature would be very useful because sometimes we are still adjusting a walkcycle, or animation, or whatever, and to see any modifications we have to erase the view, then erase the sprites, then import them all over again, assign srites to the view, etc etc.

The two things are important, in my point of view. The second one is a 'time-saver', but it does not change the fact that two people can't work at the same time on the same game. The first one solves this problem, and also the nuisance in modifying walkcycles, animations, etc.

[Pumaman]

Would an option to have everything in native co-ordinates (i.e. a 640x400 coordinate system rather than 320x200 when you use 640x400 mode) be a major or a minor thing?

Well, I was kinda including that under "overhaul of the resolution system" along with the widescreen stuff, but I didn't really make that clear.

Surely all you need to do is take out a few "x/=2; y/=2;" statements

Haha, indeed. This is a change that I'm really not looking forward to, because getting it all working properly and being backwards compatible at the same time is not going to be a fun mission...

A solution would be to cache the acsprset file, and recompile it only if one of the sprite files is modified (or 'full build' option is chosen). This is done with .h headers in C/C++ compilers (and the feature is known as 'pre-compiled headers')

Yeah, there are various possible solutions -- in fact the editor already caches the acsprset.spr file and only updates it if you change a sprite -- but the proposed change here would probably be quite a bit of work for a relatively small reward (improved source control/teamwork compatibility). Therefore it's not something I'll be looking at as a priority.

This feature would be very useful because sometimes we are still adjusting a walkcycle, or animation, or whatever, and to see any modifications we have to erase the view, then erase the sprites, then import them all over again, assign srites to the view, etc etc.

Well, you don't necessarily have to do all that. In most cases you should just be able to import over the existing sprite, and thus all the views will still be intact.

[naltimari]

This feature would be very useful because sometimes we are still adjusting a walkcycle, or animation, or whatever, and to see any modifications we have to erase the view, then erase the sprites, then import them all over again, assign srites to the view, etc etc.

Well, you don't necessarily have to do all that. In most cases you should just be able to import over the existing sprite, and thus all the views will still be intact.

Walking cycles use many sprites, about 10 or sometimes more, and 'Import over the existing sprite' only works one sprite at a time, so, either we select one by one, or do the delete view/delete sprites/import sprites/assign to view routine again.

Neither does it work on 'tiled sprites', because AGS does not remember the coordinates it used to cut sprites from (maybe game.agf can store this information?). When I started coding my game, I was using 'tiled sprites', but I dropped them as soon as I realized that 're-imports' would be very difficult and error-prone.

[Recluse]

Just reiterating my request in another post to increase the amount of background frames allowed per room on a per-game basis. Ex: Some games could use 2 backgrounds per room, others 8... etc.