All in all, I believe we just need a good plan, a goal, in regards to AGS' scaling and display behavior that we can all agree on. This has been discussed a lot previously but I'm unsure as to what has come out of that.
Here's my opinion on the matter, in case another discussion about this breaks out:
1.) We drop winsetup.exe completely.
2.) We expose functionality to AGS Script that allows game authors to change the display mode (windowed/fullscreen) during game run-time (OOP example: 'GameSettings.SetDisplayMode(eDisplayModeFullscreen); GameSettings.SetWindowScale(1.5); GameSettings.Save(); GameSettings.Load();'). Note that loading and saving the settings would write it to acsetup.cfg).
3.) In the General Settings pane inside the AGS editor, you could now only select a game resolution (technically unlimited, so this could be 16x16 or 321x59 or 1920x1080 etc.) and if your game should start in windowed or fullscreen mode.
4.) We add a GUI to the default template that takes over the functionality of the old winsetup.exe - this would allow newbies not to have to worry about creating a custom options menu in the beginning, just like we do with the saving, loading and quit game interfaces currently.
5.) Windowed mode is easy as windows can have any size all the time. The window is as big as the game resolution by default but there is a window scaling factor (see the function examples above) which can be used to make it larger.
6.) Fullscreen mode is implemented in the modern borderless fashion. It looks and feels just like proper fullscreen but allows for very quick alt-tabbing and overlaying chat windows and such on top of the game at the cost of a very small performance decrease on some systems.
7.) Internally, this system relies on creating a D3D9 render target texture that is as large as the game resolution chosen. Then everything gets rendered to that texture instead of the screen. In window mode, the AGS engine would then, after rendering, have to take that render target (I would call it a render buffer) and scale it according to the window scale factor. In fullscreen mode, the engine would instead detect the aspect ratio of the render buffer, calculate if it equals the aspect ratio of the player screen, if not, it would add black bars left/right or top/bottom, wherever necessary, and then draw the render buffer to the screen at the maximum size. The render buffer scaling is done without filtering, ie. Nearest Neighbor of course (theoretically Bilinear filtering could be selected from the General Settings pane for scaling high res games!)
I have done this exact thing (step 7) before on fresh projects and have code available if that's the problem. I don't know how much work it would be, however, to do everything else with the AGS engine. Also, it would be tricky to use this system and, at the same time, still support Direct Draw 5. Any thoughts/comments?
Here's my opinion on the matter, in case another discussion about this breaks out:
1.) We drop winsetup.exe completely.
2.) We expose functionality to AGS Script that allows game authors to change the display mode (windowed/fullscreen) during game run-time (OOP example: 'GameSettings.SetDisplayMode(eDisplayModeFullscreen); GameSettings.SetWindowScale(1.5); GameSettings.Save(); GameSettings.Load();'). Note that loading and saving the settings would write it to acsetup.cfg).
3.) In the General Settings pane inside the AGS editor, you could now only select a game resolution (technically unlimited, so this could be 16x16 or 321x59 or 1920x1080 etc.) and if your game should start in windowed or fullscreen mode.
4.) We add a GUI to the default template that takes over the functionality of the old winsetup.exe - this would allow newbies not to have to worry about creating a custom options menu in the beginning, just like we do with the saving, loading and quit game interfaces currently.
5.) Windowed mode is easy as windows can have any size all the time. The window is as big as the game resolution by default but there is a window scaling factor (see the function examples above) which can be used to make it larger.
6.) Fullscreen mode is implemented in the modern borderless fashion. It looks and feels just like proper fullscreen but allows for very quick alt-tabbing and overlaying chat windows and such on top of the game at the cost of a very small performance decrease on some systems.
7.) Internally, this system relies on creating a D3D9 render target texture that is as large as the game resolution chosen. Then everything gets rendered to that texture instead of the screen. In window mode, the AGS engine would then, after rendering, have to take that render target (I would call it a render buffer) and scale it according to the window scale factor. In fullscreen mode, the engine would instead detect the aspect ratio of the render buffer, calculate if it equals the aspect ratio of the player screen, if not, it would add black bars left/right or top/bottom, wherever necessary, and then draw the render buffer to the screen at the maximum size. The render buffer scaling is done without filtering, ie. Nearest Neighbor of course (theoretically Bilinear filtering could be selected from the General Settings pane for scaling high res games!)
I have done this exact thing (step 7) before on fresh projects and have code available if that's the problem. I don't know how much work it would be, however, to do everything else with the AGS engine. Also, it would be tricky to use this system and, at the same time, still support Direct Draw 5. Any thoughts/comments?
