AGS 3.3 Wishlist

[subspark]

I wish for the AGS Editor to support designing games and their GUI's for both widescreen 16:10 and standard 4:3 in the same compiled exe. A smart auto-detection feature should decide which aspect ratio to launch our games in.

Cheers,
Sparx.

[Trent R]

So letterboxing or pillarboxing depending on the game's native res? I'm with that.

~Trent

[GarageGothic]

I'm repeating myself, I know - this is probably the fourth time this discussion has been brought up - but I would really prefer a mode where the full screen area could be used in either resolution by cropping the screen area and repositioning the GUIs. With for instance the LucasArts GUI that takes up 1/3 of the screen, there's really no need to add additional non-active bars.

This kind of cropping is already possible by changing the resolution from for example 640*480 to 640*400 before compiling, and manually locking the viewport to wherever you want the y-cropping to start. But first of all this requires two .exe files, one for widescreen and one for 3:4 aspect ratio.  And secondly, the change of resolution makes the GUI coordinates behave inconsistently. It would be awesome if the cropping could be handled by the runtime to avoid these problems.

Oh, and since CJ asked me to repost this in the wishlist thread:

Is there any chance that savegame names could be stored as a String (or even just a 255 char string) rather than the currently very limited number of characters? I like to use it for storing additional information such as time of save, room ID and the current day in the game, which doesn't leave much space for whatever the player types.

[subspark]

I was going for the same thing Garage. Thats what I meant in my first post.

I imagine something like this:


The user makes background art for both modes and the GUI labels, borders and background image can be aligned, scaled and positioned differently and independently of the opposite mode.
I think there should be a background region tool which essentially draws the background room into a region so that it can be repositioned. The region would also have right-hand-side pane values for which image to use for what aspect mode.

Cheers,
Sparx.

PS: I'm sure someone can come up with a better example than my crappy MI1 sample.

[GarageGothic]

I'm not really fond of having separate graphics for the two modes, as it doubles file size (also, cropping the sides as you do is a bit problematic as it's usually there the exits are located). Looking at your example, I was more thinking along the lines of keeping the artwork the same size but redesigning the GUI to take up less vertical space for the widescreen version.

I think you're making things overly complicated, Subspark. There's not really any reason to implement this into the editor. A simple SetViewportCrop int parameter with the pixel offset, and of course the option to select either of the two resolutions through the setup (as you currently only can choose them before compiling) would be enough. As there already exists widescreen resolutions (320x200 and 640x400) which just crops any 4:3 (320x240 or 640x480) background you have imported, the functionality IS in there, we just need to be able to access these settings also after compiling.

[subspark]

I think you're making things overly complicated, Subspark.

Your probably right. The problem is the height of the background graphics. I was going to go your route and suggest designing our background art to be 4:3 in the first place and then dynamically cropping it at 16:10. This seems like the best method and in turn does not approximately double your game's file-size.

Good thinking Garage. I guess wishful thinking and excitement got the better of me. You can call me Sparx btw.

Cheers.

[Mehrdad]

hi
wish:put a key RUN for any room.or put RUN  key for current room.without compiled.

[Gilbert]

One big problem is that when you "run" a specific room there are a lot of uncertainties, like what values the global variables should be, etc. You can, of course, just change the starting room of the player character to test a particular room, currently. I think it may not be possible to test something without compiling though.

[Pumaman]

I wish for AGS Editor 3.1.2 to support designing games and their GUI's for both widescreen 16:10 and standard 4:3 in the same compiled exe. A smart auto-detection feature should decide which aspect ratio to launch our games in.

The problem is with available resolutions. Most modern systems that are likely to have a widescreen monitor also do not support 320x200 or 640x400. That means that AGS ends up having to run at 320x240/640x480 anyway, which negates any potential benefits that this feature would provide.

Is there any chance that savegame names could be stored as a String (or even just a 255 char string) rather than the currently very limited number of characters? I like to use it for storing additional information such as time of save, room ID and the current day in the game, which doesn't leave much space for whatever the player types.

Hmm, I forgot that it did this. I'll look into removing the 50 character truncation.

One big problem is that when you "run" a specific room there are a lot of uncertainties, like what values the global variables should be, etc. You can, of course, just change the starting room of the player character to test a particular room, currently. I think it may not be possible to test something without compiling though.

Hmm yeah, this feature would be possible to add but potentially dangerous. No matter how much documentation was added warning that the game didn't get compiled, people would still "run the room" and post bug reports about how their global script change hadn't been picked up. So it's probably safer not to do this.

The AGS 3 Test Game feature is quite fast compared to compiling the game, so it shouldn't cause too many delays.

[GarageGothic]

The problem is with available resolutions. Most modern systems that are likely to have a widescreen monitor also do not support 320x200 or 640x400. That means that AGS ends up having to run at 320x240/640x480 anyway, which negates any potential benefits that this feature would provide.

I was under the impression that 1280x800 was a pretty common widescreen resolution, but I realize there are many different standards. Shouldn't the Direct3D renderer be able to resize the image to pretty much any viewport size without framerate loss though?

[subspark]

I thought the resolution system was going to undergo an overhaul anyway. Such as drawing the screen to a polygon.

Cheers,
Sparx.

[abstauber]

Another wish:
Making it possible to set custom properties during runtime: like having SetTextProperty.
Then I could get rid of some public structs.

[SSH]

Allow structs within structs, pointers and make functions first-class objects...

oh, and polymorphism

[OneDollar]

Multi-dimensional arrays?

[AsimosVagan]

Allow structs within structs, pointers and make functions first-class objects...

oh, and polymorphism

  My vote goes to SSH for president.

[SSH]

Allow structs within structs, pointers and make functions first-class objects...

oh, and polymorphism

  My vote goes to SSH for president.

Yes, we can!

[Pumaman]

I was under the impression that 1280x800 was a pretty common widescreen resolution, but I realize there are many different standards. Shouldn't the Direct3D renderer be able to resize the image to pretty much any viewport size without framerate loss though?

1280x800 is the lowest common widescreen resolution, yes. But that would mean that if this feature was implemented, people would have to run the game at 1280x800 as a minimum if they had a widescreen monitor. Although D3D does improve the performance of the filtering, there is still a slowdown -- try it out and compare the framerate between running a 320x200 game at 320x200, and running it at 1280x800 using the 4x filter.

Obviously when using DX5 mode, the slowdown is much more pronounced.

I thought the resolution system was going to undergo an overhaul anyway. Such as drawing the screen to a polygon.

I'm not really sure what you mean about the polygon, but yes the resolution system is under consideration for an overhaul -- if we can work out a way of implementing it that makes sense.

Making it possible to set custom properties during runtime: like having SetTextProperty.

This has been requested a few times over the years; the reason it doesn't happen yet is to cut down on the size of the save games. But it probably wouldn't add too much data to persist this.

Allow structs within structs, pointers and make functions first-class objects...

oh, and polymorphism

Yes, well ... pointers to custom structs would be easy to add, except for the fact that the script state has to be saved and loaded in save games, which complicates the matter somewhat. It needs further investigation.

Multi-dimensional arrays?

This is a possibility for a future version, but they have relatively limited use (ie. not that many people need them) which means they're not a priority.

[kaputtnik]

Fine tuning the output of the translation sources. It would be very nice to have one file including character names which is sorted by rooms and GUIs, so there won't be so much confusion anymore when translating.

[RickJ]

Allow structs within structs, pointers and make functions first-class objects...

I wish for a pointer to function data type.  This would be useful in creating custom event handler and other modules where it is useful/necessary to call a function defined in a room or global script from the module.  This would also make it possible to construct a jump table (i.e. index into an array of function pointers to execute the function) which is also useful for custom event handlers.

[abstauber]

Making it possible to set custom properties during runtime: like having SetTextProperty.

This has been requested a few times over the years; the reason it doesn't happen yet is to cut down on the size of the save games. But it probably wouldn't add too much data to persist this.

People create 80 - 200 MB games and complain about save game file sizes?
As long as a save game doesn't grow up to 5 MB each, I wouldn't mind.

Oh and I second an easier translation method