64 Bit Support Required Feb 2015..

[bigsofty]

I agree, sounds good, congrats!

[spacefractal]

Yes but there would been changes to it for the iOS version:

- DEBUG command can't propertby been fixed at all, due it's now seen a reserved word already take by Apple. Instead just use STDOUT.
- you need to import the compiled cpp files as well, no longer libPROGRAM.a. The reason is to avoid two xcode projects.
- icons is changed, so old xcode project require update.
- CRYPT and ENCRYPT working again. That means I'm enable the license again.
- Gernot have just looked to the SORTARRAY issue, but still not tested.
- iOS 4 support is dropped and no longer try to test and run on that. So iOS 5+ is required.
- The init will no longer test the max resolution dev have set in Editor, due there came too many devices since that. So its now allways use the screen resolution reported.

On Android:
- Im begin to implementing AE as integrated part of glasic now. That means the old install screen will finally got deprecated (for me its was newer stable anyway). That means some old code might not work and thun, require adding DOESFILEEXITS before use reading a file. But im do hopefuly can doing that automatic behind the hood, before a final release.

EDIT:
oh dear. the fixed bug in GFCompression.h dosent work on other platforms than iOS...

[hardyx]

EDIT:
oh dear. the fixed bug in GFCompression.h dosent work on other platforms than iOS...

You can use this:

Code (glbasic) Select Expand

#ifdef TARGET_OS_IPHONE
  // ios code fixes
#else
  // old code
#endif

But, looking the code, you can change the "long m_HASH_TABLE[65536]" for "int32_t m_HASH_TABLE[65536]" and you can keep the old code, because long is a type that can change between machines, and int32_t is 4 bytes always.

Converting an app (objc/c++) to 64 bits isn't trivial, and must be done carefully.

https://developer.apple.com/library/ios/documentation/General/Conceptual/CocoaTouch64BitGuide/Major64-BitChanges/Major64-BitChanges.html

[spacefractal]

im allready did that. Correctly its should only do that when its deteceted glbasic is in 64bit mode. But now im just used the iphone target. Its could been better, but its does works now. After HeadKaze fixed the main crash, its have been somewhat easier, now im can see my game running.

Today im and Gernot did worked on some Android bits, so Android Extras finally can been made official in glbasic (without breaks any of current AE 2.4+ code and/or old glbasic code).

But by now im do have seen both Spot Race and CatchOut running nicely in 64bit mode. Only license and tilt got issues on those games. There was really not that many issues as excepted. But there can still some issues left when im testing Karma Miwa and Greedy Mouse. We let see.

[erico]

Ace...really awesome stuff going on, I have to put myself together to help out my ways too.

[MrTAToad]

If everything could be up and running, it would be nice to see GLBasic on Steam

[spacefractal]

that could been nice really. Im thinks the next version of glbasic would been great for iOS and Android users (which gave me more motivation after HeadKaze fixed the worst bug).

Today im tested Greedy Mouse 64bit. The game launch, but fails in the SORTARRAY. Here its property only because im diddent got the updated h file yet from Gernot. But im also fixed the swap x/y orientation issue in iOS8 today.

On Android im should look into the fullpath issue with PLAYMUSIC. But with the integrated next AE version, either DOESFILEEXIST or Android.Check_Asset() functions is no longer required.

PS. Yes we could try a Steam Greenlight eventuelly when the next glbasic release is done.

[Omadan]

This is looking sweet Space.

Cheers bro.

[spacefractal]

bah... Serious trouble to get Greedy Mouse working (even in 32bit mode) and recently have and still figthing about various xCode issues (nothing with glbasic to due here).

But the status is, its seen GETCURRENTDIR() does not works correctly and will only show the exe dir path, even SETCURRENTDIR working. That confuction the game, so it crash under loading, due some files not loading. Im have no clue about that, and need help on that one. Im send the issue to HeadKaze tomorrow.

This also happens in both 32 as well in 64bit mode. Im thinks im stops for today, due im quite frustated over also quite mystery xCode issues recently.

[MrTAToad]

GETCURRENTDIR() does not works correctly and will only show the exe dir path

That may be correct - different systems have different ways of dealing with - even Windows, gives different results depending on whether you run a program from the command line or through Explorer...

[spacefractal]

the GETCURRENTDIR()  issue have finally been fixed (was a little strange bug in glb_prepare_reading_file()), and Greedy Mouse is finally ran nicely and very smooth in 64bit mode. The final game is now Karma Miwa. Greedy Mouse was a one of the harder and frustation game to get working.

Also SORTARRAY() seens working as well.

Im have now gave the fixed source back to Gernot, so he can look on that. Im will not release fixes in the source code forum, except im get a green light from Gernot. But instead all fixes goes to him.

Now im thinks im should take a little vaccation. But of course im want to have my games to been first 64bit release (). But im do allready have submitted a 32bit release of CatchOut to Apple, but will do that soon after a acception instead (if its not got rejected due a issue).

PS. Im have no change to checkout 3d games. If im should, im should get a project which uses 3d to make sure its dosent crash for eventuelly issues.

[Ian Price]

Excellent news. You deserve a well earned rest

[mrplant]

Congratulations spacefractal and others.
Great work indeed - really good for the future of glbasic and the ios SDK.

I noticed today in my App Store updates - a 64 bit version of Greedy Mouse!

Fantastic work there!

[MrTAToad]

In Triority, I use :

Code (glbasic) Select Expand

    template <class T> int compare_by_foo(T& a, T& b, INT_PTR foo)
    {
        typedef int(*pcmp)(T&a, T&b);
        pcmp cmp;
//       #pragma warning(disable:4312)
        cmp = (pcmp)(void*)foo;
        return (int)cmp(a,b);
    }

with INT_PTR being typedef _W64 int INT_PTR.  When compiling in 64-bit mode, __W64 is __int64

I don't know whether it works (haven't tried it - but had to modify the function to get Triority to compile), and to use would need a global function (and I prefer to use operators in classes )

[Kitty Hello]

Yes. The return value should be DGNat. Only the pointee to foo is DGPtr.

Gesendet von meinem GT-N7100 mit Tapatalk