It would help if there were an app in your test folder for those of us who are project-builder-less

There was a pre-built app in both folders. They are Cocoa though, so if you are running Mac OS 9, they won't do you much good.

I was in jaguar :/ Where, in which folders?

I didn't find a pre-built app in the "LemmingsTest" (or whatever it was called) folder...

Out of curiosity, if you're on Jaguar, how come you don't have the developer tools? If you bought it retail you should have them on CD; if you got it pre-installed on a new Mac, the developer tools installer should have been installed too...

I cant find the dev cd :/

There are pre-built apps in there when I downloaded it, called "LemmingTest2" in the "LemmingTest2" folder of the "LemmingTest Folder" folder and called "GLTextureShredder" in the "GLTextureShredder" of the "LemmingTest Folder" folder. I like the water effect/graphics, and I see how you did terrain with OpenGL, ededed. Can that be done dynamically, without a source graphic? I'm thinking of randomly generated terrain here ...

OpenGL textures can be generated dynamically, and the Mac has lots of Mac-specific extensions to make dynamic textures super-fast. The problem is designing the algorithm to dynamically generate the image...

David, if you are an ADC member you can download the Jaguar dev tools from Apple.

I vote for OpenGL. While what we are looking at right now can be done with Quickdraw, OpenGL has many more capabilities should we later think of more complex effects to implement. I would love to be able to zoom in and out as well.

If OpenGL can do good dynamic textures, then I'm all for it. Only thing I was thinking was, wouldn't these textures be stored in VRAM? I've heard it's slow to read from, and we'd need to be checking the mask a fair bit for collision detection. Of course, we could have a copy of the mask in normal memory, which is our working copy, and just update the texture's alpha channel as and when we need to. Might have some advantages, actuallyÖ

If we do go with OpenGL, the zoom feature should be one we right into the design document off the bat ;-)

For groups of lemmings, should we use the traditional RTS approach of assigning number keys to groups?

Yeah, you wouldn't read back from VRAM.

Personally, I think that OpenGL will just end up being harder than blitting for this particular project, though. Doing dynamic textures with OpenGL isn't as easy as updating a GWorld.

The two reasons I would favor CopyBits/GWorlds over OpenGL:

1) we would have a larger audience/market
2) Hooptie is programmed in Obj-C/Cocoa, so it keeps a lot of the good Carbon programmers from helping out

These are, of course, based on the assumption that we would use Obj-C/Cocoa for OpenGL. If we were to use CopyBits/GWorlds we could obviously make a few custom wrappers/functions/replacements to make it easier or faster.

So, basically, even if we use openGL we'll still need to be messing about with our own bitmaps. I still favour a CopyBits or suitable replacement. Plus, I've decided that I rather like Carbon.

Using CopyBits & GWorlds doesn't prevent you from using Cocoa for the rest of the game, nor vice versa. And of course, you can use OpenGL from either Cocoa or Carbon.

Personally, I find Cocoa to be a significantly more productive environment to work in than Carbon, so I'd recommend Cocoa + QuickDraw for this project

Fair enough - I like GWorlds and I'm not actually that attached to CarbonÖ in fact I seem to recall vowing to use Cocoa exclusively from now on at one particularly frustrating point recently. So, Cocoa and GWorldsÖ sounds good.