Probably not a bug, but at least a difference that really should be documented: QB's RND ranges from zero to
almost, but never quite one. FB's RND actually returns 1 sometimes.
I was passing int(rnd*256) for an 8 bit color value to a function that doesn't check for >255.
Btw, I like FB's STR$ the way it is
Quote:Btw, I like FB's STR$ the way it is
Me too!
Quote:Dark prevail... try SAL and SAR insead, if rel's not trying to mislead me *GLARE*
No. You should use SHL/SHR in FB. It's the compiler which would convert it to SAL/SAR. Sorry if you misunderstood me. :*)
Ran into another interesting problem. I made a Type of Ubytes to read palette information. Four Ubytes in a row. Should have worked fine.
Well, using the Type made the program hard-crash. So, I said "okay, screw it, I'll use four arrays instead". Same result. When I simply used an Integer to read the values (the four bytes of a palette index in a BMP file), no problems...got the routine to work. The problem is...is there something wrong with Ubyte? It seems to work fine by itself, but arrays of Ubytes seem to cause trouble.
Oh...and something I discovered last night in my tinkering...
Code:
Do: Loop Until Inkey$ <> ""
causes the application to "lock up". Not really a bug or anything, just an interesting little quirk.
Quote:Do: Loop Until Inkey$ <> ""
What OS? Worked fine for me in XP, for console apps, course, windowed will not receive any input from stdin.
Quote:Ran into another interesting problem. I made a Type of Ubytes to read palette information. Four Ubytes in a row. Should have worked fine. Well, using the Type made the program hard-crash
W/o seem the code to try reproducing the error.. or else those bugs will be "unknown" until someone else runs in the same problem ;) If you had fpoint operations on expressions and byte var storing the result, see below.
Quote:pix2 = palByte And 15
pix1 = (palByte - pix2) / 16
Are pix2 and pix1 both byte vars too? That's something i didn't document - nor the error is shown as it happens at EMIT, you can't store a fpoint expression into a byte result, that's a x86 limitation and i was too slack to add a work-around for that, will do as it will (probably) used a lot ( / will do fpoint division, try \ instead).
Quote:QB's RND ranges from zero to almost, but never quite one
Didn't know that, i always used res = cint(rnd * maxres-1), that's why.. simple to fix tho. QB help says "between 0 and 1", it returns 0's, but never 1's, that's nice..
When compiled for the GUI, I've found that at least on my system, a TinyPTC app will work with inkey$. Weird.
Anyways...ran into another problem. Still in porting my TinyPTC extension library, I ran into this issue with arrays...I pass a non-zero index of an array to a function, and fbc crashes. Flat-out. Here's an example:
Code:
Sub PTC_Get(startX As Integer, startY As Integer, destX As Integer, destY As Integer, buffer() As Integer)
'this is the declaration for the routine I'm calling
... code ...
'now here's where I call it:
PTC_Get whereX, whereY, whereX + 7, whereY + 7, fontbuffer(charCounter * FONT_OFFSET)
This makes the compiler hard-crash. I've made FONT_OFFSET as both a const (this is what it was originally) and a variable. Is it a problem in the function argument, or is it a bug?
The full source can be found here:
http://www.lostsocksoftware.com/ptcstuff.bas
The problem is here PTC_TPut whereX, whereY,fontbuffer(newOffset), transcol
It's declared as Sub PTC_TPut (x As Integer, y As Integer, buffer() As Integer, transcolor As Integer)
This seems to be a general problem, if you don't pass an array descriptor where it expects it crashes. Symbol table problem?
0 < RND < 1
Tested it.. in QB that is..
DATE$ insists that it's 2001...
Also, is MM-DD-YY the locked way of having it?, So we don't have to worry about someone having DD-MM-YY etc...
Fixed, it now prints 12-06-2004 here (year was - 1900, damn libc localtime() function).
RND is fixed too, no more 1's, they are baaad.
Nek: inkey$ works with TPTC coz i hacked it, WM_KEYDOWN is being remapped to console input, so inkey$ won't lock - TPTC out-of-box will close the window when ESC is pressed too.
About the prototype, you should pass the descriptor to the array, not the element itself, i will add a check for that.. try that code with QB and it will complain with "parameter type mismatch" at the array, it has to be fontbuffer() only, with no indexes.