Posts: 922
Threads: 15
Joined: Jun 2003
Ops, a typo at rtl.bas: data "csrline", "fb_ConsoleGetY", FB.SYMBTYPE.INTEGER,FB.FUNCMODE.STDCALL, 0
"csrline" instead of "csrlin", fixed.
Posts: 6,419
Threads: 74
Joined: Mar 2002
Great news You're fast man.
Posts: 1,272
Threads: 36
Joined: Feb 2003
This code: Code: dim i as integer
dim palBuf(0 to 255, 0 to 2) as ubyte
palBuf(i, 0) = 0
Give this error with 0.04b: Code: bug1.asm: Assembler messages:
bug1.asm:31: Error: expecting scale factor of 1, 2, 4, or 8: got `3'
Posts: 922
Threads: 15
Joined: Jun 2003
Thought GAS was smart enough to convert ESI*3 to ESI*2+ESI, my bad.. got too used to MASM/TASM.. will fix asap..
Posts: 6,419
Threads: 74
Joined: Mar 2002
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:
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:
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...
Posts: 3,279
Threads: 170
Joined: Nov 2003
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
This is clearly 54 bytes long. Yet it's being returned as 56 bytes long, and the function I've written fails because something in there is getting messed up. I even tried substituting the header for a fixed length 54 byte string and then just reading the file manually and I still get no results. Is there a problem with certain kinds of variables? I'm using Ubytes to read data from the file, and of course, this header to read the header data all at once. I'm reading in a 24 bpp BMP image, so there's no palette to be worried with. Basically...the code I'm using is a direct port of the same function I used in VC.
Btw, I'm using the very latest version, the one you just released.
I'd knock on wood, but my desk is particle board.
Posts: 729
Threads: 104
Joined: Jan 2003
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"
Posts: 6,419
Threads: 74
Joined: Mar 2002
Hmmm
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
Posts: 3,279
Threads: 170
Joined: Nov 2003
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?
I'd knock on wood, but my desk is particle board.
Posts: 922
Threads: 15
Joined: Jun 2003
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).
|