|
Post by Walt Decker on Jul 20, 2023 18:11:01 GMT -5
While trying to get OpenGL textures working in LB I ran into the subject errors. I have never encountered those. It might be a quirk in my system, but I think not. I can work around them by using strings; however, I would rather not; it adds additional overhead to the OpenGL wrapper functions.
The errors occur in function FN.RenderScene() when trying to give struct elements values. The position of the errors and type of error produced is commented.
The attached zip contains: LBOGL 0.DLL DRAW.BMP ARROWKEY.BMP LSN8_TEXTURE_000._BAS
|
|
|
Post by Rod on Jul 21, 2023 10:03:52 GMT -5
Not my area of knowledge. However 6.0 creates a float and you need a double. Also float underflow is normally associated with a number becoming too small to hold as a float but not in this case. See if Brent casts any light. www.b6sw.com/forum/content.php?mode=hints&t=223
|
|
|
Post by Walt Decker on Jul 21, 2023 11:14:20 GMT -5
Thank you, Rod. In all my programming in other languages I have never run across a float underflow problem although I have run across a protection violation when the app/dll reads an address that is out of bounds. Why attempting to set a struct element would produce a protection violation I have no clue.
|
|
|
Post by tsh73 on Jul 21, 2023 15:39:14 GMT -5
I don't have any idea what's going on but it looks like
tL.Lz.struct = 6 dies
tL.Lz.struct = 6.0 dies
tL.Lz.struct = 6 + 1e-20 works OK
|
|
|
Post by Walt Decker on Jul 21, 2023 18:38:39 GMT -5
I think I have solved the float underflow problem. Although Brent's methods produce a double they do not force a double. VAL(USING()) seems to do the trick without using Brent's methods.
I have run into another problem. LB appears to not be consistent when passing pointers to the bmp bit string. In some instances it passes the pointer without error, in other cases it seems to be truncating the string, sometimes by several thousand bytes. I do not know whether it is an LB thing or a windoz thing. Regardless, I have to come up with a different method.
As for the protection violation, I think that is related to the underflow problem. Have to do more testing to determine the cause.
Thank you Anatoly. Your investigation is very helpful.
|
|
|
Post by Brandon Parker on Jul 21, 2023 21:28:42 GMT -5
Walt, This is exactly the issue with the Double type in LB's Struct and LB's ability to recast numeric values on to fly that I mentioned recently. Here is a link to a previous post of mine... libertybasiccom.proboards.com/post/16488/threadI do believe that was a good discussion regarding the float underflow on the previous Conforum forum, so if someone who has the archive could search it, they might be able to dig it up for us. {:0) Brandon Parker
|
|
|
Post by Walt Decker on Jul 22, 2023 17:34:06 GMT -5
I think I have found the protection violation problem. It appears to stem from LB's inability to properly cast real numbers and the error should be float underflow. I think LB actually uses variants instead of integers and reals. The reason is the variable "Lx" cannot be an integer at one time and a real(double precision number) at some other time, but (because of its size) a variant can. This does not explain why VAL(USING()) works in one place and not another.
If you have the test app, add this function at the end: ' FUNCTION FN.MakeDouble(Value)
Lft$ = "" Rgt$ = "" Tpl$ = "" ValStr$ = ""
DotPos = 0 'NewVal = 0.000000000000000
NewVal = Value ValStr$ = STR$(NewVal)
DotPos = INSTR(ValStr$, ".")
ValStr$ = STR$(NewVal)
IF DotPos = 0 THEN ' NewVal = NewVal + .00000002 Lft$ = " " + ValStr$ Rgt$ = SPACE$(20) Tpl$ = SPACE$(LEN(Lft$)) + "." + SPACE$(LEN(Rgt$)) Tpl$ = REPLSTR$(Tpl$, " ", "#") NewVal = VAL(USING(Tpl$, NewVal)) FN.MakeDouble = NewVal PRINT Tpl$ END IF
Lft$ = " " + MID$(ValStr$, DotPos - 1) Rgt$ = MID$(ValStr$, DotPos + 1) Tpl$ = SPACE$(LEN(Lft$)) + "." Tpl$ = Tpl$ + SPACE$(20 - LEN(Rgt$)) Tpl$ = REPLSTR$(Tpl$, " ", "#") PRINT Tpl$ NewVal = VAL(USING(Tpl$, NewVal))
FN.MakeDouble = NewVal END FUNCTION '
Somewhere after the defiition of STRUCT tL add:
Lz = FN.MakeDouble(6) PRINT Lz tL.Lz.struct = FN.MakeDouble(6) Save the source code then run it.
The app will crash with a protection violation error.
Comment out tL.Lz.struct = FN.MakeDouble().
In function FN.RenderScene() after:
ColorBits = GL.DEPTH.BUFFER.BIT OR GL.COLOR.BUFFER.BIT OR GL.ACCUM.BUFFER.BIT OR _ GL.STENCIL.BUFFER.BIT
add:
Lz = FN.MakeDouble(6)
You will get the float underflow exception.
If you use 6.0 for the function argument you will get the float underflow exception when the function is called.
Mr. Parker, your functions also fail in function FN.RenderScene().
At this point I have no idea how to fix it.
|
|
|
Post by Brandon Parker on Jul 23, 2023 0:45:49 GMT -5
Is there a reason why you are not forcing tL.Py.struct just as you are tL.Lz.struct?
Honestly, I have not studied the example to know exactly what you are trying to do nor have a done anything with OpenGL, but if I force tL.Py.struct to be 1.0 instead of 1, the program at least does not incur a protection violation nor float underflow.
{:0)
Brandon Parker
|
|
|
Post by Walt Decker on Jul 25, 2023 10:04:00 GMT -5
There is no reason to force it. Receiving the protection fault and later the underflow fault stops the application. OpenGL does not use structures for messages to it so a structure used in a wrapper function is just a convenience. Rather than use a structure I have moved to using individual floats.
|
|