Suggestions for the next version of AGS

Started by Pumaman, Sun 27/01/2008 00:59:41

Previous topic - Next topic

Shane 'ProgZmax' Stevens

#140
A circle tool for rooms that tracks the mouse for both x and y diameter (so you can make ellipses) would be awesome.  Also, if the freehand/line tool would start drawing WHEN you pressed the button instead of after you started moving that would be more in-line with how conventional art programs work.  As it is, if you want to place a single pixel you have to click-and-drag to get it, which is difficult.

SSH

The compiler should barf if someone declares a variable or function in a script header as this is almost never what someone actually wants. It could also point them to the manual section on how to do it right, although this currently only refers to functions and not variables.
12

lemmy101

Quote from: ProgZmax on Wed 19/03/2008 15:05:14
A circle tool for rooms that tracks the mouse for both x and y diameter (so you can make ellipses) would be awesome.  Also, if the freehand/line tool would start drawing WHEN you pressed the button instead of after you started moving that would be more in-line with how conventional art programs work.  As it is, if you want to place a single pixel you have to click-and-drag to get it, which is difficult.

Also a zoom for the mask editing on the room editor would be fantoostic!

cheers,

lemmy

subspark

#143
Quote from: Lt. Smash on Tue 18/03/2008 11:55:33
suggestion:
A nice feature would be to change the game language in-game. Maybe Game.Translation=String TranslationName;.
We would not need to use to the WinSetup.exe and it would look more professional to change the language from english to spain in the options menu of a game.

In the editor: Right click on a translation: Edit in default text editor. Or possibility to edit it in the editor itself.

What would also be nice: Game.Windowed=true/false; Game.GraphicsFilter=2xNN,3xNN,Hq2x,Hq3x; Game.ForceLetterboxRes=true/false;
These are things that are implemented in ScummVM and would be nice to have in AGS.

This is basically a small part of what I have already sugested, Smash. It has already been suggested by me that the options winsetup offers also be controlled via a scriptable GUI so that they can be changed in-game.

Edit:
QuoteThe compiler should barf if someone declares a variable or function in a script header as this is almost never what someone actually wants.
'Almost' isn't a very reliable statistic if functionality of the compiler is to be altered now is it.  ;)

Cheers,
Paul.

naltimari

Quote from: Le Woltaire on Sun 16/03/2008 22:53:39
- Is it possible to add optional walk to points for objects? It has already been asked. But I ask again.

Well, you can certainly do it via Custom Properties. Just define two variables, 'WalkToX' and 'WalkToY', both with a default value of -1, and put the following on your GlobalScript.asc (or on a separate module):

Code: ags

function on_mouse_click(MouseButton button)
{
  Object* obj = Object.GetAtScreenXY(mouse.x, mouse.y);
  if (obj != null && obj.GetProperty("WalkToX") >= 0 && obj.GetProperty("WalkToY") >= 0)
    player.Walk(obj.GetProperty("WalkToX"), obj.GetProperty("WalkToY"));
}


Quote from: Le Woltaire on Sun 16/03/2008 22:53:39
Could there be an additional character.asc and inventory.asc script, so that the GlobalScript.asc doesn't get messed up with all kind of character and inventory functions anymore and becomes more economic.

I support that. It's a good idea.

As if all those previous suggestions weren't enough, I have another one... ;) I think it would be very useful to draw directly on a sprite's alpha channel. If we could do it by 'fetching' a DrawingSurface out of a sprite's alpha channel, we could draw on it just like another surface. It would certainly be useful in situations where you must draw anti-aliased text.

My idea:

Code: ags

DynamicSprite* asprite = DynamicSprite.Create(320, 240, true);
DrawingSurface* alpha = aSprite.GetDrawingSurfaceForAlphaChannel();
alpha.DrawString(0,0,"Blablabla");
...


Another approach would be to copy a greyscale sprite directly onto another sprite's alpha channel, much like CopyTransparencyMask(), but instead of using the alpha channel of the source, it would use the rgb channels as alpha values on the destination. This way we could achieve the same effect, only requiring a temporary sprite.

Idea:

Code: ags

DynamicSprite* alpha_temp = DynamicSprite.Create(320, 240, false);
DrawingSurface* alpha_surf = alpha_temp.GetDrawingSurface();
alpha_surf.DrawString(10,10,"The quick brown fox jumped over the lazy dog");
alpha_surf.Release();

DynamicSprite* texture = DynamicSprite.CreateFromScreenshot();
texture.CopySpriteAsTransparencyMask(alpha_temp);


The above code takes a screenshot of the screen and applies a 'mask' to it, formed by the string 'The quick brown fox...'. The source and destination should be the same size, I guess.

GarageGothic

#145
I've started converting my RawDraw routines to DrawingSurface functions, and I find myself missing a DynamicSprite.CreateFromDrawingSurface(DrawingSurface*, int x, int y, int width, int height) function similar to DynamicSprite.CreateFromBackground.

Most of my distortion effects work by retrieving part of an image, distorting it and drawing it to either the original surface or a new one. Previously, I used the background as a buffer (which is no longer feasible due to slowdowns in Direct3D mode), and found DynamicSprite.CreateFromBackground very handy. But now my workflow looks like this:

1) Draw surface to a temporary DynamicSprite (sprite A)
2) Create an even more temporary copy of sprite A (sprite B)
3) Crop sprite B down to the actual area to deform (often a single row of pixels)
4) Deform cropped sprite B and draw it back to DrawingSurface
5) Repeat steps 2 through 4 until the whole sprite has been deformed

Without knowing exactly how AGS handles copies of sprites internally, I would guess that the repeated copying and cropping of the full sprite must be quite a bit slower than creating a new sprite consisting only of the needed area.

Recluse

Did the Show and Say for the dialog script get moved somewhere wierd in 3.0? Because I can't see them...

If they did... could we have them back... I've got instances where I'm going to need to keep the player from seeing exactly what they're going to say...
All your verbcoin are belong to us.

GarageGothic

Quote from: Recluse on Wed 19/03/2008 20:40:41Did the Show and Say for the dialog script get moved somewhere wierd in 3.0? Because I can't see them...

I don't know for sure about the stable 3.0 release, but at least the latest beta version has them right next to the dialog options as it used to be. Have you possibly moved the divider between the dialog options and the dialog script too far to the left so that they are hidden?

Recluse

Why yes, that's exactly what happened  ::)

Thanks. *goes off into a corner and feels sheepish for a while*

EDIT: Oh, by the way. Is that divider movable for you? Because it's static over here... I can provide screens.
All your verbcoin are belong to us.

GarageGothic

#149
Quote from: Recluse on Wed 19/03/2008 20:47:02EDIT: Oh, by the way. Is that divider movable for you? Because it's static over here... I can provide screens.

It's definitely movable. You just have to find the right pixel since it's not marked (the divider isn't the same as the edge of the white script window). Try just left of the arrow at the bottom, where the slider to scroll the dialog script horizontally is located.

Vince Twelve

CJ, your post in SSH's blog thread prompted me to write this, hope it's helpful!

The Assign To View feature, while completely useful, may be overlooked because it violates some usability rules about context.  It's hidden at the bottom of a right-click menu containing a number of features used to bring in new sprites, in a section unrelated to views.  The view section has all the other functionality regarding setting up views, and is where I was always looking for such a feature (which I thought was sorely missing because it wasn't there until someone finally mentioned the Assign To View to me :P).

I think that a more intuitive way to implement this would be to add another button next to the "Create new frame" button that automatically creates a new frame and sets it to the frame numerically after the previous frame.  That way, for 80% of the animations in my game which are imported sequentially into the editor, I could just set the first frame and press "Add next frame" several times, which would be almost as fast as Assign To View if not faster.

Additionally or alternatively, a way to select multiple sprites in one trip to the sprite window rather than one at a time (a process that is much slower in 3.0 than it was in 2.7) and having them be added to the loop in the order that you clicked on them would be extremely intuitive and fast.

From a usability standpoint, the Assign to View seems to me to be working backwards.  I wouldn't eliminate it, but adding some alternatives is always nice!

Also, while I'm posting, I'd really like a full makeover for the sound and music system that:
-Has more than one channel for music to allow manual crossfading effects (I usually import my music as sound due to this)
-Doesn't make music skip or stutter when changing rooms or loading large animations/sprites
-Allows full control over music and sound channel volumes
-Has functions that return the volume of each channel
-Has functions that return the music or sound number currently playing in each channel
-Allows you to toggle looping for each individual channel (including sound channels)

Shane 'ProgZmax' Stevens

QuoteI could just set the first frame and press "Add next frame" several times, which would be almost as fast as Assign To View if not faster.

This coupled with the ability to select a range of frames and re-import a gif over them (provided it has the same frame count) would greatly streamline the sprite importing/adding process!  I'd prefer a keyboard shortcut to a button that constantly moves, though.  That way I could just tap the '+' key 5 times and 5 frames would show up :D.

cat

Another suggestion (see also http://www.adventuregamestudio.co.uk/yabb/index.php?topic=19062.0).
I use custom shaped buttons, but when the gui is disabled, they have an ugly grey square.

So I would either suggest to allow a DisabledGraphic for buttons or do not grey out transparent areas.

Shane 'ProgZmax' Stevens

cat, does that still happen when you do this?


Vince Twelve

Quote from: ProgZmax on Fri 21/03/2008 13:23:34
This coupled with the ability to select a range of frames and re-import a gif over them (provided it has the same frame count) would greatly streamline the sprite importing/adding process!  I'd prefer a keyboard shortcut to a button that constantly moves, though.  That way I could just tap the '+' key 5 times and 5 frames would show up :D.

Agreed and agreed!

cat

@ProgZmax:

Thank you, you are right, it does not happen. I can do it this way. However, it would still be nice to show the gui disabled when the user cannot use it. (ok, there is still the wait cursor, so probably this feature is not really necessary)

subspark

Quote from: cat on Fri 21/03/2008 20:26:11
Another suggestion (see also http://www.adventuregamestudio.co.uk/yabb/index.php?topic=19062.0).
I use custom shaped buttons, but when the gui is disabled, they have an ugly grey square.

So I would either suggest to allow a DisabledGraphic for buttons or do not grey out transparent areas.

I actually asked this before. Back in 2.8 I believe. It's one thing to hide the controls on a gui (including inventory) but its another thing to turn the gui completely off!
Paul.

lemmy101

#157
One thing I've noticed is that when a 320 x 200/240 game is upscaled to 640 x 400/480 in DX 9 mode, the character scaling is done on the 640 x 400 screen, so you end up with characters that are higher resolution than the backgrounds which can look a bit odd. Is there (or would it be possible to have a way) to force characters to be drawn at the unscaled resolution as 320 x 200/240 is quickly becoming an unsupported screen resolution, but is needed for the retro look a lot of AGS games go for.

Thanks!

lemmy

subspark

Quote320 x 200/240 is quickly becoming an unsupported screen resolution
I doubt whether support for 320x200/240 will discontinue but I do believe that your issue with the mixed resolutions is a common one.

I noticed such an issue with The Infinity String actually. Notice the helicopter scene is in true 640x480 but the rest of the game is 320x240 scaled up. The characters, like you noted, were also displaying the same resolution mismatch symptoms.

Would it be time to overhaul the resolution system at this stage of AGS development yet, CJ?

Regards,
Paul.

rbaleksandar

#159
Quote from: Pumaman on Sun 27/01/2008 00:59:41

These are some that have already been suggested and that I'd like to do:
* Bring back drag & dropping sprites around in the sprite manager
* Drag & drop views into different view folders
* Ability to delete views
...

I know that I am new here :) and that I am not a veteran like the most of you, but I have a suggestion too, which is minor and I think - useful. Can you add in your next version the ability to copy loops and insert them directly into the same or another view. This is mostly useful if you make a mistake for example and put the wrong loop in the wrong view. If you do that, you have to delete the loop and create a new one (exactly the same) but in a new view. That is a lot of clicking... :) Also very useful is to add an invert function for the loops.
For example we have a loop that shows our hero walking on the right. Then we use "Copy loop", we insert it as another one in the same view and with the same frames. We have now to "go-to-the-right"-views. But we want a "go-to-the-left"-view too. So we invert the new one and there we have now 2 opposite views.
I am a mighty pirate. Arrrrgh!

SMF spam blocked by CleanTalk