Not logged inGosu Forums
Forum back to libgosu.org Help Search Register Login
Up Topic Gosu / Gosu Exchange / Wrong window size
- - By Drowad Date 2012-08-01 21:57 Edited 2012-08-01 22:31
Hi,

First of all, thanks for all the work :)

I have a really annoying problem : I want to use a window of 1024x768, but the problem is that the window created was a lot smaller, but for 800x600 it's work normally.
I'm using ruby 1.9.3, the last gem of gosu, and Window 7 professional.

To make a better view of the problem, I've make an example :

require 'Win32API'
require 'gosu'

def test_window_size(width, height)
  window = Gosu::Window.new(width, height, false)
  handle = Win32API.new('user32', 'FindWindow', 'PP', 'I').call("Gosu::Window", "")
  rect = [0, 0, 0, 0].pack("I*")
  Win32API.new('user32', 'GetClientRect', 'IP', 'I').call(handle, rect)
  puts "Gosu Size : #{[window.width, window.height]} - Real Size : #{rect.unpack("I*")[2..3]}"
end

test_window_size(800, 600) # => Gosu Size : [800, 600] - Real Size : [800, 600]
test_window_size(1024, 768) # => Gosu Size : [1024, 768] - Real Size : [819, 614]
test_window_size(Gosu.screen_width, Gosu.screen_height) # => Gosu Size : [1366, 768] - Real Size : [1092, 614]


It's only works on Windows, I use GetClientRect to get the "real" client size. As you can see, the window was a lot smaller than expected.
So what I can do ? If this question was already answered, I'm really sorry because I have done some research before posting.

Another question, there is a way to get the gosu window handle on Windows ? Because I want to add some "extra-features" for the Windows users :D

Thanks, and please forgive my english :)
Parent - - By Spooner Date 2012-08-02 00:07
Gosu automatically prevents you from having a window close to the size of the screen, to prevent it covering your task bar, so it will resize it and scale it for you (which can be annoying because the margin it decides to use is incredibly conservative :D). This is hard-coded in Gosu and there is nothing we can do about it.

If you want to fill the screen properly, use full-screen mode.
Parent - - By Drowad Date 2012-08-02 09:50
Thanks !

Well, fullscreen isn't an option for me, I want to be able to use the taskbar.
I've look into the gosu source code to understand how it's work, I've never seen this kind of protection before :D

Anyway, I think I've found a solution that suits me :
width, height = (Gosu.screen_width * 0.9).round, (Gosu.screen_height * 0.8).round
Will give the maximum size without gosu resize/scale my window :)
Parent - - By Spooner Date 2012-08-02 10:08
Yes, it is a very lazy (lazy bad, not lazy good :D) system in Gosu to limit it like that. Hopefully it will try to ask the system about the taskbar one day (probably non-trivial to do all all OSes consistently) or just trust us to either make a sensibly sized window or just ask the user to configure the window size. And yes, jlnr, I'm talking to you about this *angry face*
Parent - - By jlnr (dev) Date 2012-08-02 10:30
Before I've added my check, oversized windows would minimizes themselves on startup and you couldn't click them to get them out of the taskbar. Absolutely bizarre behavior. Being even one pixel too big will make the game absolutely unusable, that's why I'm so conservative.

I'm not sure if I'll try to make the check more sophisticated. I think if I'd just make the window resizable, Windows and other systems would take care of this themselves - a much nicer solution.
Parent - By Spooner Date 2012-08-02 10:34
Thanks, I'll look forward to it in 0.8, some time in 2020 :)
Parent - By danikaze Date 2012-08-08 17:06
Is it possible to add a parameter in the Window constructor so you can ignore that limit? So you can take care about that problem by yourself.

Something like this
Window (unsigned width, unsigned height, bool fullscreen, double updateInterval=16.666666, bool ignoreConstraint=false)

It would be very useful for the next release, and it's something easy to do, I think :)
Parent - - By BlueScope Date 2012-08-14 11:19
An improved way to handle different screen sizes (or be able to respond to them at all) would indeed be very desireable. I talked about how the lack of a proper fullscreen feature really impedes many game ideas with a buddy yesterday night, and having a resizeable window (which I assume includes maximizing) would be a great thing to look forward to, and depending on the game at hand even more desireable than fullscreen (which seems to be the case here).
Parent - - By Spooner Date 2012-08-14 22:25
Full-screen borderless window would also be preferable to "true" fullscreen too.
Parent - - By BlueScope Date 2012-08-15 10:50
While I definately agree there, it seems that this would need the same fix jlnr mentioned in his first post here, whereas the window would minimize itself automatically otherwise. Now, of course I really have no clue of all that OS window management stuff, but I imagine that to be quite hard with multiple target operating systems in mind...

But yeah, borderless fullscreen is on my humble wishlist as well, however a resizeable window solution that comes in the near future and should work on all systems is preferred to a borderless fullscreen solution that likely comes way after and might be buggy... no?
Parent - - By Spooner Date 2012-08-15 12:18
Borderless fullscreen is the only fullscreen supported in Ray, works flawlessly, so it is perfectly possible cross-platform, but it doesn't have the same legacy obsession as Gosu (which is both a good and bad feature of Gosu ;) ).

The problem with run-time resizing is that you need an extra chunk lot of code to handle it in your game.

I do worry a bit about pixelated games, that can't really operate at fractional zooms (e.g. in Z&G, I think the game runs at something like 160x120 internally, so is fine at 640x480, but would look terrible at, say, 800x500). For this popular use-case, we really need the ability to resize in code, rather than resize arbitrarily with maximise buttons or manual dragging of the edges. Not saying I don't want it, but it is important that it is, by default, disabled.
Parent - - By jlnr (dev) Date 2012-08-15 15:29
There's no legacy problem in rewriting the fullscreen code to make it use a fullscreen window. It's just a matter of missing time. (i.e. contributions welcome ;))
Parent - By Spooner Date 2012-08-15 15:56
Fair enough; I assumed it was something that would be difficult before the glfw transition (without any real knowledge of what is involved :D)
Parent - By BlueScope Date 2012-08-15 18:13
Again, I'm sure I'm being more optimistic on this than I should be, but I don't see the extra effort if you're not trying to resize what's displayed. If you're just trying to display more of the same scene upon resizing, it shouldn't make much of a difference.
Of course, you would need a way to access the current width/height of the window to do stuff such as HUD drawing or certain camera actions properly... but there might be something like that already, and I just missed it :)
Parent - By RavensKrag Date 2012-08-25 22:53
Runtime resizing, similar to the way Minecraft works, is a part of GLFW. Depending on how much of GLFW gosu ends up using, it might not be too hard to implement.

There are of course still some considerations about how the game should scale when the window is resized that would have to be handled by individual game code.  However, the base functionality would be there, at least.
Parent - By RunnerPack Date 2012-11-25 19:18
I started a (probably redundant) issue about this topic: https://github.com/jlnr/gosu/issues/158
Parent - - By BlueScope Date 2012-12-10 08:02
I actually ran into a new-to-me window sizing problem, that however I'm sure other people have had in the past.

What I'm doing is I'm making a game with a target resolution of 360x200 (which is just slightly wider than a ratio of 16:9). Now, that is neither working in fullscreen mode (modern monitors don't support such small resolutions, and the ratio is not a regular ratio either) nor in regular mode, which simply looks way too small on a 1920x1080 screen.

So, I was wondering if there is or could be something like an internal scaling factor... let's say I'm doing something like Window.new(width, height, fullscreen, update_interval = 16.666666, scale = 1.0)
I could imagine there already being something like that, because on the automatic window resize that's been talked about previously, this is exactly what happens: The whole viewport is scaled down to match the new window's size.

Alternatively, I once programmed a script to go with RPG Maker VX to automatically detect the screen size of the user and scale the window to full increments (1x, 2x, 4x, ...) of the original solution as long as it still fits their screen. Of course, that was a WinAPI solution, so again, not sure about multi-platform...

The only other way I can think of is something like a @scale variable to be used in every draw... and I really don't want to go there...
Parent - - By jlnr (dev) Date 2012-12-10 11:25
The easiest way is to wrap your Window#draw method in scale(2) do ... end, and to scale down mouse_x and mouse_y wherever you use them. Not pretty, but one of the smaller pain points with Gosu. :)
Parent - By BlueScope Date 2012-12-10 12:15
Alright, that actually would make it rather convenient, especially since I don't use the cursor at all... now, if screen_width and screen_height work the way I imagine it, that would make the auto-scaling quite easy again! :D
I'm going to fiddle with that the second I get home from work... but thanks already, as I don't see why it wouldn't work :)
Parent - - By BlueScope Date 2012-12-10 17:44 Edited 2012-12-10 18:28
Okay, there actually is the aliasing 'problem' that for a pixelated-style game, that just looks very untidy. Is there a way to influence that, as in change it to repeating pixels?

I've also been wondering about the Window.scale function... when I try to use it with self.scale(2, 2, 0, 0), it returns no block given (LocalJumpError). Any clues on how to use this properly (or if it even is what I'm looking for)? ^^
Parent - - By jlnr (dev) Date 2012-12-11 01:51
scale expects a block with the code that will scale...

scale(2) do  # passing 2 is the same as 2, 2, 0, 0 :)
  image3.draw(1,2,3)
end


You can stack and combine these transforms.

For pixelated-style games, use Gosu::enable_undocumented_retrofication (sic)
Parent - - By BlueScope Date 2012-12-11 20:10
Ah, that was a mistake on my part then... I suspected the Window.scale function seperated from what you suggested - the draw block I managed to get by myself luckily :D

That undocumented feature is a true gem, though... glad to know about it, as I think the 'default' way Gosu renders sprites is rather bad-looking... but that might be because I never usually work with sprite zooming (except clean increments such as 50% or 200%)...

Oh, one more thing that I found interesting: The scale function works different than I expected. What I'm doing is drawing a sprite with 50% it's original size. It's then wrapped in the scale(4) function, which scales it up to a total amount of 200%.

Gosu (left image) renders it altogether, instead of the step-wise execution I expected to happen (right). Of course this makes more sense, I just mention it because I thought it might be interesting to some :)
(by the way, the sprite is for displaying purposes only... grabbed it from Google a second ago. So, sadly, no fighting game from me any time soon :D )
Parent - - By Spooner Date 2012-12-11 23:02
That is because scaling doesn't do any rendering. All it does it alter the transformation matrix used when the image is finally rendered.

If you wanted the latter effect in Gosu, you'd need to scale down and render to a small texture (Ashton::Texture#render or something with TexPlay), then render that small texture larger onto the screen.
Parent - By BlueScope Date 2012-12-12 13:20
Yeah, I figured that's what was going on... it was more of a "Aha!" post than a "How do I fix it?" one :)
Parent - - By erisdiscord Date 2012-12-12 05:44
It's also a good idea to floor your drawing coordinates if your game uses floats for positioning and stuff. Even with smoothing disabled, drawing a sprite at 0.5, 0.5 is going to have the "pixels" misaligned.

@image.draw @x.floor, @y.floor, @z

or whatever.
Parent - By BlueScope Date 2012-12-12 13:19
That's a very nice hint, I probably would've missed that.
(What I'm working on atm only draws to integer coordinates, though... still incredibly useful to know!)
Up Topic Gosu / Gosu Exchange / Wrong window size

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill