SyntaxBomb - Indie Coders

Hi,

Recently I have revisited BlitzMax-NG having not used it since version:
    bcc[ng] Release Version 0.133
    bmk 3.48 mt-linux-x64

...where the samples (for example) like oldskool2 built and executed fine.

I have now tried newer versions:
    bcc[ng] Release Version 0.139
    bmk 3.56 mt-linux-x64
..and..
    bcc[ng] Release Version 0.143
    bmk 3.57 mt-linux-x64

...which both fail to execute due to NULL exceptions on the global TImage declarations and LoadImage statements.

After many hours headscratching and back and forth between the docs, here and github issues I finally found out the problem is due to the fact that these happen before the Graphics statement.

If I put the Graphics statement before these declarations it builds and executes fine.

Is this a bug or am I missing a caveat in the documentation that specifies a graphics context needs to be established before loading content?

Or are the samples and docs just outdated for newer changes to the language?

It always was the case that an "TImage" can only be created a "graphics context" exist.

This is because "TPixmap" is the "CPU/RAM"-representation of the raw pixel data (so a 2d array of the pixels stored in eg a png). But "TImage" contains these "TPixmap" (so a reference to the raw data) but also creates a GPU-texture (VRAM). And this is backend (OpenGL, DirectX, ...) specific. Thus it requires a graphics context (eg a glcontext ...) so create the GPU/VRam-Image-Texture.


This also means, that "Timage"-Loading needs to be done in the Main Thread of a programme. Parallel threads should simply load in TPixmaps (and store them in a TMap / Queue / ... so your main thread can then simply load the pixmaps into the TImages ... which saves the "disc loading/decoding time").


bye
Ron

Quote from: Derron on March 30, 2024, 09:28:22It always was the case that an "TImage" can only be created a "graphics context" exist.

Thanks for the reply Derron,

Two things though...

If this is the case, then why does it work out of the box on the older version I tested?

Is this just a BlitzMax-NG thing and were the samples written for the original BlitzMax only?

Can you post the sample code you used to test on "the older version I tested" - and also try to figure out what this version was (so I could try to replicate).

It could work if the image class implements some kind of "lazy loading" (only loading the pixmap until you really want to "use" the image in the sense of rendering).

Hmm ... if I remember correctly, TImage contains some "seq" field which is a number which can be compared to the graphics type instance. It also has a seq number. And if seq numbers differ, the image texture has to be recreated. We could check if that feature got "lost" for specific backends.
But I assume the biggest issue is a potential lack of "checks". I mean that it kinda creates a "by default invalid" texture so that the very first graphics instance will already lead to the above described "context changed, will reload the texture" thing.


Samples: Some samples were written with NG as test case - so "for" NG. This is of course especially valid for commands only existing in NG


bye
Ron

SuperStrict
Framework Brl.GLMax2D
Import Image.PNG

'this also requires a graphics driver / context thing
AutoMidHandle(True)

'load img first
Local i:TImage = LoadImage("logo.png")

'now the graphics
Graphics 800, 600

Repeat
 Cls
 DrawImage(i, MouseX(), MouseY())
 Flip
Until KeyHit(KEY_ESCAPE) or AppTerminate()

attached is the "logo.png"


This "segfaults" here (already the AutoMidHandle will segfault because it calls TMax2DGraphics.Current().AutoMidHandle(enable) -- with no max2d graphics existing yet, same for LoadImage which uses TMax2DGraphics.Current().LoadImage(url, flags)).
Rearrange it in the BlitzMax where it was working - until it works and then we could try to get this running in current NG too.

I dunno how it could work as the TImage-implementation really is backend specific (it gets the imageframe a driver provides - which is backend specific).


bye
Ron

Quote from: Derron on April 01, 2024, 08:39:44Can you post the sample code you used to test on "the older version I tested" - and also try to figure out what this version was (so I could try to replicate).

Hi Derron,

The version is in my original post and the example is in the "sample/flameduck/oldskool" directory.

This is the exact downloaded (older) version https://github.com/bmx-ng/bmx-ng/releases/download/v0.133.3.48.linux.x64/BlitzMax_linux_x64_0.133.3.48.tar.xz

Quote from: Derron on April 01, 2024, 10:04:17This "segfaults" here (already the AutoMidHandle will segfault because it calls TMax2DGraphics.Current().AutoMidHandle(enable) -- with no max2d graphics existing yet, same for LoadImage which uses TMax2DGraphics.Current().LoadImage(url, flags)).
Rearrange it in the BlitzMax where it was working - until it works and then we could try to get this running in current NG too.

I dunno how it could work as the TImage-implementation really is backend specific (it gets the imageframe a driver provides - which is backend specific).


bye
Ron

As expected, segfaults for me on the old version (0.133) too.

I guess the samples source codes just need updating to correct order of execution for newer versions?
It's no big deal really, unless you are a new user who is trying to see what the language can do and all you find is segfaults! Not a good showcase then, is it?

Thanks

As a side issue, it's not just graphical related inaccuraces in the samples compiling under newer versions.  Take for example the excellent "digesteroids", a simple Print statement causes non-compilation because of a missing Import brl.StandardIO or changing the Print to WriteStdErr.

I tried the original code and checked what differs there. Was a bit baffled as the "gc" they use in max2d was null there - and then realized that during my overhaul of max2d I made some stuff "methods" instead of "functions" and thus also relied on requiring an instance of it.
Once this is fixed the behaviour I described above ("seqs"-property) is seen.

I will prepare a PR for it - with these changes, oldskool2.bmx compiles and runs as it should.
edit: Created the PR
https://github.com/bmx-ng/brl.mod/pull/318

Other examples need to be checked.


bye
Ron

Brucey merged the PR - so next sunday's weekly build will contain the fix.

I also have gone through the samples and made some small adjustments here and there to make them all compile/run with the latest builds.


 bye
Ron

Quote from: Derron on April 01, 2024, 17:32:41Brucey merged the PR - so next sunday's weekly build will contain the fix.

I also have gone through the samples and made some small adjustments here and there to make them all compile/run with the latest builds.


 bye
Ron

Cheers chaps, appreciated.

BlitzMaxNG is the Best. Any improvements make it better than better.

However, im dabbling with Lazarus but want to get rid of the windows side of it! For the RETRO feel. It's a lot faster.

Baggey