SyntaxError Posted July 2, 2012 Share Posted July 2, 2012 judging by your post about os x archive utility adding an invisible folder that invalidates the signature i would wager that at some point our build process got changed in a way that files are added after the signing process thereby invalidating the signature. Link to comment
Oleg_D Posted July 2, 2012 Share Posted July 2, 2012 I don't know for sure, but I think the addition of the OSX folder came after using AppResign, rather than being a result of the (un)zipping process. The folder is basically just a mirror of the contents of the .ipa but with "._" before all the file names. Avenger - I agree. The effect of code signing is basically to prevent any third-party code running on iDevices which hasn't been approved and distributed by Apple. I struggle to see how that's not an anti-competitive practice, especially given that the EU is (was?) "investigating" Microsoft for including Internet Explorer on fresh installs of Windows. Link to comment
SyntaxError Posted July 3, 2012 Share Posted July 3, 2012 I see: the IPA was invalidated not the signature? If you have access to a mac feel free to install xcode (free) and figure out what code signing project settings are incorrect/missing and send us a patch. the __MACOSX folder, i assue you, annoyingly created by the mac archive utility. about code signing in general: it is not just a way to lock out developers (that is done by ONLY allowing signed code from your root CA). signed code itself is a GoodThing because it establishes trust much like self-signed vs trusted root signed SSL certificates. I'm sure wikipedia has an article about it that will explain its true purpose. believe it or not this is not an iOS thing or even an Apple thing. it is on Android too; of course Android lets you run untrusted code provided you enable it in device settings. lack of this ability on iOS is what makes code signing seem "anti-competitive". I'm not saying Apple isn't being anti-competitive or unfair to customers, and hope very much that one day you won't need to jailbreak just to run programs that don't meet the requirements of being distributed on apples app store. lastly: this isnt actually difficult to do. obviously without a target device it is difficult to test, however Link to comment
Oleg_D Posted July 3, 2012 Share Posted July 3, 2012 Sorry, I should have said "the effect of Apple's implementation of code signing" above. Don't think it renders the .ipa invalid because a) you can still install it via iTunes and b) I infer from various posts here that people have got the buildbot builds to work fine on iOS <5.1. From what I understand Apple changed the way the OS handles code signatures for 5.1, since the main (to my knowledge, at least) tools for homebrew signing (ldone/ldid) no longer work. If I can get access to a Mac I will have a look and see whether I can contribute at all, but given that one week ago I thought code signing was something to do with Saussure I doubt I will be able to help much. For now I've got BG1 running in EasyTutu so will give that a try over the next few days. Fullscreen disables touch input but it let me prance around Candlekeep and talk to people fine. Thanks for all your help! Link to comment
SyntaxError Posted July 3, 2012 Share Posted July 3, 2012 fullscreen doesnt disable touch input. the problem is the coordinates seemingly get screwed up, but i havent been able to reproduce the problem in the simulator so I'm not sure where the problem is exactly. there are a couple of potential candidates and the bug may actually be inside SDL (not likely i think) the most likely candidate seems to be in SDL20VideoDriver::ProcessEvent #if TARGET_OS_IPHONE if (fullscreen) { // simulated window adjustment xScaleFactor = (state->xres / backBuf->w); yScaleFactor = (state->yres / backBuf->h); } else { #endif int w, h; SDL_GetWindowSize(window, &w, &h); xScaleFactor = (state->xres / w); yScaleFactor = (state->yres / h); #if TARGET_OS_IPHONE // now we need to offset the x/y coordinates xOffset = ((w - backBuf->w) / 2) * -1; yOffset = ((h - backBuf->h) / 2) * -1; } #endif you could try using SDL_GetWindowSize for both cases. despite being the author of this code i don't recall why we are using backBuf->w and backBuf->h at all. Realistically i believe when GemRB is in fullscreen the backBuf dimensions are the same and the window. then again maybe its because iOS uses a renderer that can scale games to fullscreen that wouldnt normally fill the screen (when the resolution isn't 1024x768 ex PST). It's been so long i dont quite remember, but i'm almost certain all these cases (fullscreen vs windowed etc) work fine in the simulator so maybe it has more to do with a retina display (double pixel density) since i now have iOS 5.1 simulator and a new MBP equipped with a retina display maybe i can finally reproduce this problem in the simulator. Link to comment
Avenger Posted July 4, 2012 Share Posted July 4, 2012 This is why you gotta comment your code Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.