GLBasic 64-bit

spacefractal · **on:** December 14, 2014, 04:09:24 pm

64bit issue is one of them. The code signing is still hell to uses, where Android is much much easier to test with.

Glbasic its self seen not been 64bit aware and im dont thinks its will got updated to meet the requirements, but howover Gernot have released the Source Code for glbasic. Im did got to the point the code can get compiled directly in xCode, but still crash on startup.

More on that function in gfshoebox.h:
int FindOrExtract(const char* szFileName, char* pszFoundName, bool bAllowMemfile)

on the char* pointer me thinks with a adress error. But sadly im is not good how c++ pointers really works, so im have no clue how to fix that kind of issue and then stuck here (and hope some other can help to that issue as well). But im did fixed various Android issues yet and works excellent with that that.

But anyway my next game is Space Taxi, and im do fell that game would not been very good using touch screen, but would been better using a Game Controller in hand, so that game would NOT been relased to Android either. But its can come to Android based game consoles as well (such like Ouya, Gamestick, Fire TV and so on), which have a game controller.

PS. Nice little snake game. Yes Apple Watch is more to get noticement its, and is property not meant to been played on that. Im do thinks hud like status could been fun to been used on that, or uses that as a game controller eventuelly could been fun.

headkaze · **Reply #1 on:** December 14, 2014, 04:57:07 pm

Quote from: spacefractal on December 14, 2014, 04:09:24 pm

on the char* pointer me thinks with a adress error.

If you post the project file I can take a look.

spacefractal · **Reply #2 on:** December 14, 2014, 05:13:58 pm

im will send it later. The issue is not in the game its self, but more in the glbasic source code lib (the named function), the basic language im uses (which is wrote in c++).

Howover even the source code got released for about a month aho, there is still not issued a license how we can uses it. But iOS 64bit was the main reason the source code got released.

Im have just compiled a xCode project, where im have combined the glbasic source code to the main project, so its easier to see what it happens (normally, when source code was closed, its was allways a lib file you did include and still should do that way really).

Im pm you a link sson.

PS. if you can get it running and show the Catchout credits (rest of game is removed in that zip, which is not relevant for this issue), then im pretty sure im want to pay you as well property some members from glbasic community.

headkaze · **Reply #3 on:** December 15, 2014, 06:21:17 am

I'm happy to try and help and there is no need to pay me for it. If we have all the source code I don't doubt we can get it working.

Okay so let me at least get to where you're at. You're saying you can compile and run in 64-bit but you get a crash? I'm getting alot of errors when I attempt to link.

Code: [Select]

ld: warning: directory not found for option '-L/Volumes/STORAGE/Source/iOS/iPhoneGlbasicXcodeWithSource/XCode/Lib'
ld: warning: ignoring file /Volumes/STORAGE/Source/iOS/iPhoneGlbasicXcodeWithSource/XCode/Code/libpng-gf.a, missing required architecture x86_64 in file /Volumes/STORAGE/Source/iOS/iPhoneGlbasicXcodeWithSource/XCode/Code/libpng-gf.a (2 slices)
Undefined symbols for architecture x86_64:
  "gf_png_open(char const*, int*, int*, int*, int*)", referenced from:
      OPENGL_IMAGE::LoadImagePNG(char const*, unsigned long) in openglrainbows.o
  "gf_png_read(unsigned char*, unsigned char**)", referenced from:
      OPENGL_IMAGE::LoadImagePNG(char const*, unsigned long) in openglrainbows.o
  "gf_jpeg_read(char const*, int*, int*, int*, unsigned char**)", referenced from:
      OPENGL_IMAGE::LoadImageJPG(char const*) in openglrainbows.o
  "gf_png_close()", referenced from:
      OPENGL_IMAGE::LoadImagePNG(char const*, unsigned long) in openglrainbows.o
  "gf_write_png(char const*, unsigned char const*, int, int)", referenced from:
      OpenGLRainbows::SaveImageFile(char const*, OPENGL_IMAGE&) in openglrainbows.o
  "gf_write_jpeg(char const*, unsigned char const*, int, int)", referenced from:
      OpenGLRainbows::SaveImageFile(char const*, OPENGL_IMAGE&) in openglrainbows.o
  "_glbSoundEngine_IsBackgroundMusicPlaying", referenced from:
      iPhoneIsMusicPlaying() in dxsound.o
  "_glbSoundEngine_IsEffectPlaying", referenced from:
      SFXSoundBuffer::Play(int, int, unsigned long) in dxsound.o
      SFXSoundBuffer::IsPlaying(long) in dxsound.o
  "_glbSoundEngine_LoadBackgroundMusicTrack", referenced from:
      iPhonePlayMusic(char const*, bool) in dxsound.o
  "_glbSoundEngine_LoadEffect", referenced from:
      SFXSoundBuffer::Load(SFXSound*, char const*, int) in dxsound.o
  "_glbSoundEngine_PauseBackgroundMusic", referenced from:
      iPhonePauseMusic(bool) in dxsound.o
  "_glbSoundEngine_SetBackgroundMusicVolume", referenced from:
      iPhoneMusicVolume(float) in dxsound.o
  "_glbSoundEngine_SetEffectLevel", referenced from:
      SFXSoundBuffer::Play(int, int, unsigned long) in dxsound.o
  "_glbSoundEngine_SetEffectPosition", referenced from:
      SFXSoundBuffer::Play(int, int, unsigned long) in dxsound.o
  "_glbSoundEngine_SetListenerPosition", referenced from:
      SFXSound::SFXSound() in dxsound.o
  "_glbSoundEngine_StartBackgroundMusic", referenced from:
      iPhonePlayMusic(char const*, bool) in dxsound.o
  "_glbSoundEngine_StartEffect", referenced from:
      SFXSoundBuffer::Play(int, int, unsigned long) in dxsound.o
  "_glbSoundEngine_StopBackgroundMusic", referenced from:
      iPhonePlayMusic(char const*, bool) in dxsound.o
  "_glbSoundEngine_StopEffect", referenced from:
      SFXSoundBuffer::Stop(int) in dxsound.o
  "_glbSoundEngine_UnloadBackgroundMusicTrack", referenced from:
      iPhonePlayMusic(char const*, bool) in dxsound.o
      iPhoneStopMusic() in dxsound.o
  "_glbSoundEngine_UnloadEffect", referenced from:
      SFXSoundBuffer::Clear() in dxsound.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

spacefractal · **Reply #4 on:** December 15, 2014, 08:23:52 am

When all files is imported correctly, it's should crash in that function and works fine in 32bit mode.

it's iOS only (the is compiled only to arm7v and arm64, not the Intel processor), etc the png lib. Glbasic have never worked in the iOS simulator.

Pps. Source code is not fully public, why I'm pm it.

headkaze · **Reply #5 on:** December 15, 2014, 09:31:41 am

I had some code sign issues I had to sort out on the Apple Developer Connection website.

The strange thing is if I set the target to iPhone 6 Simulator I get those errors. If I target my iPhone 5 hardware it compiles and runs fine. Very strange.

Anyway I am not getting a crash at all. Titlescreen shows for me.

spacefractal · **Reply #6 on:** December 15, 2014, 09:34:53 am

32bit works pretty nice as you see, did you add arm64 to the list? I'm diddent do that in the project.

It's crash when arm64 is used.

headkaze · **Reply #7 on:** December 15, 2014, 09:37:39 am

You did add arm64 to the project.

Still I can't run on the Simulator for some reason.

It runs on my iPad Air and I get that error you're getting. So at least we're on the same page.

spacefractal · **Reply #8 on:** December 15, 2014, 09:38:59 am

Simulator was never worked in glbasic, due the libs was not compiled with that ind mind.Im do also not used simulator at all, due most of dev is on Windows anyway. So its not a real issue. So its best to test on a real device.

There is a libpng-gf.a file, which im also not have added the source code for (im could do that), because im dont thinks its a issue in that file really. Even its uses a little bit older version of it. But if something happens on that happens, let me known. the png library file is not compiled with simulator in mind, and hence you get the issue.

PS. Im was not home yet. But its seen you now got the same issue now.

headkaze · **Reply #9 on:** December 15, 2014, 12:03:55 pm

This was quite tricky to debug because the debugger was not giving a lot of clues as to the exact line causing the crash. But I did find it in the end!

The crash is caused by this in gfcompression.h:

Code: [Select]

	#ifdef hashing_on
		void ADDHASH(long a,long b, long c);
		long			m_HASH_TABLE[65536];
	#endif

To fix this change it to:

Code: [Select]

	#ifdef hashing_on
		void ADDHASH(long a,long b, long c);
		long			*m_HASH_TABLE;
	#endif

Then modify the constructor like so:

Code: [Select]

		GFCompression()
		{
#ifdef hashing_on
			m_HASH_TABLE = new long[65536];
#endif
			m_outfile=0L;
			Clear();
			m_Method=1;
		}

I hope this helps

flash · **Reply #10 on:** December 15, 2014, 12:14:05 pm

Well spotted/fixed, oh saint of the codewise keyboard...

spacefractal · **Reply #11 on:** December 15, 2014, 12:21:58 pm

well spotted. Im was newer thinks its was in a another h file as excepted. Im see what happens with the full game. Testing that soon (im have little time today, before im away again most of the day).

The game is now starting up, but im do now there is few more issues (like SORTARRAY and ADRESSOF). But nice to see the game running and have newer excepted its was in a another h file that cached the issue.

But that bar on the top left,?

Its seen glbasic is turning to the demo mode, which is why you seen the bar on the top left. So no worry about that. Im im seen more issue, im will went back. Big thanks for the help.

headkaze · **Reply #12 on:** December 15, 2014, 05:43:08 pm

Happy to help out SF. I hope it means you can continue developing for iOS.

spacefractal · **Reply #13 on:** December 15, 2014, 07:47:08 pm

Now my next game is space taxi and here I'm do still note sure about touchscreen. However here the could been uses of game controller support for iOS of course.

There can still been issues left when I'm testing my other games, im let you known when that happens.

I'm also pretty sure other glbasic users is happy as well :-). Not just me.

headkaze · **Reply #14 on:** December 16, 2014, 10:22:41 am

I forgot to mention that you will also need to delete that array in the destructor.

Code: [Select]

		~GFCompression()
		{
			Clear();
#ifdef hashing_on
			delete[] m_HASH_TABLE;
#endif
		}

spacefractal · **Reply #15 on:** December 16, 2014, 02:19:09 pm

Im have added the forgotten gode :-).

There is one more issue im hope you can look on, which also effects load and save games in CatchOut, which is the last remaining 64bit issue in that game. Rest seen works like its does now.

This time its in ENCRYPT() and DECRYPT(). They dosent give the same result. Im believe its due some pointer or value converting as well?

The lines is in 651 in glb-full.cpp. Im hope its init the blowfish is wrong and then easier to fix that one than its the blowfish code its self.

in windows im got those result from both commands:
ENCRYPT: 0138ab274fcbf752088a14c3704919e6
DECRYPT$: this.is.a.test

There was also some bugs in GETJOYY() and GETJOYX() as well (used for tilt), but here im do managed to fix those by my self here.

Im have updated the zip file now, and its the same link as before.

PS. IM dosent seen the reason to give the whole catchout source, so im only used a example to show the bug (which is just a output result this time, so its close down after that).

headkaze · **Reply #16 on:** December 16, 2014, 06:42:24 pm

It's okay I don't need the full project.

PS You have entered 'arm7v' instead of 'armv7'

I will have a look soon.

headkaze · **Reply #17 on:** December 16, 2014, 06:48:23 pm

Okay found the issue in gffilesystem.h

Change:

Code: [Select]

#define DWORD unsigned long
to

Code: [Select]

#define DWORD unsigned int

spacefractal · **Reply #18 on:** December 16, 2014, 06:53:54 pm

and the output is the same as on Windows? Im also mind im saw that define as well in blowflow.h as well, so have thinked the same thing.

headkaze · **Reply #19 on:** December 16, 2014, 07:07:49 pm

You may want to consider using uint32_t. That way you know it's an 'unsigned 32-bit integer'.

You can check how many bytes a type is by outputting it like so:

Code: [Select]

g_debug("sizeof(long): %ld\n", sizeof(long));
You will see you get the following output.

iOS 32-Bit Output

Code: [Select]

sizeof(long): 4
iOS 64-Bit Output

Code: [Select]

sizeof(long): 8
I would add checks to your code to make sure each type is what you expect it to be.

Eg. Add #include <assert.h> to the top of the file and the following:

Code: [Select]

assert(sizeof(DWORD) == 4);
The debugger will stop there if the assertion fails.

spacefractal · **Reply #20 on:** December 16, 2014, 07:56:04 pm

seen its worked. Im was so close about that one, and saw the same thing in a another file... hehe.

Sokurah · **Reply #21 on:** December 16, 2014, 10:34:09 pm

C - I don't even get the most basic stuff - I couldn't even make a 'hello world' program if my life depended on it (yet

)...but it's so nice to see how people with knowledge helps someone else out.

spacefractal · **Reply #22 on:** December 17, 2014, 07:55:39 pm

The chances in glcompression diddent work when compiles to get other platforms, so I'm changed it so it's chances only happens in 64bit mode.

Also today I'm got a email the 64bit requirement for iOS only is for new app in feb, while updates is in jun.

Also we have various of spam post.

But thanks for help headkaze.

spacefractal · **Reply #23 on:** December 20, 2014, 08:53:34 pm

look like im finally could fix that by my self about the strange GETCURRENTDIR() and now got the game running again. Its was A bug in glb_prepare_reading_file() im diddent excepted.

But.... Greedy Mouse does now crash in 64bit mode, but its a excepted a SORTARRAY bug in compare_by_foo().

Its a pretty much a similar issue me thinks.

EDIT:
m did fixed that one by my self. its was a 32/64bit define that got swapped and was allready nearly got fixed.

Greedy Mouse now run nicely. Phew. One game ago (Karma Miwa).

headkaze · **Reply #24 on:** December 21, 2014, 12:59:01 pm

Quote from: spacefractal on December 20, 2014, 08:53:34 pm

Greedy Mouse now run nicely. Phew. One game ago (Karma Miwa).

Great to hear that SF

spacefractal · **Reply #25 on:** December 23, 2014, 11:51:06 am

Greedy Mouse 64bit is uploaded to iTunes Connect now.

Its too late for Catch Out (which did have some fraterate issues with iOS5 devices, so im set iPad 1, iPhone 3gs and iPhone 4 to 30fps, rest to 60 fps). But the game was allready uploaded for over a week ago, and im wont remove that binary. So soon the game got released (or rejected), then im will do a 64bit upload to them (which im also look on the iCloud issue with Catchout).

Later Spot Race and Karma Miwa will give it a ago. Howover merry xMas and im now take a little vacattion on those issue.

Now im have the source code, then its could been fun to add msi game controller support to iOS, which is more possible to uses those.

spacefractal · **Reply #26 on:** December 28, 2014, 11:39:06 am

its is me, its look complete impossible to rename the final a file. Im came accidently call it libGlBasicPhone for the project.

But im have MANY times tried it to FORCE xcode to compile it to libGlBasicPhone.a and not liblibGlBasicPhone.a, but with no luck. That even im have edited all files in project.pbxproj and remove the two folders created there.

Im do not understand this very strange and very annoying xcode bug.

spacefractal · **Reply #27 on:** December 28, 2014, 01:46:37 pm

There is a 64bit issue with SORTARRAY, still not fixed correctly. Im have pm the source. This time its on the last game, Karma Miwa, which uses SORTARRAY by sorting the sprites priotity under a level load.

Thie project is using the final xcode a glbasic user would use, etc without glb source code, but the code required to look in is there.

headkaze · **Reply #28 on:** January 02, 2015, 09:38:44 am

Okay I have it compiling for 32-bit and 64-bit. I see some output on the screen. What I need to do is run it in 32-bit and compare the output with the 64-bit mode so I can see what is going wrong. At the moment all I get is a constant stream of values. Also what file are these values being output from so I can output a marker for the start of the list of values so they actually make sense?

spacefractal · **Reply #29 on:** January 02, 2015, 10:39:46 am

It's crash when you select a level in the SORTARRAY command (used for sorting sprites). Etc in glbasic.h.

The game menu runs fine. Do it's a crash issue with a another pointer issue.