Messages

As a test, I just did a comparison of a 5 Case Select and 5 IF equivalent in a 10mil pass FOR loop, both of which gave me an average of 16.5ms completion times. This could just be the way my system handles them though and testing on your target platform will be the best way to determine the route to take.

Another thing to mention is to always use the most probable match for your Cases first to least probable. This can be help reduce the amount of checks it has to do if you know a certain value will be more common then others.

Switches (Select in this case) are generally faster, though not by a lot, and it depends on the situation and compiler. It also can help with readability of your code. As a general rule, if you have a variable that may have 3 or more different potential results to deal with, a Select should be used. Also, a Select will only use the first matching case from the list and bypass any others that may also match so if that is an issue for what your trying to do, If statements would be the route to go.

Is is giving you any specific errors?

Quite right. I think I've been writing too many functions these past 7 days where I needed to manipulate the return more.

Here's a simple function to do that. You can specify any position in the string and the amount of characters to change.

string$ is the input string you wish to modify
alter$ is the text you wish to append/alter in string$
start_pos is the starting position in string$ where the change will take
end_pos is the ending position in string$ where the change will take place

Code (glbasic) Select Expand

FUNCTION string_replace$: string$,alter$,start_pos,end_pos
LOCAL out$
out$ = MID$(string$,0,start_pos) + alter$ + MID$(string$,end_pos,-1)
RETURN out$
ENDFUNCTION

Sample Usage:

Code (glbasic) Select Expand

a$ = "A dog that's big"
b$ = "cat"
print string_replace$(a$,b$,2,5),0,0

Will produce the following output:
A cat that's big

You were right on Moru. The functions that I found to appear bad do work correctly but will fail if you read more data than the file contains at it's end for the particular data type. In the app I'm currently working on I had some simple checking for the remainder bytes which I now know is faulty. It's always something obvious. XD

Interesting. I'll test that out. Reading a long though should just be four bytes irregardless of what each byte is which would lead me to believe that the function is doing something with carriage returns and line feeds that it shouldn't. 

Edit:
Well I just tried that and got the same thing. I guess in the meantime I will just use two word reads combined for a simple solution.

An update, I tested this on one of my other dev comps and got the same problem so it does not appear to be a system dependent issue.

I've been using version 6.248 of GL Basic for the longest time and didn't really need to upgrade it since it has worked fine with everything I threw at it. Well, I come to the point where I needed to do some extensive work with files and started using openfile() and it's related functions. What I found is that some of the READ functions work and some fail as in the compiled app just closes as soon as it starts. A similar close as if you referenced an array with an index that is out of it's bounds though that's just an example to maybe narrow down the issue at hand. It could just be something I'm over looking. Anyway, I decided to install the latest version 8.148 in hopes that it would be a bug that got fixed since the last version I was using but this also had the same behavior. A search brought up a few topics on the matter but they didn't bare any fruit.

Below is some sample code I wrote for this issue and it lists the commands that work and the ones that exhibit the problem. I did not test any of the WRITE commands yet though except WRITEUBYTE and it is working correctly. I mainly need to use the LONG versions of the functions. The test file I used is not included, it was only 2k containing some random text.

Code (glbasic) Select Expand

GLOBAL storage%[]; DIM storage[1]
GLOBAL storageieee
GLOBAL storage$
GLOBAL pos = 0

IF OPENFILE(1,"test.txt",1)
WHILE ENDOFFILE(1) = 0
// Not working
READLONG 1,storage[pos]
//READULONG 1,storage[pos]
//READSHORTIEEE 1,storageieee
//READIEEE 1,storageieee
//READSTR 1,storage$,4

// Working
//READBYTE 1,storage[pos]
//READUBYTE 1,storage[pos]
//READWORD 1,storage[pos]
//READUWORD 1,storage[pos]
//READLINE 1,storage$
WEND
CLOSEFILE 1
ENDIF

WHILE TRUE
PRINT "Test: " + storage[pos],0,0
PRINT "Test: " + storage$,0,10
SHOWSCREEN
WEND

Yeah, you won't find better out there, especially a product like this that the creator gives personal attention to. Also, it saves me allot of time on my random projects and it works excellent. I consider it to be the top development software purchase I have ever made.

I take that back, don't bother with the OpenGL stuff. My brain is not functioning right this morning. XD  There is a function to set the alpha value, I just don't remember it off hand atm. I'll post back when I find it.

Sure is but with some modifications. In the glReadPixels call, you will need to change GL_RGB to GL_RGBA and un-comment out the GL_RGBA define. Also, the PNG_COLOR_TYPE define needs to be changed from 2 to 2 | 4.

As far as I know, it and savesprite only saves BMP files which is why I made it but maybe there was an update I didn't notice. I needed something smaller for screenshots.

This creates screenshots in the PNG format. There would be more to say but that's all it does.

=======================
Notes
=======================
When this example starts, it allows you to take only one screen shot with the "=" key. You will find the
screenshot inside the same folder as this example binary named screenshot.png.

Please note there is NO error handling. If something screws up, especially with libpng, you will get
a program crash.

When calling the screenshot_png function, it will automatically determine your screen size. You only
have to supply a file name or a folder/directory along with file name you want to save the screenshot
as.

All required headers are included and should be placed in the same folder where your source is located.
They are:
_mingw.h | stdarg.h | stddef.h | stdint.h | stdio.h | stdlib.h | and the sys folder with types.h

=======================
Usage
=======================
screenshot_png("something/screenshot.png")

=======================
Arguments
=======================
file$ - The name and path/name for the PNG image you would like to create.

=======================
Other
=======================
Feel free to use, chop up or mangle this code for your own usage. It is supplied AS-IS and should be
used at your own risk!

I will probably add more to this such as PNG text info customizing etc and I'm always open to ideas.

[attachment deleted by admin]

LOL As always, something painfully obvious that slipped by me. Thanks for the help!