Okay, I've been using a crappy framework for my small 3D demos for a while, but it's time I replace it with something that will scale well to larger projects. There are three internal problems with the current design that I'm having trouble figuring out how to fix:

1) It uses GLUT, which has that weird Preferences menu and is user-resizeable to any size, which I want to avoid. Should I switch to something else? The code is C/C++, so it would have to work with that.

2) I use BMP files for textures, which of course would be stupid to use in an actual game. What format is recommended for importing, and how would I do that?

3) After each frame is loaded, I go into a busy-loop, where I just waste CPU cycles until 1/30th of a second passes, which is obviously a huge waste and must be rewritten. However, how would I fix that?

Sorry for all the questions recently, but when the internals are that broken, drastic measures need to be taken.

(the old design was even worse, but I worked through all but those three glaring issues)

Some ideas:

1) Check out SDL.
2) Use PNGs and JPEGs. You can go a few different directions to load and save them. Quicktime is a good idea. Libpng and libjpeg are good ideas for cross-platform. There are other means as well.
3) Look into using a timer.

-- lastly, you can search these forums for these topics I just listed and come up with loads of discussions on them.

AnotherJake Wrote:-- lastly, you can search these forums for these topics I just listed and come up with loads of discussions on them.

Will do, thanks. Hopefully I'll be able to sort these things out.

Of course, if you do decide to use SDL, use SDL_Image to load pngs, jpegs, bitmaps, and more!

Blacktiger Wrote:Of course, if you do decide to use SDL, use SDL_Image to load pngs, jpegs, bitmaps, and more!

Sounds good.

Does anyone have a premade skeleton framework that will compile to an empty SDL window? I'm having a hell of a time trying to get this to work.

Plus everywhere I read, it claims projects must be Cocoa/Obj-C to use SDL.

EDIT: Would I be better off making a NIB-based Carbon app? Like add the OpenGL context to the window there and a timer, then handle things like that?

SDL is implemented using Cocoa on Mac OS X, but that's completely irrelevant as far as you're concerned. It provides you with a C API, so you can use any language which can call that API.

Don't use SDL_image to load textures -- it's either dangerous or unnecessarily inefficient. Search the forums for the explanation.

Googling will turn up any number of simple SDL programs.

This website is looking promising to me:

http://www.meandmark.com/sdlopenglpart1.html

Excellent, I seem to have SDL up and running now, with a blank app taking up 1% of the CPU. That's much better than 99.9% for the GLUT version. Also, the annoying Preferences window is thankfully gone, so that's good too.

Hopefully my only question left is this: how can I move the SDL window to the center of the screen? On GLUT I'd just use glutInitWindowPosition(left, top), but it doesn't seem so trivial in SDL.

I tried using the SDL_SysWMinfo class of the SDL_SysWM.h file in the SDL framework, but that doesn't appear to have a window reference on the Mac - only Windows. Darn.

Using GetWindowCount() doesn't seem to work either, in terms of getting a window handle and trying to use that to move the window.

SDL uses Cocoa, not Carbon. There are no WindowRefs for Cocoa windows by default, and Carbon knows nothing about them.

I'd be surprised if -[NSApp mainWindow] didn't return your window.

OneSadCookie Wrote:I'd be surprised if -[NSApp mainWindow] didn't return your window.

Running that idea through Google showed this thread:
http://www.codecomments.com/archive242-2...00367.html

Where one person says it isn't useful until after the window appears, causing it to disjointedly jump to the new position on the screen instead of appearing there, and another person says it is prone to failure and should be avoided.

I'm trying to avoid all this guesswork and just find one of the thousands of people who have done this before, since I've seen a lot of SDL games with the windows in a non-default position.

imikedaman Wrote:Hopefully my only question left is this: how can I move the SDL window to the center of the screen? On GLUT I'd just use glutInitWindowPosition(left, top), but it doesn't seem so trivial in SDL.

I should be trivial, as in "appears centered by default". At least that's the case with my SDL apps.

It's centered horizontally but not vertically for me - meaning the window is near the top of the screen.