You are not logged in or registered. Please login or register to use the full functionality of this board...
SIGN IN Join Our Community For FREE

09-20-2017, 05:56 PM
Post: #1
 (Print Post)
Hey Walter,

Have you had anyone reporting a potential problem with '_putimage()'?

I am suspecting that it's 'putimage'... but I could be wrong...

Reason I haven't made mention before, because most of the examples that most users share, are created using primitive graphics commands. I tried using png files yesterday (20 Sept) and figured I must have either typed an incorrect handle or file name...

I am trying to use png sprites but always get an 'in valid handle' error. I even cut-n-paste the command directly from the 'help' and it still fails. I've tried many types of files; Used variations of upper/lower case filenames. I even used the same sprites in other editors and they all display just fine.

I suspect the issue may not be the filename or file type, but an issue with a combination of putimage and Linux (or Linux and 64bit)

Just curious.


May your journey be free of incident.

Live long and prosper.
Find all posts by this user
Like Post
09-21-2017, 06:02 PM
Post: #2
 (Print Post)
RE: putimage()

I have not heard of anyone having issues with the _PUTIMAGE statement.

Many of my demos on this forum uses the _PUTIMAGE statement, and they run fine for me. I also use *.PNG images most of the time, which I prefer most of the time, especially when transparency is involved.

Here are some demos that use these two features:

Bad TV Reception with Rolling:

Spinning RGB Sub-Pixel Color Wheel:

Background Shifting in a Circle Motion:

If you haven't figured out the issue, and you would like some help without having to post it on the forum, please feel free to PM it to me.

My goal is to bring joy, excitement, fun and education to all computer programming hobbyists, tinkerers, and amateurs. I also enjoy helping and working with those who aspire at becoming masters of their craft.
Find all posts by this user
Like Post
09-21-2017, 08:35 PM
Post: #3
 (Print Post)
RE: putimage()
The 'shifting background' ran without issue.

The 'TV Reception' returned 'unhandled error #258' in line 117.

The 'Colour Wheel' returned 'unhandled error #258' in line 138

My conclusion: All 3 used _putimage() but the only one that worked was the one that did not use png's. So therefore: _putimage() seems to work but not when using files. (on Linux - I cannot test for windows)


May your journey be free of incident.

Live long and prosper.
Find all posts by this user
Like Post
09-22-2017, 06:58 AM (This post was last modified: 09-22-2017 07:17 AM by SMcNeill.)
Post: #4
 (Print Post)
RE: putimage()
_PUTIMAGE doesn't care about file types at all.  BMP, PNG, GIF -- it doesn't know or track any of that information for us.  All _PUTIMAGE does is copy information from one image and puts it somewhere else.  

_LOADIMAGE may be failing for you, for some odd reason, which is what the "invalid handle" message is telling you, but it's not an issue with _PUTIMAGE itself.

For a very simple test, try the following:

image& = _LOADIMAGE("yourimage.PNG",32)
_DELAY .2 'Allow initial screen time to display
SCREEN image& 'swap over to the image screen -- if it loaded at all into memory!

If your image fails to swap over to the visible screen, the issue is in the _LOADIMAGE routine and not the _PUTIMAGE command.

Several things can make _LOADIMAGE fail to work properly with PNG files...

First issue I can think of off the top of my head is a glitch in the CRC check routine which plagued some of the older versions of QB64-GL.  Grab the latest version from the repo, extract and install it, and see if that corrects the issue.  I remember pushing a fix which cleared up that issue for us, but I can't tell you exactly when that was now.  If the version of QB64 you are using is older than that patch, it's probably the reason why the PNG files are failing to work properly for you.

Second issue may be screen mode or image color format.  _LOADIMAGE doesn't work AT ALL with 256 color images, currently.  I keep meaning to go in and work on that for us, but there's always so much other stuff to do in life that I just haven't gotten around to it, and apparently neither has any of the other people who help develop the language.  _LOADIMAGE, as it exists currently, automatically changes all images to 32-bit files, which makes them fail to work properly in 256 color screens.  The only fix currently is to swap your program over to 32-bit images or else to decode the PNG format and import it yourself manually.  

If the problem isn't one of those two issues, I'll be rather surprised.  _PUTIMAGE has been tested extensively on Linux, Windows, and Mac and hasn't had any issues since I went in and patched the STEP routines for it several months back.  (They weren't working either, so a command like _PUTIMAGE (x,y)-STEP(100,100) would always fail -- but that's also been patched and corrected in the newest versions of QB64.)

Try a fresh download from the repository and see if the issue still persists for you and let us know how things turn out. I hope that's all it'll take to correct the issue for you, and if not, I'll take time and dig back into the internals once again and make certain that one of the latest patches hasn't broken something unintentionally.  We're careful to test changes before we push things live into the repo, but glitches happen sometimes and I'll be the first to admit to that.  (Heck, I even broke the whole QB64 dirty build system itself for a few weeks last year when I swapped out the config file system for us, so I definitely know we're not beyond the point of breaking one thing while working on another...)

EDIT:  Just caught up to my emails and push notifications... Felippe pushed a patch into the repo yesterday which should allow us to start using _LOADIMAGE with 256 color images once again.  Just another reason to grab a copy of the latest build and test it out -- it should correct both issues (the CRC/Addler check issue for PNG files and now also the 256 color image issue) and might very well take care of whatever glitch you're experiencing.  If not, let us know and we'll do some further testing and see what the problem might be on Linux systems with regards to PNG format files. Wink
Find all posts by this user
Like Post
09-22-2017, 09:13 AM (This post was last modified: 09-22-2017 09:31 AM by johnno56.)
Post: #5
 (Print Post)
RE: putimage()
Ran the test program and it failed with an 'invalid handle'. I do not use 256 sprites, only 32bit.

The qb64 version I am using is not current. I don't know it's version number but I installed it in April of this year. I have downloaded the current version and the latest repository version. Neither will install. Error message "bash: ./ /bin/bash^M: bad interpreter: No such file or directory" Neither installation attempt were as 'root'. As the 'setup' does not require a parameter, I would have to assume, that the script is trying to access/download information that does not exist. I am sorry for 'opening this can of worms'. Something told me I should have stayed in bed this morning... lol (just out of curiosity, I'll try to run the Windows version via Wine - if qb64 runs then it should tell me if it is a qb64 problem or a Linux problem... maybe...)


ps: Just downloaded and ran the Windows version and it too returned the same error when running the same test program. 'Invalid handle'. Just to add further confusion, I just ran the open_gl sample - it too uses loadimage and putimage, and it ran flawlessly (Windows version) as did also the "April" Linux version - I'm so confused - my brain hurts.

May your journey be free of incident.

Live long and prosper.
Find all posts by this user
Like Post
09-22-2017, 12:03 PM
Post: #6
 (Print Post)
RE: putimage()
If you downloaded from Galleon's site, the Linux line endings are messed up.  We've reported the issue to him several times already, but he still hasn't gotten around to fixing it.  All you should need to do to fix the issue is to run the following command from the same folder with the qb64 install scripts:

Code Snippet: [Select]
find . -name '*.sh' -exec sed -i "s/\r//g" {} \;

After that, the setup should work as intended for you with:

Code Snippet: [Select]

A few quick questions with the issue you're seeing:  Are you certain the image files are in the correct directory?  And do you have read/write access to that directory?

Most of the time, programs are written so that they're in the same directory that QB64.exe is in, and archives like Walt's image rolling demo which extract to their own subfolder won't work until you either change the paths or move the files to the proper folder.  This might also be the source of your issues, so double check to make certain that everything is where it's supposed to be.  From what you say, it sounds as if it's really a case of the file not being found and loading at all, instead of an issue with _PUTIMAGE.  Give me a little time and I'll work up a nice test program for you and we might be able to narrow down what the root problem is a bit better.  Smile
Find all posts by this user
Like Post
09-22-2017, 07:19 PM
Post: #7
 (Print Post)
RE: putimage()
In regards to installation: The command worked like a treat and the "setup" ran and installed qb64 as designed. Many thanks for that... Much appreciated.

Directories: I have tried running the test program with the sprites in the same directory as the ".bas" file and also using the proper 'path' as well. I am fairly certain that the folder and files concerned have the appropriate permissions. The permissions are ok. I then deliberately modified the folder and files to "create, delete and access" (folder and files) for all users and re-ran the test with the same results as before... *sigh*

It still puzzles me that a simple test program will not work but the qb64 sample program does. Both contain the same commands. The only difference that I did notice is that the sample program used a "jpg" image. I will modify the test program to incorporate a jpg instead of a png... fingers crossed... Nope. jpg didn't work either... my brain hurts again... low caffeine levels!!!


May your journey be free of incident.

Live long and prosper.
Find all posts by this user
Like Post

Forum Jump:

User(s) browsing this thread: 1 Guest(s)

QB64 Member Project - Score 4
QB64 Member Project - Red Scrolling LED Sign
QB64 Member Project - Full Color LED Sign
QB64 Member Project - Spiro Roses
QB64 Member Project - Pivet version one
QB64 Member Project - Rubix's Magic
QB64 Member Project - 9 Board
QB64 Member Project - MAPTRIANGLE
QB64 Member Project - Martin Fractals version two
QB64 Member Project - Dakapo
QB64 Member Project - STxAxTIC 3D World
QB64 Member Project - Blokus
QB64 Member Project - Isolation
QB64 Member Project - Foursight
QB64 Member Project - Othello
QB64 Member Project - Qubic
QB64 Member Project - Overboard
QB64 Member Project - Domain
QB64 Member Project - Splatter
QB64 Member Project - Color Triangles
QB64 Member Project - Kobolts Monopoly
QB64 Member Project - Kings Valley verion one
QB64 Member Project - Kings Vallery version two
QB64 Member Project - Martin Fractals version three
QB64 Member Project - Line Thickness
QB64 Member Project - Input
QB64 Member Project - Color Rotating Text
QB64 Member Project - Pivot version two
QB64 Member Project - Swirl
QB64 Member Project - Spinning Color Wheel
QB64 Member Project - OpenGL Triangles
QB64 Member Project - Basic Dithering
QB64 Member Project - ARB Checkers
QB64 Member Project - RGB Color Wheel
QB64 Member Project - Kings Court
QB64 Member Project - Connect Four
QB64 Member Project - Inside Moves
QB64 Member Project - Touche
QB64 Member Project - Dreamy Clock
QB64 Member Project - Exit
QB64 Member Project - Sabotage
QB64 Member Project - Quarto
QB64 Member Project - Bowditch curve
QB64 Member Project - Martin Fractals version one
QB64 Member Project - Amazon
QB64 Member Project - Martin Fractals version four
QB64 Member Project - Algeria Weather
QB64 Member Project - Rotating Background
QB64 Member Project - Point Blank