Apple Development: iOS, macOS, Swift, Dylan

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Apple Development: iOS, macOS, Swift, Dylan

«‹›27 »

Doc Block: Apr 15, 2003; Fun Shoe

AFAIK the game logic for Angry Birds is written in Lua.

Also, Apple doesn't have rules against scripting languages anymore if I'm not mistaken.

# ¿ Apr 7, 2011 19:15

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 13:39

Doc Block: Apr 15, 2003; Fun Shoe

UraniumAnchor posted:

Yeah the guy I was talking to said he was under the impression it was too slow for game logic on an iOS device, but if Angry Birds uses it extensively then maybe he misheard. Or maybe the person he talked to was just a bad programmer.

So how would this work with DLC addons that include scripts? I assume I could get the addon approved by Apple and this wouldn't be an issue.

I imagine that, for Angry Birds, only the high-level logic is done in Lua. The physics, rendering code, etc., is probably mostly C++ with some Objective-C where required.

Whether or not your game will be able to get away with using a scripting language depends entirely on how processor intensive it is.

# ¿ Apr 7, 2011 20:45

Doc Block: Apr 15, 2003; Fun Shoe

Make sure you've got the right frameworks added to the project.

# ¿ Apr 23, 2011 19:18

Doc Block: Apr 15, 2003; Fun Shoe

modig posted:

I had no idea what this meant, but googled around and figured it out. Thanks.

Useless rant:
I loving thought thats what the #import command was for... why didn't it just say "hey you cant loving import that, its not part of the project".

#import and #include are preprocessor directives. They tell the preprocessor to read in the contents of whatever file you've specified and put those contents in place of the #import/#include directive. It has nothing to do with adding things to the project, because a .h file isn't a framework or a library, and the actual compiler never even sees the preprocessor directives.

And the reason it didn't fail at the #import directive is because the preprocessor could read the file you specified. The file doesn't even have to be a .h file, it could be a C or Objective-C source file, or a big commented-out text file, or whatever.

# ¿ Apr 23, 2011 21:52

Doc Block: Apr 15, 2003; Fun Shoe

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 might still do it, since a lot of the other apps look pretty terrible, but :mad:

So much for me thinking of myself as a clever guy...

Doc Block fucked around with this message at 00:33 on May 8, 2011

# ¿ May 8, 2011 00:30

Doc Block: Apr 15, 2003; Fun Shoe

klem_johansen posted:

Just about to issue a new app and I got this note warning me against compiling it with 4.3, noting that Verizon users won't be able to run them.

...?!?!

Is Verizon forcing Apple to delay 4.3 for CDMA iPhones for "testing" or whatever?

# ¿ May 10, 2011 05:44

Doc Block: Apr 15, 2003; Fun Shoe

Is it true about the "Always release on Thursday. Always." thing? If so, why do you think that is?

# ¿ May 11, 2011 18:45

Doc Block: Apr 15, 2003; Fun Shoe

skidooer posted:

I'm very new to OpenGL and 3D in general. I started learning how to do the modelling a month or so back and now I'm starting to focus on the programming end of the spectrum, specifically for iOS.

I'm trying to draw what is essentially a line using GL_TRIANGLE_STRIP. I've created an array of vertices (the dots in the image below) and I'm expecting that it should look something like this:

Now what is strange is that my solution works perfectly in the simulator, but when I tried to install it on the device I see almost nothing, just a few strange artifacts. If I change the drawing mode to GL_LINES, I do get the horizontal lines, as expected.

I am assuming the simulator uses OpenGL and I'm exploiting something that isn't supported by OpenGL ES. Do I have to redefine a previous vertex to complete the triangle? I was assuming it would figure that on its own. Is there a better approach? I need more control than what GL_LINE_STRIP offers, so I do not think it is a viable alternative.

Edit: Turns out bad data was being copied to the device, but not the simulator. It wasn't the drawing routines at all. Though I am still curious if there are any OpenGL gotchas between the simulator and the actual device.

Do you have to redefine a previous vertex to complete the triangle? No, that's the whole point of GL_TRIANGLE_STRIP, you only provide each vertex once.

Also, remember that it's a simulator, not an emulator. The simulator isn't attempting to recreate an iPhone on your Mac, it's just simulating the iOS environment on OS X. When compiled for the simulator your app is actually being compiled for x86, not ARM, and will run at the full speed of your Mac's CPU and GPU.

So while the simulator does simulate OpenGL ES, as HiriseSoftware said, you're running on a different GPU using a different driver.

# ¿ May 19, 2011 03:32

Doc Block: Apr 15, 2003; Fun Shoe

I don't think it's publicly documented by Apple, but IIRC some dudes reverse engineered it.

# ¿ May 19, 2011 17:18

Doc Block: Apr 15, 2003; Fun Shoe

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: Apr 15, 2003; Fun Shoe

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

Doc Block: Apr 15, 2003; Fun Shoe

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

Doc Block: Apr 15, 2003; Fun Shoe

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: Apr 15, 2003; Fun Shoe

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

Doc Block: Apr 15, 2003; Fun Shoe

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

Doc Block: Apr 15, 2003; Fun Shoe

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.

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?

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

Doc Block: Apr 15, 2003; Fun Shoe

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

Doc Block: Apr 15, 2003; Fun Shoe

I'm a moron, been saying TextureTool when I meant TexturePacker.

# ¿ May 24, 2011 00:36

Doc Block: Apr 15, 2003; Fun Shoe

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

Doc Block: Apr 15, 2003; Fun Shoe

AFAIK the book Learn to Program Objective-C on the Mac assumes you already know C or C++.

edit: so does Beginning iPhone 4 Development or whatever it's called. It's for iOS 4 though, and won't have any of the new iOS 5 stuff, but neither will any other book for a while.

edit2: all the books out there also seem to still be for Xcode 3.x

Doc Block fucked around with this message at 16:42 on Jun 15, 2011

# ¿ Jun 15, 2011 16:33

Doc Block: Apr 15, 2003; Fun Shoe

I haven't looked at the ARC stuff too closely, but if there are no dealloc methods then how do you clean up when your object goes away?

# ¿ Jun 16, 2011 18:43

Doc Block: Apr 15, 2003; Fun Shoe

rjmccall posted:

ARC destroys __strong and __weak instance variables at the same time that it would call the destructors of C++ instance variables, which is basically during -[NSObject dealloc]. You can still write dealloc methods in ARC if you need to; they're just not required for ivars, and [super dealloc] is called implicitly at the end.

Thanks, good to know.

baronmasochist posted:

"It just works"

The dealloc method still exists, it's just getting filled in by the compiler instead of you having to actually write it out explicitly. It's a bit like if the compiler ran static analysis on your source and then fixed all the problems it found instead of throwing up analyzer messages.

Yeah, I knew the compiler would clean up your ivars and whatnot, my curiosity was just more along the lines of how do you clean up an object with cleanup requirements beyond just calling release on some things if there's no dealloc method in ARC. but rjmccall answered that, so evidently you can still have dealloc if you need it.

Doc Block fucked around with this message at 21:07 on Jun 16, 2011

# ¿ Jun 16, 2011 20:37

Doc Block: Apr 15, 2003; Fun Shoe

Is it normal for the root view controller's viewDidLoad method to be called before the app delegate's application:didFinishLaunchingWithOptions: method?

# ¿ Jun 22, 2011 07:58

Doc Block: Apr 15, 2003; Fun Shoe

pokeyman posted:

That sounds abnormal but not impossible, especially if the root view controller is in your main nib file. Do you have a problem triggered by the ordering of the calls, or are you just curious?

Yeah, my app delegate is supposed to restore the app's state on startup, but since the root view is somehow getting loaded first, it will always act as if this is the first time the user has run the app.

It's a universal app, started from the Window template, and I think the problem is just how I connected everything up. The root view controller is in a separate nib.

edit: aaand it's fixed. :ughh:

Ask for help and immediately get it working yourself.
I think the overall gist of it was that I had connected the root view controller to the main window's rootViewController property in Interface Builder (or whatever it's called now in Xcode 4) instead of doing it in code in the app delegate's application:didFinishLaunchingWithOptions: method. And when MainWindow.xib was loading, my root view controller would get loaded too because of the connection made in IB.

Doc Block fucked around with this message at 09:10 on Jun 22, 2011

# ¿ Jun 22, 2011 08:54

Doc Block: Apr 15, 2003; Fun Shoe

What don't you understand? You can't access self.whatever if whatever isn't a declared property of self. UITableViewDelegate and UITableViewData aren't classes you're extending, they're protocols. Basically, saying that your class conforms to a certain protocol is a way of telling other classes that your class implements certain methods.

For instance, if your class is the delegate for a table view, the table view can check to see if your class has been declared as conforming to the UITableViewDelegate protocol, and know that your class implements the methods necessary for the table view to tell your class when something happens, etc.

# ¿ Jun 26, 2011 02:12

Doc Block: Apr 15, 2003; Fun Shoe

Keep in mind that Cocoa and Cocoa Touch are pretty big on the whole model-view-controller paradigm. And protocols are pretty much the same thing as interfaces in C# and Java, as far as I know.

Read these two important links from the OP: The Objective-C Programming Language and Memory Management Programming Guide.

Also, even though you're a .NET and Java programmer, From C++ to Objective-C might be at least a little helpful, and is fairly short. This one helped me a lot.

And if you have questions about a specific class, a good place to start is Apple's own docs for that class (which are usually the first or second result of googling for the class name).

Doc Block fucked around with this message at 08:35 on Jun 26, 2011

# ¿ Jun 26, 2011 08:18

Doc Block: Apr 15, 2003; Fun Shoe

Lemme just go ahead and post this: UIWebView Must Die

# ¿ Jun 29, 2011 09:50

Doc Block: Apr 15, 2003; Fun Shoe

What's wrong with Objective-C?

# ¿ Jun 30, 2011 18:28

Doc Block: Apr 15, 2003; Fun Shoe

A class method like imageNamed or imageWithContentsOfFile (a so-called convenience method) is going to return an object you don't own. The way to think of it is that if you didn't create the object explicitly, but instead got it from a convenience method, then you don't own it and shouldn't release it (unless the method's docs say otherwise).

# ¿ Jul 9, 2011 03:50

Doc Block: Apr 15, 2003; Fun Shoe

I have a Mac programming question. Once I'm done with the iPad app I'm working on I want to do a Mac app.

This will be a content creation app and I want it to be able to use plugins. Right now my idea is for plugins to be compiled as shared libraries, load them with dlopen(), and call a C function inside the plugin (load_PLUGINNAME or something) that creates an instance of the plugin and returns a pointer to it.

My question is: is there a better way? A more Objective-C/Cocoa-ish way?

# ¿ Jul 11, 2011 20:34

Doc Block: Apr 15, 2003; Fun Shoe

Gordon Cole posted:

I have almost no experience with this, but I'm pretty sure that Cocoa Bundles are exactly what you're looking for.

http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/LoadingCode/LoadingCode.html%23//apple_ref/doc/uid/10000052-SW1

Thanks, that looks pretty helpful.

# ¿ Jul 12, 2011 01:12

Doc Block: Apr 15, 2003; Fun Shoe

Campbell posted:

After first going up to the store, the app got pulled because of rule 3.3.2 against interpreted code. I'm kind of thinking that initially he was reading stuff at runtime, and then had to go and compile everything natively or something to get back on the store. The games folder then, being a relic of that original code. That doesn't answer anything about the emulator part though.

I'd love to know more about its architecture because it seems to do some pretty tricky stuff behind the scenes.

It was rejected initially because it had a BASIC interpreter that was user-facing (can't make apps that are basically SDKs for end users), and I think there was something about Apple not being sure if the developer had gotten permission from the owners of the games he was including, and the developer threw a huge hissy fit and whined about evil Apple all over the tech news sites.

Then the developer "removed" the BASIC interpreter and licensed the games he was including, which finally got the app onto the app store, until somebody discovered that the BASIC interpreter was still there as an easter egg and could still be accessed if you knew how, so Apple pulled the app.

Then they removed the BASIC interpreter for real and got back onto the app store.

From what I can recall the whole "no interpreted code" thing didn't enter into it too much. Many of the rules get relaxed for games, and many "classic" games were literally just a dumped ROM and an emulator. Never mind that Angry Birds uses Lua extensively, and it came out long before the ban on interpreted code was lifted.

# ¿ Jul 13, 2011 18:29

Doc Block: Apr 15, 2003; Fun Shoe

McFunkerson posted:

I'm smashing my head against a wall trying to get a subview to draw and I just don't understand what I'm doing wrong.

I have subclassed NSView and have a subview I am trying to draw in that view. I know the subview works fine because if I do:
code:
-(void) drawRect: (NSRect)dirtyRect
{
    rect.size.width = 832;
    rect.size.height = 120;
    NSPoint point = { 0, 0 };
    rect.origin = point;
    TabloidProgressView *newJob = [[TabloidProgressView alloc] initWithFrame:rect];
    [self addSubview:newJob];
{
it works fine. However what I'm trying to do is use an NSOperation to send notifications to my NSView to add in a subview. So I have something that looks like this:
code:
-(void) newJobNotification: (NSNotification *) notification
{
    ++jobCount;
        rect.size.width = 832;
        rect.size.height = 120;
        NSPoint point = { 0, ((jobCount *120) - 120) };
        rect.origin = point;
        TabloidProgressView *newJob = [[TabloidProgressView alloc] initWithFrame:rect];
        
        [self addSubview:newJob];

        NSLog(@"Notification Count %i", [[self subviews] count]);
    }
}
code:
- (void)drawRect:(NSRect)dirtyRect
{
    NSLog(@"Draw Count %i", [[self subviews] count]);
}
When this runs, nothing visually happens. My subview count in the notification is 1 like I'd expect, but in drawRect: it's 0. I can actually add a job with the GUI, get a subview count on 1 in the notification, then get a 0 in the drawRect: and then add a second job and get a 2 in the notification. WTF isn't drawRect: seeing my subviews?

I don't know much about OS X programming yet, but maybe try [self setNeedsDisplay:YES] once you add the new subview?

Also, unless your app is garbage collected, you need to release newJob after the addSubview call (NSView retains its subviews).

edit: and unless you're doing custom drawing, you don't need to implement drawRect:. In fact, your custom drawRect: is keeping the NSView class's drawRect: from being called, so if you're just testing try adding [super drawRect:dirtyRect] after the NSLog() call in your drawRect:

Doc Block fucked around with this message at 18:49 on Jul 13, 2011

# ¿ Jul 13, 2011 18:44

Doc Block: Apr 15, 2003; Fun Shoe

It's not compiled into the binary, but it is in the app bundle. Open up the IPA and see, from what I can recall there are a bunch of .lua files (of course, they've been compiled to bytecode with the lua compiler, so you can't read them).

Conceptually, downloading new game logic and executing it isn't that big of a deal, assuming the new logic is in an interpreted language. You just download it like you would any other file, then have your app's built-in Lua interpreter run it when needed.

# ¿ Jul 13, 2011 19:21

Doc Block: Apr 15, 2003; Fun Shoe

Use the diff viewer or whatever it's called and see what changed.

# ¿ Jul 13, 2011 21:17

Doc Block: Apr 15, 2003; Fun Shoe

Yeah, sorry, I wasn't trying to imply that downloading new code was allowed. I was just responding to Campbell's comment about downloading new code hurting his head, just that conceptually it isn't that hard (for interpreted languages, anyway).

# ¿ Jul 14, 2011 01:48

Doc Block: Apr 15, 2003; Fun Shoe

Does the Torque3D engine still have an iPhone port? If so you can try that. It isn't open source, but you do get the source code.

# ¿ Jul 14, 2011 16:28

Doc Block: Apr 15, 2003; Fun Shoe

Looks like it's just a view with text fields that animates out from underneath the toolbar. So when you tap the toolbar's search field, it brings out the other view.

# ¿ Jul 14, 2011 19:22

Doc Block: Apr 15, 2003; Fun Shoe

KVO is supposed to be synchronous AFAIK, but that doesn't necessarily mean the observer gets called on the same thread.

Try performSelectorOnMainThread, so your observe method would instead do

code:

[sv performSelectorOnMainThread:@selector(setSeqStartPosition:) withObject:[newVal integer] wait:YES];
[sv performSelectorOnMainThread:@selector(updateSeqRangeDisplay) withObject:nil wait:NO];

or something.

edit: or maybe you have conflicting key-value observations

Doc Block fucked around with this message at 00:04 on Jul 17, 2011

# ¿ Jul 16, 2011 23:58

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 13:39

Doc Block: Apr 15, 2003; Fun Shoe

The new edition of Cocoa Programming For Mac OS X is coming out in October, I think it's been updated for Xcode 4. Also Snow Leopard!

Unfortunately even tech book publishers are slow and usually a version or two behind.

You can still use the information in books written for Xcode 3, the stuff specific to Xcode will just be a little different.

Doc Block fucked around with this message at 16:54 on Jul 20, 2011

# ¿ Jul 20, 2011 16:52

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Apple Development: iOS, macOS, Swift, Dylan

«‹›27 »