Windows bug for small screens / fullscreen
-
- Posts: 2958
- Joined: Jun 02, 2015 16:24
Windows bug for small screens / fullscreen
Hello,
the example at the Pmap (graphics functionality) would be clearer if it used screenres 640, 480 rather than screen 12. Otherwise things are a little more obscured than necessary I think.
By the way, I have a bug when I set a screenres 100,100 on win10. A vertical thick white band appears near right side, and cls doesn't remove it. I don't known if it's known?
Thank you
edited: title changed according to the most important among affairs treated around here.
the example at the Pmap (graphics functionality) would be clearer if it used screenres 640, 480 rather than screen 12. Otherwise things are a little more obscured than necessary I think.
By the way, I have a bug when I set a screenres 100,100 on win10. A vertical thick white band appears near right side, and cls doesn't remove it. I don't known if it's known?
Thank you
edited: title changed according to the most important among affairs treated around here.
Last edited by Tourist Trap on Feb 06, 2019 18:12, edited 1 time in total.
Re: Documentation of PMAP function
This weird behavior only appears with fbc 1.06 and 64-bit.Tourist Trap wrote: By the way, I have a bug when I set a screenres 100,100 on win10. A vertical thick white band appears near right side, and cls doesn't remove it. I don't known if it's known?
Thank you
[fixed]
- Github #113: When a WINDOW was active, the top/right edges (bottom/right for WINDOW SCREEN) were transformed out of the viewport.
???
[edit]
Similar behavior for a similar code with fbc 1.05 and 64-bit.
Re: Documentation of PMAP function
It looks OK with 32 bits, but it behaves badly also in a different way.
(1.05)
(1.05)
Code: Select all
screenres 100,100,32
color , rgb(200,0,0)
dim as integer mx,my
do
getmouse mx,my
screenlock
cls
line(0,0)-(99,99)
locate 1,1
print mx;my
screenunlock
sleep 1
loop until len(inkey)
sleep
-
- Posts: 2958
- Joined: Jun 02, 2015 16:24
Re: Documentation of PMAP function
It's my version. I took it from the last WINFBE package. I'm not sure if it's related to WINDOW. Can't investigate too deeply those days.fxm wrote: This weird behavior only appears with fbc 1.06 and 64-bit.
Version 1.06.0
[fixed]
- Github #113: When a WINDOW was active, the top/right edges (bottom/right for WINDOW SCREEN) were transformed out of the viewport.
???
Anyway, here is what I get with your test under 1.06:dodicat wrote:It looks OK with 32 bits, but it behaves badly also in a different way.
Re: Documentation of PMAP function
With 32 bits -gen gcc or gas the screen is drawn as is 129 by 100 if set for 100 by 100.
A white line doesn't show.
I tested on fb .24 as well as the latest official (1.05) build.
A good find TT.
I think all graphics bugs should be resolved in fb, gfx graphics are fb's main strength.
I have no idea how to view Github #113 - sorry.
A white line doesn't show.
I tested on fb .24 as well as the latest official (1.05) build.
A good find TT.
I think all graphics bugs should be resolved in fb, gfx graphics are fb's main strength.
I have no idea how to view Github #113 - sorry.
-
- Site Admin
- Posts: 6323
- Joined: Jul 05, 2005 17:32
- Location: Manchester, Lancs
Re: Documentation of PMAP function
It's at https://github.com/freebasic/fbc/issues/113.dodicat wrote:I have no idea how to view Github #113 - sorry.
Hmm, we have bbcode for bugs on SourceForge, but not for Github. Maybe that's worth adding..
Anyway, I don't think the above bug is related. The fixes should only affect the resulting image in the screen buffer, not how it's rendered in the window.
Re: Documentation of PMAP function
No problem (with 100x100) when there is no frame (flag: FB.GFX_NO_FRAME), or with a shorter title bar (flag: FB.GFX_NO_SWITCH).
Re: Documentation of PMAP function
Code: Select all
screenres 60, 60
do
dim as integer mx ,my
getmouse mx, my
screenlock
cls
line(0, 0)-(59, 59)
locate 1, 1
print mx; my
screenunlock
sleep 1
loop until len(inkey)
sleep
- Regardless of the graphics window width requested, a minimum width is always imposed (when the GFX_NO_FRAME flag is not used) to allow the display of a minimum window bar.
- In such a case, on the x-axis, the view mapping for any drawing keyword does not match the physical mapping (only the GETMOUSE statement always follows the physical pixel): as if the image was internally stretched.
It seems that for fbc 64-bit, this behavior does not work properly (if we consider that the behavior with fbc 32-bit is the wanted).
Re: Documentation of PMAP function
Tourist Trap and the others:
I can, if you allow, fill in a bug report on this behavior, but from my point of view as described in my post above.
Otherwise, do it yourself.
I can, if you allow, fill in a bug report on this behavior, but from my point of view as described in my post above.
Otherwise, do it yourself.
-
- Site Admin
- Posts: 6323
- Joined: Jul 05, 2005 17:32
- Location: Manchester, Lancs
Re: Documentation of PMAP function
So far, it seems like this is a problem with Windows refusing to make the window as small as the graphics area.
Are you saying that on 32-bit it stretches the graphics to fill the window, while on 64-bit it is not stretched, but the remaining area is basically filled with nothing useful?
I've tested quickly on FB 1.05 64-bit on Windows 10. I see a similar effect to the screenshot, although the white bar fills the height of the window.
Tourist Trap, the separate PMAP issue seems to have been forgotten here. I suggest starting a new thread if you want to talk about it, and rename this one.
Are you saying that on 32-bit it stretches the graphics to fill the window, while on 64-bit it is not stretched, but the remaining area is basically filled with nothing useful?
I've tested quickly on FB 1.05 64-bit on Windows 10. I see a similar effect to the screenshot, although the white bar fills the height of the window.
Tourist Trap, the separate PMAP issue seems to have been forgotten here. I suggest starting a new thread if you want to talk about it, and rename this one.
Re: Documentation of PMAP function
Yes (including the printed characters which are also stretched on fbc 32-bit).counting_pine wrote:Are you saying that on 32-bit it stretches the graphics to fill the window, while on 64-bit it is not stretched, but the remaining area is basically filled with nothing useful?
I observed that behavior on Windows 10 (64-bit), testing both with fbc 32-bit and fbc 64-bit.
The day before yesterday, I added a comment after 'SCREEN 12' to highlight the dimensions (640x480) of the corresponding window:counting_pine wrote:Tourist Trap, the separate PMAP issue seems to have been forgotten here. I suggest starting a new thread if you want to talk about it, and rename this one.
- KeyPgPmap → fxm [Added a comment on the first line of the example]
-
- Site Admin
- Posts: 6323
- Joined: Jul 05, 2005 17:32
- Location: Manchester, Lancs
Re: Documentation of PMAP function
I see now, just a documentation shortcoming.
The simplest solution is probably just to use ScreenRes, as suggested.
The simplest solution is probably just to use ScreenRes, as suggested.
Re: Documentation of PMAP function
KeyPgPmap → fxm ['ScreenRes 640, 480' rather than 'Screen 12' in example to explicit the window resolution]
-
- Posts: 2958
- Joined: Jun 02, 2015 16:24
Re: Documentation of PMAP function
Thank you.fxm wrote:KeyPgPmap → fxm ['ScreenRes 640, 480' rather than 'Screen 12' in example to explicit the window resolution]
By the way, as we evocated issues about screen sizes, FBSHOOT , and my own test, tends to show that GET_DESKTOP_SIZE fails with 1920×1080 res on win10. It seems that Lachie has also encountered this behaviour. I have no time to go in deep for the instant, so take it as just a warning.
-
- Posts: 2958
- Joined: Jun 02, 2015 16:24
screen sizes...
I tnink tbe pmap affair is solved, just left the screen sizes difficulties.counting_pine wrote: Tourist Trap, the separate PMAP issue seems to have been forgotten here. I suggest starting a new thread if you want to talk about it, and rename this one.