For those of you who've been wondering...

[Jetrel]

Anyways, EP, I looked at the source you provided... If you could send the whole package, minus a build of the app, I might be able to try my hand at debugging it.

Right now, the only thing I can say is that I can't quite understand why you use two NSSound objects. The allocation of one, the copying of it's contents to another, and the subsequent deletion of it seems a bit ... strange.

If this is intended to prevent it's deletion before the sound finishes playing or something, uhm, I would just load the sounds globally, and then deallocate them when the application quits (which is done for you, but I digress).


I'm not really an expert on this newfangled OS X game stuff, seeing as how most of my experience came from programming in the horrible, horrible world of system-7 games. Needless to say, the sound system back then involved ... assembly.

[Elvish_Pillager]

Right now, the only thing I can say is that I can't quite understand why you use two NSSound objects.

When I tried

Code: Select all

[[NSSound soundNamed:@"blah"] play];

it couldn't play another instance of the sound when it was already playing it. When I tried

Code: Select all

[[[[NSSound soundNamed:@"blah"] copy] autorelease] play];

it allocates two sound objects and only releases one of them. The technique I use is the only one I could get to work.

The "dastard-hit" sound uses the first mechanism because it shouldn't be playing more than once at a time. None of these have any problems with deleting before it's done playing.

However, I won't be able to upload the whole package, because the images and sounds take up >30 MB.

[Dave]

Yes, you do have to explicitly call it, but this is usually called in an object's destructor.

Ahhh okay....then it sounds like Objective-C does support it, if it supports destructors.

Basically the idea of RAII is to only ever release objects in destructors. Any resource which is allocated is immediately placed into an object which will release it when the object is destroyed.

Since it's a language guarantee that an automatic variable will be destroyed when its scope ends, regardless of how its scope ends (via explicit or implicit return, exception, or long jump), then you can be assured that a resource allocated to be used within a function will be released at the end of the function.

David

[Elvish_Pillager]

Whooops... looks like I was confused...

Subtracting the build leaves a manageable file size. (yes, this is the entire project.)

[Invisible Philosopher]

Objective-C does not support destructors in that sense because objects cannot be allocated automatically, only in the heap. You may only declare pointers to objects. It is quite a bother, but there are good reasons behind it, I'm sure. For example a technique used in standard Objective-C classes is the init method returning a different object than that which the method was send to. However it makes the idea of RAII impossible to implement in pure Objective-C, AFAIK.

EDIT: It has a (different?) idea that often serves the same purpose: the autorelease method. Most of the time when a method is asked to return a new object, the object is first sent an 'autorelease' method, which means that sometime later its reference count will be decreased by 1 (and the object deallocated if appropriate). That time is normally during the event loop, which automatically exists as part of a normal Objective-C program. This is possible because all objects have a common superclass that implements basic functionality. Instead of deallocating immediately at the end of the scope, it does something just as good. This is not entirely automatic, however. Objects are expected to keep the correct reference count where appropriate... but perfect memory management solutions are not to be found anywhere.

[Jetrel]

Whooops... looks like I was confused...

Subtracting the build leaves a manageable file size. (yes, this is the entire project.)

Yeah, I know. I can only speculate where the other 30 megs come from...

[Elvish_Pillager]

It was all in the "build" folder. Most of it was the precompiled header.

Update: Did some code reform, and added a few very minor features (I've replaced my previous upload with the more recent version.)

[Jetrel]

It was all in the "build" folder. Most of it was the precompiled header.

yeah, I know, but, 30 megs for the pch... it must be precompiling a whole ton of stuff from Foundation and AppKit into there. Something they certainly couldn't have gotten away with back in the days of system 7.

Coding with codewarrior was quite different than it is with XCode, though at least codewarrior Didn't Suckâ„¢. Because MPW sure was a mess.



I always knew those files were big, I've just never been sure exactly what they're putting in there...

[Jetrel]

Ok, I looked over the code, and then reached for my handy programming manuals. As I was looking through Aaron Hillegass's excellent Cocoa Programming for Mac OS X, I found the following.

Rather than paraphrase it, I thought I would just post it. Better for everyone, especially those who know nothing about the language.

This specific problem has bitten me before, and is something apple is sadly lax in describing in their own documentation. It has the potential to cause some truly dastardly bugs, and yet is caused by use of the standard Foundation containers, something almost any real program will need to use.

Anyways, I think something in the tick function for the custom NSView might be at fault. You have a bunch of shizzo with containers in there, and it might be what is causing the problem.

[Elvish_Pillager]

(all instances of "enemies" in my newer version have been replaced with "things")

Thing is, I can't find anywhere it could be leaking! subThings has all its objects removed, things contains all and only those things which should exist, and the rest of the NSMutableSets get removeAllObjectsed. That, and everything I "alloc" gets autoreleased.

So, I basically don't know where to look, because everything I look at looks fine.

Hey wait... *jaw drops* what the ....?!? How could I have deleted those two lines of code?

Code: Select all

[thingsToBeRemoved removeAllObjects];
[thingsToBeAdded removeAllObjects];

Well, putting them back didn't fix anything...

EDIT: Gahhhh... that's what happens when you clean up code and then forget what you've done.

Also ObjectAlloc seems to say there isn't a memory leak in my application...

[Elvish_Pillager]

Update: The problem seems to lie entirely in the sounds. When I remove the sounds, the game does not become laggy.

EDIT: And that's just the sounds I copy, not the 'simple' scheme I use for the dastard-hit.

[Elvish_Pillager]

Update. It's been a while, but not much new has been done.

Every minute, now, the game stops, says:

Stage X
Click to begin

and your shield is reset to 25. (It's not 100 anymore.) Once you click, the game begins again. Also, the number of enemies in each stage is multiplied by X, instead of being constant. Soon[1], I will make some enemies appear only past certain stages.

I like the effect of this multiplication. In the first stage in which an enemy appears, it is in very small numbers compared to afterwards, giving the player a minute to get used to it.

Unlike Wesnoth, which concerns itself with balance, Fling[2] is not a strategy game, and I intend to make as many of its features as possible be controlled by preferences. My plans include many types of weapons for the player, and I have come up with no way to fit them in except to make them optional weapons. This sure is going to be fun...

Upcoming enemies: Laser Turret

Weapon ideas: Flamethrower, Sniper Rifle, Cannon

Details on the weapons will come later, because I cut my finger today, and I won't put up with this painful typing anymore.

[1] Soon in programming-time, not in real-time.
[2] I am likely to rename it "Cascade".

[Elvish_Pillager]

Weapon ideas: Flamethrower, Sniper Rifle, Cannon

Details on the weapons will come later, because I cut my finger today, and I won't put up with this painful typing anymore.

Flamethrower: Random shots, dying once they've gone a certain short distance, appearing at random angles between PI/8*3 and PI/8*5.

Sniper Rifle: Shots aimed with the mouse.

Cannon: Its shots are huge, and don't die when hit.

Also, incredibly minor update: The rocket launchers' size has been reduced, and I fixed them so that they don't look smaller than they are anymore.

[Elvish_Pillager]

No tangible progress, but I've made an important coding advancement that makes lasers much more possible to implement.

I just realized that posting this was rather useless

And now I realized that I forgot to mention that I have actually gone through and changed the ~6 instances of "Fling" to "Cascade", so it's officially Cascade now.

[Elvish_Pillager]

Lasers have been successfully implemented. Thing is, their display is messed up...