Rewriting a (rather large) codebase in Cocoa

Member
Posts: 67
Joined: 2006.07
Post: #1
So a few years back I made the (now I realize gravely mistaken) decision to write a fairly large scale 2D platform scroller game in Carbon/QuickDraw, mainly because they were faster than Cocoa/Quartz (yes, it was pretty noobish of me). After having discovered OpenGL, I realize now that Cocoa's overhead doesn't matter because of OpenGL's speed. However, the game's ~80% done, with 25,000+ lines of Carbon code, yet due to compatibility problems and memory management issues, I'm considering switching the codebase to Cocoa.

I'm kind of stuck in a dilemna, because Carbon's giving me a lot of unnecessary headaches, and I know Cocoa pretty well (having used it for everything except this game), but most of the game is already done. I'm also conflicted because my whole event handling model will have to change -- I initially wrote it like they did in the old days, in a tight loop (with an occasional WaitNextEvent()). But I'm on Leopard (10.5.1), and Carbon's basically deprecated anyway.

Anyways, is it worth it to completely rewrite the codebase in Cocoa this late in the game, or should I just finish the game off in Carbon and then leave Carbon behind forever?
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #2
That depends entirely on what you want to get out of it. How long will it take you to finish? How much of your game is "actually" Carbon, and how much is API-neutral? Do you care about a Windows or Linux port? Are you going to sell the game when it's done or is this just a learning exercise? Do you want to continue to support the game on new OSes 3 years away? 5? 10?
Quote this message in a reply
Moderator
Posts: 1,560
Joined: 2003.10
Post: #3
If Carbon API calls aren't scattered throughout the entire codebase, it may be possible to do a minimal amount of work to switch over to Cocoa and OpenGL while leaving most of the code intact. Switching out the event loop, for example, should be pretty trivial, but that again depends on how you've structured your code.
Quote this message in a reply
Apprentice
Posts: 6
Joined: 2008.06
Post: #4
I'd recommend rewriting it in Cocoa.

1: It sounds like you are not going to every use carbon again, so no use in working more in it.

and

2:The "translating" will help you learn more in Cocoa, even though you are already experienced in it.
Quote this message in a reply
Member
Posts: 67
Joined: 2006.07
Post: #5
OneSadCookie Wrote:That depends entirely on what you want to get out of it. How long will it take you to finish? How much of your game is "actually" Carbon, and how much is API-neutral? Do you care about a Windows or Linux port? Are you going to sell the game when it's done or is this just a learning exercise? Do you want to continue to support the game on new OSes 3 years away? 5? 10?

Yeah, basically this is a learning experience/hobby game, although I could theoretically market it as shareware once I'm done. But then again, who'd want another Super Mario Land? (albeit extended and with different sprites, storyline, etc.) Still, I designed it with the sole intention of keeping it a Mac-only game, so API-neutralness is not a major priority.

I'd probably be able to finish the entire game by the end of the summer if I was working full-time, but seeing as it's more of a hobby right now, I've been working part-time on it (which is why the development's taken several years now).

ThemsAllTook Wrote:If Carbon API calls aren't scattered throughout the entire codebase, it may be possible to do a minimal amount of work to switch over to Cocoa and OpenGL while leaving most of the code intact.

Looking at my code, I'm actually surprised in that I managed to abstract most of the OS-specific code. However, there's a slight snag: I use tons and tons of Str255s, so that's going to be a pain to deal with.

I'm not really sure which classes to convert to Objective-C and which to leave as straight C++. I'm pretty sure most of my controllers/Cocoa-specific stuff should be rewritten as Objective-C classes, but my main game engine class (the in-game controller, so-to-speak) would be a pain to rewrite as an Objective-C class.

Also, would intercepting key events from NSApplication be on par (in terms of performance) with GetKeys()? I've been using GetKeys() up until now mainly for its speed, so I was wondering if Cooca's input handling system matches up with it.

Again, thanks for the advice -- I think I'm leaning towards the Cocoa rewrite right now...
Quote this message in a reply
Moderator
Posts: 3,570
Joined: 2003.06
Post: #6
Well heck, if it's hobby programming, then by all means you should do it *all* in Cocoa! Grin

The C++ stuff? I say stop fighting with it, and just redo everything in Obj-C. I had all my "speed stuff" in straight C and switched it all over to Cocoa/Obj-C and couldn't be happier. Thinking in one methodology for the programming when it's a one man show is always a good thing IMHO. Besides, it was actually fun, and most of it was re-engineered to be done the "right" way. Everything turned out way better all the way around. Highly recommended. Oh, and plus, I have yet to see any speed problems at all.

As far as GetKeys? Get your input events through Cocoa and you will be perfectly happy -- either as first responder, or through sendEvent, or a combination of both, which is what I do. Besides, GetKeys wasn't the right way to do things to begin with on OS X.
Quote this message in a reply
Member
Posts: 67
Joined: 2006.07
Post: #7
Yeah, that's what I was thinking. I would probably structure it better anyway if I rewrote it in Cocoa. And not to mention eliminate those random memory-related crashes and "DrawPicture() failed" errors... ugh.

AnotherJake Wrote:Besides, GetKeys wasn't the right way to do things to begin with on OS X.

I've known that all along (doesn't take into account different keyboard layouts, etc.), but I thought it was a tradeoff for the speed. I guess Cocoa's responder system is good enough, so I can ditch it now.

Although I have a question. Currently (in the Carbon version), for texture loading, I use glpng to load PNG files and then map them onto quads. In Cocoa, would I just use an NSImage to load image files? And is there any way to grab the raw image data from an NSImage in order to use them for texture mapping? Or should I find a different route?
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #8
You may be able to use ImageIO, but if you've got working libpng code, I'd personally stick with it. NSBitmapImageRep is pretty much a no-no.
Quote this message in a reply
Member
Posts: 67
Joined: 2006.07
Post: #9
Alright, thanks for the help!
Quote this message in a reply
Moderator
Posts: 3,570
Joined: 2003.06
Post: #10
I use ImageIO as well, but I agree there isn't anything wrong with using whatever you have for image loading as long as it's sensible. PNGs and JPEGs are preferred, so if you're already loading PNGs just fine, no need to change direction there.

I should add that ImageIO only works for 10.4 and above.
Quote this message in a reply
Moderator
Posts: 1,560
Joined: 2003.10
Post: #11
Wowbagger Wrote:Also, would intercepting key events from NSApplication be on par (in terms of performance) with GetKeys()? I've been using GetKeys() up until now mainly for its speed, so I was wondering if Cooca's input handling system matches up with it.

I've never seen any performance bottleneck related to input handling in Cocoa. The usual rules of optimization apply: don't do anything nontrivial to make your code faster until you've objectively measured a working solution and proven it to be an actual bottleneck.
Quote this message in a reply
Member
Posts: 67
Joined: 2006.07
Post: #12
Apologies in advance for reviving this thread.

So I've been thinking about this some more, and I've decided that making the game cross-platform is a lot higher priority than I initially thought. In light of this, I've started to investigate a switch to SDL instead. SDL's always intrigued me, but there have been a few issues with it that have always discouraged me from using it.

First off, it seeems as if the key response is a little sluggish (as I've noticed in the OS X port of Maelstrom). Is this the case in general for SDL apps? Or is it just because the Maelstrom port (I assume) didn't use OpenGL, and was therefore bottlenecked by the rendering routines?

Secondly, I would assume that SDL has no provisions for dialog box/window management, right? In that case, would the best way to handle, say, a key config dialog be to isolate the dialog code and then write platform-specific versions of it?

Of course, I guess either way wouldn't prevent a switch to Cocoa (I think the SDL skeleton app is a Cocoa app IIRC), but I guess I'm thinking that the base code should be kept in the C++ for now?
Quote this message in a reply
Member
Posts: 320
Joined: 2003.06
Post: #13
1) sluggish key response will not be SDL's fault. That will be a problem with the way the events are handled later.

2) right. If you have the time - or have a fullscreen option, do all the UI yourself in OpenGL. That way you have complete control and platform independence with your UI. That can be a fair bit of work however, so otherwise you are correct that you should use nibs and cocoa for OS X and the windows equivalent for that other platform.

3) Cocoa simply isn't an option for a windows game at this point. Might as well keep that code as C++.

I highly recommend SDL for Mac OS X / Windows game development, and it sounds like you want to keep your code in C++ but progressively migrate your Carbon code to the C++ STL and SDL and branch to the Cocoa or Windows API where needed.

Chopper, iSight Screensavers, DuckDuckDuck: http://majicjungle.com
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Best technology to draw large indexed textures BahamutZERO 6 3,339 Mar 31, 2005 12:30 AM
Last Post: lpetrich