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.fxm wrote:I think that this warning in -lang qb is not wanted
FreeBASIC 1.08.0 Release Discussion (June 2021)
Re: FreeBASIC 1.08.0 Release Discussion (June 2021)
Re: FreeBASIC 1.08.0 Release Discussion (June 2021)
Still got that bug where an array of udt's can be passed to a sub as an array of some other udt.
It could be a handy kind of template method, but it smells a little.
Well done England, it has been a long time coming!
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
Well done England, it has been a long time coming!
Re: FreeBASIC 1.08.0 Release Discussion (June 2021)
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!)
#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!)
Re: FreeBASIC 1.08.0 Release Discussion (June 2021)
You're not wrong there on both counts.dodicat wrote:It could be a handy kind of template method, but it smells a little.
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.
Re: FreeBASIC 1.08.0 Release Discussion (June 2021)
@Jeff, @St_W,coderJeff wrote: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.fxm wrote:I think that this warning in -lang qb is not wanted
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.
Re: FreeBASIC 1.08.0 Release Discussion (June 2021)
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.fxm wrote: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.
I've added the change message on the master branch now.
Re: FreeBASIC 1.08.0 Release Discussion (June 2021)
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
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
Re: FreeBASIC 1.08.0 Release Discussion (June 2021)
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.coderJeff wrote:- 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
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
Re: FreeBASIC 1.08.0 Release Discussion (June 2021)
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.adeyblue wrote: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.
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.
Re: FreeBASIC 1.08.0 Release Discussion (June 2021)
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.
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
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.
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
Re: FreeBASIC 1.08.0 Release Discussion (June 2021)
Looks really good. Got the libs in the right place now.adeyblue wrote: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
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
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() ) )
Re: FreeBASIC 1.08.0 Release Discussion (June 2021)
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?
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?
Re: FreeBASIC 1.08.0 Release Discussion (June 2021)
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)Iczer wrote: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".
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.
-
- Posts: 25
- Joined: Dec 11, 2019 15:14
- Contact:
Re: FreeBASIC 1.08.0 Release Discussion (June 2021)
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
Re: FreeBASIC 1.08.0 Release Discussion (June 2021)
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.visualfreebasic5 wrote:in the near future is there any possibility to add some new features to fb compilers such as ..