Suggestions for the next version of AGS

[magintz]

An option to select recently edited games from within the editor. Such as "File->Open Recent Games->Game 1, Game 2, Game 3" etc... I don't know if anyone else would find this useful, but I know I would.

[lemmy101]

Hi CJ! What would be incredibly handy for us would be an option in the editor to stop the generated .exe having exception handling around the plugin calls, as at the moment if there is a crash inside our AGX plugin the callstack is kicked out back into AGS (I assume into a catch that handles the error dialog) and this can add hours to debugging the plug-in as I need to step through the entire game hoping to find the line it crashed onin stead of it throwing an unhandled exception on the offending line.

Thanks!

lemmy

[Shane 'ProgZmax' Stevens]

For managing views it would be nice for the scrollwheel to work without having to click on a frame first (for it to work when you open the tab).  Likewise, it would be useful if the scrollwheel worked when dragging folders or views from the property list.

[Lt. Smash]

hmm what about implementing a Frame Editor?

I could imagine that it would be useful.

[GarageGothic]

May I suggest a DrawingSurface.DrawStringWrapped function? Seeing as global and room messages are slipping out of use, DrawMessageWrapped seems a bit limiting (especially as Room.Messages is read-only, so there's no easy workaround). I tend to write my own linebreaking code for most RawDrawing of text, but for some purposes it would be quite helpful.

[monkey0506]

May I suggest a DrawingSurface.DrawStringWrapped function?

I've actually suggested this before...or something like it that resolved to the same suggestion. Still, it is something I would like to see.

[naltimari]

May I suggest a DrawingSurface.DrawStringWrapped function?

I would find it very useful too.

[naltimari]

I have a suggestion for on_event(). When event == eEventLeaveRoom, data carries the room number the player is leaving. Well, this is kind of pointless to me, because we already know this information, it's player.Room!

IMO, data would be more useful if it carried the room number the player is moving to.

I know it's not good to alter this behaviour, because it has a potential to break existing code, especially considering that many modules use this function. So, I suggest creating an #ifdef for testing at compile time, like this:

Code: ags

function on_event(EventType event, int data)
{
  if (event == eEventLeaveRoom) {
    #ifdef AGS_VERSION_301_beta3
    int room_number_the_player_is_going_to = data;
    #endif
    ...
  }
}

Well, maybe there is a better way to implement it, this is just an idea.

EDIT: On a second thought, one could watch eEventEnterRoomBeforeFadein, and fetch player.PreviousRoom and player.Room... this way he would get both room numbers, where the player WAS and where the player IS... Nevermind.

[monkey0506]

On that note however naltimari, it would be useful if we had an eEventEnterRoomAfterFadein event...we can do this for individual rooms via their respective event handlers, but we don't have a way of doing this in a generic sort of way like we can with BeforeFadein.

[Rui 'Trovatore' Pires]

But DOES player.room say the room the player is going to? At that point, HAS the player actually switched rooms? Maybe it hasn't, we need to take these things into consideration. eEventLeaveRoom is one of those actions that take place in that sort of limbo, isn't it?

IMO, your suggestion can be so specific that a simple variable, to be set at the leaving room and read back by the function, could work perfectly, and changing the current behaviour would bring few, if any, advantages.

[SSH]

On that note however naltimari, it would be useful if we had an eEventEnterRoomAfterFadein event...we can do this for individual rooms via their respective event handlers, but we don't have a way of doing this in a generic sort of way like we can with BeforeFadein.

in: on_event

if (before_fadein) { some_global=1; }

in: rep_ex

if (some_global) {some_global=0;
//after fadein stuff
}

[naltimari]

On that note however naltimari, it would be useful if we had an eEventEnterRoomAfterFadein event

Totally agree.

But DOES player.room say the room the player is going to? At that point, HAS the player actually switched rooms? Maybe it hasn't, we need to take these things into consideration. eEventLeaveRoom is one of those actions that take place in that sort of limbo, isn't it?

I thought about that. I think it is being called from the leaving room, but I cant say for sure, since I didnt perform many tests. I will do it, then I'll report here.

IMO, your suggestion can be so specific that a simple variable, to be set at the leaving room and read back by the function...

Well, you're right, this could be done, but this is sort of a hack to me, and I try to avoid using globals whenever I can. To me, globals are only justifiable if they are used in many places. In this case, I think it's not justifiable, especially when there's an event where we could hook our code onto.

[Layabout]

It would be really nice to have the option to have a 'sidebar' mode, like the letterbox mode, since I have a 16:10 screen (and i'm sure many others do), it is really ugly to have the pixels stretched horizontally when playing a game if you know what I mean.

What I would prefer is to have black bars down the sides of my screen as opposed to having the pixels stretched horizontally.

And there is that other thing... but you know, that can wait till 3.1... The thing that wintermute has that ags doesn't... (subtle hint)...

Great work, love your stuff...

[Snarky]

Isn't that something you can set on your monitor/graphics card? How it deals with aspect ratios that don't match the native resolution? Usually you can at least choose between stretch-to-fit and center. You might have to run the 3x filter if you want a 320x200 game to be larger than a postage stamp, though.

[GarageGothic]

The aspect ratio problem is something I've been considering a lot lately. I wanted to create a new thread about it, because I do think it's a big deal, but since it's already being discussed here, I might as well throw in my two cents.

After my beloved laptop with its nice 4:3 screen died miserably, I borrowed a 16:10 laptop and was instantly confronted with the horrors of the new format. Seeing as an increasing amount of users are replacing their desktop machines with llaptops and it's almost impossible to find a 4:3 laptop these days, this IS an issue that AGS must deal with eventually. It may be that some laptops support 'sidebars', but the one I had (a HP notebook with an onboard Intel video chipset) didn't allow any such choice.

In fact, AGS already DOES support resolutions with the 16:10 aspect ratio: 320x200 and 640x400. And it's perfectly possible to create a game that supported both 4:3 and 16:10 screens by creating your game in 320x200 or 640x400 and requiring 4:3 users to check the "Force alternate letterbox resolution" box in winsetup.exe. This would give nice, non-stretched images in either aspect ratio.
HOWEVER, as someone developing a game in 640x480 (albeit with black letterbox borders used for interface and text display) and loathing wasted screen space, I'd like to propose a new feature which at least I would love to use in my game: Optional cropping of a 640x480 viewport to 640x400.
By checking System.ScreenHeight in game_start, the game developer could then reposition GUIs, text displays and similar to custimize the game for the specific resolution. Of course this would require a bit of planning and extra implementation on the part of the developer, but I think it's worth it. Many games using the LucasArts interface could easily have an alternate GUI for 16:10 users, taking up less vertical space and still displaying the backgrounds without any cropping.

What I'm asking from CJ is this:

1) An offset value (Game.ScreenOffset or similar) ranging from 0-40 (in the engine's 320x200 grid), which would position the 240/480 pixels high image within the 200/400 pixel tall viewport of the screen. A 640x480 image with an offset of 15 would thus have 30 pixels cropped from the top of the screen and 50 from the bottom.

2) Winsetup support for the feature (possibly just having the "Force alternate letterbox" checkbox work in reverse if a game is 320x240 rather than 320x200).

The only possible problem I see is that a new resolution (800x500) would have to be implemented for the feature to fully support all existing resolutions. Thanks for reading my lengthy suggestion.

Edit: I actually discussed this issue two years ago, but nobody seemed to really get the point back then. I hope that the almost ubiquitousness of 16:10 laptops (and growing number of widescreen desktop displays) makes it a bit more relevant now.

[Pumaman]

Hmm, perhaps we need an opposite letterbox mode, whereby if the game is 320x200/640x400 it will run full screen, but if it's 320x240/640x480 it will get black borders at the side. The problem with this approach is that AGS would have to initialize a graphics mode like 384x240 and then paint black bars down the side, and I imagine that the graphics cards don't support any such resolution...

[SSH]

Is it possible to query which formats the graphics card support, choose the closest one to the game resolution and then use it with black bars as necessary and if it is possible to apply the 2x or 3x filter within the allowed resolutions, do so?

[Layabout]

Actually, I did figure out that my video card does support such a feature, (intel intergrated graphics) but i don't think many of the less advanced users would figure it out. There is a little dropdown box that has full screen as default and fixed aspect ratio, which sorted out my problems.

It's just less advanced users wouldnt be able to play games in the intended graphical way.

[Shane 'ProgZmax' Stevens]

Any chance of getting character avatars able to be placed in room edit for the next beta, CJ?  That would be a very useful little update indeed!

[GarageGothic]

Hmm, perhaps we need an opposite letterbox mode, whereby if the game is 320x200/640x400 it will run full screen, but if it's 320x240/640x480 it will get black borders at the side. The problem with this approach is that AGS would have to initialize a graphics mode like 384x240 and then paint black bars down the side, and I imagine that the graphics cards don't support any such resolution...

But please, please, please, for those of us who'd like to make use of the full screen area in either resolution, wouldn't it be possible to force a vertical cropping of a 640x480 screen as I suggested above? The engine does seem to support this kind of thing already (though currently it's an error rather than a feature). This is what I got when running Blackwell Unbound windowed 1280x960 with the 2x filter on a 16:10 laptop:

Normal 4:3 resolution:


Windowed 2x resolution on 16:10 monitor:


As you can see, here the top op the screen has been cropped off by the engine and the GUI has moved down 40 pixels. If we as developers had control of this behaviour we could easily design our games to be compatible with either kind of screen.