FreeBASIC 1.10.1 Release Discussion
Re: FreeBASIC 1.10.0 Release Discussion
Yes, I appreciate that too, thank you to all who have helped.
Re: FreeBASIC 1.10.0 Release Discussion
Congratulations!
Re: FreeBASIC 1.10.0 Release Discussion
Thank you developers.
Just a quick question, what changed to make the first print statement not work in 1.10.0
I had to bracket off to let it work.
Just a quick question, what changed to make the first print statement not work in 1.10.0
I had to bracket off to let it work.
Code: Select all
Type udt
r As Long
End Type
dim as udt x
x.r=10
dim as any ptr p=@x
print *Cptr(udt Ptr,p).r
print (*Cptr(udt Ptr,p)).r
sleep
Re: FreeBASIC 1.10.0 Release Discussion
Because of this change:
- sf.net #811: *(ptr).field should give an error
- sf.net #811: *(ptr).field should give an error
It looks like '*(ptr).field' is parsed as '(*ptr).field', but that's wrong, it violates operator precedence rules. The '.' member access operator should be evaluated before the '*' dereference.
.....
.....
Re: FreeBASIC 1.10.0 Release Discussion
Thanks fxm.
Broken some of my old (as mentioned SLOPPY) code, and I am sure I am not alone.
But onwards and upwards.
Broken some of my old (as mentioned SLOPPY) code, and I am sure I am not alone.
But onwards and upwards.
Re: FreeBASIC 1.10.0 Release Discussion
However at the time of the fix, I tried to alert the users:
But with a member pointer, one can more naturally use the '->' operator (instead of dereferencing plus the '.' operator), then there is no more possible error:
'ptr->field' instead of '(*ptr).field'
fxm wrote: ↑Dec 07, 2022 10:37 Attention users:
The old '#811 *(ptr).field should give an error' bug is now fixed for fbc version 1.10.0 (and later).
I noticed that some used this wrong expression '*(ptr).field' in their code.
They will need to replace it with the valid expression: '(*ptr).field'
Same problem for a pointeur to procedure-pointer 'Ptr_to_ProcPtr'.
Use:
'(*Ptr_to_ProcPtr)()' instead of '*Ptr_to_ProcPtr()'
'(*Ptr_to_ProcPtr)(...)' instead of '*(Ptr_to_ProcPtr)(...)'
(this post because who reads the 'changelog.txt' file besides me ?)
But with a member pointer, one can more naturally use the '->' operator (instead of dereferencing plus the '.' operator), then there is no more possible error:
'ptr->field' instead of '(*ptr).field'
-
- Posts: 4315
- Joined: Jan 02, 2017 0:34
- Location: UK
- Contact:
Re: FreeBASIC 1.10.0 Release Discussion
Re 1.10.0 - well done guys.
WinFBE users:
With WinFBE I use Win64 GUI(Release) as my default build.
I always have '#Console On at the head of my source code. If I want a GUI, then I'll double quote it.
An indeterminate -arch ? puts -arch 686 into the SetCompilerSwtches (SCS)command line, forcing win32, 686, 32bit overriding the Win64 build.
Now that we have 686 by default instead of 486 for x86, you may think that -arch 686 can be removed from the SCS command line. If I do that, an indeterminate -arch ? will give win64, x86-64, 64bit and not what we want.
So just keep using SCS as you have been doing and forget the fact that in fbc 1.10.0 we have 686 by default instead of 486 for x86. Of course, SCS has been using 686 for x86 for quite some time now.
WinFBE users:
With WinFBE I use Win64 GUI(Release) as my default build.
I always have '#Console On at the head of my source code. If I want a GUI, then I'll double quote it.
An indeterminate -arch ? puts -arch 686 into the SetCompilerSwtches (SCS)command line, forcing win32, 686, 32bit overriding the Win64 build.
Now that we have 686 by default instead of 486 for x86, you may think that -arch 686 can be removed from the SCS command line. If I do that, an indeterminate -arch ? will give win64, x86-64, 64bit and not what we want.
So just keep using SCS as you have been doing and forget the fact that in fbc 1.10.0 we have 686 by default instead of 486 for x86. Of course, SCS has been using 686 for x86 for quite some time now.
Re: FreeBASIC 1.10.0 Release Discussion
@Jeff,
Well done.
Next release 1.20.0 ?
I would have guessed 1.11.0 instead !
(is there a major change planned ?)
Well done.
Next release 1.20.0 ?
I would have guessed 1.11.0 instead !
(is there a major change planned ?)
Re: FreeBASIC 1.10.0 Release Discussion
I thought the 'n'th small update of '1.10' would be referenced as '1.10.n' (as before) and not '1.1n'.
Re: FreeBASIC 1.10.0 Release Discussion
Thanks for the new version. Looks good so far.
Any changes to get the gfx lib updated with "modern" functions? Further, I cannot compile the D3D9 example in FreeBASIC/examples/win32/d3d9_primitives.bas and ddrawtest.bas.
For d3d9_primitives.bas I get
ddrawtest.bas errors:
Tested on Win11 x64.
Any changes to get the gfx lib updated with "modern" functions? Further, I cannot compile the D3D9 example in FreeBASIC/examples/win32/d3d9_primitives.bas and ddrawtest.bas.
For d3d9_primitives.bas I get
Code: Select all
FreeBASIC/examples/win32/d3d9_primitives.o:fake:(.text+0x74e): undefined reference to `D3DXMatrixPerspectiveFovLH'
FreeBASIC/examples/win32/d3d9_primitives.o:fake:(.text+0xe9f): undefined reference to `D3DXMatrixRotationZ'
FreeBASIC/examples/win32/d3d9_primitives.o:fake:(.text+0xf0e): undefined reference to `D3DXMatrixTranslation'
ddrawtest.bas errors:
Code: Select all
FreeBASIC\examples\win32\ddrawtest.bas(76) warning 37(2): Ambigious len(), referring to type alias DDSCAPS, instead of variable DDSCAPS
FreeBASIC\examples\win32\ddrawtest.bas(167) error 42: Variable not declared, MAKE_DDHRESULT in 'elseif( hRet = DDERR_SURFACELOST ) then'
FreeBASIC\examples\win32\ddrawtest.bas(171) error 9: Expected expression, found 'MAKE_DDHRESULT' in 'elseif( hRet <> DDERR_WASSTILLDRAWING ) then'
Re: FreeBASIC 1.10.0 Release Discussion
Just curious, when was the last time you did / could compile and run these? btw, These examples don't have anything to do with fb gfx lib.
DirectX SDK from MS is needed to get the d3dx9 library and link the library to the example program. I tried only on win7 - it ran and "worked" but crashed on exit. Sorry, I didn't spend more time on it.
A couple of minor correction. Again I only tried on Win7. Seems my system can't support 320x200 full screen. However, directx sdk libraries not needed for this example.
Change lines:
Code: Select all
#include once "windows.bi"
#include once "win/d3dx9.bi" '' <<<<<<<
#include once "win/ddraw.bi"
const SCR_WIDTH = 1024
const SCR_HEIGHT = 768
Re: FreeBASIC 1.10.0 Release Discussion
I just wanted to mention that these examples don't work with Win11 and I'm sorry I confused it with the FB gfx lib "modernisation" request. Certainly it has nothing to do with D2D / DX. The current GFX lib feels like it's from the 90s.
Imho, all the examples in the examples folders are useless if they can't be compiled properly without installing any 3rd party SDKs. Either the examples run with the current FB package or you remove them because they can't be compiled properly.
Yes, the example can be compiled with warnings:
Code: Select all
FreeBASIC\examples\win32\ddrawtest.bas(77) warning 37(2): Ambigious len(), referring to type alias DDSCAPS, instead of variable DDSCAPS
Re: FreeBASIC 1.10.0 Release Discussion
An idea I had. No specific changes planned at the moment but psychologically bumping the version number might help allow improvements we would otherwise avoid. It is very difficult to keep everything the same and compatible while at the same time adding features and bug fixes.
The version number itself won't solve any problem on it's own but I hope give a slightly different perspective on how we might move forward.
Versions 1.11.x -> 1.19.x: maintenance, other platforms, community contributions
Versions 1.20.x and up: whatever is next.
Re: FreeBASIC 1.10.0 Release Discussion
hi all
@UEZ
if you add #inclib "d3dx9_42" to d3d9_primitives.bas then it may work
it compiles ok here, however the first time that I ran it displayed the colorful triangle then it crashed, but ran ok on second try
this is for Windows x64, don't have the 32-bit version of the d3dx9_42.dll
@UEZ
if you add #inclib "d3dx9_42" to d3d9_primitives.bas then it may work
it compiles ok here, however the first time that I ran it displayed the colorful triangle then it crashed, but ran ok on second try
this is for Windows x64, don't have the 32-bit version of the d3dx9_42.dll