Another question for lillo (about PUT)

[Hordeking]

Ok, more fun for you. It might just be me being totally silly, though.

Ok, I'm doing something a little arcane. I'm trying to BLOAD data from the file into an array. This works ok, except I have to be tricky by having to declare the array to be unsigned short and and manually hack the first two elements in order to have PUT properly display the image. Ok. That works.

Now, when I try to be clever and create a type, such as

Code:

TYPE FB_IMAGE
  height AS SHORT
  width AS SHORT
  imageData(64000) AS BYTE
END TYPE

FB makes it most of the way through the program, which essentially only declares a variable of type FB_IMAGE, BLOADS it into FB_IMAGE.imageData(0), sets width and height properly, and then tries to PUT it somewhere. I'll list the code at the end of this message.

The problem occurs with PUT. When I try to PUT the image, PUT complains about not being given an identifier. Except I am giving it an identifier. I essentially give it PUT (x,y), @FB_IMAGE. Since this should technically be a pointer to some data, hopefully in the format PUT expects, should that cause it any problems? Does it matter that LEN(FB_IMAGE) = 64005 rather than the expected 64004?

Code:

SCREEN 13, 8, 1, 1
CLS

TYPE FB_IMAGE field = 1
  width as USHORT
  height as USHORT
  imageData(64000) as BYTE
END TYPE

DIM testimg AS FB_IMAGE

BLOAD "image.raw", @testimg.imageData(0)     ''Load a full screen image

testimg.width = 320*8     ''Image is 320 pixels wide at 8bpp
testimg.height  = 200     ''Image is 200 pixels tall

PUT (50,100), @testimg     ''PUT really seems to hate anything besides regular arrays.

Actually, it completely hates anything besides a regular array, I tried arguments like testimg.imageData (passing the name of the array itself), testimg.imageData(0) (The array name more or less the way it likes), testimg (without the at-sign, maybe it would have taken that, I thought). None of them worked. Maybe you've got some ideas.

[na_th_an]

This won't solve stuff, but I think you should use (63999) instead of (64000), as arrays in BASIC go from 0 to Ubound.

Also, when I use PUT I always pass an index number, i.e. PUT (x, y), sprite(0). I don't know what's "sprite(0)" internally for fB, but I guess it is just a variable and PUT get's its address, so you better pass the variable instead of that pointer.

You could always DIM testImg(0) AS FB_IMAGE and use testImg(0) in GET and PUT.

[Hordeking]

So when I declare an array, I shouldn't do like in C (total number of elements)? I don't want to call it inconsistent, but I kind of expected it to do that, especially when array indexing starts at 0. Either way, that's a little off topic, but at the same time, it does solve my problem of the extra byte. Thanks for pointing out that part of it. I would have been using index 0-63999 and wondering why there's an extra byte.

[na_th_an]

In BASIC, the numbers specified in the declarations are the lower and upper bounds. The original form of DIM Is:

Code:

DIM a (lBound TO uBound)

So DIM a(7 TO 10) will define a 4 elements array: with indexes 7, 8, 9 and 10.

The form:

Code:

DIM a (number)

Is in fact a (uBound), assuming that lBound is 0. So to define a 4 elements array this way you'd have to

Code:

DIM a(3)

Which will create an array with 4 elements with indexes 0, 1, 2, and 3.

In C it is different, as you declare telling the number of elements, unlike in BASIC where you tell the uBound.

Code:

int arrayInC[20];      // This means that the array has 20 elements.

DIM arrayInBASIC(19)    ' This means that 19 is the upper bound, and 0 (implicit) the lower.

[Hordeking]

Figures I'd get stung by that. Took me awhile to pick up the C way of doing it too, for the opposite reason (before college, I used Basic, and I was always confused in C if I used the ubound or the element count. I did realise the C array started at 0). Perhaps Victor could add an OPTION BASE directive or metacommand of some sort, to allow modification of the behavior.

Anyway, I think the array part of the question got sufficient treatment.
Maybe Angelo can answer the question about PUT without worrying about that part now. :rotfl:

[lillo]

Yep, in theory your trick should work, but as of now, the compiler only accepts regular arrays as sprite data... You don't have to specify the array index (that was required in FB < 0.11, but it's optional now), but the variable must be a standard array. I should really change it to accept ANY PTR too, and your example would work...

[Hordeking]

Looks like I've created a nice little test example then.

Exactly where is the behavior controlled, anyway? In the compiler code, or in the external library where the code for PUT is?

I'd attempt to contribute more, except I was a relative latecomer to this project and by no means whatsoever an insider. Also, I have no clue how to go about reading the code (some of it actually looks like input to a lexical analyser) This isn't really though ignorance of basic as much as it's hard to read other people's code, at least for me.

[lillo]

The behaviour is defined in the compiler code, module parser7.bas, function cGfxPut. Yes it's hard to study the code of a big existing project like fbc... By myself I still don't know most of the internals; I mainly know rtlib and obviously gfxlib since I wrote it.