12-06-2004, 06:42 AM
12-06-2004, 06:44 AM
Great news You're fast man.
12-06-2004, 08:28 AM
This code:Give this error with 0.04b:
Code:
dim i as integer
dim palBuf(0 to 255, 0 to 2) as ubyte
palBuf(i, 0) = 0
Code:
bug1.asm: Assembler messages:
bug1.asm:31: Error: expecting scale factor of 1, 2, 4, or 8: got `3'
12-06-2004, 08:33 AM
Thought GAS was smart enough to convert ESI*3 to ESI*2+ESI, my bad.. got too used to MASM/TASM.. will fix asap..
12-06-2004, 09:20 AM
I found what looks like some nasty corruption of string variables. I'm working on translating an old text adventure I wrote into English but first I wanted to make it run in FB.
Almost no changes, and it got compiled. Everything looked fine, but when I played a few turns it began to act strange.
There is a SUB that is passed a string with the room ID (i.e. "TOWN"). It opens the locations file, and looks for the ID inside. The first time I run the game it works fine, i.e. it finds the line and reads upon it.
The code is as simple as:
When I exit that room and enter again, the line is not found. It only happens with some rooms, not with every one.
I changed the code. Coded a simple comparator:
Still fails. I added prints to see what's happenning (great way of debugging, isn't it? ) and the first time it works great. It receives "TOWN" and "TOWN" and returns -1 (true). The second time it is called with "TOWN" and "TOWN" it reports that the first string is 25 characters long instead of 4, so it fails and returns 0. Extremely odd, taking in acount that I used RTRIM$ and LTRIM$ inside the function and before calling it.
This line:
Outputs:
I can't be more helpful. I could post the code, but it's a big project and in Spainsh... a pain to check. But if you like...
Almost no changes, and it got compiled. Everything looked fine, but when I played a few turns it began to act strange.
There is a SUB that is passed a string with the room ID (i.e. "TOWN"). It opens the locations file, and looks for the ID inside. The first time I run the game it works fine, i.e. it finds the line and reads upon it.
The code is as simple as:
Code:
DO
LINE INPUT #f%, nLine$
IF nLine$ = ":" + roomID$ THEN
found% = -1
END IF
LOOP WHILE NOT EOF(#f%) AND NOT found%
When I exit that room and enter again, the line is not found. It only happens with some rooms, not with every one.
I changed the code. Coded a simple comparator:
Code:
Function compare%(in1$, in2$)
in1$ = ucase$(ltrim$(rtrim$(in1$)))
in2$ = ucase$(ltrim$(rtrim$(in2$)))
if len(in1$)<>len(in2$) then
compare% = 0
exit Function
end if
for it% = 1 to Len(in1$)
md1$ = mid$(in1$, it%, 1)
md2$ = mid$(in2$, it%, 1)
if md1$ <> md2$ then
compare% = 0
exit Function
end if
next it%
compare% = -1
End Function
Still fails. I added prints to see what's happenning (great way of debugging, isn't it? ) and the first time it works great. It receives "TOWN" and "TOWN" and returns -1 (true). The second time it is called with "TOWN" and "TOWN" it reports that the first string is 25 characters long instead of 4, so it fails and returns 0. Extremely odd, taking in acount that I used RTRIM$ and LTRIM$ inside the function and before calling it.
This line:
Code:
PRINT in1$;"|";LEN(in1$)
Outputs:
Code:
TOWN| 25
I can't be more helpful. I could post the code, but it's a big project and in Spainsh... a pain to check. But if you like...
12-06-2004, 09:32 AM
Code:
Type BITMAPHEADER
bfType As Short
bfSize As Integer
bfReserved As Integer
bfOffBits As Integer
biSize As Integer
biWidth As Integer
biHeight As Integer
biPlanes As Short
biBitCount As Short
biCompression As Integer
biSizeImage As Integer
biXPelsPerMeter As Integer
biYPelsPerMeter As Integer
biClrUsed As Integer
biClrImportant As Integer
End Type
Btw, I'm using the very latest version, the one you just released.
12-06-2004, 09:39 AM
This is nit-picking(but then, it's programming, so I suppose...), but the STR$ function should have a space before the number.
FB: "0"+str$(1)+"0" = "010"
QB: "0" + str$(1) + "0" = "0 10"
FB: "0"+str$(1)+"0" = "010"
QB: "0" + str$(1) + "0" = "0 10"
12-06-2004, 09:43 AM
Hmmm
Found something.
I'm using a fixed length string to see what's happenning:
The first time the function is called, it shows it good. T, O, W, N, and then 36 null chars.
The next time it is called for "TOWN", I am getting T, O, W, N, a null char, and then other chars, that are exactly ' ', 'S', 'U', 'R', ' ', 'D', 'E', 'L', ' ', 'C', 'A', 'M', 'I', 'N', 'O', ' ', 'S', 'E', 'C', 'O'... Filling until precisely char #25, then null chars again.
The variable that's passed to the function was given "TOWN", it worked, then it was given "PARTE SUR DEL CAMINO SECO", it worked, and then it was given "TOWN" again, and I got what I showed.
See what I mean? (# is the null char)
All are variable-length strings.
I've patched my program to have it working. This does the trick:
Found something.
I'm using a fixed length string to see what's happenning:
Code:
Function compare%(in1$, in2$)
Dim FixLength as string * 40
FixLength = in2$
for i%=1 to len(fixlength)
print mid$(fixlength,i%,1);"->";asc(mid$(fixlength,i%,1));"|";
next i%
... etc
The first time the function is called, it shows it good. T, O, W, N, and then 36 null chars.
The next time it is called for "TOWN", I am getting T, O, W, N, a null char, and then other chars, that are exactly ' ', 'S', 'U', 'R', ' ', 'D', 'E', 'L', ' ', 'C', 'A', 'M', 'I', 'N', 'O', ' ', 'S', 'E', 'C', 'O'... Filling until precisely char #25, then null chars again.
The variable that's passed to the function was given "TOWN", it worked, then it was given "PARTE SUR DEL CAMINO SECO", it worked, and then it was given "TOWN" again, and I got what I showed.
See what I mean? (# is the null char)
Code:
TOWN#
PARTE SUR DEL CAMINO SECO#
TOWN# SUR DEL CAMINO SECO#
All are variable-length strings.
I've patched my program to have it working. This does the trick:
Code:
DIM fixBug AS STRING * 80
fixBug = varLengthStringThatFail$
varLengthStringThatFail$ = fixBug
12-06-2004, 10:07 AM
Okay...I found a way around the error I was getting. It appears to be an error in the Type (the first entry seems to believe it's an Integer rather than a Short for some reason!). If an Integer is first in a Type, it looks like it works fine, but a Short as first in a Type and it looks like it throws a tantrum. Then again, as I'm off to bed now, I'm unable to test this theory. Can anyone confirm this potential bug?
12-06-2004, 10:15 AM
Nek: all UDT elements are aligned and the UDT size is rounded to multiple of len( integer ) - all 32-bit C compilers do the same by default.
To turn that off, use:
Type BITMAPHEADER Field=1
...
End Type
No alignament or padding will be done then.
Zero: Yeah, i know it, it's on purpose, i always hated to use ltrim$( str$( value ) ), but then its just me..
Nathan: I will check it tomorrow, i think it's not the string comparator, i tested it using some old sorting algos made for qb and results were the same, it could be the data read from file, i could have missed some detail from LINE INPUT or something - that test with fixed len is okay, LEN used on a fixed-len will return it's full size, as in QB, but FB does not pad the fixlen string with spaces, but puts a null-term on it (RTRIM$ checks for the null too, besides the spaces).
To turn that off, use:
Type BITMAPHEADER Field=1
...
End Type
No alignament or padding will be done then.
Zero: Yeah, i know it, it's on purpose, i always hated to use ltrim$( str$( value ) ), but then its just me..
Nathan: I will check it tomorrow, i think it's not the string comparator, i tested it using some old sorting algos made for qb and results were the same, it could be the data read from file, i could have missed some detail from LINE INPUT or something - that test with fixed len is okay, LEN used on a fixed-len will return it's full size, as in QB, but FB does not pad the fixlen string with spaces, but puts a null-term on it (RTRIM$ checks for the null too, besides the spaces).