I'm trying to play Curse of Monkey Island in a window. By default, the window is much too small and I'm left squinting at everything. If I set the scaling to 2x, part of the game goes off the bottom of my screen. Is there any way to force a 1.5x scaling or manually resize? This really makes things hard to read with my poor eyesight.
Note: My resolution is only 1440x900 so doubling 640x480 puts it over my screen's size.
1.5x Scaling?
Moderator: ScummVM Team
-
Raptor10439
- Posts: 6
- Joined: Sun Feb 28, 2010 6:52 am
I could play it fullscreen but then I have to go back to window to get to my chat windows. It wouldn't be so much of an issue if Steam/Xfire worked in game. I would think by now there would be someway to resize the window as I'd see fit. I guess I could always play on my xbox and play on my TV but I'd rather just play on my computer in a larger window.
Folks, Raptor is entitled to use his computer just how he likes to. Telling him to not chat while playing just because *you* don't want to do that, is not helpful.
Personally, I also very often play adventures in windowed mode and do something else in the background... e.g. I have a lengthy computation running, and while it's running, I play a bit, and occassionally check on the progress of the computation.
As to the 1.x5x scaling: It wouldn't be difficult to implement, I guess, but so far nobody requested that. As for arbitrary rate scaling: This has been requested, but not that often; it's not completely trivial to implement either, and so far none of the team members seems to have had this particular itch, so nobody was/is strongly interested in implementing this.
Personally, I also very often play adventures in windowed mode and do something else in the background... e.g. I have a lengthy computation running, and while it's running, I play a bit, and occassionally check on the progress of the computation.
As to the 1.x5x scaling: It wouldn't be difficult to implement, I guess, but so far nobody requested that. As for arbitrary rate scaling: This has been requested, but not that often; it's not completely trivial to implement either, and so far none of the team members seems to have had this particular itch, so nobody was/is strongly interested in implementing this.
http://sourceforge.net/search/?words=sc ... ct&pmode=0
People have requested and submitted patches for alternative scalers, but the solutions are either too ugly or rejected for some other reason.
Anyway, I have been researching this a bit.
Because I HATE to switch monitor resolution for fullscreen play as that never works well with a dual screen setup. And because I have some unrelated project going based on libSDL that I need to be able to scale randomly.
LibSDL seems not to be very helpful with this. You need to create the surfaces (textures) with a particular size and there seems not to be a proper way to resize them arbitrarily.
What I found was the cleanest and best looking solution BY FAR was dropping surfaces alltogeter and going for OpenGL.
OpenGL textures can be made to look as pixel-perfect as surfaces, if you set gltexparameterf() right, and can obviously be rendered at any size.
There obviously is some smoothing for odd scale factors like 0.7 or 1.3 but you have to look closely to notice it.
I am however simply not good enough to roll out a patch as expansive as this for a project I didn't code myself.
People have requested and submitted patches for alternative scalers, but the solutions are either too ugly or rejected for some other reason.
Anyway, I have been researching this a bit.
Because I HATE to switch monitor resolution for fullscreen play as that never works well with a dual screen setup. And because I have some unrelated project going based on libSDL that I need to be able to scale randomly.
LibSDL seems not to be very helpful with this. You need to create the surfaces (textures) with a particular size and there seems not to be a proper way to resize them arbitrarily.
What I found was the cleanest and best looking solution BY FAR was dropping surfaces alltogeter and going for OpenGL.
OpenGL textures can be made to look as pixel-perfect as surfaces, if you set gltexparameterf() right, and can obviously be rendered at any size.
There obviously is some smoothing for odd scale factors like 0.7 or 1.3 but you have to look closely to notice it.
I am however simply not good enough to roll out a patch as expansive as this for a project I didn't code myself.
-
Raptor10439
- Posts: 6
- Joined: Sun Feb 28, 2010 6:52 am
Is it probable that it will be patched in or implemented in a build in the near future? Not being able to resize windows has always been an annoyance to me. I honestly can't believe it's not requested often or not currently in the game. Also, I'm not saying I want 1.5 scaling exactly, I just want to be able to resize my window as I see fit. You'd think it would at least be able to stretch the image to whatever size I wanted the window to be.
There are no immediate plans to support such a feature, and as far as I know, nobody is working on this. We wouldn't turn down a well-written patch which adds such a feature. But it's a non-trivial thing to write, and so far it seems nobody with the abilities to do it had enough interest in it, and vice-versa.
I've seen several requests for this in the past, but not really an abundance...
I've seen several requests for this in the past, but not really an abundance...
Unfortunately I doubt it's really that simple. The thing is this: most older games were not able to switch resolutions so easily -- they were designed and always displayed at a particular resolution. Usually 320x240 or 640x480 (or less in some cases).Raptor10439 wrote:Is it probable that it will be patched in or implemented in a build in the near future? Not being able to resize windows has always been an annoyance to me. I honestly can't believe it's not requested often or not currently in the game. Also, I'm not saying I want 1.5 scaling exactly, I just want to be able to resize my window as I see fit. You'd think it would at least be able to stretch the image to whatever size I wanted the window to be.
Although I am far from an expert on the subject, I imagine that a free resize would introduce a whole bevy of graphical issues on every different engine. It's probably doable, but for games with resolutions that were never meant to be changed, I imagine it could cause a lot of trouble.
And I was never trying to tell anyone how to use their computer. I was serious about getting a better monitor though. If your max resolution is 1440x900, there are monitors available for a bit more than $100 that can improve that.
It's not exactly what you think.KuroShiro wrote: Although I am far from an expert on the subject, I imagine that a free resize would introduce a whole bevy of graphical issues on every different engine. It's probably doable, but for games with resolutions that were never meant to be changed, I imagine it could cause a lot of trouble.
The game engines themselves should never be 'aware' of this scaling feature. They should think they are running on 320x240 or 640x480 or whatever it is they want.
The scaler just takes what the game engine feeds it and smears (rasterizes) the result over the screen in the way needed. It also translates the mouse location from screen coordinates back into coordinates the game engine understands.
A properly designed free scaler will either never be made or will work globally for all game engines.
Anyway since noone seems capable of doing it soon, my guess is that advances in window manages (the part of your OS that draws your desktop) will make this feature unnecessary at some point.
Modern window manages already know how to to scale any window (Google-image "OS X Expose" if you don't know what I mean).
It won't be long before they will allow you to permanently upscale anything and then you won't even need any scaling build into ScummVM.
The trick is to not actually resize, but kill the window and re-initialize it. That will always work regardless of DirectX, OpenGL, libSDL version or whatnot.
This will make the window snap to the default position, but you can prevent accidental resizes by making the user change window size though a menu item instead of allowing click-n-drag.
This will make the window snap to the default position, but you can prevent accidental resizes by making the user change window size though a menu item instead of allowing click-n-drag.
It is technically certainly doable to implement a resizable window (at least on Mac OS X, Windows, Linux) which automatically re-scales the current game scripts, with some help of OpenGL, and fully transparent to the running game (i.e. the game does not need to know anything about this at all). With some extra work one could even restrain the window to preserve the aspect ratio etc. Doing this all in a clean and portable fashion (as opposed to hacking up some code that will only work on, say, Windows 7 but not Windows XP nor Linux, Mac OS X), *and* writing the code such that it is maintainable, and integrates well into ScummVM, is where it starts to become more difficult.
I am pretty sure several team members could in principle write such code, but doing it properly takes time; time which part of our little spare time we have to hack on ScummVM; and if I only have that little time every week left to hack on ScummVM, I'll first spend it on things that I enjoy, or that are important to myself. I guess others feel the same, and I hope this is quite understandable!
Anyway, we have had an open task for this for some time now. Maybe this year a student will work on it during Google Summer of Code (if we are accepted as a project, if a student is interested, if we pick him, etc.
I am pretty sure several team members could in principle write such code, but doing it properly takes time; time which part of our little spare time we have to hack on ScummVM; and if I only have that little time every week left to hack on ScummVM, I'll first spend it on things that I enjoy, or that are important to myself. I guess others feel the same, and I hope this is quite understandable!
Anyway, we have had an open task for this for some time now. Maybe this year a student will work on it during Google Summer of Code (if we are accepted as a project, if a student is interested, if we pick him, etc.