Posts Tagged ‘Cocoa’

Interior Pointers For The Lose

Friday, December 19th, 2008

Remember the post I made awhile back, talking about how I needed to turn off optimizations for two pieces of code and I didn’t understand why? Of course you do, it was here, remember? Well, I was listening to the latest episode of Late Night Cocoa wherein they were talking about garbage collection. The guest, Andre Pang, made a comment about how crashes with code that uses C pointers into NSData objects were fairly common. Ding ding ding!

See, the problem is this. I have code this like at the top of my problem functions:

NSData* theData = [some data blob];
byte* myPointer = [theData bytes];

The problem here is that I then use “myPointer” for the remainder of the function as I read from the data blob. As far as the runtime is concerned, I’m done with “theData” since I never talk about it again throughout the entire function. It doesn’t care about my C pointer, it only sees that I’m no longer talking about “theData“. So it marks it as collectable and the GC comes along at some random point and removes my data from underneath my feet.

The solution is to add a line of code to the end of the function that looks like this:

[theData self];

This is a do-nothing line of code but it DOES force the runtime not to mark the object as collectable since it’s going to be talked about again at the end of the function. This fixes my random crashes! I was able to remove the stupid pragma statements and now everything hums along as it should.

Amazing what you can learn from a humble podcast! Thanks, Late Night Cocoa!

Core Data Twiddling

Monday, October 13th, 2008

I got the itch over the weekend to get back into application coding. I’ve been away doing level design for awhile now and the programming side of my brain was starting to feel neglected. So it’s time to get some book learnin’ done!

I decided to take another stab at a photo viewer. Unimaginative, I know, but it does provide a good platform for learning. I’m going to try a different tactic than I normally do. Normally, I create a monolithic application that evolves over time as I learn new things or better ways of doing existing things.

This time I’m taking it slow. I’m creating small applications that demonstrate one piece of technology that I need for the larger photo viewing application. For example, I created one on the weekend that takes a group of images and creates proportionally scaled thumbnails for them (for testing purposes, it wrote them out to my hard drive as well so I could physically see the results). After that, I started into an application to teach myself Core Data.

Core Data looks really interesting. I know that I want to store the thumbnails and tags and references to the original images in some sort of database – ideally using SQLite since the Mac has native support for that format. When I did this stuff the first time I wrote the database handling code by hand which was a major hassle so I decided to delve into Core Data this time around.

So far I’m definitely happy with what I’m seeing. Using the visual data modeler they have built into XCode is very easy and the fact that it generates the glue code to get to the database entities themselves is pretty slick. I really like how with 2 code changes you can switch from an SQLite database to an XML file. That will prove to be invaluable when it comes time to debug issues. Being able to see what was written to the database in text form makes it so nice.

I don’t have anything significant working yet but I’m on the right track here.

Command Line Processing In Cocoa

Saturday, July 12th, 2008

I stumbled over this great article from 2006 that outlines a really easy to use method of grabbing command line arguments in a Cocoa application.

Read About It Here

I threw this into a test application and it works great! Amazing what you can find on the web sometimes.

QuakeC Char Emitter

Wednesday, March 5th, 2008

So I was struggling with trying to set up an ending cinematic screen for Qonquer. I wanted to do a screen where it would spit out some stats on your game and give you some closure rather than just sitting there staring up from the floor in your dead body.

However, when I tried to customize the text being sent to the SVC_FINALE screen in QuakeC I discovered that you can’t send a dynamic text block. You can only send a static string. Even better, you can’t even send multiple strings. You can only send one if you’re using the WriteString function. Nasty.

So Preach over at func_msgboard gave me a link to some source code that included routines for spitting out chars to a channel in QuakeC. There were 8 versions of the function, each sending from 1-8 characters at a time to the channel (I named them pr1() through pr8() in my code base). I thought I was home free. Nope! Those emit values, not characters. Which means that if you want to spit out, for example, the word “Qonquer” you need something like this in your code:

pr7( 81,111,110,113,117,101,114 );

Those numbers are the ASCII character codes for each letter. Yeah, not exactly intuitive to read OR to write.

So what I ended up doing was writing a real simple Cocoa application to help me out. It will take a text string and split it up into the necessary function calls to get that text into the SVC_FINALE screen.

For example, let’s say I wanted to spit out “[Qonquer] – game over!”. I would use my program and it would generate this:

// [Qonquer] - game over!
pr8( 91,81,111,110,113,117,101,114 );
pr8( 93,32,45,32,103,97,109,101 );
pr6( 32,111,118,101,114,33 );

As you can see, it breaks the string up into multiple calls because QuakeC can only handle 8 arguments in any given function. It also emits a comment line at the top so you can see what those lines are supposed to be emitting.

Here’s a screenshot of the utility in action:

quakecemitter.jpg

I need to add some checkboxes and things to this screen to support adding newlines and things like that but this is basically it! This will help me out a lot on this and future QuakeC projects. When it’s done, I’ll make the source available with the rest of the Qonquer mod.

Multithreading Brings Joy

Sunday, February 3rd, 2008

I’ve been listening to Cocoa oriented podcasts and subscribing to RSS feeds in an attempt to get my knowledge base up to snuff. While listening to “Late Night Cocoa” I was happy to find that the most recent episode featured multithreading and the guest was the head Mac guy over at Google (aka guy who knows what he’s talking about). It was great! Very informative and it gave my wife many excuses to make nerd jokes at my expense.

At any rate, he talked about a pair of classes that remove 90% of the pain of multithreading. NSOperation and NSOperationQueue. Using those, I was able to replace all of my multithreading code in Phorg and now it runs faster, automatically scales based on system performance, and I don’t have to worry so much about locking and synchronizing. Look into those classes if you have any plans to delve into multithreading on the Mac. So worth it!

I’ve been able to add a bunch of multithreading to ToeTag today as a result of using these classes. Everything is a little faster from loading WAD files, to generating mipmaps, to loading MAPs, etc. It’s amazing how once you have multithreading at your disposal how you can suddenly see spots in your code that could benefit.