Jump to content
  • entries
    943
  • comments
    5,899
  • views
    923,759

An Eventful Weekend


Josh

1,949 views

 Share

The windows class on OSX has been a bit neglected, so i spent some time getting it ready for the final release. Creating a full-screen window on Mac is a little funny. There's a fullscreen mode that's been around a while, but it locks the system so that CMD+TAB doesn't work. That means if your application crashes, or you don't program it to close with the escape key, you'll be stuck in fullscreen mode, with no way out but a computer restart! :D

 

You can create a window on top of everything else, and CMD+TAB will still work, but the borderless style you use for this makes it so no keyboard input is recognized! If you press escape, the system just beeps and the window doesn't catch an event. :o :o

 

There's also a new full-screen mode for apps in OSX Lion, but it's for GUI apps, and I wanted this to work on Snow Leopard. I knew it was possible because Left 4 Dead 2 on Mac does this. Using the Google, I was finally able to find the information I needed. I had to create a new subclasses NSWindow class to get keyboard input working.

 

Another problem I had was that when a window was resized, the NSOpenGLContext wasn't sizing with it. Many, many search queries later I found what I needed, and added a couple of methods to my OpenGL view class.

 

Objective-C may be the greatest thing in the world for writing GUI applications for Mac, but I found it very complex for simply creating a window. It takes about 700 lines of code to create a window that has OpenGL rendering and keyboard and mouse input. Out of all that code, you guys end up with one or two functions that do exactly what you need to create a window and get events. B)

blogentry-1-0-34790700-1321823478_thumb.jpg

 

Let's talk events. Event queues are the most compatible with all languages, but a callback is really better. When a window is being resized, the application loses control and doesn't get it back until the user lets up the mouse. That means an event queue system doesn't allow the window to be re-rendered as it is sized, and you get ugly artifacts as it is sizing. Therefore, I think we need a hook system where you can add your own hooks like this:

System::AddHook(int hookid, char* funcptr, Object* extra)
System::AddHook(HOOK_EVENT, myfunction, NULL)

I think we're also going to set up the App class so that it has a ProcessEvent method, which automatically gets added as a hook:

App::ProcessEvent(int eventid, int data, iVec2 position)
{
switch (eventid)
{
	case EVENT_WINDOWSIZE:
	world->Render();
	context->Sync();
}
}

Your thoughts?

 Share

2 Comments


Recommended Comments

I get the System::AddHook method. The first line was the definition, and the second an example, right?

What I don't understand is the ProcessEvent method.

 

Also, I suggest Application instead of App. First, App is connotated with iOS applications, or at least Mac applications, which is not platform neutral. Second, the engine doesn't use other abbreviations elsewhere, except when extremely often used (e.g. Vec for Vector).

Link to comment

Vec3 vs. Vector3 is a 43% reduction in size. App vs. Application is a 73% reduction.

 

Besides, "Apps" are for everything. Didn't Steve Ballmer tell you? PCs today have new form factors and touchscreens, and Windows 8 will be a powerful operating system capable of running the Apps that consumer want, like "Weather"! :)

 

It will be CHROMELESS so it won't confuse your pretty little head! CHROMELESS!!! WITHOUT CHROME!!! :)

 

As you know, teens are very social creatures!!! :o

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...