FreeBASIC 1.08.0 Release Discussion (June 2021)

[fxm]

As long as 'v' and 'h' arguments are passed to ScreenInfo, passing INTEGER variables works even with fbc version 1.08 64-bit, because in this case, the overload function with LONGINT parameters is used.
With fbc version 1.08 32-bit, passing INTEGER variables always select the overload function with LONG parameters.

Example for the fbc compiler 64-bit (still works fully for the fbc compiler 32-bit):

Code: Select all

DIM PixelSizeAbs AS INTEGER
DIM PixelSizeOrd AS INTEGER
SCREENINFO PixelSizeAbs, PixelSizeOrd  '' still works
 
DIM NbrBitsCol AS INTEGER
SCREENINFO , , NbrBitsCol  '' does not work anymore

[coderJeff]

I switched to 1.08.0, and found this bug.

Hmmm. I wrote the new gfx SCREENCONTROL API entry points wrong .. so that sucks. They are ok for GET functions but not SET. The mistake is obvious now that you have pointed it out, thank-you.

If you do want to test other parts of version 1.08.0 you can use this work around to get back the old SCREENCONTROL gfx API:

Code: Select all

#if __FB_VERSION__ = "1.08.0"
	'' remove new 1.08.0 SCREENCONTROL gfx API entry points
	#undef screencontrol
	#undef screencontrol
	#undef screencontrol

	'' add back the 1.07.x and earlier SCREENCONTROL gfx API entry points
	extern "rtlib"
		declare sub ScreenControl overload alias "fb_GfxControl_s" _
			( _	
				byval what as long, byref param as string = "" _
			)
		declare sub ScreenControl alias "fb_GfxControl_i" _
			( _
				byval what as long, _
				byref param1 as integer = 0, _
				byref param2 as integer = 0, _
				byref param3 as integer = 0, _
				byref param4 as integer = 0 _
			)
	end extern
#endif

[coderJeff]

Looks like ImageInfo doesn't allow optional arguments any more ?

Sort of. I did not make this change lightly and knew that it could cause some source code breaks.
imho, LONG data type should be preferred since the FB.IMAGE type which directly represents the underlying implementation in gfxlib all LONG types.

The IMAGEINFO function (which existed before fbc's 64-bit capability) is not great to work with. Using INTEGER probably seemed like the best compromise at the time since a lot of code then was using INTEGER data type.

Short answer is, use LONG data type with IMAGEINFO and it works same on both 32-bit and 64-bit.

IMAGEINFO(img, width, height, bpp, pitch, imgdata, size ) is kind of weird in that all parameters are optional. This would be fine if all the datatypes were the same, but imgdata is an ANY PTR and will causes problems with overload resolution unless at least one other parameter is made mandatory.

Anyway, in 1.08.0 to allow LONG (preferred, and all parameters are optional), but also also LONGINT and INTEGER if desired at least one parameter other than imgdata had to be made mandatory (non-optional), and I choose width and height.

----
But, if you want the old gfx IMAGEINFO API back (to ease the pain):

Code: Select all

#if __FB_VERSION__ = "1.08.0"
	extern "rtlib"
		#undef IMAGEINFO
		#undef IMAGEINFO

		declare function IMAGEINFO alias "fb_GfxImageInfo" _
			( _
				byval img as any ptr, _
				byref w as integer = 0, _
				byref h as integer = 0, _
				byref bpp as integer = 0, _
				byref pitch as integer = 0, _
				byref imagedata as any ptr = 0, _
				byref size as integer = 0 _
			) as long
	end extern
#endif

[adeyblue]

The problem I discovered is only for Win7 - Win10 seems to work properly.

ok, confirmed. Here's what I think is happening:

It's not really a bug, it's by design.

https://stackoverflow.com/a/52310714
There are three conditions that forces DPI awareness in Windows 7 regardless of the manifest:
•DPI Virtualization is globally disabled (the "Use Windows XP style DPI scaling" setting in Display->Set Custom Text Size)
•Desktop composition is disabled for the current desktop (either a non-Aero theme is selected or hardware acceleration in unavailable, note that this means that DPI awareness is always on when running in a HyperV VM!).
•Display scaling is disabled in compatibility settings.

In a VM, that second one is going to be true 99% of the time - which forcefully turns DPI awareness on, even though nobody asked for it explicitly.

[Makoto WATANABE]

Thanks dear all.
Especially thanks dear adeyblue.

In Windows 10 Japanese environment (Microsoft IME), drawing programs are now displayed without the screen disappearing.
FreeBASIC 1.08 is also an improvement over FreeBASIC 1.07 in this respect.
I am very grateful to you.

P.S.
When using "XFont" with FreeBASIC 32Bit, it cannot be compiled with the following error.
I would appreciate it if you could tell me how to fix it.
XFont (Text Render Library) Version 11.9.13.
http://xaviorsoft.freebasic.net/fbproduct/
http://xaviorsoft.freebasic.net/fbproduct/xfont_win.zip
c:\tool\freebasic\bin\win32\ld.exe: c:\tool\freebasic\lib\win32/libxfont.a(xfont.o):fake:(.text+0x12f8): undefined reference to `fb_ArrayClear@8'

[badidea]

When using "XFont" with FreeBASIC 32Bit, it cannot be compiled with the following error.
I would appreciate it if you could tell me how to fix it.
XFont (Text Render Library) Version 11.9.13.
http://xaviorsoft.freebasic.net/fbproduct/
http://xaviorsoft.freebasic.net/fbproduct/xfont_win.zip
c:\tool\freebasic\bin\win32\ld.exe: c:\tool\freebasic\lib\win32/libxfont.a(xfont.o):fake:(.text+0x12f8): undefined reference to `fb_ArrayClear@8'

Hi Makoto WATANABE, I forked the XFont library some time ago and applied some fixes to make it compatible with 64-bit FBC and called it version 12.0.0. See: https://github.com/verybadidea/XFont-Lib
I have not yet tried the new compiler release myself.

[Landeel]

I switched to 1.08.0, and found this bug.

Hmmm. I wrote the new gfx SCREENCONTROL API entry points wrong .. so that sucks. They are ok for GET functions but not SET. The mistake is obvious now that you have pointed it out, thank-you.

If you do want to test other parts of version 1.08.0 you can use this work around to get back the old SCREENCONTROL gfx API:

Code: Select all

#if __FB_VERSION__ = "1.08.0"
	'' remove new 1.08.0 SCREENCONTROL gfx API entry points
	#undef screencontrol
	#undef screencontrol
	#undef screencontrol

	'' add back the 1.07.x and earlier SCREENCONTROL gfx API entry points
	extern "rtlib"
		declare sub ScreenControl overload alias "fb_GfxControl_s" _
			( _	
				byval what as long, byref param as string = "" _
			)
		declare sub ScreenControl alias "fb_GfxControl_i" _
			( _
				byval what as long, _
				byref param1 as integer = 0, _
				byref param2 as integer = 0, _
				byref param3 as integer = 0, _
				byref param4 as integer = 0 _
			)
	end extern
#endif

I couldn't get 'SET_GL_SCALE' to work even with this workaround.

[Makoto WATANABE]

Dear badidea;
Thanks for your quick reply.

I tried "XFont" version 12.0.0, but unfortunately it failed to compile with the same error below.
I presume that "libxfont.a" is not compatible with FreeBASIC 1.08.0.

c:\tool\freebasic\bin\win32\ld.exe: c:\tool\freebasic\lib\win32/libxfont.a(xfont.o):fake:(.text+0x12f8): undefined reference to `fb_ArrayClear@8'

[coderJeff]

I presume that "libxfont.a" is not compatible with FreeBASIC 1.08.0.

Probably, yes. To fix some really old bugs in fbc internal changes had to be made that break binary compatibility. Try recompiling the library also using the new version of fbc.

[coderJeff]

I couldn't get 'SET_GL_SCALE' to work even with this workaround.

The work-around works for me. Can you post (short) sample code to compare between fbc 1.07.3 and 1.08.0?

Fix for screencontrol committed in fbc 1.08.1 (fbc-1.08 branch) & fbc 1.09.0 (master branch)

[angros47]

Have you seen my post about class destructor, CoderJeff?

[Kwabbernoot]

Dear badidea;
Thanks for your quick reply.

I tried "XFont" version 12.0.0, but unfortunately it failed to compile with the same error below.
I presume that "libxfont.a" is not compatible with FreeBASIC 1.08.0.

c:\tool\freebasic\bin\win32\ld.exe: c:\tool\freebasic\lib\win32/libxfont.a(xfont.o):fake:(.text+0x12f8): undefined reference to `fb_ArrayClear@8'

Why Xfont? FBTrueType font is much better.
viewtopic.php?f=14&t=25083

[Landeel]

I couldn't get 'SET_GL_SCALE' to work even with this workaround.

The work-around works for me. Can you post (short) sample code to compare between fbc 1.07.3 and 1.08.0?

Fix for screencontrol committed in fbc 1.08.1 (fbc-1.08 branch) & fbc 1.09.0 (master branch)

I'm on Lubuntu 22.04. Tried compiling both 32-bit and 64-bit.
Changing 'SCALE' makes no difference. I can even set it to 0, and it will still draw as if SET_GL_SCALE was set to 1.

Code: Select all

#define SCALE 0 ' <-----------

#include "fbgfx.bi"
using fb

#if __FB_VERSION__ = "1.08.0"
   '' remove new 1.08.0 SCREENCONTROL gfx API entry points
   #undef screencontrol
   #undef screencontrol
   #undef screencontrol

   '' add back the 1.07.x and earlier SCREENCONTROL gfx API entry points
   extern "rtlib"
      declare sub ScreenControl overload alias "fb_GfxControl_s" _
         ( _   
            byval what as long, byref param as string = "" _
         )
      declare sub ScreenControl alias "fb_GfxControl_i" _
         ( _
            byval what as long, _
            byref param1 as integer = 0, _
            byref param2 as integer = 0, _
            byref param3 as integer = 0, _
            byref param4 as integer = 0 _
         )
   end extern
#endif


screencontrol(SET_GL_2D_MODE, OGL_2D_MANUAL_SYNC)
screencontrol(SET_GL_SCALE, SCALE)
screenres 320, 200, 32, , GFX_OPENGL

dim as integer w, h, d
dim as string driverName
screeninfo w, h, d, , , , driverName
print driverName & " @ " & str(w) & "x" + str(h) & "x" + str(d)
circle(320\2, 200\2), 90, rgb(200,200,0)

'' You need to poll flip() so the window doesn't become unresponsive
do
sleep( 1, 1 )
flip
loop until( len( inkey() ) )

[dodicat]

I have fixed my noughts and crosses with the workaround.
viewtopic.php?f=8&t=20182&p=177284&hili ... 2A#p177284
Landeel.
The fix works OK on Win 10, with scale 0 and scale 1 giving the same circle, and scaling up (3 say) works OK.
I should really have been testing code with 1.08 pre release, I might have found the bug ages ago, I am always messing with graphics, too late now though.

[Landeel]

It does work when I cross-compile for Windows and run it with wine.