NeHe revival?

The ADC article OpenGL Programming Guide isn't too bad for learning how to set up NSOpenGLView/NSView in Cocoa or the equivalent in Carbon. After setup, the NeHe tutorials are a whole lot of straight GL commands...

unknown Wrote:Can you elaborate on that please? I don't know what you are getting at.

Well, like for instance:

- How much keyboard support do you want? Do you need to override sendEvent to pick up events and maybe keyUps?
- What about full screen support? Do you want to handle multiple displays?
- How about updating display capabilities on the fly when/if things change?
- How about gamma fading?
- Preparing for miniaturization? (drawing the view to the backing store)
- Do you need/want to draw a resize control since Cocoa doesn't draw one over an OpenGL view?
- If you want to capture the mouse, do you want to support Wacom tablets? That's not trivial.
- How about custom mouse cursor images? That kind of needs to be handled in the OS layer as well.
- How about smoothly handling fatal errors?
- What about threading? I realize that may be easy to say not to do, but it should be structured so that can be optionally added later.
- How about fixed aspects?
- How about a resizable window that maintains a fixed aspect for the glViewport? (automatic letterboxing/pillarboxing)
- How about caching/shadowing OpenGL state? I guess that can be done in the subclass but...
- Would you like to have basic image loading built-in using Cocoa?
- And on and on and on...

How about the minimum stuff required to release a shareware game without people complaining about the obvious things like it does not work on my 10 display system?

From AnotherJake's list I would say the following would be required:

- Keyboard support - show how to override sendEvent to pick up events and maybe keyUps - if the developer does not need it then they can skip it.
- Full screen support would be a must, multiple displays an almost certainty with the cheapness of displays these days. I'm not meaning playing across displays, just behaving how the user would expect display selection to behave etc.
- Draw a resize control to allow windowed play.
- Mouse capturing. Non tablet support can be listen in the known issues by the developer.
- Custom mouse cursor images.
- Smoothly handling fatal errors - this would be a must.
- Fixed aspects.
- Resizable window that maintains a fixed aspect for the glViewport (automatic letterboxing/pillarboxing)
- Basic image loading built-in using Cocoa.

Nayr Wrote:I like beyondcloister's list-these are good basic things. People shouldn't have to worry about multiple displays, or threading, or tablets.

What! No tablet support?! Common man, that's all I use anymore... Besides, I *almost* have a solution coded for it which I tuck into my NSApp subclass (since I already have to subclass for sendEvent anyway). It was hard to figure out, but it's not complicated after that. I just haven't bothered getting mouse deltas from it yet (kinda necessary), so my evil plan might fall apart there. I can help implement it (or write a short tutorial for it) if a decent base code for tutorials is written. It doesn't take up much extra code in the NSApp subclass either, and from the NSOpenGLView (or wherever) it only takes a single line here or there to turn it on and off. The only caveat is that it requires five extra source files from Wacom engineering to be included in the project, which kind of screws any notion of elegance, but hey...

As I said, threading is not necessary, but it would be useful for it to be structured to be thread-friendly (IOW, initialize, update, draw). Drawing and updating through the same method will really screw things up in this department. Shouldn't be doing that anyway, but I know there are several folks around here do not separate, so I thought it was worth mentioning.

[edit] To clarify a little more on what I'm thinking for the threading thing: I'm definitely not trying to advocate threading for a basic tutorial code base at all! What I'm thinking is that if there were a nice base code to write tutorials for which was structured in a thread-friendly way, threading would be a good topic for me (or someone else for that matter) to write a tutorial about. I've spent the last year playing with threading in my little OpenGL projects, so I've learned a lot of what works and what doesn't. I can imagine there are others who might like to give it a try, what with all the machines from Apple now being multi-proc/core systems. But it's not to worry about too much anyway since I can easily point out anything that is non-thread friendly from the start. It doesn't require anything tricky or special (except for handling fatal errors from full screen), but there might be a couple non-thread-friendly issues here and there.