Designing a better framework

[imikedaman]

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. :wow:

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

[AnotherJake]

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.

[imikedaman]

-- 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.

[Blacktiger]

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

[imikedaman]

Of course, if you do decide to use SDL, use SDL_Image to load pngs, jpegs, bitmaps, and more!
Sounds good. :D

[imikedaman]

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?

[OneSadCookie]

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.

[imikedaman]

This website is looking promising to me:

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

[imikedaman]

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.

[imikedaman]

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.

[imikedaman]

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

[OneSadCookie]

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.

[imikedaman]

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-2005-2-400367.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.

[PowerMacX]

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.

[imikedaman]

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

[PowerMacX]

Right, I think it is using the 2/3rds rule or "visually centered" as recommended in the Apple Human Interface Guidelines:

Apple Human Interface Guidelines: Window Behavior - Positioning Windows (http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGWindows/chapter_17_section_4.html#//apple_ref/doc/uid/20000961-BACFHDHE)

[OneSadCookie]

"centered" on Mac OS X means "the alert position" usually, which is slightly above centered vertically. This is correct behavior!

[imikedaman]

"centered" on Mac OS X means "the alert position" usually, which is slightly above centered vertically. This is correct behavior!
I'm making a game, not an alert screen. For example, Halo shows up in the center of the screen, as do all the various apps I use (and the loading screens for UT2k3 and CoD2). I'm used to having the game screens centered, and I'd like to replicate it for my own games.

[OneSadCookie]

... and I prefer having the window in the correct place :p

Stop wasting your time worrying about it ;)

[imikedaman]

... and I prefer having the window in the correct place :p
You prefer it at the top of the screen because new Finder windows appear in that position. I prefer it in the center because all the games on my computer appear in that position. I wonder which one is more relevant here. :wacko:

[unknown]

Default or Expected behaviour wins, go with it.

[PowerMacX]

Well, you can always tweak the SDL source to get the exact behavior you want. Or, use a horrible hack like:
setenv("SDL_VIDEO_WINDOW_POS","0,0",1);

Add it before you create your surface "0,0" being "bottom,left" corner position relative to the bottom left of your screen.

(warning: just found a getenv("SDL_VIDEO_WINDOW_POS") in SDL source thanks to spotlight, might break things - I didn't test this other than to verify it changed the starting position of the main window)

[imikedaman]

Wow! The stubborn window finally moved to the middle of the screen! Unfortunately it has a weird side effect, which is that the video itself shifts up and to the right the same amount as the window moved from (0, 0). Here's what I mean:

http://waterfallsw.com/~mike/SDL_video.png

Really promising except for the glitch!

[Frank C.]

For example, Halo shows up in the center of the screen...Halo also doesn't properly capture the screen or the mouse, which means you can exposé the game window in fullscreen mode - Joy! Moral of this is to do what's right, not what other people do - unless their right ;)

That said my current engine doesn't do the two-thirds thing either - it's centred plus a nudge upward - but that's mostly 'cause I'm lazy and haven't fixed it yet.

[OneSadCookie]

Both Cocoa and Carbon have simple routines to put the window in the right place ;)

[imikedaman]

Both Cocoa and Carbon have simple routines to put the window in the right place ;)
Yes, I already tried a few ideas and listed them on the first page. I was trying to get a window reference and move the window that way, but needed help figuring out how since my ideas failed.

[OneSadCookie]

[[NSApp mainWindow] center]

but you've already said that SDL's doing that for you (it should be) and you don't want it to (you should).