Ant Planet

[macnib]

Time to test the waters...

I've released a beta demo of Ant Planet. Feedback would be welcome!

Actually, there are two works in progress. The underlying Reliabit engine and the game. Both are exclusively for the mac. :)

I've tested on my g4 iBook, dual g5 and quad xeon macs. Video card tests have been with the Radeon 9800, GeForce 7300 GT and ATI Mobility Radeon 9200.

Game demo requires Mac OS 10.4.

http://www.reliabit.com/antplanet.html

Thanks again,
Nib

[AnotherJake]

Well the screenshots certainly look nice! But I saw this on the sys reqs page and I guess it leaves me out, with a lowly Intel Mac Mini:
A minimum of 128 megabytes of video ram is required

[macnib]

I have not tested Ant Planet on a mini and in particular the intel gma chipset.

Though, its my understanding that the gma will do vertex processing in software which would slow things down. Yet, do fragment processing in hardware. Also, I understand it uses system memory which is going to slow things down some more.

Though, I have gotten the game to run on my g4 iBook which has 30 megs of texture memory in 800x600 mode. Of course, the laptop has a slow bus too.

If you do attempt to run the program on the mini then I'd suggest turning off shadows, shaders, and blur. Also, going to a lower resolution might help. There are tiered options such that you can disable settings to get it to run on low end computers.

[AnotherJake]

Though, its my understanding that the gma will do vertex processing in software which would slow things down. Yet, do fragment processing in hardware.
Right, no hardware vertex processing for the gma950 I'm afraid.

Also, I understand it uses system memory which is going to slow things down some more.
It does indeed share some reserved system memory, but it's actually surprisingly fast. I guess that's one of the reasons gma950 systems require dual channel memory.

We've all been complaining about the lack of hardware T&L on the gma950, but the reality to consider is that Apple has pushed literally millions of those suckers out the door in new systems. I think it's pretty hard to ignore specific support for them if you are going to be developing a real-time engine for the mac.

Waiting for big 159 MB download of Ant Planet demo now. Will report back success or failure soon...

[AnotherJake]

Well it does actually appear to work, albeit a tad sluggishly with default settings (as expected) -- 10.4.9 Mac Mini Intel Core Duo 1.66 GHz 1 Gigaram. I don't have time to tweak settings right now, but I'll get a chance either later or tomorrow. I don't know how to display frame rate info, but it *acts* like it's doing maybe 12 or 15. I haven't seen any visual glitches or any other major problems yet. Looks like a pretty high-poly scene. I think the controls are pretty clunky. I definitely despise installers for games on a Mac. I gave GolfHacker some grief about it a month or two ago. I'm too tired to complain anymore about the installer right now, sorry.

Congratulations, it looks like you have a pretty good start with it! :)

Welcome to iDevGames!

[macnib]

Sounds good. When the program runs in default mode its vanilla opengl. It tries to avoid as many opengl extensions as possible. Think the one exception might be an attempt at texture rectangle.

Ya, some of the models have a high poly count. In particular, the truck.

As far as frame rate is concerned, its going to be caped at the monitor frequency. I'll have to check the sleep periods.

Some people don't like installers. But they can check system characteristics. Thus, installers can perform a support role. Also, the game does a gestalt check on the system version during start up.

[AnotherJake]

Yeah, it definitely looks like vanilla OGL. The only OS X card that can't handle rectangle textures is the Rage128, which I would safely consider obsolete. ;)

Also yeah, the (rendering) framerate need not, and should not be any higher than the framerate. However, simulation/physics ticks can be as high as they need to be for whatever reasons. The rendering MUST be synched to VBL in any case for release versions to avoid tearing, and as arekkusu likes to point out: seizures... Plus it just plain looks bad so there's no reason not to VBL synch.

I would strongly argue that *most* Mac users do not like installers for games and consider them unnecessary, and even less professional. But it looks like you have plenty of work on your plate as it is, so I'll refrain from nagging further... for now...:p

Perhaps for the poly count you might consider going with LOD models using something like Melax's most excellent progressive mesh algorithm (http://www.melax.com/polychop)? Heck, maybe you're already doing that, considering the eternity it takes to load the models. :D

[OneSadCookie]

Installers are bad. This is a strong feeling in the community. Many, many Mac users will not install software that requires an installer. You can (and need to, anyway) check hardware characteristics at application launch time.

The *only* reason to use an installer is if you need to put a file in a place a regular user does not have access to, and a game should *never* need to do that.

[macnib]

Hmm, I think you guys are right about the installer. For instance, if I was in a lab somewhere and I did not have admin privileges, then I would have a problem installing.

The DropDMG program is pretty handy. Made a bzip2 dmg file. I'll have to test it first. But it displays the license etc. Check..

[macnib]

Now there is a zlib compressed dmg file for the demo. No more installer. :)

Also, fixed a minor issue where a palm tree might be drawn in front of the status bar at the bottom of the window. Since I draw the status bar after the main scene, I just set depth test to always.

[Fenris]

Looks like a cool game. Two things you will need to fix, though: the camera (please don't have me move it around to keep it behind the car!) and the input (please don't have me tap the keys to turn!).

Other than that, I agree that you're off to a great start. It runs pretty well on my 2.0GHz G5 iMac. :)

[macnib]

Thanks for the feedback!

My cousin, a Halo/Bungie fanatic, had the same issue with the camera too.

At one point, in an internal version, I did have the camera slowly gravitate to the back of the car but I have mixed feelings about it. I suppose I got accustomed to aiming the camera -- when the camera is not aimed where I want to look then I'd get frustrated. Might be a good default config option setting to track the car. Might want to put code in if the player is behind a hill to swing the camera around if not visible.

As far as the keyboard, the program is taking in kEventRawKeyDown and kEventRawKeyRepeat events. I'll have to double check the event code. The program takes these readings and passes them to the simulator thread.

I think running opengl with threads ( the opengl thread feature ) on intel macs was causing some sluggish behavior in earlier demos. So, in the current revision of things threads are turned off.

I have a revisions log. Been a busy bee. Working on CD packaging art the last week.

http://www.reliabit.com/antplanetvers.html

Thanks again for the feedback!

[Fenris]

Very cool to hear that you're making progress. :)
As far as the keyboard, the program is taking in kEventRawKeyDown and kEventRawKeyRepeat events. I'll have to double check the event code. The program takes these readings and passes them to the simulator thread.
Right. Key repeats aren't very reliable, since they could be changed, have a delay or even be turned off. What you should do is set a flag on key downs - for instance, "accelerateButtonIsDown = true" - and then set that flag to false on key up events.

That way you reliably track when the button is up or down, without having to trust key repeats. :)

[macnib]

Well, I got the key repeat working. Every quarter second, if the key is down, the program emits another character. Works pretty good and should be more consistent on different computers. Shooting is more like a machine gun. The ammo counts will need to be increased. Movement is not as sluggish. :)

I'll have to think about the camera stuff some more. The camera does need to be improved.

[macnib]

Well, I actually needed to write a cocoa program! :)

Sort of funny but its a pain to enter a registration number when a game is in full screen mode and you can't see your email! A different case than reading off a CD sticker. Not everyone has a printer either. A mac app with an interface was needed.

Actually, cocoa is nice. Just need to make a mental map to c++. Initially, I hit a brick wall with events but then you come to realize how easy it is to set up outputs and actions. Then you realize you make an .mm file and you can mix in your c++ anyways.

Very mac dependent but thats not much of an issue in this case. Learn something new every day...

The Pierre Chatelier is pretty helpful too. Very to the point etc.

[AnotherJake]

I'm pretty surprised! Switching over to Cocoa like that is not a trivial task with what you're doing, specifically with the development stage of your game being so far down the road. So I figured I'd offer a small congratulations here for your effort. :)

[macnib]

Actually, there are two apps. The game and the registration app. I thought it was a perfect time to try to understand cocoa more. In retrospect, porting the game to cocoa might be easier than I thought. Its easy to mix in the c++. I'm going to make some configuration tools in cocoa too. Its a seasons of change thing -- I cant change major points in my game now because its too late in the process. I'm in maintenance and lessons learned mode.

For the next game, I'd like to add in 3ds or fbx. Parsing obj text is really slow.

Sort of interested in doing bones and IK stuff with glsl vertex shaders.

Also, I need to get rid of my display lists. At one point, I was using vbos with my vertex data. But I had it wrapped in a display list. It worked well but it violated the opengl guidelines. So, I had to go back to display lists. :( Still works fine.

I made some CD art. Though, I think download distribution is the way to go.

http://www.reliabit.com/antp_cdshots.html

I'll keep practicing in Cheetah. I'm getting a little better at box modeling. Still a long way to go. After all this programming, one starts to realize good quality models can make a major impact!

[AnotherJake]

Box art looks cool!

I'm still practicing in Cheetah too, so I know the feeling... But you're right that good models mean more to the quality of the game than what first meets the eye. My saying is that content is king!

I am also interested in using fbx in the future, as it appears to be taking off as a pretty solid standard (Maya, Max, many others, including Cheetah3D (woohoo!) support it, plus XNA can use FBX as well). I checked out the sdk a while back and was a little shocked at the size of the lib as I recall (several MB), although maybe it can be efficiently stripped, I dunno. I couldn't make heads or tails of how to use it. If you manage to get it going for you I'm sure we'd all appreciate hearing about it!

I've found that parsing obj files is plenty fast enough. I can parse, remove duplicate vertices, and auto-tessellate 75k triangle models (IOW not realistically usable in a game because of the size, but good for testing) in about seven seconds. More realistically sized models (few thousand tris) in mere fractions of a second. If you need more speed than that, then I would think that pre-processing them into your own optimized format should fix any loading speed problems.

[macnib]

Well, Ant Planet needs to be ironed out for Leopard. ( maintenance ) Upgraded to xcode 3. Got cvs working with launchd now. Though, I've run across two main issues.

1. Carbon key events do not appear to get to the app in the main case. The odd part is if I'm in terminal and run the unix executable there like ./thingy then I get key events. But if I double click on the thingy.app from the finder then no keyboard events. Stripped all the Quickdraw out before because I knew it was depreciated. Don't have a carbon window but I just install a handler via InstallApplicationEventHandler.

2. Looks like glsl scripts are getting put into software mode. So, things run extremely slow with fragment shaders. The scripts compile in the GLSLEditorSample program. There were no errors before but now it gets this link error during compilation when I attach the program:

Samplers of different types use the same texture image unit.
- or -
A sampler's texture unit is out of range (greater than max allowed or negative).

Sort of like using the GLSLEditorSample program. In the render window, if it goes to software mode it would show the software driver...