Page 1 of 1

FreeBASIC problems: Using PUT for graphics.

Posted: Fri Apr 01, 2005 11:24 am
by DarkDread
Okay guys, I'm using FBIde to compile and run my program, however, for some reason, it has trouble with this command:

PUT (TileX%, TileY%), TileSet(TilePos%), PSET

It basically refuses to accept TileSet(TilePos%) as a vaild statement. It doesn't want to compile becasue of the (TilePos%) part, which, of course, is where I'm pointing PUT to the array index start point.

...

Gha, that was a lousy sentence... anyway, I hope you guys know what I mean. So, my question is, why isn't this recognized as a valid statement? ...I never had a problem using variables for the image index start position in QB, so why is it a problem in FB? ...or is it just the FBIde which causes the problem?

I guess, I'm gonna try compiling my code through a command line, and see what happens... but other than that, does anyone have an ideas why it won't let me run my code? (Note: that is the only problem... everything else checks out fine)

EDIT: Tried compiling at a command line, I still get the same problem. So, I'm stuck... anyone? Some help would be greatly appreciated.

EDIT2: Okay, I've got it figured out... looks like I forgot to declare some variables there. I'll post here again, if I have more problems, heh.

Posted: Fri Apr 01, 2005 4:46 pm
by Rattrapmax6
:D Glad you figured that out..

Fun Fact, FB's PUT can be set off screen with no errors,.. alsome! aye? :wink:

Posted: Fri Apr 01, 2005 11:39 pm
by barok_unlogged
Hey Darkdread! Glad to see you (partly) back. Good that you seemed to have fixed your problem. Yeah, i figured it was a variable problem. It's a freebasic problem, not a FBIDE. FBIDE actually will not cause any problems alone, since all the error checking is done by the compiler itself, or something like that. It's by far best that you dimmension your variables... there are several changes i noticed while porting some code...

-In qbasic, you can have array() AND also have a variable called array. However, you cannot do this with freebasic.
-make sure your subs are declared as a type of variable... initial variable is an integer, and if you try to plug a variable that is, say a single, into the sub that accepts an integer, your code will choke.

Posted: Sat Apr 02, 2005 12:01 am
by Nodtveidt
Some people used to use QB's error when using PUT offscreen for checks...I wonder if that causes any portability problems to have it now gone?

Posted: Sat Apr 02, 2005 10:00 am
by Rattrapmax6
:) Portibility probs, how do you figure that? no, what do you mean by that? :roll:

Posted: Sat Apr 02, 2005 2:46 pm
by DarkDread
Rattrapmax6 wrote::D Glad you figured that out..

Fun Fact, FB's PUT can be set off screen with no errors,.. alsome! aye? :wink:
Yep, I noticed that. Saves me the trouble of using a lib, or writing a routine to do that. :)

Posted: Sun Apr 03, 2005 3:30 am
by Nodtveidt
Rattrapmax6 wrote::) Portibility probs, how do you figure that? no, what do you mean by that? :roll:
Meaning that I've seen game code where an error trap was used to run functions when PUT was used out-of-bounds. Such games wouldn't work in FB because of the error being gone now. I can't think of any specific examples of this being done and it's quite rare to see in the first place but it's been done before...

Posted: Sun Apr 03, 2005 7:54 am
by Rattrapmax6
Well, when porting, change the err event to be tiggered from the PUT's X Y equaling the SCREEN's limt X & Ys... Thats not much of a prob is it? or am I wrong?

Posted: Sun Apr 03, 2005 10:13 am
by Mitth'raw'nuruodo
Rattra your right. There are problems but they can be advoided.

Oh and SpaceMerc uses SuperPut. Thanks again! There are no bounds to worry about in that.

Posted: Sun Apr 03, 2005 1:05 pm
by Rattrapmax6
Yeah, but SuperPut is a alful lot of code to compile.. :D

Posted: Sun Apr 03, 2005 3:47 pm
by Mitth'raw'nuruodo
I don't understand, its not THAT much. :(