BASIC

Author Topic: GLB 15.004 DO NOT COMPILE  (Read 475 times)

Offline Qedo

  • Mr. Polyvector
  • ***
  • Posts: 132
  • UNUS SED LEO
    • View Profile
GLB 15.004 DO NOT COMPILE
« on: 2017-Aug-17 »
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

Offline Ian Price

  • Administrator
  • Prof. Inline
  • *******
  • Posts: 4094
  • On the shoulders of giants.
    • View Profile
    • My Apps
Re: GLB 15.004 DO NOT COMPILE
« Reply #1 on: 2017-Aug-17 »
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.

Offline Qedo

  • Mr. Polyvector
  • ***
  • Posts: 132
  • UNUS SED LEO
    • View Profile
Re: GLB 15.004 DO NOT COMPILE
« Reply #2 on: 2017-Aug-17 »
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

Offline Ian Price

  • Administrator
  • Prof. Inline
  • *******
  • Posts: 4094
  • On the shoulders of giants.
    • View Profile
    • My Apps
Re: GLB 15.004 DO NOT COMPILE
« Reply #3 on: 2017-Aug-17 »
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.

Offline Qedo

  • Mr. Polyvector
  • ***
  • Posts: 132
  • UNUS SED LEO
    • View Profile
Re: GLB 15.004 DO NOT COMPILE
« Reply #4 on: 2017-Aug-17 »
I checked again.The code I linked is full code and work in 14.497
Ciao

Offline Ian Price

  • Administrator
  • Prof. Inline
  • *******
  • Posts: 4094
  • On the shoulders of giants.
    • View Profile
    • My Apps
Re: GLB 15.004 DO NOT COMPILE
« Reply #5 on: 2017-Aug-17 »
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.

Offline Qedo

  • Mr. Polyvector
  • ***
  • Posts: 132
  • UNUS SED LEO
    • View Profile
Re: GLB 15.004 DO NOT COMPILE
« Reply #6 on: 2017-Aug-17 »
Thanks Ian
Some others want to compile with 15.xxx?

Offline dreamerman

  • Mr. Polyvector
  • ***
  • Posts: 159
    • View Profile
    • my personal website
Re: GLB 15.004 DO NOT COMPILE
« Reply #7 on: 2017-Aug-17 »
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

Offline Qedo

  • Mr. Polyvector
  • ***
  • Posts: 132
  • UNUS SED LEO
    • View Profile
Re: GLB 15.004 DO NOT COMPILE
« Reply #8 on: 2017-Aug-17 »
I did not understand why but this workaround works.
Thank you
Ciao

Offline Qedo

  • Mr. Polyvector
  • ***
  • Posts: 132
  • UNUS SED LEO
    • View Profile
Re: GLB 15.004 DO NOT COMPILE
« Reply #9 on: 2017-Aug-17 »
Unother problem always with FLAG_SPRITE.
When enable debugging and setting a breakpont the programm stops with "insufficient memory".

Offline Qedo

  • Mr. Polyvector
  • ***
  • Posts: 132
  • UNUS SED LEO
    • View Profile
Re: GLB 15.004 DO NOT COMPILE
« Reply #10 on: 2017-Aug-20 »
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

Offline Qedo

  • Mr. Polyvector
  • ***
  • Posts: 132
  • UNUS SED LEO
    • View Profile
Re: GLB 15.004 DO NOT COMPILE
« Reply #11 on: 2017-Aug-21 »
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

Offline Qedo

  • Mr. Polyvector
  • ***
  • Posts: 132
  • UNUS SED LEO
    • View Profile
Re: GLB 15.004 DO NOT COMPILE
« Reply #12 on: 2017-Sep-09 »
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


Offline dreamerman

  • Mr. Polyvector
  • ***
  • Posts: 159
    • View Profile
    • my personal website
Re: GLB 15.004 DO NOT COMPILE
« Reply #13 on: 2017-Oct-23 »
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

Offline Kitty Hello

  • code monkey
  • Administrator
  • Prof. Inline
  • *******
  • Posts: 10649
  • here on my island the sea says 'hello'
    • View Profile
    • http://www.glbasic.com
Re: GLB 15.004 DO NOT COMPILE
« Reply #14 on: 2017-Oct-26 »
Fixed in next update.