Working on a recent ruby/gosu game I happened to notice that the window I'm creating of dimensions 800x600 isn't quite accurately respecting those dimensions from what I can tell. It would appear that I can display a quad that actually goes from 0,0 to 800,600 and see it. In otherwords, one would assume counting from 0 that you could only write to coord 799 in an 800 width display. I've noticed this because I am both writing a quad layer to the background most z-layer and then rendering some bitmaps over top on the same z-layer which are wider than 800 pixels. This in affect showed me a black line where my underlying quad wasn't quite covering. Any thoughts on when you create an 800x600 window in gosu window init that it is really making it 801x601 ? That is what it looks like.
The lower right coordinates are exclusive, if you draw a 800x600 image it should cover the window exactly. Maybe this should be somehow documented. Until you think about it, It Just Works, though. ;)
Not sure I'm understanding how you are answering my question. Are you saying that I'm seeing this "undocumented feature" because I'm trying to write a quad from 0,0 to 799,699.. and also writing out a bitmap that starts at 0,0 but is in effect 1600x600 dimensions thereby hitting the 'exclusive lower right coords' and that is why I see the 'line' of 1-pixel wide black?
Sorry I'm having trouble getting what you're telling me! ;) If we keep having prob I will post a test program to demonstrate what I mean in case you aren't understanding me. Thanks for the reply!
Hmm, if you see a 1-pixel wide black line by drawing an image that is as large as the window, then that is indeed a bug in the Windows port that I need to check. But it is neither a feature nor a bug that a rectangle drawn from 0, 0 to 800, 600 covers the screen exactly. In contrast, a rectangle from (0, 0) to (0, 100) is even invisible. One way to view it is that the lower right pixels aren't included. One explanation that I like more is that Gosu's coordinates aren't the pixels, but the infinitely small points between them, so that 0, 0 is to the top left of the first physical pixel and 800, 600 would be to the low right of the last physical pixel. draw_line probably destroys the latter imagination. But I hope clears up why a quad to 799, 599 would leave a black line.
Anyway, this example program should cover the screen exactly, show one 10x10 px square and nothing more, does this not work on Windows? (Can't start VM right now, exam time until this weekend)
class MyWindow < Window
super 400, 300, false
def draw_rect x, y, w, h, color = 0x40ff0000
draw_quad x, y, color, x + w, y, color,
x, y + h, color, x + w, y + h, color
draw_rect 5, 5, 10, 10
draw_rect 5, 50, 100, 0
# covers window
draw_rect 0, 0, 400, 300
Hope that helps! :)
This helps a lot, thanks! I think your explanation about the way you think of 0,0 to 800, 600 working makes a lot of sense. I just was never suspecting it to work that way. But, visualizing it as drawing pixels from the "edge" of 0,0 to the "edge" of 800, 600 makes me get why it is behaving that way. Thanks for the example code. It correctly runs on windows and doesn't leave a black line. I was always knocking -1 off my dimensions and getting the black line because of the way I was thinking about it. I never noticed until I was also drawing bitmaps that were so much wider than the screen width that it started to fill the last pixel on the right that I had left blank on my bottom most quad layer. Rock!
Powered by mwForum 2.29.0 © 1999-2013 Markus Wichitill