FreeBASIC 1.07 Release Discussion

[srvaldez]

thank you for the new release :-)

[angros47]

Is the ABI constructor/destructor issue already fixed in the new release?

[coderJeff]

heh, I guess no sense in dwelling on any feeling of accomplishment .. back to slapping the keyboard ;)

Highlights:

• updates to makefile and build scripts
• gas64 win/lin x86_64 emitter can build the fbc compiler and pass all tests in the test-suite making this the first self hosting release for gas64 (SARG)
• improvements for linux-arm and linux-aarch64 targets with official download packages for Raspbian9-arm & Ubuntu-20.10-aarch64
• bootstrap now includes linux-arm and linux-aarch64 targets
• several minor bug fixes

If you don't need official packages for arm, aarch64, or gas64, then you probably OK to stick with 1.07.1 release until 1.08.0.

That's literally it. 1.07.2 is intended to be very compatible with 1.07.1. I needed to release 1.07.2 to have new base packages to build a 1.08.0 release. I had hoped to also do FreeBSD packages, but there's still a lot of work to do there.

ABI is not changed yet in 1.08.0. I'll do my best, but no promises on what get's done in the next month -- the list of requests is *very* long. :)
I'd like to get 1.08.0 released in Jan 2021 as we are coming up on 1.5 years for a new release now...

Discussion for 1.08.0 development is at FreeBASIC 1.08 Development

[UEZ]

Thank you very much for all your efforts!

[Provoni]

Code: Select all

.▀█▀.█▄█.█▀█.█▄.█.█▄▀　█▄█.█▀█.█─█
─.█.─█▀█.█▀█.█.▀█.█▀▄　─█.─█▄█.█▄█

For 1.07.2!

Also, GAS is great!

[UEZ]

When I use this code in x64 mode then the window is not top most after start - it is behind the code editor. Further, when it is topmost and I click another window it moves behind the activated window. With x86 it works as expected.

Code: Select all

#Include "fbgfx.bi"

Using FB
Screenres 800, 600, 32, , GFX_ALWAYS_ON_TOP Or GFX_ALPHA_PRIMITIVES Or GFX_NO_SWITCH

Sleep

[Pim Scheffers]

Hello,

Thanks for the release, small issue is that on Raspbian OS (latest version) the keyboard does not process input (Multikey) when the flag GFX_FULLSCREEN is set. It works fine in windowed mode.

OS: Raspberry Pi OS (32-bit) / 2020-08-20

Again, thanks for this release,

Greets,
Pim

[coderJeff]

When I use this code in x64 mode then the window is not top most after start - it is behind the code editor

@UEZ, top window not in front -- is this a new bug in this release, or was always a problem? Is it only when the app is run from the IDE?

on Raspbian OS (latest version) the keyboard does not process input (Multikey) when the flag GFX_FULLSCREEN is set

@Pim Scheffers, just this release? Like does it work OK in some other user contributed package?

Related?:
https://github.com/freebasic/fbc/issues/123
https://sourceforge.net/p/fbc/bugs/493/

Unfortunately, the gfxlib needs some real attention. Feels like we've had little quirks and troubles like this for years. Kind of funny, kind of not (because could be a design problem) is https://github.com/freebasic/fbc/pull/273

I don't plan on making anymore 1.07.x releases -- it's too time consuming to maintain 2 branches. So any changes or fixes will need to be in 1.08+ now.

[UEZ]

When I use this code in x64 mode then the window is not top most after start - it is behind the code editor

@UEZ, top window not in front -- is this a new bug in this release, or was always a problem? Is it only when the app is run from the IDE?

It doesn't matter which editor I use. When I select "compile and run" the opened window is always in the background behind the visible IDE window.
Compile option is "-s gui" whereas with "-s console" it works properly. I didn't have this behavior before the update.

When I start the compiled exe from the CMD box then the window will start just behind the CMD box.

[Muttonhead]

https://1drv.ms/u/s!AsTPhVzcfzRriKsoTCS ... Q?e=ZtvOpR
even if starting the executable from an explorer window, the program is behind it.

ps: screen centered but always behind explorer

Mutton

[coderJeff]

For me it happens only with DirectX driver, only with 1.07.2, and only on Win10.

My guess is that this new bug may have appeared trying to fix this other windows gfx bug: Graphics screens are not displayed in Windows 10 Japanese environment

Can you try this work-around?
Set the driver for GDI before SCREEN or SCREENRES:

Code: Select all

#include "fbgfx.bi"
#ifdef __FB_WIN32__
'' set graphics driver to GDI (Win32 only), before calling ScreenRes
ScreenControl FB.SET_DRIVER_NAME, "GDI"
#endif

This should be fixed in 1.08.0 already, as I could not reproduce the problem on Win7 or Win10 with any of the fbgfx drivers.

[UEZ]

For me it happens only with DirectX driver, only with 1.07.2, and only on Win10.

My guess is that this new bug may have appeared trying to fix this other windows gfx bug: Graphics screens are not displayed in Windows 10 Japanese environment

Can you try this work-around?
Set the driver for GDI before SCREEN or SCREENRES:

Code: Select all

#include "fbgfx.bi"
#ifdef __FB_WIN32__
'' set graphics driver to GDI (Win32 only), before calling ScreenRes
ScreenControl FB.SET_DRIVER_NAME, "GDI"
#endif

This should be fixed in 1.08.0 already, as I could not reproduce the problem on Win7 or Win10 with any of the fbgfx drivers.

Yes, this "fixes" the issue when setting the gfx driver to GDI. Btw, I'm on Win10.

[coderJeff]

Yes, this "fixes" the issue when setting the gfx driver to GDI. Btw, I'm on Win10.

IMHO, we've had troubles with the DirectX driver on Win10. adeyblue wrote a new Direct2D driver that will be the default selected in fbc 1.08.0.

[adeyblue]

GDI and DirectDraw (DirectX) now initialize the window in the same way:

Create (but not show) the window
Do the FB related drawing initialisation
Show the window

so it's weird that one works and one doesn't. Setting topmost for a hidden window succeeds but monitoring WM_WINDOWPOSCHANGING, it sets topmost and then sends a second message before SetWindowPos returns where it unsets it again, but still returns success.

I think DirectInput creates its own window to handle the input (which doesn't happen in the GDI driver) so I guess that messes with some things? That or the DirectDraw initialisation does something different when the window is hidden, but that doesn't cause it to fail

[coderJeff]

@adeyblue, I think the 1.08.0 gfx changes are just fine. Thanks for checking it out.

I found a new way to shoot myself in the foot ...

sf.net #898: fbc win gfxlib DirectX driver failed to initialize on 64-bit, due to incorrect construction of DIDATAFORMAT for keyboard device (macko17)

And I forgot to cherry pick on to 1.07.2, duh. I have such a mess to clean-up :(

Anyway, if apply this change then the window appears on top even with the old directx driver.