GLB 15.004 DO NOT COMPILE

Previous topic - Next topic

Qedo

I rewrite after thread problem.
GLB 15.004 DO NOT COMPILE my FLAG_SPRITE, see source at http://www.glbasic.com/forum/index.php?Topic=11002msg96884#msg96884 and also Kanonet's X_SPRITE program (http://www.glbasic.com/forum/index.php?topic=7992.msg74110#msg74110).
GLB 15.005 fails to install
Can anyone check?
Ciao

Ian Price

Kanonet's example (as linked to) doesn't compile in any version of GLB as there are TYPEs that aren't declared. And your link just links to the whole forum index, not your example. :/

Haven't tried 15.xx s can't comment on that specifically.
I came. I saw. I played.

Qedo

OK then to be precise, attached you find the X_SPRITE program that compile correctly with 14.497 and fail in 15.004. Strange what you say, it's just a problem on my computer?

Sorry for the wrong address (was missing a dot). The correct link to FLAG_SPRITE is : http://www.glbasic.com/forum/index.php?topic=11002.msg96884#msg96884
Could you verify?
Thank you.
Ciao

Ian Price

I'm guessing the bit of code you linked to isn't the full code, hence it didn't work. Nothing to do with your computer and more to do with the fact you didn't link to the actual working code.

Kanonet's code crashes v12.xx but does compile and work in 14.XX (although I'm not sure it's working properly).

So, yeah, if it's/they're not compiling in 15.xx there may well be a problem.
I came. I saw. I played.

Qedo

I checked again.The code I linked is full code and work in 14.497
Ciao

Ian Price

TheXSprite  code you linked to in your first post for Kanonet's code did not compile for me, due to missing TYPE definitions. Your last post, with the attachment DID compile in 14.XX.
I came. I saw. I played.

Qedo

Thanks Ian
Some others want to compile with 15.xxx?

dreamerman

Tooked quick look at it, and with GLB 15 it doesn't compile, it looks like new debugging options/capabilities conflicts with types made in inline, something with type constructor if I see correctly. Fast fix for the issue -> add GLB variable at start of tsprite type like this: (code.gbas)
Code (glbasic) Select
TYPE TSprite
dummy%
INLINE
namespace libSPRITE {
Check my source code editor for GLBasic - link Update: 20.04.2020

Qedo

I did not understand why but this workaround works.
Thank you
Ciao

Qedo

Unother problem always with FLAG_SPRITE.
When enable debugging and setting a breakpont the programm stops with "insufficient memory".

Qedo

Heiiii, has anyone verified?
Furthermore the version 15.004 (15.005) seems unreliable. In debugging mode, without breakpoint enabled, fps falls to unacceptable values
Ciao

Qedo

As written by Gernot in another thread, in debugging + breakpoint mode, I reduced the "max array size when debugging" to 5 and the "Out of memory" error remains. Only works if set to 2.
In debugging mode alone, fps drop from 130 (GLB 14.497) to 9 (GLB 15.004) regardless of the "max array size when debugging".
Ciao

Qedo

The debugger 15.004 don't work with array type.
With the following code:
in debugging (wrong):
     AnimationG.AnimationData[0].NameSubAnim$="" 
     AnimationG.AnimationData[1].NameSubAnim$=""
     AnimationG.AnimationData[1].TimeDraw[0]=2
     AnimationG.AnimationData[1].TimeDraw[1]=3
while must be (exact):
     AnimationG.AnimationData[0].NameSubAnim$="Animation G[0]"
     AnimationG.AnimationData[1].NameSubAnim$="Animation G[1]"
     AnimationG.AnimationData[1].TimeDraw[0]=4
     AnimationG.AnimationData[1].TimeDraw[1]=5

Any idea?

Code (glbasic) Select

TYPE TAnimationData
NameSubAnim$
TimeDraw%[2]
ENDTYPE

TYPE TAnimationList
        AnimationData[2] AS TAnimationData
FUNCTION GetAnim% : pos%,name$,par1%,par2%
self.AnimationData[pos].NameSubAnim$= name$
self.AnimationData[pos].TimeDraw[0]= par1
self.AnimationData[pos].TimeDraw[1]= par2
ENDFUNCTION

ENDTYPE

GLOBAL AnimationG AS TAnimationList

AnimationG.GetAnim(0,"Animation G[0]",2,3)
AnimationG.GetAnim(1,"Animation G[1]",4,5)

DEBUG AnimationG.AnimationData[0].NameSubAnim$+","+AnimationG.AnimationData[0].TimeDraw[0]+","+AnimationG.AnimationData[0].TimeDraw[1]+"\n"
DEBUG AnimationG.AnimationData[1].NameSubAnim$+","+AnimationG.AnimationData[1].TimeDraw[0]+","+AnimationG.AnimationData[1].TimeDraw[1]+"\n"
END



dreamerman

Yeah new debugger has some problems, but it always added some slowdowns, due that I prefer to almost always compile as release and use custom functions to show needed variables/arrays data, only when encountering serious problems I'm switching to debug mode. Debugger may be really handy to track game flow yet it has some issues at this stage.
Is your code ok? results using release and debug mode are different? That would be serious issue..
Check my source code editor for GLBasic - link Update: 20.04.2020

Kitty Hello

Fixed in next update.