FPNG (from PHGTK) and QLiberator

[Sebright]

Hi,

I'm having some problems compiling a program with QLiberator that uses the PHGTK graphics extensions.

The idea is to convert .png images as required, saving temporarily as "pic" format to ram1_, then loading back in. I know I could pre-convert them, but I would need to do it for Modes 16, 32 and 33, and with lots of images, it gets a bit out of hand.

It all works fine in SuperBASIC, but when compiled with QLiberator, it stops with:

Q_LIB error 19 Indices wrong

The line giving the problem is:

3245 e%=FPNG(x$,"ram1_test_pic",scrMode%)

Anyone found this before. I just assumed it would work, but am I missing something?

Cheers,
Alan

[dilwyn]

I've used PHGTK a lot since it was released, and not noticed this issue with compiling programs using it.

(For anyone who doesn't know of PHGTK, it's the Photon General Toolkit, a set of graphics extensions for converting GIF, PNG and JPG files)

So I've just made a little test program which I compiled with QLiberator v3.46 on QPC2 v5.02 running in high colour mode 32 (also tried converting to mode 16 and 33 while running in mode 32. I shoved several PNG test files through it and it seemed to compile and run OK, albeit with PHGTK resident, not linked into the generated _obj file.

I was using PHGTK 1.00. From memory, the main difference between that and 1.10 was the addition of FPIC_CONTRAST extension.

Here was my test program:

Code: Select all

100 CLS : CLS #0
110 x$ = 'ram1_test_png'
120 scrMode% = 32
130 e% = FPNG(x$,'ram1_test_pic',scrMode%)
140 PRINT 'e%=';e%
150 INPUT'Conversion finished. Press ENTER > ';x$

I'm assuming you're aware that PHGTK won't convert to QL mode 4 or 8 - that would just give a -15 Bad Parameter error (which isn't listed under the possible error codes for the FPNG extension in the manual I have). A workaround for this is to convert the PNG to JPG in Windows then use Photon itself to convert to mode 4 or 8.

I know from experience it doesn't handle all PNG files, especially interlaced ones, but for the unsupported types it gives a -19 Not Implemented.

May help do further tests if you can give an idea of what platforms and software versions and display modes you are using, to help us recreate the error?

I don't know if David (Sylvester) who wrote PHGTK is still on this forum.

[Sebright]

I've used PHGTK a lot since it was released, and not noticed this issue with compiling programs using it.

(For anyone who doesn't know of PHGTK, it's the Photon General Toolkit, a set of graphics extensions for converting GIF, PNG and JPG files)

So I've just made a little test program which I compiled with QLiberator v3.46 on QPC2 v5.02 running in high colour mode 32 (also tried converting to mode 16 and 33 while running in mode 32. I shoved several PNG test files through it and it seemed to compile and run OK, albeit with PHGTK resident, not linked into the generated _obj file.

I was using PHGTK 1.00. From memory, the main difference between that and 1.10 was the addition of FPIC_CONTRAST extension.

Here was my test program:

Code: Select all

100 CLS : CLS #0
110 x$ = 'ram1_test_png'
120 scrMode% = 32
130 e% = FPNG(x$,'ram1_test_pic',scrMode%)
140 PRINT 'e%=';e%
150 INPUT'Conversion finished. Press ENTER > ';x$

I'm assuming you're aware that PHGTK won't convert to QL mode 4 or 8 - that would just give a -15 Bad Parameter error (which isn't listed under the possible error codes for the FPNG extension in the manual I have). A workaround for this is to convert the PNG to JPG in Windows then use Photon itself to convert to mode 4 or 8.

I know from experience it doesn't handle all PNG files, especially interlaced ones, but for the unsupported types it gives a -19 Not Implemented.

May help do further tests if you can give an idea of what platforms and software versions and display modes you are using, to help us recreate the error?

I don't know if David (Sylvester) who wrote PHGTK is still on this forum.

Thanks for your help Dilwyn,

I'll get back onto it tonight and give your test prog a try...

Cheers,
Alan

[pjw]

<>
It all works fine in SuperBASIC, but when compiled with QLiberator, it stops with:

Q_LIB error 19 Indices wrong

The line giving the problem is:

3245 e%=FPNG(x$,"ram1_test_pic",scrMode%)

Anyone found this before. I just assumed it would work, but am I missing something?
<>

As it works in SBASIC, the first thing Id try is to increase the various data spaces of the compiled program. Try:

$$heap=<whatever youve got x 2>

Since the command involves an implicit channel, Id try increasing this:

$$chan=<whatever youve got + 4>

Theres also $$stak= to try

You can always reduce later.

Good luck, and please report back!

[Sebright]

Thanks for the suggestions. I tried your code Dilwyn, and it worked as expected.

After some head scratching, I wondered whether the fact I had written and compiled the code in Q-emulator with JS ROM would mean it wouldn't run properly under SMSQ/E. So I recompiled the same code while in SMSQ/E and it worked. It worked without any issues in BASIC under SMSQ/E, so I assumed there wouldn't be a problem. I really should have done the whole lot in SMSQ/E, but the constant pressing of F12 to access the drive slots gets to be a pain. Lesson learned (though I bet I forget again a few months down the line )

Cheers,
Alan

[BSJR]

Hi,

I'm having some problems compiling a program with QLiberator that uses the PHGTK graphics extensions.
...
It all works fine in SuperBASIC, but when compiled with QLiberator, it stops with:

Q_LIB error 19 Indices wrong
The line giving the problem is:
3245 e%=FPNG(x$,"ram1_test_pic",scrMode%)

Anyone found this before. I just assumed it would work, but am I missing something?

When the FPNG code is included in the _obj you must not forget to put the name in a QLib directive:
EXT_FN "FPNG"
Omitting that can also cause this error 19 (see manual page 5.4)

BSJR

[dilwyn]

Hi,

I'm having some problems compiling a program with QLiberator that uses the PHGTK graphics extensions.
...
It all works fine in SuperBASIC, but when compiled with QLiberator, it stops with:

Q_LIB error 19 Indices wrong
The line giving the problem is:
3245 e%=FPNG(x$,"ram1_test_pic",scrMode%)

Anyone found this before. I just assumed it would work, but am I missing something?

When the FPNG code is included in the _obj you must not forget to put the name in a QLib directive:
EXT_FN "FPNG"
Omitting that can also cause this error 19 (see manual page 5.4)

BSJR

Thought that was only needed if the extensions weren't resident when you compiled the program (to prevent ambiguity)?

[Sebright]

Hi,

I'm having some problems compiling a program with QLiberator that uses the PHGTK graphics extensions.
...
It all works fine in SuperBASIC, but when compiled with QLiberator, it stops with:

Q_LIB error 19 Indices wrong
The line giving the problem is:
3245 e%=FPNG(x$,"ram1_test_pic",scrMode%)

Anyone found this before. I just assumed it would work, but am I missing something?

When the FPNG code is included in the _obj you must not forget to put the name in a QLib directive:
EXT_FN "FPNG"
Omitting that can also cause this error 19 (see manual page 5.4)

BSJR

Thanks for that, although the PHGTK extensions were loaded at the time of compiling, otherwise I would have had an error. Done that many times!

But it might be due to the fact that I complied from QDOS with a few SMSQ/E keywords in the code (SCR_BASE, SCR_LLEN and DISP_MODE). That didn't cause an error on compiling, but might have caused instability that resulted in the error I saw...???

I was just hoping that I could write a single prog that worked in both QDOS and SMSQ/E, with an appropriate check of VER$ to fence off any non-QDOS keywords.

Cheers,
Alan

[pjw]

<>
But it might be due to the fact that I complied from QDOS with a few SMSQ/E keywords in the code (SCR_BASE, SCR_LLEN and DISP_MODE). That didn't cause an error on compiling, but might have caused instability that resulted in the error I saw...???

I was just hoping that I could write a single prog that worked in both QDOS and SMSQ/E, with an appropriate check of VER$ to fence off any non-QDOS keywords.
<>

If toolkit keywords arent present when compiling they wont give an error, because they are seen as variable names. The error then occurs when your program tries to use them. As Dilwyn writes, you can use EXT_FN and EXT_PROC as placeholders instead, provided you then add the corresponding toolkits with $$asmb with your compilation.

The "missing" toolkit commands (SCR_BASE, etc) can be added using my Q2S toolkit. Details here