|
Small White Dragon: What are you using to do your refreshes? If it is anything other than CADisplayLink then that can be a problem. Otherwise I'd use the new Instruments to check on your OpenGL pipeline and see why it is freaking out. It has some nifty new abilities to suggest best-practices or highlight issues that are performance problems.
|
#
¿
Mar 28, 2011 15:27
|
|
|
|
| # ¿ Apr 28, 2024 21:21 |
|
|
Small White Dragon posted:Selling out this fast is insanity. That is an excellent assumption, unless Apple expands capacity. Unfortunately that can have the effect of reducing the effectiveness... I've heard that the best part about going is being able to talk to Apple folks one on one. If it gets too big that will be less likely. Watching the WWDC videos, most of them are fairly basic stuff so I wonder how much there is to get out of the sessions.
|
|
#
¿
Mar 29, 2011 18:59
|
|
I can only assume it will get worse.
|
edit: doh
Simulated fucked around with this message at 18:58 on Apr 1, 2011 |
|
#
¿
Mar 31, 2011 03:07
|
|
|
Ixian posted:Anyone have any ideas on directions to look in? And if you know how to do it/have this experience and are available (and allowed) to get some consulting cash let me know because that would work too. I don't believe you can, unless you use streaming and control the stream as a "live" stream on the server-side. Then you can approximate where they are in the stream since the amount the iPhone can buffer in that scenario is limited (eg: the server can figure that the movie is at T-00:10 from what frame was last sent over the wire). If you have an app you can get explicit control/info on the movie - where it currently is, if the user rewinds/fastforwards, etc. You can also explicitly control the caching, don't download when on 3G, or whatever other policy you want. I'm certainly available for contracting if you need an app written but that is pretty much the only reliable way to achieve what you want to achieve.
|
|
#
¿
Apr 1, 2011 18:58
|
|
|
pokeyman posted:currentTime works great on my iPad running iOS 4.3, even switching to/from fullscreen. Oh snap, thanks for that find sir. It does indeed work on the iPhone.
|
|
#
¿
Apr 1, 2011 20:30
|
|
|
Xenomorph posted:I paid for Xcode 4, but downloaded Xcode 3 since all my old books and most guides I've seen cover that. One of the big improvements in Xcode 4 is an integrated Interface Builder, which makes it much closer to the Visual Studio experience. You still have to manually hook up actions (event handlers) and outlets (named code reference to the control on the form), but now you can drag and drop them from the visual designer surface to the code in the assistant window.
|
|
#
¿
Apr 3, 2011 16:10
|
|
|
Xenomorph: Don't worry about the SDK version so much; just make sure you pick something like 4.0 as your target in the project options. Then you can run on any 4.x version of iOS, even though you are using 4.3. You just need to avoid (or weak-link against) features that are new to 4.3 (or 4.2, etc). For the record, based on the stats I see from my app everyone is using 4.2.1 or 4.3.x now; I haven't seen much of the other versions.
|
|
#
¿
Apr 4, 2011 17:03
|
|
|
pokeyman posted:Public service announcement: don't call -[NSNotificationCenter removeObserver] outside of dealloc. tldr: you unregister your superclass too, which can break things. Instead use the more specific -[NSNotificationCenter removeObserver:name:object:]. Not sure about that but I have noticed that people generally forget to unregister their observers. This one bit me as well and was the primary cause of Storm Sim crashing.
|
|
#
¿
Apr 11, 2011 14:39
|
|
|
Bob Morales posted:Is there any reason not to do stuff like puzzle games in just plain UIKit? Nope, if CoreAnimation is good enough then you can feel free. UIKit draws with OpenGL under the hood anyway.
|
|
#
¿
Apr 14, 2011 02:48
|
|
|
Small White Dragon posted:Hey Clang friends: I haven't seen anything. You can check the Clang mailing list archive but I'm not sure that they've really discussed it beyond 100% C++'0x support. I've been curious myself about what is coming up for Objective-C but haven't heard anything.
|
|
#
¿
Apr 16, 2011 21:12
|
|
|
You can also just take a list of blocks. But I second the motion on blocks - it is much closer to writing "normal" code and really easy to use. Generally you can just have your API class expose the methods that take certain parameters and run onSuccess and onError blocks depending on the situation. If you have more advanced needs you can define a protocol so that you could have different underlying APIs or a simulator. The onComplete can pass any number of objects into the block when it runs. Personally I don't care for having a bunch of different Request/Response objects for each operation but some people do it that way. It just seems like a lot of boilerplate to wrap and unwrap the parameters. Just don't fall into the trap of thinking that because you didn't have to write new methods or re compile that you are doing a good thing. I've known too many people that think having an ultra-flexible interface or doing stuff in SQL stored procs are great because hey - changes without a new build! Until I remind them that those are changes that receive no testing or validation before deploying to production.... So instead of catching the bugs at compile time and re-running unit tests, they decided to let customers find the bugs in the field.
|
|
#
¿
Apr 18, 2011 23:12
|
|
|
pokeyman posted:Or maintain one. [thinger onSuccess:^(id result) { ... }] adds the block to the array of success handlers, all of which are called on the success event. Like an EventEmitter. That'd be handy to have for Foundation actually... Oh coming from C#, a proper event handling system with real language support would be fantastic, but they have already moved beyond next-next gen. LINQ/PLINQ is awesome and the IObservable stuff makes composing event handlers really cool (and solves the unhook problem too). But the real magic is the async stuff that is coming next. It makes closures look positively ancient by comparison. You literally write code that looks and works just like regular old synchronous code but gets turned into async calls with completion and error handlers by the compiler. C# is turning into the best parts of C, Java, dynamic languages like Python, and functional programming... But without the glacial pace, infighting, and 'sperging architecture astronauts that tend to dominate projects like GCC or Java 1.7 Not that I'm abandoning Objective-C by any means!
|
|
#
¿
Apr 19, 2011 00:11
|
|
|
modig posted:http://paulpeelen.com/2010/10/01/programming-in-xcode-iphone-ios4-hello-world-tutorial/ That's a c-style function, stick it in an implementation file but outside of a class. Put the prototype in a header file but outside a @interface block. The you can call it from your Objective-C code just like you call functions like NSLog. You may need to do conversion of parameters in some cases but classes like NSString and NSDatahave methods that will convert to standard C types (eg: char*) and back (and some classes are toll-free bridged to Foundation types so a pointer to NSString can be used as a CFString* without conversion.)
|
|
#
¿
Apr 21, 2011 15:59
|
|
|
rjmccall posted:You're absolutely right that that's how it should work, but sadly that's just not how it actually does under the C separate compilation model. #import/#include directives have no idea what runtime libraries are associated with a header file, and even if they did, there's no way for the compiler to collect all that information and present it to the linker. People need to remember that for backwards-compatibility and other reasons, the straight C languages are still laboring under the compiler restrictions imposed on 1970s mainframes. In the days of limited memory and CPU time, it was far more important to make the humans do the compiler's work for it as much as possible. The current setup lets the compiler just read the header files (processing as they go which is why it will barf if it sees functions out of order without a prototype), pretending the headers are part of the source file, then read the source file. When it sees a type that exists in another file, the compiler doesn't actually know anything about that type except what the headers tell it because it literally doesnt have that other file in memory at the time. This scheme also let's you cache the OBJ files so if only one source file changes you can compile it then relink against the existing OBJ files. It is at the link stage that you actually resolve all those framework symbols (function names). Granted, I doubt LLVM is actualy doing it this way but in principal you can still write an Objective-C compiler that runs with 640k memory on a 386. It should be possible to indicate in the header files what framework is required, but that would require adding actual metadata attributes to C and good luck with that. Not to mention you'd need to introduce the idea of versioning, which would be nice but has other complications associated with it. C#/Java on the other hand are perfectly happy to cache all the referenced library metadata as well as continuously compile all the source files in the background and keeping the resulting AST/metadata in memory because memory is cheap and we all have multicore machines that have idle processors most of the time. So they will just remember that they saw an unknown type in the first pass, then hook up the reference to the definition even when they appear out of order. They can also deal with multiple versions of libraries, mismatched calling conventions, etc because of their VM runtime nature. That is really problematic when you have ObjC calling C functions and vice-versa in a way that doesn't horribly break everything. edit: this is not for your benefit rjmcall, I don't have any intention of explaining black holes to hawking or atheism to Dawkins. Also, is there any publicly available information on Objective-C 3? Simulated fucked around with this message at 03:20 on Apr 24, 2011 |
|
#
¿
Apr 24, 2011 03:13
|
|
|
Only in the sense that you can get the frame rate. There is no way to know if there is a delay in the TV, receiver, etc... Though that is rare on most equipment these days.
|
|
#
¿
Apr 28, 2011 15:28
|
|
|
modig posted:I don't need to know when it shows up on the TV, just when it was sent to the TV. I assume the frame rate will be 60fps out, but I'm not even sure if that is true. Well if you use CADisplayLink to handle your refreshing on the external window, you can request a specific multiple of the display framerate which is 60hz by default (so 2.0 gives you 30fps) by setting the frameInterval property. You can also use timestamp and duration to figure the real framerate if needed. That's the most reliable way to know and is much better than a timer/etc. I'm not sure exactly why you expect there to be a delay or how precise it needs to be. If your requirements are simpler, you can use CoreAnimation completion blocks when making updates on the external view and you will know it is done updating. Eg: use it to update a progress bar and when the last animation frame is rendered your completion block will fire.
|
|
#
¿
Apr 30, 2011 03:59
|
|
|
Sir Davey posted:Well I guess it's a good sign, since an app of ours that was rejected was In Review for only 2 days! When my update was in review for over a week I emailed them and they responded fairly quickly. (Got another Storm Sim update pending right now actually). People are just impatient; it takes time to review stuff. I usually just submit the stuff and leave them to it.
|
|
#
¿
May 1, 2011 01:48
|
|
|
wellwhoopdedooo posted:The advantage of developing this way is, provided I'm careful about exception safety, I never have to write "invalid object state" errors for when you, say, try to call loggingFileWriterInstance.write("some text") without supplying a logger, because you can't even construct the object in an invalid state. By extension, you don't have to handle invalid state errors, because they don't exist. First rule of Objective-C: It has much more in common with Javascript than C++. In Javascript, I can mess with Object's prototype and do all kinds of insane things. I can mess with the browser's built-in objects/DOM objects, etc. Objective-C is basically the same in that regard; you are free to do a huge range of things and a lot of what is required in other languages is merely by convention in Objective-C. For example, @private/@public are just suggestions. You can ignore them and access private ivars if you like. You can also send messages corresponding to private methods if you know their signature. You can use categories to supplement system objects or even replace Apple's implementation. You don't even have to ever call init if you don't want to. You can also construct wildly odd and dangerous inheritance hierarchies, shove proxies in there to move stuff around, use KVO and dynamic invocation, and a bunch of other stuff that makes a regular C++/C#/Java person freak out. You can even get fancy and start returning yourself autoreleased or returning non-autoreleased objects from regular methods, or start swizzling so your program is impossible to debug. But much like Javascript you realize that in the real world it tends to work out just fine most of the time. You also realize that a lot of the OO stuff provided by other languages (friend/internal/protected/etc) aren't really necessary unless you are writing a large complex library... in which case you do things like provide NSString as your public API but actually spit out NSCFStrings at runtime, thus hiding your implementation details. However I'd still vote for garbage collection on iOS if I could; manual memory management is for chumps. Bonus unrelated protip: If you are adding stuff to a class via a Category and need a slot to stash property values (since you can't add ivars), meet these two lovely functions: code:
|
|
#
¿
May 2, 2011 01:55
|
|
|
modig posted:Should I not sell an App as an individual? I do and it doesn't seem to be a problem, though my app shows up under my personal name first, then my DBA company name after.
|
|
#
¿
May 2, 2011 17:59
|
|
|
Lumpy posted:I'm working on a app with another developer, using hg as our source control. The one problem we're having is when we add files or groups. Is it possible to have files and groups somebody else added show up in the project? It's annoying to have to do a pull / update then manually drag new files into the project, and it would be wonderful to have them groups the same in both environments. Obviously it's not a huge deal, but it would be nice to have one less hoop to jump through. If you are both checking in changes to the Xcode project bundle, it should prompt you to merge them and thus combine both sets of changes. Most of that stuff is just plist XML so in theory it should merge fine. NOG posted:I've put back the dealloc in the other class of my hero thats used in my level class. It makes sense now because the array is alloc'd. This should be fine. Generally if you aren't using threads and aren't calling release, you can be guaranteed that any objects you access within a single method will live for the duration of that method. Autoreleased objects get released at the end of that run loop iteration. Since HeroClass allocated the array it is correct to have it dealloc it when HeroClass gets dealloc'd. Also remember that the array will retain any objects inserted to it and dealloc them when removed, so be sure you release the object after adding it to the array /or/ you can just allocate/init/autorelease right up front. When the pool releases at the end of the iteration the object still exists because the array still retains it.
|
|
#
¿
May 2, 2011 20:35
|
|
|
Shameless self-promotion: I don't know if any of you remember Storm Sim from the previous iOS dev thread, but Storm Sim 2.14 just went live. It now has an iPad native UI which is pretty much the only change for this version. App Store Link It was a bit of a PITA to get going because it wasn't clear in Xcode4 exactly how to iPad-enable an app without having Xcode take a big fat dump all over the project. The way the XIB files ended up organized was nuts and I was seeing it load the iPhone views on the iPad simulator in some cases (but stopping and starting the process would fix it). I realized I hadn't noticed at first because my iPhone views were mostly well-designed and supported any orientation, so they just scaled themselves to the iPad screen. That gave me an idea and I ended up deleting the iPad-specific XIBs for a number of views and just using the same exact view on both platforms. So the sleep timer, add effect, etc screens are all identical and just get shown in a popover on the iPad vs getting pushed on the navigation stack on the iPhone. Also a protip: when you create a view for a universal app (or an iPad app) and want the view to have a smaller size, delete the default "View" from the XIB (Xcode won't let you change the view size). Then drag a new View object onto the canvas and hook it up to the file's owner "view" outlet. Now you can change its size, yay!
|
|
#
¿
May 3, 2011 01:42
|
|
|
It varies so widely, there's no telling. Getting featured in the Games category can translate into thousands and if you are lucky enough from that to hit the top 10 that's worth millions. Other categories have different dynamics. I released in mid-January. The highest Storm Sim ever got was 98 on the Health & Fitness chart. So far I've paid back my licensing costs, iOS dev membership, and bought an iPad. If I'm lucky and sales continue, it will buy me a new MBP this year. About 10-20% of revenue comes from in-app downloads. I just enabled iPad support and am waiting to see if that has any effect. Storm Sim Free hasn't really been doing much, maybe $100 total since it was launched... If I were doing it over, I don't think I would have bothered with the free version. It just isn't the kind of app people spend a lot of time looking at the UI for so it just doesn't generate iAd revenue. Overall I'm happy with it. I've spent more time on consulting projects that paid less (assuming sales numbers hold). I can't quit my day job by any means, but I plan on continuing to put out apps.
|
|
#
¿
May 4, 2011 04:23
|
|
|
Zhentar posted:Except that if you're both adding stuff at the end of the list, it'll conflict (easy enough to resolve though). And if you're messing with groups you can break things even without conflicts. Combine the terrible usability and miserable performance of XCode4's visual diff with several developers on a large project and you're not going to have a good time. Oh sorry, I forgot to mention that I use Mercurial (MacHg) so that stuff is a non-issue for me. I put everything in source control anyway... artwork, design notes, test projects, and all the other misc. crap that goes along with a product. On an unrelated note does anyone around here speak German (or any non-English languages)? I want to translate my app but I don't have the resources to haul off and do it on my own. I need a native speaker who is willing to help perhaps in exchange for something you can only get in the US, a gift basket, or a small fee. My only other option is Google Translate, which I'm sure would do fine on single words but will simply mangle the description. Also, does anyone know if you are required to keep the "what's new" stuff up to date in each language once you enable them?
|
|
#
¿
May 6, 2011 00:39
|
|
|
Lumpy posted:I have a conceptual question: The app I am working on shows a list of video mail messages. The messages (video files) are being downloaded in the background and I want to provide an activity indicator to the user, preferably a UIProgressView. I know how to do this in a "normal" view, so tying the progress bar to the DL isn't the problem, it's how do I deal with this in a table view? Do I make a single UIProgressBar and hang onto it in the class, and add it to the cell view of the appropriate cell (but then what happens if / when I reuse that cell?) Do I give every cell a progress bar, and only show it in the appropriate cell? If so, how do I handle it's delegate as it pops in and out of existence on scroll? I basically do this exact thing in Storm Sim. There will be some number (eg: 8) created by the table view at any one time and they will always exist. Have the progress reported to your controller as the delegate. The UIProgressView itself doesn't need a delegate, it just has a progress property. When you hit cell for index path hide the progress view if there is no progress, otherwise show it and set it to the current progress value you have stored. Whenever the delegate fires on your controller, check that the cell currently exists for the indexPath. If it comes back nil, that progress view isn't visible and you can ignore the value (or store it in the controller if you can't dynamically get it from your model). If it does exist, you can get progress view and update the value right there.
|
|
#
¿
May 7, 2011 01:19
|
|
|
Sir Davey posted:Well, we got some feedback from our app which was rejected for being "Marketing materials or advertisement". We basically removed the "inbox" (which, come to think about it, was just a way for us to shove poo poo down people's throats), added 2-3 extra features and mostly a lot of content, BUT we got rejected again! Typically you'd have a Wifi MP3 and a Cellular MP3 and hit the correct one based on the current connection type. (Obviously the cell one will be lower quality).
|
|
#
¿
May 7, 2011 19:03
|
|
|
Doc Block posted:Ugh, had what I thought was a great idea for an app, but checking the app store it seems there are already a bunch of apps with similar functionality. I just has the same experience, but coding is already underway on my app... Then I used their app and realized there is a subtle but all-important difference. Hopefully I can deliver on the great execution part.
|
|
#
¿
May 8, 2011 04:03
|
|
|
Small White Dragon posted:Newer SDKs can produce binaries that run on older OSes just fine. If you set the target to 4.2 and don't use any 4.3-specific APIs, you'll be fine. This. Also note that the number of new APIs between 4.0 and 4.3 is pretty small so odds are you can set 4.0 as your target OS which opens you up to most devices except the original iPhone. edit: Has anyone with an iPad2 noticed you can get it into a wierd screen-locked but not locked state? Basically certain interactions of the smart cover and plugging/unplugging the power adapter get the screen functionally locked but the actual "swipe to unlock" screen isn't visible so you can't unlock it. Simulated fucked around with this message at 14:47 on May 10, 2011 |
|
#
¿
May 10, 2011 14:38
|
|
|
I thought it was 3.0 that introduced the "modern" runtime (non-fragile base classes and the ability to add ivars dynamically) and was the last ABI change but I could be wrong.
|
|
#
¿
May 11, 2011 00:32
|
|
|
Substar posted:xcode 4: What the poo poo? In the simulator, you can select Retina display or non. In the upper-left drop-down you will see each product listed, then under the product you will see the available devices and versions (eg: iPad 4.2, iPad 4.3, iPhone 4.2, iPhone 4.3, etc) but that depends on what your project targets.
|
|
#
¿
May 11, 2011 05:55
|
|
|
eeenmachine posted:marshmonkey and I's company NimbleBit have been developing for iOS going on 3 years now with a good deal of success. We put together a little infographic to celebrate the milestone: http://dl.dropbox.com/u/461612/NBgraph.jpg How have you gotten artwork done for your apps? My biggest problem with starting a game project is I can't find an artist to work with. (I'm sure at this point you have the cash to pay whoever you need). My current goal is release early and often so I've been focusing on projects that I can do on my own without having to wait on or rely on anyone else. So far I haven't done any advertising except here on SA but my live app (Storm Sim) is somewhat niche. My next app isn't but it isn't a game either. Any other general advice would be appreciated. Simulated fucked around with this message at 01:54 on May 12, 2011 |
|
#
¿
May 12, 2011 01:52
|
|
|
Are you kidding? With the left and right bars open and the assistant view on there is absolutely no space. Using the assistant while editing an iPad XIB is almost useless and I have a 1920x1280 MBP. I guess I need to setup a workspace with a second monitor.
|
|
#
¿
May 13, 2011 17:23
|
|
|
Speaking of in-app purchases, the "Manage in-app purchases" link in iTC seems to be gone but if I go directly to my apps I can still get to it from that page. I submitted some items for review but I'm not sure if they are processing items in that queue or not. I can't remember from last time if the system emails you like it does for apps. Not a huge deal, just curious if anyone else has seen this. Also: Patent process broken in this country? Used by blood-suckers to extort money out of the successful people? I'm shocked, simply shocked. This is probably just their attempt to setup some precedents by going after small devs with no resources so they can use that to go after the big players... or be annoying enough that Apple pays them to go away without having to sue Apple directly. They'll probably claim Apple doesn't have legal standing to get directly involved in the cases but try to force enough apps off the app store that Apple has to respond. I doubt it will work but with the craziness of patent law in this country who knows. edit: SCOTUS fairly recently said you can't take multiple bites at the "apple" so to speak, if you sue a manufacturer (i.e. apple) you can't also sue the customers. I don't know if the issue of suing customers (i.e. devs) directly was fully addressed, though I wanted to say they struck that down... as an innocent user of an infringing product you can't be sued for patent infringement in that product. However they may be trying to claim that we devs are the manufacturers in this case... but a decent lawyer should be able to prove that Apple's SDK is the actual issue. Not to mention both of these patents are so obvious as to be worthless and should fail under the KSR test but the lower courts don't seem to have fully applied that logic yet. Simulated fucked around with this message at 19:57 on May 13, 2011 |
|
#
¿
May 13, 2011 19:28
|
|
|
Major Thom posted:I've been agonizing over whether to get a 21.5" iMac or a 27" iMac. The hardware isn't the stumbling block - it's the screen resolution. I can tell you having a 1920x1200 MBP makes doing iPad screens a much better experience since the whole thing fits onscreen at one time (with no scaling). The same applies to retina screens since they are almost the same size (why iPhone4-enabled apps don't run in retina resolution on the iPad baffles me... it would be a much nicer experience). I would say get the 27"... you are gonna have that thing for a while, might as well get as much computer as you can. wellwhoopdedooo posted:Is there any difference between declaring overridden methods in the overriding class's @interface and just defining the new @implementation? Beaten like a red-headed stepchild by rjmccall but yes you can. In fact you can override any method in your implementation or a category and your method will get called instead of the base implementation. You can even override the SDK's implementations via categories (but see below). rjmccall posted:.... Bolded part is important. Just because you can do something doesn't mean you should. This applies to any programming language, but double for dynamic stuff like Javascript and quadruple for a language like Objective-C that combines C's power to shoot yourself in the foot with a JS-like flexibility to modify everything at runtime. Yes, you can use a category to hijack NSObject's alloc implementation but you have to ask yourself... is that really a good idea?
|
|
#
¿
May 15, 2011 14:13
|
|
|
Well it turns out my app crashes on iPod Touch 4G devices... no clue why, it works on iPad 2, iPhone 4, and iPhone 3GS. *sigh* I ordered an iPod Touch today so I can track this down.
|
|
#
¿
May 16, 2011 02:18
|
|
|
lord funk posted:I know why! At least, if it's the same issue I had. Well it starts up on the iPod Touch, it just crashes when you try to play a storm. I wish I had a crash log to see what is going on.
|
|
#
¿
May 16, 2011 03:29
|
|
|
You can't do it that way. When you draw outside the context of the normal draw loop, it won't get displayed. That's the reason for calling setNeedsDisplay - to let iOS know that it needs to update part of the screen (it caches the render results to improve performance and make some of the CoreAnimation effects work). Typically in a game you separate out the concerns of drawing vs game state. For example, just do the calculation to see how many lines need to go away then kick off an animation that will remove the lines and let the logic code path continue. In your drawing code, after every x amount of time you can remove another line and move things down, adjusting the animation object as you go. When the animation is finished the draw code can remove it from the queue. This is just one approach... There are many other possibilities. If you stay with your current design the performance will be limited but it might not matter for a tetris game, in which case using setNeedsDisplay (after every visible change) might suffice.
|
|
#
¿
May 17, 2011 15:54
|
|
|
Bob Morales posted:I realize that, but I thought I put [self setNeedsDisplay] in that other loop and it either didn't re-draw, or crashed. The code is at home or I'd check for sure. Hmm.. if you are calling setNeedsDisplay at the end of your main timer it shouldn't cause a crash but there are plenty of ways to shoot yourself in the foot. Do you remember what the crash was? edit: I still can't find any reason my app should crash on iPod Touch 4G devices. They have the same graphics hardware as the iPhone 4 right? It is just so wierd... it all works fine on iPad 2, iPhone 4, iPhone 3GS, and the simulator.
|
|
#
¿
May 17, 2011 23:23
|
|
|
Bob Morales posted:stuff This is all from memory so YMMV but you can't store the context because it can and does become invalid; I believe it is actually an error condition to attempt to draw to screen outside of drawRect. You can create your own bitmap context (matching your view's dimensions and scale) and draw to that, then in drawRect blit that to the screen (which is just another form of deferred rendering). Apple's stated requirements are to update your state, set needs display, then defer the actual drawing to drawRect. Like I said, iOS is doing all the caching and other nonsense (actually IIRC the drawn pixels are loaded as a texture and rendered on a set of z-ordered polygon surfaces for compositing, which is how iOS does alpha, mixing OpenGL and UIKit, CoreAnimation, etc. Basically the window manager is just another OpenGL 3D app that happens to have special system privileges). Any drawing that happens outside drawRect is happening outside of this system and you are only asking for trouble if you try to do it differently.
|
|
#
¿
May 18, 2011 04:28
|
|
|
wellwhoopdedooo posted:OK, so after loving around with custom build rules and aggregates running custom scripts and building straight into the source tree and I don't know what else, I took a look in the app bundle it builds, and everything is just stuffed into one folder there even once I've got things building into separate folders. This isn't directly related but I too like to organize my resources into subfolders and this is one of the single most annoying things about Xcode's retard file/group management and the resources stuff in general. To get stuff into subfolders in the Resources bundle I had to setup the folder structure how I wanted, copy it to the correct location in the project directory, then add it to Xcode and choose to add a folder reference. Then it got copied into the final bundle with the folder structure intact. But the resource stuff then refused to load the files so I had to grab the main bundle's path and calculate the path to the resource that way. It really seems that Apple wants you to use long multi-part filenames and actively attempts to prohibit you from any attempt at organizing via the filesystem. This also applies to your source files in general. My advice: Just give up and accept name mangling. It isn't worth it. Protip: Create a group in Xcode. Then in the File Inspector pane, click the icon/button next to the group name and it will prompt you for a folder that corresponds to the group. Go to the parent folder for this group (if any), click New Folder, name it the same as the group, then select it. Viola! Your project structure can now match the on-disk structure, instead of just randomly lumping everything into the root folder. Amazing! Protip #2: For some mongoloid reason that makes absolutely no sense, Xcode 4 will *not* show you the frameworks available for the currently selected platform like Xcode 3 did. Wondering how the hell to add a reference to MapKit or AVFoundation? Right-click an existing framework, click Show in Finder, now look at the list of framework folders and find the one you want. Drag the folder from the Finder into Xcode 4 under Frameworks. Fiddle with the trackpad/mouse until you are vaguely sure that it isn't trying to add this framework as a child of another framework. When the add dialog appears make sure you specify these settings, or curse, undo the damage you did, and restart this entire process: Uncheck "Copy" and select "Create folder references". May God have mercy on your soul if you both dragged it under an existing framework and forgot to uncheck "Copy"... I think you have to reformat and reinstall the SDK* *I am not certain if this is a joke or not. Simulated fucked around with this message at 04:44 on May 18, 2011 |
|
#
¿
May 18, 2011 04:37
|
|
|
|
| # ¿ Apr 28, 2024 21:21 |
|
|
skidooer posted:Though I am still curious if there are any OpenGL gotchas between the simulator and the actual device. Yes, thousands of them. The simulator is using your Mac's graphics hardware to draw which means you are running on a different driver, different chip, etc. Almost nothing is the same as the actual hardware. (It isn't simulating the PVR hardware the devices have.) You definitely need to run on the device to test both drawing and performance.
|
|
#
¿
May 18, 2011 16:54
|
|