Any known issues with LoadImage on Linux?

BlitzMax Forums/BlitzMax Programming/Any known issues with LoadImage on Linux?

dan_upright

(Posted 2014) [#1]

I'm using the BLIde FontMachine code with an incbinned font - it works fine on windows but on linux it crashes. I've checked and it is finding the file and opening it successfully but when it tries to use LoadImage on the open stream, it returns null.

Given that it's the exact same file and code as on windows, does anyone know what could be causing this?

Brucey

(Posted 2014) [#2]

It may depend what other dependencies you are using in your project.
Have you tried a basic test with a minimal set of code/modules ?

dan_upright

(Posted 2014) [#3]

Not yet, I posted that on my way out the door this morning, so it's first on the list now that I'm home. Do you have any particular dependencies in mind when you say that?

Derron

(Posted 2014) [#4]

Brucey surely means something like:

SuperStrict
Framework Brl.Standardio
Import Brl.Image
Import Brl.Stream
Import Brl.PNGLoader
...

a minimal example just using the barely needed things.

bye
Ron

dan_upright

(Posted 2014) [#5]

I actually seem to be unable to load anything via "incbin::" on linux - if the file wasn't found, it wouldn't compile, right? It's still slightly mystifying because the original crash is after the TStream is checked against null and inside a "While myStream.Eof() = false" loop, so that is definitely being found.

I'm trying to do some testing with just a basic incbinned image file and I can't open it as a stream or pass it to loadimage, it's bizarre.

Brucey

(Posted 2014) [#6]

Remember to add

Import BRL.RamStream

if you are using Framework.

GfK	(Posted 2014) [#7]

Ah, you're using Linux. Have you tried standing on your head in the corner while whistling "O Lord our God of the Swazi" backwards, in the "lounge" style?

Sometimes you have to go the extra mile to get Linux to graft.

dan_upright

(Posted 2014) [#8]

Ok, I cut this right down and it's actually just LoadImage and has nothing to do with incbin.

SuperStrict

Import "-ldl"
Import brl.pngloader

Local imagePath:String = "pointer.png"
Local fhnd:TStream = OpenStream(imagePath)
If fhnd Then
	Print("Stream opened")
	Local myImage:TImage = LoadImage(fhnd)
	If myImage = Null Then Print("Image did not load")
	CloseStream(fhnd)
EndIf

Local myImage:TImage = LoadImage(imagePath)
If myImage = Null Then Print("Image did not load")

This will fail to load the image both times if the image is a png but work fine with a jpeg. Am I missing something obvious or should that not just work the same way as it does under windows?

Edit - even this fails:

Local myPixmap:TPixmap = LoadPixmapPNG(imagePath)
If myPixmap = Null Then Print("Pixmap did not load")

dawlane

(Posted 2014) [#9]

I do take it that the file names match exactly. Linux is case sensitive. A file name such as Pointer.png would be not be loaded by using a command to load a file named "pointer.png".

When writing for cross platform. It's best to use lower case and underscores for where the is white space.

degac

(Posted 2014) [#10]

Why did you use OpenStream AND LoadImage?

*maybe* OpenStream 'lock' the file under Linux for some reason? (I dont' really know... just ideas)

dan_upright

(Posted 2014) [#11]

Linux is case sensitive.

I know linux is case sensitive, that's not the issue - running that code will print "Stream opened" then "Image did not load" twice (assuming it's a png and not a jpeg), so OpenStream can find the file but LoadImage cannot.

Why did you use OpenStream AND LoadImage?

*maybe* OpenStream 'lock' the file under Linux for some reason?

I used OpenStream and LoadImage because that's what the FontMachine code does and I was trying to reproduce that issue. I know OpenStream doesn't lock the image because with a jpeg, that code loads the image both times.

Is it possible that my linux install is missing a library which means that not only will pngs fail to load but they'll do so silently with no compile issues? That seems highly unlikely to me but I'm sure if LoadImage just didn't work on Linux someone would've spotted it before now, right?

Brucey

(Posted 2014) [#12]

Are you using the default (the one that comes with BlitzMax) pub.libpng ?

There are more up-to-date PUB and BRL modules available here.
Note, the newer libpng libraries are better at checking for correctly formatted files, colour profiles, etc.

dawlane

(Posted 2014) [#13]

Try executing that test code via a command line terminal. If you are lucky you may get some information from libpng complaining.

dan_upright

(Posted 2014) [#14]

Are you using the default (the one that comes with BlitzMax) pub.libpng ?

That was it mate, I'd downloaded from your github on windows but not on linux, works fine now. Cheers.

dan_upright

(Posted 2014) [#15]

And just like that my game is running on linux. \o/

It segfaults when you quit out but whatever, at least I know cross-platform support is more than a pipe-dream.

Derron

(Posted 2014) [#16]

Segfaults: null access.

If the vanilla bmx modules fail to load your PNG: what software was used to save the png? Did you try loading that PNG with GIMP and export it again?

Think the new PNG libs will print some complaints about "ICMP profiles" which were not printed with the vanilla ones.

bye
Ron

dan_upright

(Posted 2014) [#17]

Segfaults: null access.

So basically the linux version of "Exception Access Violation"?

In any case, the segfault went away once I'd applied Skidracer's freejoy fix from this thread, so I think it was FlushJoy that was causing it. I suspect it might happen again if I was to unplug my joypads before running the game but that didn't occur to me until I'd booted back into windows so I'll have to check another time.

If the vanilla bmx modules fail to load your PNG: what software was used to save the png? Did you try loading that PNG with GIMP and export it again?

The original crash was stuff saved by FontMachine but I use GIMP for editing stuff, so most if not all of the others had been exported from there. The windows version though, not that it should matter.