|
I have seen people claim that AirPlay is an open protocol and I've also seen people claim there are apps out there that can stream pictures to AppleTV. What I haven't found is an actual specification for the AirPlay protocol. Does anyone know if it is documented anywhere? I'd like to send pictures specifically but as far as I know that isn't supported in the SDK.
|
#
?
May 19, 2011 15:02
|
|
|
|
| # ? May 15, 2024 19:04 |
|
|
I don't think it's publicly documented by Apple, but IIRC some dudes reverse engineered it.
|
|
#
?
May 19, 2011 17:18
|
|
|
pokeyman posted:I'm sure you've had a look at the Key-Value Coding Programming Guide. Specifically, I mean the part where it discusses resolving key paths to values. If a method with the same name as the key is implemented, it gets called and its return value is the value for the key path. Otherwise, if an instance variable with the same name exists, its value is returned. Thanks pokeyman. I still haven't got to this stage yet because I gave up on subclassing my sprite methods for a bit to make progress in other places, but this will help so much and makes a ton of sense to use it. I have yet another problem if anyone wants to help. Right now I can't get it to run on my device without immediately crashing. It worked with a much older version. I made a question on Stack Overflow if anyone wants to see more details: http://stackoverflow.com/questions/6049827/cocos2d-crashing-on-iphone-immediately-but-not-in-simulator But basically on the simulator, I get a message in the console "CCSpriteFrameCache: Trying to use file 'heroTestSheet.png' as texture" but everything seems to work fine. Putting it on to a device just gives me a white screen until it crashes and the console gives me a report. I saw this a lot of time has to do with filenames in my resources verses my code have different capital letters, but I've looked over all of them and even revealed them in the Finder to make sure.  Starting to think it has to do with how I'm coding the sprite class and I did something wrong. LP0 ON FIRE fucked around with this message at 18:36 on May 19, 2011 |
|
#
?
May 19, 2011 18:33
|
|
|
In the Cocos2D debug output it says that it couldn't find one of the frames you specified. Open the plist in a plist editor and see what is actually in there. Also, what are you using to generate the sprite atlases in the first place?
|
|
#
?
May 19, 2011 18:40
|
|
|
Doc Block posted:In the Cocos2D debug output it says that it couldn't find one of the frames you specified. Open the plist in a plist editor and see what is actually in there. In the plist there is heroFrame1.png and heroFrame2.png. Which means it's using the plist to make those from the texture heroTestSheet.png, right? Here's a shot:  I'm using Zwoptex. edit: I just wanted to add that I also put this in my zone class that adds the map and the sprite in init: hero = [[HeroClass alloc] init]; [self addChild:hero.heroSpriteSheet]; I didn't do addChild to anything else for the hero class which I hope is okay and makes sense. LP0 ON FIRE fucked around with this message at 19:37 on May 19, 2011 |
|
#
?
May 19, 2011 19:09
|
|
|
I'm searching around my build settings and info plists for what I can do to change the default language of my app in the store. It's a Chinese app offered only in the Chinese store. It's not really a localized app, so I haven't messed around with that. I have a suspicion that changing the Localization native development region, but I want to be sure before uploading a new binary. Would setting it to Taiwan make any difference? Or could it be that it's an error on Apple's side? Someone mentioned that it could be a matter for iTunesConnect support.
|
|
#
?
May 19, 2011 21:54
|
|
|
klem_johansen posted:I'm searching around my build settings and info plists for what I can do to change the default language of my app in the store. It's a Chinese app offered only in the Chinese store. It's not really a localized app, so I haven't messed around with that. I have a suspicion that changing the Localization native development region, but I want to be sure before uploading a new binary. This is a shot in the dark but... If you can change the country to Taiwan, can't you change it to China? If China's not there, try People's Republic of China as that is the official name of the country.
|
|
#
?
May 20, 2011 10:17
|
|
|
NOG posted:But basically on the simulator, I get a message in the console "CCSpriteFrameCache: Trying to use file 'heroTestSheet.png' as texture" but everything seems to work fine. Putting it on to a device just gives me a white screen until it crashes and the console gives me a report. I saw this a lot of time has to do with filenames in my resources verses my code have different capital letters, but I've looked over all of them and even revealed them in the Finder to make sure. Then run your App on the device and step into the code line by line verifying that everything is working as you'd expect until you find the point at which Cocos is giving up on loading/creating the texture. That'll give you (and us) a big hint as to what's failing. Cocos isn't a particularly fat framework and is pretty well structured & commented so you shouldn't be afraid to delve into its code to discover just what it's doing when expectations are being confounded.
|
|
#
?
May 20, 2011 13:33
|
|
|
Sir Davey posted:This is a shot in the dark but... If you can change the country to Taiwan, can't you change it to China? If China's not there, try People's Republic of China as that is the official name of the country. Everything I read tells me that I need to add .lproj localization folders but this isn't a localized app. It's a single language but somehow the app store won't say that it's Chinese.
|
|
#
?
May 20, 2011 21:33
|
|
|
Maybe an app without any localization info is considered "localized" to English. So you most likely *do* need to add a Chinese localization, but make it the only one.
|
|
#
?
May 20, 2011 21:40
|
|
|
Thanks! I think you're right. I recently did a Dutch one and it's listed as dutch in the store without me having to do a thing. I think Chinese might be an odd case since the character encoding might be different.
|
|
#
?
May 20, 2011 21:42
|
|
|
iOS disk: can someone briefly summarize what the correct options are for writing to disk on iOS? I have a couple of settings I need to store, and potentially some other dictionary or array-like data. The options have changed over time, and I'm trying to avoid reading 100 meandering blog posts to figure out what could be succinctly stated in a a few lines.
functional fucked around with this message at 23:56 on May 20, 2011 |
|
#
?
May 20, 2011 23:48
|
|
|
AFAIK you still just write to Documents, and it'll get backed up when the user syncs their device with iTunes. The actual method can be anything, you can just write binary blobs with fwrite() if you want. You could save to XML, an SQLite database, CoreData, or whatever, it just depends on your data.
|
|
#
?
May 21, 2011 00:04
|
|
|
Thanks, Doc Block, exactly what I was looking for.
|
|
#
?
May 21, 2011 00:10
|
|
|
A lot of people forget that all the Unix stuff is still in there, including all the Unix file stuff. John Carmack wrote up an interesting blog post about using relatively low-level Unix stuff like memory mapped files in Rage HD. Doc Block fucked around with this message at 00:53 on May 21, 2011 |
|
#
?
May 21, 2011 00:47
|
|
|
Doc Block posted:A lot of people forget that all the Unix stuff is still in there, including all the Unix file stuff.
|
|
#
?
May 21, 2011 01:02
|
|
|
For simple stuff like settings you can use NSUserDefaults. It is also trivial to serialize plists.
|
|
#
?
May 21, 2011 03:50
|
|
|
ynohtna posted:Stick a breakpoint on the line which calls [[CCSpriteFrameCache sharedSpriteFrameCache] addSpriteFramesWithFile:@"heroTestSheet.plist"]; Thanks for the suggestion. So it stopped on CCTexture2D *texture = [[CCTextureCache sharedTextureCache] addImage:texturePath]; in the addSpriteFramesWithFile:(NSString*)plist method in CCSpriteFrameCache.m. Is a .png a valid texture? Still don't get what's wrong, but I guess it can't get the correct path or something?
|
|
#
?
May 21, 2011 21:17
|
|
|
Yes, a PNG is a valid texture. Dunno if Cocos2D can deal with color indexed PNGs or progressive PNGs, though. For whatever reason it can't load the heroTestSheet.png. I'm not really familiar with a lot of the new Cocos2D stuff, try asking the Cocos2D forums.
|
|
#
?
May 21, 2011 22:49
|
|
|
Figured it out.. it's so stupid, but it was just the heroTestSheet.png it was trying to use was somehow invalid. I exported in an older photoshop, but I'm not really positive what settings it had. I exported it again from a newer photoshop without any color mange settings, and now it works fine! I stepped through the Cocos2D methods when I was debugging, and getting the message "CCSpriteFrameCache: Trying to use file 'heroTestSheet.png' as texture" in the console is totally fine, it's just saying it's doing something different to assign the filename.
|
|
#
?
May 22, 2011 00:20
|
|
|
Wait... why are you putting together a sprite sheet in Zwoptex and then messing with it in Photoshop? Glad you figured it out at least.
|
|
#
?
May 22, 2011 00:31
|
|
|
Had a discussion with another developer and now I'm curious. Anyone here do programmatic layouts? If so, where do you your cleanup for loadView?
|
|
#
?
May 23, 2011 09:48
|
|
|
Small White Dragon posted:Had a discussion with another developer and now I'm curious. Yes, what do you mean by cleanup? nil your subview properties in viewDidUnload and in dealloc.
|
|
#
?
May 23, 2011 10:42
|
|
|
[tell] me about Core Data. As someone who's very comfortable in both SQL and C, and who started to miss things you can do in SQL in the first 15 minutes of modeling my data, why should I use it anyway? The advice to use it seems very emphatic.
|
|
#
?
May 23, 2011 18:47
|
|
|
Doc Block posted:Wait... why are you putting together a sprite sheet in Zwoptex and then messing with it in Photoshop? Glad you figured it out at least. The sprite sheet was already one graphic. I just want the plist. This way I can still go back into photoshop and make any changes I need. That's okay, right? Maybe that doesn't make sense, I don't know. Probably doesn't, but I'll learn. Anyway, I'm trying to make this run fast on older iPhone models, 3G and prior. It runs at a full 60 fps on iPhone 4, but around 30 on 3G. I've seen an automatic way to ignore tile rendering outside of a screen area, but I can't find the page that showed how to do this. Does anyone know what I'm referring to?
|
|
#
?
May 23, 2011 19:48
|
|
|
OHIO posted:Some patent troll is asking for licenses on people using in-app purchases: http://cultofmac.com/ios-devs-under-fire-by-patent-troll-for-offering-in-app-purchases/94916 Apple is not going to stand for the in-app-purchases patent troll! http://www.macworld.com/article/160031/2011/05/apple_legal_lodsys_letter_text.html
|
|
#
?
May 23, 2011 20:46
|
|
|
NOG posted:The sprite sheet was already one graphic. I just want the plist. This way I can still go back into photoshop and make any changes I need. That's okay, right? Maybe that doesn't make sense, I don't know. Probably doesn't, but I'll learn. I don't know if Zwoptex does, but TextureTool can be called from the command line, and you can make a custom build step in Xcode that will call TextureTool to assemble the sprite sheet as part of the app's build process. I don't recommend opening up the sprite sheet and modifying it directly. Also, keep in mind that pre-3GS devices have a max texture size of 1024x1024 and only have 128MB RAM. They also make up a pretty small segment of the iOS market.
|
|
#
?
May 23, 2011 20:49
|
|
|
wellwhoopdedooo posted:[tell] me about Core Data. For me, Core Data answers the question "what can I use to persist my model objects, assuming I don't give a poo poo at all about how it's done?" In theory, there's basically zero friction when using Core Data. Need to fetch a collection of related objects? Just use them and Core Data will fetch them on demand. Need to save everything? Just send -save. Need a new scratchpad to make some objects and relationships? Fire up a new context and save it (or ditch it) when you're done. Core Data is fast as hell, there's almost nothing you can do faster if you do it manually. Oh, and mogenerator is fantastic at writing cruft-removing code for you. In practice, I find Core Data to be quite painful. Maybe it's because I get mad at it and swear off using it for months, thereby forgetting everything about it in the intervening period. But I find its promise of free undo management consistently broken (the actions sent to the undo manager were whacked). Handling validation errors at save time really sucks, especially on the save just before the app quits. And I typically have to write some code over top of Core Data to do away with some of its verbosity (check the docs for, say, fetching all the objects of one kind). And NSFetchedResultsController sucks. Overall, if you like accessing databases in C, you might find Core Data just gets in your way. On the other hand, if you're of the opinion that less code means less time wasted debugging and supporting, Core Data can replace huge chunks of your code. Just don't believe all the hype around Core Data! You still need to write code, undo isn't free, etc.
|
|
#
?
May 23, 2011 21:05
|
|
|
Doc Block posted:I don't know if Zwoptex does, but TextureTool can be called from the command line, and you can make a custom build step in Xcode that will call TextureTool to assemble the sprite sheet as part of the app's build process. I don't recommend opening up the sprite sheet and modifying it directly. Thanks for the info. So a work flow of making a sprite sheet with an automated plist, is usually making separate files for each sprite, and then assembling them together in sprite sheet tool like Zwoptex to make the sheet? The only thing that catches me off guard about this is now someone is making graphics in a bunch of separate files, which seems disorganized and confusing. Maybe I'm just crazy, but is this the way it's usually done? I'll definitely look into Right now all I'm using is a test player sprite sheet thats 128x64 and split up into two 64x64's, and a texture atlas for the tiles that's only 320x320, that's split up into 16x16's. My background is just a gradient background rendered from code. I should have mentioned, but I'm also testing this on iPad 1 and 2 which are displaying a lot more tiles. On the iPad 1, it runs 30 fps, much like the iPhone 3G. On the iPad 2, it runs 60 fps, much like the iPhone 4. It's good to know there's very little market for pre 3GS devices, but I'm curious if there was something I could do to give a significant boost in performance, or if that's what usually happens to pre-3GS devices and Cocos2D. LP0 ON FIRE fucked around with this message at 06:22 on May 24, 2011 |
|
#
?
May 23, 2011 21:19
|
|
|
Yes, AFAIK most people work on each sprite as a separate file. There are a few advantages to this, a big one being that you can work on the sprite on its own, then let Zwoptex or TextureTool optimize how it all goes onto the sprite sheet. Different frames can be different sizes, etc. Also, with TextureTool at least, it will show you how the sprite sheet would look if reduced to RGBA444 or RGB565 or whatever, and can even go ahead and do the quantization when it saves the sprite sheet. So you would at least want to have your "original" sprite sheet that you made in Photoshop and then have TextureTool output a "final" sprite sheet that's been saved in a device-friendly format. Which leads me to my next point, optimization. One of the ways you can optimize your game to help it run better on older devices is reduce your texture size. Cocos2D can convert your 32-bit PNGs down from 8 bits per channel (RGBA8888) to 4 bits per channel (RGBA4444), which reduces the texture size in memory and also increases performance since the GPU will be able to fit more of the texture in it's cache. It can also convert to RGB565 for textures that don't need an alpha channel (like backgrounds), and other formats as well if memory serves. You may also want to look at using PVRTC for some of your textures. This is one place where having your sprites all be in separate files comes in handy, because you can put the sprites that still look acceptable in PVRTC one one sprite sheet and the rest on another. Another optimization is to use a 16-bit framebuffer instead of a 32-bit one, if it doesn't cause too much color banding. I don't remember if this is the default for Cocos2D or not. Also, as to your 320x320 texture atlas for tiles: NO! That texture is going to get bumped up to 512x512, which is the nearest power-of-two size that will fit the whole thing. Lastly, read Cocos2D's best practices guide.
|
|
#
?
May 24, 2011 00:26
|
|
|
 I'm a moron, been saying TextureTool when I meant TexturePacker.
|
|
#
?
May 24, 2011 00:36
|
|
|
pokeyman posted:Stuff I second this motion. The problem with CoreData is the same problem I have with the whole framework as compared to something like C#... I end up writing the same boilerplate over and over (and so does everyone else). Everyone ends up writing unique ID generation stuff. Everyone rewrites pulling all of the same object out. Everyone rolls their own undo. No generics or custom typing of properties so everyone has a different solution for dealing with the fact that all your bools, floats, and ints end up as NSNumbers. Still, I do use it.
|
|
#
?
May 24, 2011 07:05
|
|
|
wellwhoopdedooo posted:[tell] me about Core Data. The price you pay, of course, is that Core Data is a tremendously overengineered framework and a pain in the rear end to use. Particularly, doing database migrations are a *bitch* (if anyone has difficulties with this in their app, feel free to PM me). Is it worth it? If you're doing a database driven iOS app, I would say yes, since there's a lot of useful stuff you get for free. But there is definitely a learning curve to it.
|
|
#
?
May 25, 2011 06:30
|
|
|
I was just tasked with writing an image exporter / upload plugin for Aperture and iPhoto at my job. While I can find plenty on Aperture, I can not find anything remotely recent about where to begin on writing a plug-in for iPhoto or if there is an API available for it. Perhaps I am missing something and don't know where to look for documentation, so any help would be appreciated.
|
|
#
?
May 26, 2011 18:31
|
|
|
I'm trying to create a write-only property. If I just define the set* method like thiscode:code:code:
|
|
#
?
May 27, 2011 00:17
|
|
|
Why are you trying to use properties for this? Just call [foo setBar:@"YOURMOM.LAFFO"]; A property is supposed to look (to the caller) like an instance variable, and a write-only variable doesn't make sense.
|
|
#
?
May 27, 2011 00:29
|
|
|
fankey posted:I'm trying to create a write-only property. If I just define the set* method like this No there is not. It only supports readwrite and readonly @property declarations, though the usefulness of a write only property is debatable, since your code should be using the getter inside the class anyway.
|
|
#
?
May 27, 2011 03:46
|
|
|
fankey posted:I'd rather not have a bunch of dummy accessor functions that return garbage since I'm not storing the state - it gets passed on to another layer. A setter is not what you want if you're literally doing nothing but passing along the message. Just make it a method. Maybe you could post the actual problem you're trying to solve and we can help organize it for you? (Note: code is better than a description.)
|
|
#
?
May 27, 2011 05:10
|
|
|
Apparently I kicked the write-only property hornets nest. I was mainly curious as to why it didn't work. Is it an intentional design choice in ObjC to fail so one cannot create write-only properties or is it a side effect of how properties are implemented? The Property Declaration docs state that you must have both a setter and getter. Since I wasn't declaring the property explicitly I was surprised I got an error.
|
|
#
?
May 27, 2011 06:50
|
|
|
|
| # ? May 15, 2024 19:04 |
|
|
Without getting into write-only, you don't capitalize the property when setting it. -(NSString *)bar; -(void)setBar:(NSString*)str; means you use foo.bar = @"whatever"; //not foo.Bar = ... It probably still won't work without a getter though.
|
|
#
?
May 27, 2011 07:10
|
|
