FreeBASIC 1.08.0 Release Discussion (June 2021)

[coderJeff]

I think that this warning in -lang qb is not wanted

I agree. I wrote a fix for this. It will get merged in to 1.08.1 sometime. Not just yet because I have a couple of work in progress branches to sort out and push first.

[dodicat]

Still got that bug where an array of udt's can be passed to a sub as an array of some other udt.

Code: Select all

#include "file.bi"

type udt
    as zstring * 8 st
end type

type other
      as double d
end type

type dummy 
      as boolean b
end type

#macro printout(a,dot)
for n as long=lbound(a) to ubound(a)
      print a(n)dot
next
#endmacro

sub load(file as string,u() as dummy)
   var  f=freefile
   if fileexists(file)=0 then print file;"  not found":return
    Open file For Binary Access Read As #f
    If Lof(f) > 0 Then
      Get #f, ,u()
    End If
    Close #f
    end sub

sub save(file as string,u() as dummy)
    var h=freefile
    open file for binary access write as #h
    put #h, ,u()
    close #h
end sub


'=================================

dim as udt x(1 to 3)
dim as other z(1 to 3)

for n as long=1 to 3 
   x(n).st= "Elem " +str(n)
   z(n).d=sqr(n)
next n

print "ORIGINAL UDT"
printout(x,.st)

save("data",x())'<------  x() is UDT

var N=filelen("data")\sizeof(udt) 'get the number of elements to load

redim as udt y(1 to N)
load("data",y())'<------  y() is UDT

print "============= FROM FILE ============="
printout(y,.st)

kill "data"
print
print "does datafile exist?   ";fileexists("data")
print
print "ORIGINAL OTHER"
printout(z,.d)

save("data",z())'<------- z() is OTHER

N=filelen("data")\sizeof(udt) 'get the number of elements to load

redim as other w(1 to N)
load("data",w())'<------- w() is OTHER
print "============= FROM FILE ============="
printout(w,.d)

kill "data"
print "does datafile exist?   ";fileexists("data")
print "done"
sleep


  

It could be a handy kind of template method, but it smells a little.
Well done England, it has been a long time coming!

[fxm]

My corresponding bug report is still open (since 2016-03-07) :
#817 Type mismatch not detected when passing an array of UDT incompatible with the expected UDT
(This is not a recent bug or a regression. Already present since fbc version 0.12b!)

[coderJeff]

It could be a handy kind of template method, but it smells a little.

You're not wrong there on both counts.

fbc currently allows "x() as any" parameters in declarations to enable declaring the array run time library functions - which accept any kind of array.
It's not yet possible to directly use "x() as any" in user subs because some other supporting code needs to be written for accessing array elements by reading the array descriptor information instead of fbc knowing it at compile time based on the type.

As for the UDT type checking, I looked at bug #817 before, but it's not really a bug with existing code ... it's just simply not there; never written. There's a check on the number of dimensions and little else for UDT array parameters.

[fxm]

I think that this warning in -lang qb is not wanted

I agree. I wrote a fix for this. It will get merged in to 1.08.1 sometime. Not just yet because I have a couple of work in progress branches to sort out and push first.

@Jeff, @St_W,

This fix (https://github.com/freebasic/fbc/commit ... e16925c582) is now included in the daily build (fbc version 1.09) at https://users.freebasic-portal.de/stw/builds/, but I don't see it in the associated changelog.txt file.

[coderJeff]

This fix (https://github.com/freebasic/fbc/commit ... e16925c582) is now included in the daily build (fbc version 1.09) at https://users.freebasic-portal.de/stw/builds/, but I don't see it in the associated changelog.txt file.

Thanks, fxm. I'll have to watch my merges a little closer ... or not do them so late at night when my eyes are tired. The changelog message was on the 1.08.1 branch, but when I merged it in to master there was a merge conflict on the changelog.txt file and never noticed that I clobbered the message when resolving the conflict.

I've added the change message on the master branch now.

[coderJeff]

I've built most of the packages for 1.08.1 and will start uploading soon.

There are 3 reports that I have decided not to deal with in 1.08.1 and will instead deal with in 1.09.0
- missing 64-bit gdb.exe on windows - I'm still evaluating. gdb_77 from freepascal looks like a good candidate.
- missing zlib1.dll - it's only included because some gdb.exe's need it. And we have traditionally not included zlib1.dll thinking that should be up to the user to install as a system component, or have we included libz.a static as it should be built specifically for each system it's used on. Adding some form of libz either as a dynamic or static library would be a change earlier versions of fbc.
- the scaling issue on win 7 versus win 10 (the only two windows I can test with non-virtual machine). I don't fully understand the problem so I am very cautious about jamming in a fix right now. Even if it is by design, I can confirm there is an issue on win 7 versus win 10. So, either there is a by design fix for win 7, or we need to add some special logic just for win 7. But I don't know. Will reassess in fbc-1.09.0

[adeyblue]

- the scaling issue on win 7 versus win 10 (the only two windows I can test with non-virtual machine). I don't fully understand the problem so I am very cautious about jamming in a fix right now. Even if it is by design, I can confirm there is an issue on win 7 versus win 10. So, either there is a by design fix for win 7, or we need to add some special logic just for win 7. But I don't know. Will reassess in fbc-1.09.0

I figured it out. D2D surfaces have two sizes. The one you create it with 'the pixel size', and then a what-that-would-be-at-96dpi size. When creating a 400x300 window @ 120dpi, creating a 400x300 pixel size surface would size it really as 320x240.
So then the problem was that it took the 320x240 top left corner of our framebuffer and stretch it out for the 400x300 window.

As D2D allows drawables to have different DPIs, there are two fixes. Scale the pixel size of the render target so the 96dpi-size is correct, or just force the target to use 96dpi. And it seems like there's only one winner.


There's a zip here with (windos obvs) gfxlibs that are hardcoded to 96 is anybody wants to test if that works properly.
https://www.airesoft.co.uk/files/temp/gfxlibs.zip

[coderJeff]

As D2D allows drawables to have different DPIs, there are two fixes. Scale the pixel size of the render target so the 96dpi-size is correct, or just force the target to use 96dpi. And it seems like there's only one winner.

Thank you for the explanation. With new knowledge, I retested again here forcing the render target to 96 dpi and it makes sense to me. We have a user requested screen[res] size in pixels, and fbgfx will give exactly what was asked, a window sized to the requested pixels.

With the forced scaling, all drivers are consistent in fbc-1.08+

I was going to conclude that to support scaling either by system dpi or user request, this should be a new feature change either through screen[res] flags or screencontrol set_scaling of some kind.

However, we have the difference with fbc-1.07.3 where scaling was automatic on win 10 ... and I'll have to log out and in again to test on win 7.

[coderJeff]

I think I have my facts straight:
1) Forcing the target to 96 DPI looks correct for a first step.
- windows 7 will consistently scale the gfx window/image to 100%, regardless of system dpi
- windows 10 will consistently scale the gfx window/image to the system dpi (100%, 125%, etc)
- this seems OK to me as it gives consistent behavior on all drivers
2) There remains a bug with Direct2D driver on windows 7 related to screen updating - separate from the scaling issue (I think).
3) 'screencontrol fb.GET_DESKTOP_SIZE, w, h' is the desktop size in pixels independent of system dpi scaling. Maybe a new GET function can retrieve the desktop size after scaling.
Next step is to add the forced scaling and can deal with the refresh issue later. Either a windows version check to select the default driver or investigate win 7 more.

FWIW, below is the details of what I tested:

UPDATE: Tested with updated libfbgfx.a libfbgfxmt.a from adeyblue - works good.

Code: Select all

Tested at 125% system dpi scaling - with adeyblue's libraries

                  force
fbc     bits win  96dpi  driver    window  image   notes
------  ---- ---  -----  --------  ------  ------  ----- 
1.07.3   32    7    -    gdi       100%    100%    OK
1.07.3   32    7    -    directx   100%    100%    OK
1.07.3   64    7    -    gdi       100%    100%    OK   
1.07.3   64    7    -    directx   100%    100%    OK     
1.07.3   32   10    -    gdi       125%    125%    OK      
1.07.3   32   10    -    directx   125%    125%    OK  
1.07.3   64   10    -    gdi       125%    125%    OK      
1.07.3   64   10    -    directx   125%    125%    OK  

1.08.1   32    7    -    gdi       100%    100%    OK
1.08.1   32    7    -    directx   100%    100%    OK   
1.08.1   32    7   Y    direct2d  100%    125%    OK
1.08.1   64    7    -    gdi       100%    100%    OK
1.08.1   64    7    -    directx   100%    100%    OK
1.08.1   64    7    Y    direct2d  100%    125%    OK
1.08.1   32   10    -    gdi       125%    125%    OK
1.08.1   32   10    -    directx   125%    125%    OK
1.08.1   32   10    Y    direct2d  125%    125%    OK
1.08.1   64   10    -    gdi       125%    125%    OK
1.08.1   64   10    -    directx   125%    125%    OK
1.08.1   64   10    Y    direct2d  125%    125%    OK

1.09.0   32    7    -    gdi       100%    100%    OK
1.09.0   32    7    -    directx   100%    100%    OK
1.09.0   32    7    Y    direct2d  100%    100%    OK
1.09.0   64    7    -    gdi       100%    100%    OK
1.09.0   64    7    -    directx   100%    100%    OK
1.09.0   64    7    Y    direct2d  100%    100%    OK
1.09.0   32   10    -    gdi       125%    125%    OK
1.09.0   32   10    -    directx   125%    125%    OK
1.09.0   32   10    Y    direct2d  125%    125%    OK
1.09.0   64   10    -    gdi       125%    125%    OK
1.09.0   64   10    -    directx   125%    125%    OK
1.09.0   64   10    Y    direct2d  125%    125%    OK

[coderJeff]

There's a zip here with (windos obvs) gfxlibs that are hardcoded to 96 is anybody wants to test if that works properly.
https://www.airesoft.co.uk/files/temp/gfxlibs.zip

Looks really good. Got the libs in the right place now.
Works well for me on windows 7 and windows 10. Tested with fbc-1.08.1 and fbc-1.09.0 both on 32-bit and 64-bit.
maybe PR soon? ;)

Unless my eyes deceive me, looks like you added some magic for window sizing:

Code: Select all

'' create an empty half screen width and height - works with adeyblue's new updates
 
#include once "fbgfx.bi"

dim as long w, h
screencontrol fb.GET_DESKTOP_SIZE, w, h

screenres w/2, h/2

print w, h
sleep

And some simple test code for checking scaling - this seemed to display OK for every combination I tested with you libs.

Code: Select all

#include "windows.bi"
#include "fbgfx.bi"
using fb

dim as integer w = 320, h = 240

if( command(1) > "" ) then
	screencontrol SET_DRIVER_NAME, command(1)
end if
screenres w, h, 32

dim as string driver
screencontrol GET_DRIVER_NAME, driver

color 0, -1

print "fbc version: " & __FB_VERSION__
print "driver:      " & driver
print "windows:     " & LOBYTE(LOWORD(GetVersion())) & "." & HIBYTE(LOWORD(GetVersion()))

circle (w/2, h/2), h/2-1, rgb( 200, 200, 0 )
line ( 10, 10 ) - ( w-11, h-11 ), rgb( 0, 200, 200 )

do
	sleep 1
loop until( len( inkey() ) )

[Iczer]

I tried to move to FB 1.08.1 (gcc 9.3 x64) from 1.07.3 (gcc 5.2 x64), but after my library successfully compiled (compile time is another story...), on load i get "The procedure entry point "aaa" could not be located in the dynamic link library bbb.dll" errors. Note - library "bbb.dll" just last-loaded lib, not corresponding/containing to function "aaa".
one error was resolved by stripping "lib" prefix from lib name "libSomeLibName.dll" --> "SomeLibName.dll" as i known from wich lib function was. But on second load it was "ASN1_OCTET_STRING_free" function and, after googling, renaming openssl related libraries did not help...

on fb 1.07.3 my library was not plagued by those errors, loaded libraries did not changed. It seems lib-naming issue on dll-load time.
How i can fix it?

[coderJeff]

I tried to move to FB 1.08.1 (gcc 9.3 x64) from 1.07.3 (gcc 5.2 x64), but after my library successfully compiled (compile time is another story...), on load i get "The procedure entry point "aaa" could not be located in the dynamic link library bbb.dll" errors. Note - library "bbb.dll" just last-loaded lib, not corresponding/containing to function "aaa".

If you really get stuck and want to try fbc-1.08.1 but not deal with a change in tool chain: FreeBASIC-1.08.1-mingw64-gcc-5.2.0.7z- 32bit and 64bit combined version (fbc32.exe & fbc64.exe)

Going from mingw-64-gcc-5.2 to winlibs-gcc-9.3 then there are a couple things to keep in mind:
- they are different tool chains, have a different run-time library - mixing bits and pieces from 2 tool chains won't work out well.
- there are binary differences between fbc-1.07.3 and fbc-1.08.1 - if you are passing fb objects (like arrays) between your main program and the DLL you may have run-time problems.
- if you are using standalone versions, keep each separate and not have both in your PATH at the same time.

You don't list the actual errors, so I need to guess a little, and just give some suggestions.
- For the linking issues, you shouldn't need to rename the DLL just to get it to link.
- jj2007 reported an issue once having issue with compiling a DLL, but when running the program, the previous versions loaded, or something. I'm not sure. I couldn't duplicate the issue.
- I could only come up with DLL caching (by windows), but that didn't seem right - I thought that was only for system DLLs, but I could be wrong.
- Finally, try a reboot and come at the problem clean, record your steps to reproduce the issue and we might be able to find the cause. Thanks.

[visualfreebasic5]

in the near future is there any possibility to add some new features to fb compilers such as ..

Code: Select all

dim aa() as long
 aa=bbbbb() 
Function bbbbb() as long()
   dim cc(1) as long
   Function =cc
end Function
'------------------------------------
dim bb() as long 
bb=aa

[coderJeff]

in the near future is there any possibility to add some new features to fb compilers such as ..

To return arrays as function results, or temporary arrays as in 'var x = array( elements... )' the path forward is probably to rework the variable length [w]string API's first. The lessons learned there will hopefully help to implement array expressions. Both variables length STRING's and hopefully soon variable length DWSTRING's have a descriptor. Arrays also have a descriptor and intent would be that arrays could be handled as objects similar to [dw]strings.