PALETTE USING and SCREEN bug on newer windows OS
PALETTE USING and SCREEN bug on newer windows OS
I found a problem when using PALETTE USING and with SCREEN function on windows 7 machines or newer. When an 8 bit screen mode is initialize from the SCREEN function and PALETTE USING is used to initialize a new palette for it. The new palette is not loaded and the palette remains at it's default colors. This only happen when a compiled program runs on windows 7 or newer OS. The same compiled program will work on older windows. The SCREENRES with PALETTE USING function on the other hand, works just fine on windows 7. I think this is a bug with the SCREEN function not being fully compatible with newer windows OS. I am using the latest fbc 1.06.0. This was a problem lingered from previous versions also.
Re: PALETTE USING and SCREEN bug on newer windows OS
Are you certain, that there isn't a simple misunderstanding?
(about the statement and/or it's use)
Where is the code, that is proof, of your theory?
(about the statement and/or it's use)
Where is the code, that is proof, of your theory?
-
- Site Admin
- Posts: 6323
- Joined: Jul 05, 2005 17:32
- Location: Manchester, Lancs
Re: PALETTE USING and SCREEN bug on newer windows OS
Interesting...
I could be wrong about this, but I seem to recall FB does its own palette rendering, and just uses RGB mode on the final Windows screen..
Either way, Screen and Screenres should behave the same way in most respects. There are no deep architectural differences.
Can you provide code that demonstrates the problem? The same executable should be tried on each system, to rule out FB differences, but I don't think that would be the cause of the problem here anyway..
I could be wrong about this, but I seem to recall FB does its own palette rendering, and just uses RGB mode on the final Windows screen..
Either way, Screen and Screenres should behave the same way in most respects. There are no deep architectural differences.
Can you provide code that demonstrates the problem? The same executable should be tried on each system, to rule out FB differences, but I don't think that would be the cause of the problem here anyway..
Re: PALETTE USING and SCREEN bug on newer windows OS
I have code that will replicate the problem. You will need the "256mask.pal" file from Bowser's Story in the Freebasic games directory or create your own palette to distinguish from the default one.
If you guys have 64bit version of freebasic and/or Linux version. Does this still work in both screen modes?
Code: Select all
cls
'256mask.pal file required to run this program!
'This program will test a palette bug with 8 bit screen vs screenres
'with windos 7 or greater.
'Not tested on the 64bit compiler
dim as integer selection
dim pal(255) as uinteger ' array for the palette
dim as string filename = "256mask.pal"
print "1 for SCREEN functon"
print "2 for SCREENRES funcion"
print "After selection, the default palette will be displayed, then"
print "press any key to see the loaded palette."
input selection '1 or 2 to test both screen initialize modes
'palette does not load correctly in SCREEN on windows 7+
'palette does load correctly in SCREENRES
'If the palette loads correctly(after the first pause), you should see 16 color scales:
'grey, red, green, blue, cyan, yellow, violet, orange, navy blue, dark green, brown,....
if selection = 1 then
screen 18,,,1 ' aka 640, 480, 8
elseif selection = 2 then
screenres 640, 480, 8
else
end
end if
for i as integer = 0 to 255' draw palette colors on screen
for y as integer = 0 to 479
pset (i,y), i
next y
next i
sleep'wait and view the default palette.
bload filename, varptr(pal(0)) ' load palette from file to array.
palette using pal(0) 'load palette into fb graphics.
sleep'wait and view the loaded palette.
-
- Site Admin
- Posts: 6323
- Joined: Jul 05, 2005 17:32
- Location: Manchester, Lancs
Re: PALETTE USING and SCREEN bug on newer windows OS
Thanks. I just generated a quick greyscale palette with for i as integer = 0 to 255: palette i, i,i,i: next i
It looks like your Screen 18 is set to go fullscreen, that might make a difference. It would probably be a good idea to go fullscreen on both or neither, to confirm whether that's the problem.
Sadly, my computer doesn't actually seem to like going into fullscreen on Screen 18...
It looks like your Screen 18 is set to go fullscreen, that might make a difference. It would probably be a good idea to go fullscreen on both or neither, to confirm whether that's the problem.
Sadly, my computer doesn't actually seem to like going into fullscreen on Screen 18...
Re: PALETTE USING and SCREEN bug on newer windows OS
Win 10
On this machine:
Both compilers (32 and 64 bit) will not produce a full screen with 8 bits.
In fact, running this code (from the help file under screenlist), I get nothing
with screenlist(32) I get
Full screens are only obtainable with resolutions given out by this help file code (As far as I understand anyway)
On this machine:
Both compilers (32 and 64 bit) will not produce a full screen with 8 bits.
In fact, running this code (from the help file under screenlist), I get nothing
Code: Select all
Dim As Integer mode, w, h
Print "Resolutions supported at 8 bits per pixel:"
mode = ScreenList(8)
While (mode <> 0)
w = HiWord(mode)
h = LoWord(mode)
Print w & "x" & h
mode = ScreenList()
Wend
sleep
Code: Select all
Resolutions supported at 32 bits per pixel:
320x200
512x384
640x400
640x480
800x600
848x480
1024x768
1152x864
1280x960
1280x1024
Re: PALETTE USING and SCREEN bug on newer windows OS
I have tested SCREENRES 640,480,8,,1 in full-screen in 8 bits. It has the same problem as SCREEN 18 in full-screen in windows 7. The palette is corrupted. It is fine in window mode. While pressing Alt+Enter from full-screen to window mode. The program crashes. This was confirmed on my laptop and PC with both running Windows 7. My conclusion is that Freebasic's graphics API needs to be updated to be compatible with newer versions of windows.
Re: PALETTE USING and SCREEN bug on newer windows OS
Out of curiosity, I ran the code from ShawnLG with the "256mask.pal" on my Linux laptop and 32-bit freebasic.
Result: Seems to work as expected fullscreen, windowed and switching between the two.
"256mask.pal" can be found (in zip-file) here: http://games.freebasic.net/dumpbyid.php?input=145
I did notice an issue with the 64-bit compiler: Less colors, half of them seem skipped.
This is probably because "palette using pal(0)" actually expects and "uinteger".
But the code "bload filename, varptr(pal(0))" will behave different for 32 and 64-bit I expect.
I guess no-one bothered converting the "pallete" code to 64-bit.
Result: Seems to work as expected fullscreen, windowed and switching between the two.
"256mask.pal" can be found (in zip-file) here: http://games.freebasic.net/dumpbyid.php?input=145
I did notice an issue with the 64-bit compiler: Less colors, half of them seem skipped.
This is probably because "palette using pal(0)" actually expects and "uinteger".
But the code "bload filename, varptr(pal(0))" will behave different for 32 and 64-bit I expect.
I guess no-one bothered converting the "pallete" code to 64-bit.