[SOLVED ]I don't understand my room's resolution / Camera / Viewport ?

Started by Monsieur OUXX, Tue 11/05/2021 17:51:37

Previous topic - Next topic

Monsieur OUXX

Version: AGS 3.5.1.5 patched with latest build

Scenario:
- I had a 320x200 game.
- I changed the resolution to 640x400
- AGS asked me : "Do you want to automatically rescale the GUIs?" - I said no.
- I created a new room
- I set a 320x200 background
   So now I have a 640x400 game with a 320x200 background

- I run the game.
Now, this:
I see the 320x200 image fill only the top-left quarter of the screen. Why not, I'm not really shocked here I didn't expect AGS to upscale it for me.

Then I add this :
Code: ags

function room_RepExec()
{
  if (mouse.IsButtonDown(eMouseLeft)) {
    Display(String.Format("%d, %d", mouse.x,  mouse.y));
  }
}

This way every time I click I see the mouse position in room coordinates.

To my great surprise when I click in the bottom right of the screen the coordinates are 320,200.

Can someone explain this contradiction?
- The actual background of this 320x200 room is rendered as a 320x200 image in the top-left quarter of the 640x400 game (in other words: no upscale)
BUT
- the room coordinates are upscaled so that room coordinates (320,200) match screen coordinates (640,400) (in other words: upscaled)


Is that expected behaviour?
 

eri0o

#1
I think you have a 320x200 camera in a 640x400 viewport.

From the manual: The maximum camera size is determined by the dimensions of the room background, so it may not be larger than the room

Crimson Wizard

#2
Quote from: Monsieur OUXX on Tue 11/05/2021 17:51:37
Can someone explain this contradiction?
- The actual background of this 320x200 room is rendered as a 320x200 image in the top-left quarter of the 640x400 game (in other words: no upscale)
BUT
- the room coordinates are upscaled so that room coordinates (320,200) match screen coordinates (640,400) (in other words: upscaled)

No, this is not an expected behavior.
But firstly, you do not display mouse position in room coordinates, you display mouse position in screen coordinates. If your game is 640x400 then screen coordinates should be in 640x400, and mouse.x/y in the bottom-right corner must be 640x400.

I am also not sure why the room viewport is not stretched to the whole screen either, I thought it supposed to. But maybe I forgot how I made it work.
EDIT: Right, so, default behavior is to not scale the room, this is something that you may do for your game by disabling Screen.AutoSizeViewportOnRoomLoad and/or explicitly setting viewport's size on game start or room load event.
Although today I begin to doubt that was a good decision, maybe it should scale to whole screen by default instead.


Quote from: eri0o on Tue 11/05/2021 18:07:47
I think you have a 320x200 camera in a 640x400 viewport.

In that case the room image will be stretched to whole 640x400 screen.


EDIT

When I tested this in AGS 3.5.1, the room background indeed was in the top-left quarter of the screen, but mouse coordinates were not upscaled and shown correctly (from 0,0 to 640x400 in bottom-right).
So the only question is why your coordinate test shows 320x200 in the bottom-right screen corner.

Monsieur OUXX

#3
Yes I have a mixup regarding the mouse coordinates (screen coords instead of room coord).
But so you confirm that the image should have been upscaled.

I'm whipping up a prototype game with buttons to change the viewport and the camera in real time, to see what's up, because its so new to me I'm struggling.
 

Crimson Wizard

#4
Quote from: Monsieur OUXX on Tue 11/05/2021 19:03:23
But so you confirm that the image should have been upscaled.

No, opposite, it should not be upscaled by default.

To keep things clear - it's also not the question of whether image is upscale or not, but a question of how room viewport is set.

But mouse coordinate should be in screen coordinates, from 0,0 to 640,400.

EDIT: The only guess I have is that some backward compatible option is enabled in General Settings and that screws up coordinate system.

Monsieur OUXX

Thanks.

There's definitely a problem though (I think?) :
Code: ags

function room_AfterFadeIn()
{
  Display("Room size: %d, %d", Room.Width,  Room.Height);
}

...Displays "Room size: 160,100".

We agree that the Viewport and the Camera cannot impact on the room's size, correct? The only thing that defines the room size is the size of the background image at the time it was imported?
 

Monsieur OUXX

#6
The test project can be downloaded here.

The test room is room 130.
You can access it by doing this :
- Start the game
- Ignore error messages (click to dismiss "Display" messages)
- You're presented with a panel. Focus on the right-hand side. Scroll down (you can use the mouse wheel) and double-click on entry named "UPSCALE (no upscale)"

When you enter the room a GUI appears on the left. Top buttons are to increase and decrease viewport size and move it around
Bottom buttons = same but for the camera.

Pay special attention to the fact that the camera cannot go above160x100 (why???) and to the fact that mouse coordinates go up to 320x200, not 640x400, even when the room is zoomed out and you can see that the screen is effectively rendered in 640x400.
 

Crimson Wizard

Like I suspected, you have "Backward Compatibility" -> "Use low-res coordinates in script" setting enabled.

This setting converts 640x400 coordinates into 320x200 system.

Monsieur OUXX

I apologize for being so bad at reading
 

Crimson Wizard

I think this setting was never necessary for 320x200 games. It makes difference in 640x400 though.

Idk what your plans are, but I believe today you should not be using this. This is a remnant of the times when there were no scaling filters, and ags games could be run 640x400 while keeping 320x200 logic.

Monsieur OUXX

#10
Quote from: Crimson Wizard on Tue 11/05/2021 20:07:35
I think this setting was never necessary for 320x200 games. It makes difference in 640x400 though.

Idk what your plans are, but I believe today you should not be using this. This is a remnant of the times when there were no scaling filters, and ags games could be run 640x400 while keeping 320x200 logic.

3 bonus questions :
1) If that's not the recommended value, then how do you recon this setting got set to "true"? A mis-click on my part? That's how it was by default? After I selected "no" when the Editor asked me if I wated to upscale my GUIs? Etc.
2) Is there a way to see the value of the setting from the code?
3) After changing the setting to "false", things seem to make much more sense to me. One thing still eludes me though : If I "zoom in" the camera (I make it 160x100 in the 320x200 room) then I still can't move the camera using my buttons (up,down,left,right). The viewport can move in the screen, but the camera cannot move in the viewport. How's that?



FYI: I remember that setting. Its history is related to how at some points Microsoft was encouraging developers to move away from Screen coordinates. Visual Basic 6 had some grid coordinates that were disconnected from the window size, for example. It was like early "subpixel logic", even though it wasn't as extreme yet as things you see in OpenGL (0.0f --> 1.0f for everything). I imagine Chris Jones followed the trend even though he gave up on it later, when it turned out to be more confusing than helping.
 

Crimson Wizard

#11
Quote from: Monsieur OUXX on Wed 12/05/2021 09:29:16
3 bonus questions :
1) If that's not the recommended value, then how do you recon this setting got set to "true"? A mis-click on my part? That's how it was by default? After I selected "no" when the Editor asked me if I wated to upscale my GUIs? Etc.

Are you sure it was not already on in your older project? I.e. if you are reusing same game as a template for years.
As far as I know it is not touched when you upgrade from older project, and definitely it should not be set when you change game resolution in the new version.

Quote from: Monsieur OUXX on Wed 12/05/2021 09:29:16
2) Is there a way to see the value of the setting from the code?

This is not documented, but you may use GetGameOption(38). The option is called OPT_NATIVECOORDINATES and it's ID is 38, but it's not declared in script for some reason.
EDIT: Strangely SetGameOption looks like would allow to change it, although I won't recommend trying as that may lead to weird bugs in the engine.
This seem to be another part of the engine that became mostly unused and so was never fixed.

Quote from: Monsieur OUXX on Wed 12/05/2021 09:29:16
3) After changing the setting to "false", things seem to make much more sense to me. One thing still eludes me though : If I "zoom in" the camera (I make it 160x100 in the 320x200 room) then I still can't move the camera using my buttons (up,down,left,right). The viewport can move in the screen, but the camera cannot move in the viewport. How's that?

I don't know, please show the script.
To clarify, does the camera zoom work?

Monsieur OUXX

Quote from: Crimson Wizard on Wed 12/05/2021 14:17:05
I don't know, please show the script.
To clarify, does the camera zoom work?

It was still the same one that I had uploaded, except with the compatibility setting changed to False. If you feel like you have enough time to help an idiot, then you can re-download it, change the setting, and then follow the instructions in my previous post to reach the test room.
Yes, the zooming works. Only not the X/Y changes. I'm not accusing AGS, but maybe there's an indirect restriction caused by something (the viewport, the game's resolution...) that's not clear.
 

Crimson Wizard

#13
Hmm, ok, this is rather confusing, but in the version I downloaded these buttons that supposedly control camera movement (U L D R?) do not have any script attached to them.

At the same time, buttons C+ and C- also dont have any script attached, but they work in game.... So, I don't understand how the gui controls work in this game. This is why I need instructions to find where the actual script is located.


EDIT: Ok, I found it works through ViewportTests script module somehow.

Crimson Wizard

#14
Monsieur OUXX, you have an old SetViewport(x,y) called in repeatedly_execute_always in Smooth Scroll module, that overrides camera position to 0,0 every time.

In my opinion new features are best tried out in a small test game where nothing else can affect the process.

Monsieur OUXX

#15
Quote from: Crimson Wizard on Mon 17/05/2021 17:01:08
Monsieur OUXX, you have an old SetViewport(x,y) called in repeatedly_execute_always in Smooth Scroll module, that overrides camera position to 0,0 every time.

In my opinion new features are best tried out in a small test game where nothing else can affect the process.
You are absolutely right. In my defense, I didn't think that setting the Viewport impacted the size of the Camera. But then again it's my first time with the new system. Apologies.
Curious : How did you find that other SetViewport? Did you do a full text search?
 

Crimson Wizard

Quote from: Monsieur OUXX on Sat 22/05/2021 17:17:12
You are absolutely right. In my defense, I didn't think that setting the Viewport impacted the size of the Camera.

I think there may be a misunderstanding. SetViewport is an old function that sets camera position in the room. New system's viewport is completely separate thing.
This function call is inside a smooth scroll module, it's already been there.

Quote from: Monsieur OUXX on Sat 22/05/2021 17:17:12
Curious : How did you find that other SetViewport? Did you do a full text search?

I was searching for all possible functions that could change camera position.

SMF spam blocked by CleanTalk