FreeBASIC 1.10.1 Release Discussion

[hhr]

Yes, I appreciate that too, thank you to all who have helped.

[marcov]

Congratulations!

[dodicat]

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.

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
 

[fxm]

Because of this change:
- 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.
.....
.....

[dodicat]

Thanks fxm.
Broken some of my old (as mentioned SLOPPY) code, and I am sure I am not alone.
But onwards and upwards.

[fxm]

However at the time of the fix, I tried to alert the users:

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'

[deltarho[1859]]

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.

[fxm]

@Jeff,

Well done.

Next release 1.20.0 ?
I would have guessed 1.11.0 instead !
(is there a major change planned ?)

[paul doe]

...
I would have guessed 1.11.0 instead !
(is there a major change planned ?)

Next release has been increased to allow for small updates within the 1.10 release (such as updating headers, examples, that sort of thing).

[fxm]

I thought the 'n'th small update of '1.10' would be referenced as '1.10.n' (as before) and not '1.1n'.

[UEZ]

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

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'

Tested on Win11 x64.

[coderJeff]

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.

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.

For d3d9_primitives.bas

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.

ddrawtest.bas errors:

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

Hope this helps. If you make a fixed / better / nicer example, we can include it in fb's examples/win32/... directory.

[UEZ]

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.

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.

Hope this helps. If you make a fixed / better / nicer example, we can include it in fb's examples/win32/... directory.

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

It runs but it is crashing after a few seconds. I need to understand DX / D2D before I can make examples, but without a proper working FB foundation it will be difficult....

[coderJeff]

Next release 1.20.0 ?
I would have guessed 1.11.0 instead !
(is there a major change planned ?)

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.

[srvaldez]

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