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
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.
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
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 checked again.The code I linked is full code and work in 14.497
Ciao
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.
Thanks Ian
Some others want to compile with 15.xxx?
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)
TYPE TSprite
dummy%
INLINE
namespace libSPRITE {
I did not understand why but this workaround works.
Thank you
Ciao
Unother problem always with FLAG_SPRITE.
When enable debugging and setting a breakpont the programm stops with "insufficient memory".
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
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
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?
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
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..
Fixed in next update.