Too many definitions in include

[matty47]

I have finally created an include file for Xors3D. There are in the vicinity of 1100 aliases in the file. A project which includes the file fails to compile/run but gives no error message even in debug mode. I sectioned off sections of the include file using /*....*/ and if I removed a reasonable section then the project compiles and runs OK. I further checked the syntax by sectioning off "bits" of the include a bit at a time. Found a few errors that I corrected but if I try to include the whole file, compiling fails.
Is there a limit on the number of aliases or is it a stack memory issue?
Happy to send a zip of the project if needed.
Hopefully I am not becoming a "pain" - Thanks

[kevin]

  Can you zip and attach the include (the pba file) so I can have a look at it. 

[matty47]

Thanks for offering to look at this. I keep forgetting to do it. I went to send you a PM with the whole project as a .7z but cannot see how to add an attachment to either a PM or a post. I don't have a website anymore to store the zipped file and add a link.

[kevin]

 Just zip and attach it to a post..   Don't need the dll(s) just the PBA file.

[matty47]

I have attached the whole project hopefully to make it easier to look at. The dlls are from the shareware package. I purchased a key for this engine when it was available many years ago(not included in file). The project will compile as is as I have commented out lines 270-318 and 434-470 in the include file. If you uncomment either of these blocks the project should not run( well not for me anyway). I tested all the lines in the include by commenting and uncommenting various blocks. Could not find any errors. This was just an attempt to see if I  could adapt the engine to Playbasic.

[kevin]

  Hmmm, So what's it compiled as ?   

 

PlayBASIC Code: [Select]

linkdll "Kernel32.dll"
    LoadLibraryA(lpLibFileName$) alias "LoadLibraryA" as integer
endlinkdll 

    print LoadLibraryA("Xors3d.dll")

    sync
    waitkey
  

  calling LoadLibrary doesn't seem to even return a valid handle.  So my guess would be library is 64bit, where PlayBASIC is 32bit.


  Re: Too many definitions

  From memory this would be possible, but I don't remember know what the current limit of definitions is.    Ran into something similar a while back, where I tried to import (as source) a huge table of floating point values as DATA statements only to run into some type of overflow problem.    So there must still be a limit. 

  There's a few different approaches regarding keywords (depending upon PlayBASIC revisions) over the years, but unique identifiers exist in a big table generally.  Which is all pretty standard except from memory this also applies to numeric symbols too.  So literal integers and floats. 

PlayBASIC Code: [Select]

   a=45
   b=a

  So in terms of unique identifiers in this code would be three.   A, B & 45 

  One way perhaps to get around this when building a wrapper would be reduce the parameter names to a symbol for an integer and symbol for float. 

  eg.

PlayBASIC Code: [Select]

   xGraphics3D(width, height, depth, mode, vsync) Alias "xGraphics3D"

  eg.

PlayBASIC Code: [Select]

   xGraphics3D(i, i, i, i, i) Alias "xGraphics3D"

  Would this work to get around the too many definitions issue..  maybe..  does it solve the 32bit/64bit issue.  No..

[matty47]

Thanks for looking at this. I checked Xors3d.dll with Sigcheck (from Microsoft I believe). Result shows it is 32 bit. As I indicated the project compiles and runs (when not so many definitions in the include) so Playbasic seems to be loading the dll ok.
I'll look at your suggestion of shortening the parameter names. Thanks again.

[kevin]

 

Playbasic seems to be loading the dll ok

  hmmm fails to even load here in PB1.65. Sort of loads in 1.64P4 but fails at runtime.   Hmmm, might I ask what version your using ?

[matty47]

I am using version 1.65C3 Beta 09 with Ide 1.1.7b. I am on WIn 11 64 bit latest updates. Please don't waste too much time on this - it was just an experiment.

[kevin]

 Yeah i'm busy,  but i can't see any reason for it not to work..