Apple said today..
'Starting February 1, 2015, new iOS apps uploaded to the App Store must include 64-bit support and be built with the iOS 8 SDK, included in Xcode 6 or later. To enable 64-bit in your project, we recommend using the default Xcode build setting of "Standard architectures" to build a single binary with both 32-bit and 64-bit code."
Source: http://appleinsider.com/articles/14/10/20/apple-to-require-64-bit-support-from-all-ios-apps-starting-in-february (http://appleinsider.com/articles/14/10/20/apple-to-require-64-bit-support-from-all-ios-apps-starting-in-february)
Just wondering what this announcement means for GLBasic - if anything?
im knew this was happens sooner or later when xcode 6 is a requirements, just like its happens with ios7. But was not aware they now require 64bit now.
Also when im compile in my current project, its does works with standard architectures with both arm7 and arm64, but the linked O files is howover not 64bit, when trying to add arm64 to the Valid Architectures. So glbasic might require a update.
So Gernot, its time to update. Howover im do recently releasesd a xcode 8 project in a another thread, so its easier to get it working.
Oh my God, Xcode 6 requires OSX Mavericks!!
I made good creating two partitions in the Mac.
A GLBASIC update is REQUIRED, see below screenshot.
(http://dl.dropboxusercontent.com/u/3236515/glbasic/64bitfails.png)
yeah Apple will 64 bit support ! :rtfm:
.
.
.
.
.
.
.
great :/
I need an x64 cross compiler toolchain then.
are those tools not got updated since the 2009 version? Im have seen a much newer versions. But im do hope its dosent bugs out on the newer compiler with arm64 support. Im do thinks the proccssor is named arm64, not x64. Im do also thinks we will lost 32bit support on Windows too when compiling iOS? Im dosnet thinks its a big deal throught.
Also Google side, Android 5.0 will also supports 64bit too. So they might choice to require it sooner or later.
This can also means we could support 64bit on Windows too with the new compilers eventuelly?
PS. We do still have about 3 month to get it working, but would been nice to see this happens.
Not much related but a bit. While pushing ios platform to 64b would tou think it could be sport or worth to use the 64b java for the android part too? Is there any benefit at all?
Its just a marketing gimmick IMHO. 64bit means you can address more memory but until we see 16GB RAM phones/tablets, there really is no need to force it on mobile developers. There are some slight advantages in that there is 64 bit registers ect. but the main advantage is the address bus. As I said, I think Apple will be using it to sell iPhones soon, "iOS 64"? :P
also its not just memory, its can also execute some instructions faster and perform some calculates faster too. This can been the main reasons.
Yes, that's why I mentioned the 64bit registers(some additional op-codes too) but the speed increase is negligible for most apps unless specifically designed for 64bit(not just run through a 64bit compilation and hoping the compiler will do the optimisations for you). From my own experience(64bit Delphi), you never get more than 5% extra-speed usually its averaging out the same or 1-2% faster. On desktop there is a real chance that you will come into contact with large amounts of RAM, this is where the real advantage is.
how much time would this take to get glbasic updated to 64bit?
This can been highly concern for me, if im cant update my apps anymore (even its deadline is first 1. feb), but im do not thinks none of the 3 current games will require a update really quite a time allready now.
Compiling using xCode 6 is not a issues its self (which does works and glbasic can do uses the new resolutions), but just take some time, so here to get 64bit code to work is a must if we cant to countinue supports ios.
Today im planning to do 2 projects, one is a smaller touch screen based game (hence ios and android is a must), which im still can do glBasic for that project, while the other one dont need to been touchscreen really, but that game is also been a great learning game for unity. Im hope im start looking on Unity later this week.
QuoteIm hope im start looking on Unity later this week.
This is also something I have considered and I am a registered developer for it. Looks like it's the way forward for many indie devs.
I'm registered developer and I don't like Apple only supporting the latest iPhones. I buy an iPhone 4 a year ago and I must to buy another iPhone or iPad to continue developing after february 2015 :S. I understand Apple, because they want to sell their new products. I only know that I must to release my games before the next year and buy a new iPod if I want to release anymore. They release a new iOS version (and abandon an old device) each year!!!
Xcode 6 still Can deploy to my old iPad 1, which is iOS5....
Just a small point I just remembered regarding support for the older devices..
Get your apps approved now. That way you can take advantage of the "download the last version of this app that works with your device" feature of the app store where it lets users download older versions than the current of your app.
A useful workaround meantime?
Smells of Apple trying to push away 3rd party development beyond indies...I mean its not very indie-friendly to keep buying and updating devices and development libraries etc...
I will need to reconsider my iOS plans for the moment...
QuoteI mean its not very indie-friendly to keep buying and updating devices and development libraries etc...
Apple has never been developer friendly. Just look at all the hoops you have to jump through to get anything on one of their machines, starting with only using their hardware, having to have a developer license, then certificates and provisioning, then XCode and finally the upload tool (ignoring the Review process and wait for it to go live). Then look at webOS. Or even Android. Or any other platform - ever. Even Nintendo, typically stryngent with their developer policies don't force devs to go through anything like that nowadays (they even offer loaner devices, as do other dev portals including Sony and Microsoft. Apple doesn't).
Btw its not that hard as you thinks and even kids have could code for it and the new Swift language is the right direction for Apple for indie support really. Actuelly its have been easier in the recent years, even its is still annoying about the code signing issues. But in the other side, im have 3 games for iOS, all got approvede with xCode 6. So xCode 6 is not a issue at all.
Also xCode 6 older supported version seens to been iOS 5.1 or around here. Im can still test it on my that old iPad 1 using xCode 6. Im do even thinks 3gs is still supported in xCode 6 too.
Thinking of dropping iOS altogether personally, tired of hoop jumping. I've never been able to afford the development equipment necessary, I ebay for older Macs(I've 2 of them now). It was gauling that I had to buy a 2nd Mac because Apple decided that people should no longer be able to compile 64bit code on a 32bit CPU(you can do it on an 8bit CPU + 64bit compiler if you wanted to). Annual payments for devs, when Apple takes a cut already from the AppStore is annoying. Forcing the use of ObjC/Swift in an attempt to isolate devs from the rest of general dev community is annoying.
IMHO in general indie devs built Apple, their hardware is nice(but no longer unique) but the bedrock of the AppStore is the massive amount of apps supplied by us. I just don't think Apple respects its indie devs anymore but if they were all to disappear off of planet earth tomorrow, Apple would die off soon after.
I never said it was hard, I just said you HAVE to jump through Apple's hoops. And they aren't as straight forward as you make them seem - there are forums filled with questions about certificates and provisioning and books to help people get through the whole process.
It's not XCode in itself that's the issue - it's HAVING to use XCode after you've got your code up and running.
Apple have not done anything to make the situation easier for devs - and that's ignoring the deliberate obfuscation of devices and the multiple resolution issues (I know that's something that plagues Android too with some very obscure sizes with/without the menu bar).
Swift is indeed a step in the right direction, but it seems a little too late to me.
Apple want a closed-shop so that they wont have to depend on indie devs...I dont know if they make more money on apps or music...but they are loosing the run of themselves.
I havent Apple-bashed in a while but thats gonna change soon.
Making users compile with Apple-only is just a cheap trick to force Windows users to convert over...and build up the tech talent for Apple.
I heard you cant even delve into the nuts and bolts of the new MacOS Mavericks? Apple wont let you...they despise hackers and adapters etc.
Generally me thinks, about 90-95% of apps would not been have a issue with this new requirement at all. Those which have a issue often only require few addition days of code to get it working.
xCode as requirement can annoying, but most issues did have got fixed. But there is also requirements with Android as well (Java and adb hell). WebOS was only system that escaped some of the issue, but its was newer sold in Denmark. That why its was HP Touchpad im got, because im knew im could install Android sooner or later (here its was installed such, im could uses both system, today WebOS is sadly wiped). My main system is still iOS and countinue to been that (yes of course im have brought the new iPhone 6, upgraded from a iPhone 4s).
But lucky my Ultimo 2009 Mac still works with Yosemite (the newest osX). Its a quite little slow today, but does works as intended. Yosemite is a free upgrade, so there is no reason not to upgrade it today. This was also one of the previous issue as well, which costed money each time they upgraded.
To be fair to Android - Java is an important aspect of many plug-ins and online applications and adb is not necessary at all to deploy to Android devices.
None of the other OS's require you to buy an over-priced, under-specced name brand machine and to me, that's the biggest *love*-over by Apple. Although obviously if you have a large disposable income or sell lots of apps this is a non-issue, as are all points for all systems.
By all accounts Yosemite is Apple's version of Vista or Windows 8... The comments I'm reading about it (even if it is free) are not too complimentary.
Anyway, the move to 64Bit was expected and a step in the right direction, I think.
As for TouchPad - I finally bit the bullet and installed Android on mine last week (dual boot option though, although I doubt I'll ever go back to webOS).
for me adb is very much necessary for me, due logcat is so important. Logcat is the main reason im could do Android Extras. This is only feedback im can get when thing go wrong. Its simply so important due that. Recently im even removed all inapp purchases from my Android apps, due the stupid physical requirement exsponded to the public. That is not indie friendly at all.
Yes Yosemite have been redesigned using a quite flat design. Actuelly im do like that, but have not checked that that much. Its not my main OS at all. But finally they fixed the annoying jumping icons in that OS, which is pretty nice. Im do not have plans to purchase a new Mac, and a near 5 years is a quite long time to have one without have changed its hardware.
Yes even this requirement is a bit annoying, im do understand why they want to get thier apps to support the new processors.
Quotedue the stupid physical requirement exsponded to the public. That is not indie friendly at all.
Yeah, that's pissed off a fair few indies, that's for sure, although the potential for negative activity as a result seems minimal to me - most indie apps are less than five dollars/pounds/euros; I doubt anyone is going to take it upon themselves to visit the developer or send something nasty through the post for such limited amounts. I know there are idiots out there, but the risk is small IMHO.
I'm more concerned about Google's general practice than displaying my name and address to everyone on the net.
The address is not only for inapps - if you have ANY paid apps inapp or paid then its required.
I have a happy work around - I use a coworking space and used my office address there. :)
My issue is the ad agency crowds pestering me to skype them and accept their calls.
I think some might have the cheek to turn up at the office.
Now there is a good thing about living in Brasil, no one is going to visit me whether my app is good or not.
But I suspect some of my friends might take it as an excuse to show up.
The thrills of living in a tropical island...strangely, everyone remembers and misses me when summer is around. ;/
OK. The background is this: I need to compile the GLB code to a library and link that in XCCode later. For x64 libs I need a new compiler. The Apple GCC versions are however not easy to build on Windows. Our 32 bit compiler is close to be a miracle. Trucidare invested lots of time to build it.
I fear I reached a dead end finally.
Propably focusing on HTML5 is the most future safe way. No idea.
I'm so sorry for this bad news.
Gesendet von meinem GT-N7100 mit Tapatalk
Android is the future!!
That and Garlic Bread!
Bloody Apple and their hoops
Ok, now we reach the point of no return...
No iOS support is a pretty serious revenue loss. :(
HTML5 is not something in aiming at either unfortunately(way too much low level hackish C code in my project, even for Emscripten to handle).
That means im cannot countinue to support glbasic, so Spot Race is my last game for now. for me iOS and Android was the main requirements.
But we cant compile on the Mac instead. Im see... We require a Mac to build iOS binaries anyway in xCode.
With the above in mind, could the gcc compiling not to been done on the Mac too, eventuelly using a runable script file, and drop Windows so much as possible?
Im do cant see the issue the two O files could been 64 bit compiled, which can been done on Mac too.
maybe kitty can say some words ...
Quote from: spacefractal on 2014-Oct-30
But we cant compile on the Mac instead. Im see... We require a Mac to build iOS binaries anyway in xCode.
With the above in mind, could the gcc compiling not to been done on the Mac too, eventuelly using a runable script file, and drop Windows so much as possible?
Im do cant see the issue the two O files could been 64 bit compiled, which can been done on Mac too.
Sounds like a good idea Spacefractal, take the GLB generated source code across and do the compilation over there. This may need some Mac GLB runtime libs to be compiled by Gernot first though.
How is libpng-gf.a and libGLBasiciPhone-egl.a been created?
If they are allready created by GCC and in xCode, then im cant see that issue to compile them using 64bit version here.
Same can should been extractly to been done with libPROGRAM.a really. Eventuelly the compile part can been executed by a bat like script on the Mac. Its only one extra step for us. That script could also take care of icons etc on the xcode project eventuelly, instead doing that on the Windwows side too.
Then im thinks Windows GCC should been dropped completly.
It could work, obviously Gernot would need to create his closed source static libs on the Mac first. Silly thing is that, it actually could speed up the overall compile as you would only need to do the compile+link once.
the two a files can still been closed source. If they are allready compiled using xCode gcc on Mac, then there should not been issue to create a 64bit binaries of those two files at all.
The main issue is the project we create. First at all the source code is first created as cpp files as well varioues other files. But soon after that, the rest of the compiling should been done with xCode gcc in the same way libpng-gf.a and libGLBasiciPhone-egl.a got compiled on the Mac.
GCC on Windows should been dropped and moves to Mac. Same can really been happens with the MacOSx version.
Maybe we are at a tough end right now, but nothing should be impossible, there must be a way.
I wonder if Trucidare would step around this thread to help share some light on the subject.
I take it as a hard challenge, not and impossible feat. I´m a pessimist/realist person towards almost anything, except GLBasic. :)
Another idea is that is GLBasic would produce C++ source only, it does this already but it then compiles and links for you. If the final process was at least optional then we could source our own compile chains or at least install them for GLB to pick up via environment path variables for example or a config file. Or, create a make file on another platform and do it yourself. Not simple but a little more flexible.
Quote from: Kitty Hello on 2014-Oct-30
...
I fear I reached a dead end finally.
Don´t.
Please consider the help everyone here can pull on the subject. ;)
its look like the cpp is compileable using xcode, despite many unused variable warnings as well red warnings. Here was the red warning:
SORTARRAY(Objectdata(),ADRESSOF(compare))
Cast from pointer to a smaller type 'DGNat (aka 'int') loses information.
There was two other red warnings too in glb.h file, but they was just DEBUG thing, which can been removed safe.
But im thinks the best alternative way is create a special xcode project needs to been used for compile by yourself, which can been done before you submit your game and then uses the 32bit compiler for testing (etc debug = uses the 32bit compiler, release = only compile c++ files).
Quote from: spacefractal on 2014-Oct-31
its look like the cpp is compileable using xcode, despite many unused variable warnings as well red warnings. Here was the red warning:
SORTARRAY(Objectdata(),ADRESSOF(compare))
Cast from pointer to a smaller type 'DGNat (aka 'int') loses information.
There was two other red warnings too in glb.h file, but they was just DEBUG thing, which can been removed safe.
But im thinks the best alternative way is create a special xcode project needs to been used for compile by yourself, which can been done before you submit your game and then uses the 32bit compiler for testing (etc debug = uses the 32bit compiler, release = only compile c++ files).
That message is quite common - its converting a 64-bit to a 32-bit one. Usually it wont be a problem, although it is certainly possible that any lost data could cause problems, especially if it's being used as a pointer. Whilst it could be left, it is a gamble that at some point it couldl cause a problem.
xCode wont compile that one for this error and got that as a red warning (which stops the compiling). So its needs fixed here.
Howover im thinks im have got a xCode project that can been used for that task and will release it later this week to Gernot.
Here is something that can been done when building a release build and the output could show like this:
_______________________________________
*** Configuration: IPHONE ***
precompiling:
GPC - GLBasic Precompiler V.10.053 SN:73686179 - 3D, NET
Wordcount:8255 commands
creating cpp files:
create process success
_______________________________________
For iPhone you need to manual compile the 64bit code in xcode. Do this on your Mac:
1. Open xCode_Source/PROGRAM.xcodeproj
2. Import any files from xCode_Source/PROGRAM/code folder to your xCode project.
3. Build the project as a iOS Device project.
4. Copy xCode_Source/libs/libPROGRAM.a to XCode/Lib/libPROGRAM.a
You now uses the normal XCode project and eventuelly follow the readme.txt instructions.
This asume its will been created two Xcode projects: one final project which act as normal one, and one for this task alone. This is the best alternative for 64bit project and is ONLY required when release the final release build before submitting it. We can still uses Windows 32bit compiler under testing. So its just few more steps before submitting to Apple. That is not a big deal really.
PS. AS im wrote there is some bugs needs to been fixed first, but im do thinks its no big deal in the end. Gernot should do the same with the other two A files and begin manually build the project in Xcode in the same way.
Its quite right that it should be treating it as an error, rather than a warning :)
in SpotRace im actuelly got a 32/64bit library compiled correctly AND even got that lib to launch (but of course in the 32bit mode, but the library does include 64bit code).
So using two xcode projects can nicely work in "tandam" when most dirty work have been done (which im do in a blitzmax app, which im still like doing tools like that). Im will release a xcode project with that code tomorrow or sunday, so Gernot have something to work with.
All he really is needed is "gcc" compile libGLBasiciPhone-egl.a and libpng-gf.a in xCode with a combined 32/64bit code (hopefully sdl still works in that mode) in xCode and fix eventuelly issues (like in SORTARRAY as im found). So we should not fear a closedown of the iOS support using this way and im even tried to do a nicely readme.txt file how to do those steps.
When Mac and PC is in network, then its also pretty easy those new steps (im have done most of the dirty work).
So im do thinks we dont need to remove iOS support at all, but as im previous just more manually work for the RELEASE build.
PS. This method is also a really nice way to find eventuelly bugs, that might not got catch by glbasic precompiler. For Spot Race there was one red warning, that diddent got catch by glbasic precompiler, but its was a line safely to been removed and here, nothing Gernot can do.
outstanding! :nw:
Good job! :good:
Here is a possible sovle for 64bit (which is of course untested until the new a files is released, but the combined 32/64bit did work with 32bit runtime):
https://www.dropbox.com/s/frlld7juqnvjnf2/iOS8forGlbasicBeta.zip?dl=0
This is so you can see the idea behind how to uses xcode as compiler instead of Windows compiler (which should still been used, since 32bit apps is nice under testing, so we dont need to require the new steps every time. Most steps is one time setup.
now im wating for the new a files, so im can finish of this one.
its seen its more in ADRESSOF() there is a bug. Im create a thread in the bug section about this one (no reason debate about the bug here really):
http://www.glbasic.com/forum/index.php?topic=10103.msg88677#msg88677
Karma Miwa launch very fast after using xCode GCC, so there is speed gain here by using newer compilers, even in 32bit mode.
That's good news, I hope Gernot picks up on this as its a nice solution to a potentially very bad problem.
I can't test as I don't have an Apple account presently. :(
the only downside is the lib size is about 3-4 times bigger, but here nothing to do. Im havent tested about 64bit yet. There can been some issues if 32bit pointeres have been used. They needs to been updated to uses 64bit. normal variables and all can still been uses 32bit.
Hmm I really really hope these technical issues can be solved. It seems there are some very smart people here with possible workarounds...
I am an optimist..
If it means switching to a subscription or paid mode for glbasic updates to cover any costs in development then I am all for it so long as iOS support can be ongoing..
I think with the right support, workarounds won't be required. Work is underway on maintaining GLB and improving it in a way that perhaps wasn't possible before. It's not going to happen quickly, but hopefully it will be good for the longer term.
=D :booze:
The iOS port does neither use SDL nor SDL_Mixer.
Gesendet von meinem GT-N7100 mit Tapatalk
ahh, ok. Im have removed sdl for this project so. The only issue left which wont compile is in glb_pc.cpp
etc its have red errors on SFXSound and property all other sound functions.
Im thinks im still missing add a file to xCode Project, but here im not sure which one missing (or missing a define or a FrameWork)?
Also there is some deprecations, some allready from iOS2.0 (StringWidthCString). Some also deprected from iOS 5.0. But since im only want to support from 5.1 and up anyway, those can been fixed throught. Im do not have plans to make sure its works from iOS 4.x at all (since xCode 6 seens not support that).
Im also added a lots of (int) as well in various files (except sortarray, which needs convert to (long).
PS. Im did succesfull compile libpng-gf.a and working in 32bit mode. When anything is done, im will post in the new Source Code forum (as well posting a files only here).
im got today glbasic compiling with the source code and got Karma Miwa running in 32bit mode, but there is still linker errors when trying to run in 64bit mode (property a double issue). but im is closer.
Sounds like your progressing! :)
oh man. im finally got compiled it to arm64, and the game do now start... But its crashing now.
That crash that does in the game is due its trying to load a internal font, but crash with a BAD_ACCESS error....
So there is quite bugs that needs to been fixed.
If anyone can sort it, it's going to be you Alan :)
im soon or this weekend create a installer, which easier can integrate sourecode with the ios 8 project. its still fails with arm64 on "FindOrExtract" function with a pointer issue and property needs help on that.
But howover im got a idea how to do a one pass compiler, rather than using two by importing cpp files directly to xcode (from a Code folder, so easy to spot that) as well setting few things up. Those cpp files glbasic have generated in the temp folder.
Since its include gernot source code, im will of course not put it in the public forum, but in the Source Code forum. But its will been easier to test and run, because my new makeapp.exe can copy a files directly from the source code a file and copy those (if they exists).
There is a define to remove shoebox calls.
Gesendet von meinem GT-N7100 mit Tapatalk
yes im did noticed that, but its does works nicely on 32bit, but crash on 64bit. Im send you a xcode project soon in the source code folde. Im do still believe its quite a simple thing to fix in the glb.h file (which im guess the bug is in there and in the string class). Im do away most of the day soon, so its must wait after that.
PS. DEBUG seens to been a reservered word in xCode, and hence its needs to been renamed (by now im DEFINED them out).
Maybe GLB can generate the libPROGRAM in very obfuscated C/objC source code instead in binary form. Then you can get an XCode project to compile for iOS8 (or other) using a Mac. I think obfuscation is an option to keep closed source and continue developing for Apple without problems.
Example obfuscated code:
#include <stdio.h>
#define l11l 0xFFFF
#define ll1 for
#define ll111 if
#define l1l1 unsigned
#define l111 struct
#define lll11 short
#define ll11l long
#define ll1ll putchar
#define l1l1l(l) l=malloc(sizeof(l111 llll1));l->lll1l=1-1;l->ll1l1=1-1;
#define l1ll1 *lllll++=l1ll%10000;l1ll/=10000;
#define l1lll ll111(!l1->lll1l){l1l1l(l1->lll1l);l1->lll1l->ll1l1=l1;}\
lllll=(l1=l1->lll1l)->lll;ll=1-1;
#define llll 1000
l111 llll1 { l111 llll1 * lll1l,*ll1l1 ;l1l1 lll11
lll [ llll];};main (){l111 llll1 *ll11,*l1l,*
l1, *ll1l, * malloc ( ) ; l1l1 ll11l l1ll ;
ll11l l11,ll ,l;l1l1 lll11 *lll1,* lllll; ll1(l
=1-1 ;l< 14; ll1ll("\t\"8)>l\"9!.)>vl" [l]^'L'),++l
);scanf("%d",&l);l1l1l(l1l) l1l1l(ll11 ) (l1=l1l)->
lll[l1l->lll[1-1] =1]=l11l;ll1(l11 =1+1;l11<=l;
++l11){l1=ll11; lll1 = (ll1l=( ll11=l1l))->
lll; lllll =( l1l=l1)->lll; ll=(l1ll=1-1
);ll1(;ll1l-> lll1l||l11l!= *lll1;){l1ll
+=l11**lll1++ ;l1ll1 ll111 (++ll>llll){
l1lll lll1=( ll1l =ll1l-> lll1l)->lll; }}
ll1(;l1ll; ){l1ll1 ll111 (++ll>=llll)
{ l1lll} } * lllll=l11l;} ll1(l=(ll=1- 1);(l<llll)
&& (l1->lll[ l] !=l11l);++l); ll1 (;l1;l1=
l1->ll1l1,l= llll){ll1(--l ;l>=1-1;--l,
++ll)printf( (ll)?((ll%19) ?"%04d":(ll=
19,"\n%04d") ):"%4d",l1-> lll[l] ) ; }
ll1ll(10); }
libPROGRAM is not need at all. By now im simply just import the cpp directly to a new xcode project as long with the m files. That avoid using 2 pass compiling with xCode. Howover there is some 64bit pointer issues needs to been fixed and here im have uploaded a test project in the Source Code forum.
im do not thinks about obfuscated at all until all is working.
LibPROGRAM was the file compiled from your own project, and does not cointain glbasic source code.
Well, what I said for libPROGRAM is applicable to all glbasic libraries needed.
Hi.
It's been a few weeks plus now since anything was reported back here - any update on how things are going ?
Not much since last update but is working on it. Deadline do might slip, but trying keep that short a possible.
When catch out is finished I'm do more focus on those issues.
im have looked into this again. Howover im will now completly stopping working with iOS issues by now and came to the point im have no clue how to get the pointer mess to get working with 64bit mode. Its simply to much a mess and is got stuck now :-(.
With that in say, im do can compile it and get it started and running, and got the xCode project running and compiling the files pretty fine. But various functions is not 64bit aware and have various pointer issues (im hate them in that why they works in c++).
So unless others take over (im need help), 64bit iOS wont been successed at all. The xCode projects im have created is in the source code forum. So checkout there.
What that is stuck and not workking is thinking is SORTARRAY() in glb.h and in FindOrExtract() functions in gfshowbox.h. Those is pretty much the most important issues right now (the swap x/y issue is a easy fix, but wont fix it before im see this running). Also DEBUG need to been renamed, due its a reservede word in xcode, but howover STDOUT is actuelly better to use that anyway.
Im thinks soon im see code how to fix those typical pointer issue. rest should been easier, so im understand better how the pointer works in the strings thing.
PS. Im have today updated the source code relocation project in the Source Code folder, so its easier to get it working.
Hopefully Gernot can spare some time to shed some light into this issue. :whistle:
im have issued a special xcode project with a runable code, which instead using the lib file, included the glbasic source code its self, so its should been easuer to get it working. This is what im can do. Find that in the 64bit project thread in source code folder.
Howover even the startup thing got fixed, there mightbeen issues with various commands, but here. mostly there can been workaround and cant test them all. But still, its important to just to see some running code.
exciting news:
Just now, im finally seen CatchOut (not tested with other games yet) to been running in 64bit mode.
The main bug have finally been found (in gfcompression.h), thanks HeadKaze. Gernot, im hope you dont mind im gave him the code to been looked on extractly that issue. He might even want to help more.
But there is still some issues left (SORTARRAY and ADRESSOF), but finally im do see glbasic running in 64bit mode at least (even im not sure what that bar at the top left is):
(http://dl.dropboxusercontent.com/u/3236515/glbasic/64bitworking.png)
Howover its seen the game is in glbasic demo mode throught, which is what its telling. So the license might have been failed when checking in 64bit mode throught. So property that can been force me to remove that, when 64bit is detected.
Here is the fix for the main startup crash issue:
http://greatflash.co.uk/index.php?topic=1130.msg27332#msg27332
Holy Moly, Space that is fantastic news, I would love to carry on working with Glbasic. Hopefully we can.
I have grown fond of this tool, hard to stop using it hehe.
Keep up the good work Space, you rock!!!
Looks like the bar , showing if you have no license
Great news
I'm of course have the license, but it's fails when it is in 64bit mode. It's easy to disable it temporary, but I'm don't do that now etc. it's a issue gernot should checks, but it's not a important issue right now.
It's was headkaze that fixed the issue. but might have effected the license.
you have no license .... :nana:
joke !!!
Wow!!! Great news!! Thank you so much Spacefractal!! You are the boss!! :good:
Haha, I'm lost my license, but yes I'm did got some help, but as least im got see the game running. I'm do tomorrow checks other games as well for eventuelly more issues.
Have you got the system compiling in Visual Studio as well ?
I'm don't have visual studio, but the CRoss compiler for windows compile the source code fine(except a sortarray thing issue in file sorting, which need to look on).
whaat? why and how are we letting people like Space Fractal without a license mess with the source code?? :D :D :D :P
Could not resist the joke. Congrats Space! It seems things are shaping up quite greatly. :good:
Super!
Ah, I was hoping you had the whole system compiling :)
It's does but visual studio was just not a requirement really to compile win32 version. It's was easier than excepted. But there is still some 64bit issues but have first a chance to test my other games tomorrow.
But yes headkaze is the man. IF more issues I'm let him know. I'm also did created few games with him, where I'm did the music part of the game.
Give headkaze a big frenchkiss for me. hehehe
Keep it up guys
the license fails seen can been due its uses (long), which can been dangerous to uses in some cases, because they are not the same length with 32bit as well 64bit. This also cause the tilt commands to barly fails as well.
etc when a float number is negative, then long is displayed it totally wrong with a very hugh positive number. That got wrong in GETJOYY() and GETJOYX(). by now fixed by only internally uses positive number and conveting to int first.
its look its still various issues left.
Exampe its seen DECRYPT$ and ENCRYPT$ does not works correctly. Im dosent get the correct DECRYPT result at all. This can also have caused why the license fails. So those commands is still not 64bit aware at all. Im give the issue to HeadKaze for extractly this issue for those commands.
There was also issues too in GETJOYY() and GETJOYX(), where long to float convert goes completly wrong, when the number was negative. They fixed now, but was also removing the orientation state, since Rot_Gravity2Display() dident work correctly (but im dont thinks its was newer used for iOS). But its easy to workaround that throught.
So im wont release the a file before its ready (all my 4 games should run correctly before a final release). Im do release the fixed beta release source code soon after after Headkaze have looked to the new issue in the source code forum.
Another issue fixed is also resolution, which is now allways uses the screen size detected, regardless wrote in the editor. The reason there is now a bit too many devices out it and using more resolutions now. So no reason to doing that check anymore.
PS. Those is the last remaning issues in CatchOut, which would been the first 64bit release for iOS. Im do need to testing my other games as well, which uses far more commands.
Just tested Spot Race, which uses more graphics commands:
The game started straight away and worked completly fine and played well.
Only issues was the same as im have with CatchOut with the named commands (tilt and crypting do some kiddings, but same thing).
So the progressing very nice.
Good progress then!
I agree, sounds good, congrats!
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...
Quote from: spacefractal on 2014-Dec-17
EDIT:
oh dear. the fixed bug in GFCompression.h dosent work on other platforms than iOS...
You can use this:
#ifdef TARGET_OS_IPHONE
// ios code fixes
#else
// old code
#endifBut, 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
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.
Ace...really awesome stuff going on, I have to put myself together to help out my ways too. :good: :booze:
If everything could be up and running, it would be nice to see GLBasic on Steam
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.
This is looking sweet Space.
Cheers bro.
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.
QuoteGETCURRENTDIR() 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...
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 (=D). 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.
Excellent news. You deserve a well earned rest :)
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!
:nw:
In Triority, I use :
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 :) )
Yes. The return value should be DGNat. Only the pointee to foo is DGPtr.
Gesendet von meinem GT-N7100 mit Tapatalk
(Sorry about messing a post, after im tried to split the SORTARRAY issue to own post). This is what the previous two post is about.
Yes Greedy Mouse got accepted, so its believe we close to release a final project.
There is a SORTARRAY issue left (see own thread). When that is fixed, then im will release the public version of the new xCode project, included with compiled source code files. Im is waiting Headkaze for look on this final issue, hopefully fixed in the weekend.
There can stil been other bugs, but that would been the last important bug to been fixed.
Catch Out and Spot Race does both run nicely in 64bit mode too, but have not submitted a 64bit binaries of those yet (but will do that after new year). Im tested with Greedy Mouse first.
Its possible your comparison function is being called with pointers and not values. You need to use something like :
DGNat routine(DGNat &a, DGNat &b)
{
DEBUG("A:"); DEBUG(FORMAT_Str(0, 0, a)); DEBUG("\n");
DEBUG("B:"); DEBUG(FORMAT_Str(0, 0, b)); DEBUG("\n");
return (a<b ? -1 : \
a>b ? 1 : 0);
}
In the template <class T> void sortarray(T* low, T* high, int foo) function, T t is unused...
please repost the in the SORTARRAY thread. Im want the issue to been seperated.
Good to hear you are Taking the time to fix these issues - just glad and appreciate work is being done on this complex issue.
A fitting end to the hear to hear this news..
Meanwhile I am continuing coding on my latest app, happy that it will thanks to you all here be able to be submitted to apple sometime in the future when apple requires 64 bit apps.
:nw:
now the final issue is fixed. There will not been long im can release the xcode project or Gernot can upload it. There was only a minor change to glb.h to get SORTARRAY working in 64bit mode, but the example in the manual is also have a little bug too there (float not working when using compare functions).
Gernot, im send the Android and iOS projects to you, what im have today or tomorrow. Im will later release it to public (in the none source code version of course).
a 64bit beta project have now finally been released:
http://www.glbasic.com/forum/index.php?topic=10191.0
The glbasic source code is NOT included there, because its a public forum.
There is so many changes, im recommered you to create a new xCode project. This due libPROGRAM.a is not used anymore, but compiles the generated cpp files directly in xCode (not included glbasic source code, which is still created as a file).
Im did that to prevent having to xCode projects for compiling. See readme.txt how to do that.
That's great news. I still need to get spare time to mysef to sit down and try it out - hopefully soon.
Meantime I have a few questions ..
1/ does the new compilation process in Xcode allow you to now use the Xcode simulator? I am guessing not but Thaught I'd ask anyway..
2/ are both 32 and 64 but binaries produced ?
3/ lastly if so, how can you tell which version 32 or 64 bit is actually running once you start it up on your Ipad or iPhone or iPod ?
Thanks a lot.
1. X64 is not included in the compiled a files (png and glbasic sourcecode). So no, a device is still required. But should been pretty easy to support it in the simulator, but by now easier to not include it, due that xcode project you would uses is the release build. But if makeapp.exe could accept a debug or release buold ticked, then the simulator could have been supported.
2. A files is both 32/64bit as required by Apple.
3. You can in the xcode build still change settings to add armv7 and arm64 code when you compile your cpp files, glbasic generate (now required to avoid having two xcode projects). So you can checkout either 32bit and 64bit on same device. If you example want to compile on iPad 1, 64bit is required to been disabled (which is still supported).
Wow! Sounds really good!
Maybe i will get a iOS version of some of my apps out after all!
"But if makeapp.exe could accept a debug or release build ticked, then the simulator could have been supported."
Quick question - what is makeaoo,exe and would it be possible to alter it to accept a debug build, hence allowing the simulator to work?
Yet another question...
So IOS builds can now be true native 64 bit due to all the work done...
What about other platforms going forward? Will it be easy to modify GLBasic to produce 64 bit code for say Windows?
Any advantages to doing so?
why ? you use > 3,7 Gigabyte ?
its not easy to support win and mac with 64 bit , and i dont think this is needed atm.
For Windows it's also require new compiles, but don't thinks it's really hard.
If release or debug tag was added as argument to make app.exe then simulator could been added.
Now I'm might not answer before next week due vacation trip