Resize Window Using GLFW3

When porting our game from mobile to desktop we wanted to add a few desktop specific interface enhancements. Things like using the keyboard, mouse, or managing the Window. By default games are setup to run full screen instead of within a window on desktop platforms, but since our game is pixel art full screen is a bit large on modern 24″+ monitors. So we’re sticking with running inside a window for now.

Ideally we’d allow players to resize the window. In order to support resizing a running scene we would need support to dynamically update every single UI element. Each scene or menu does size, scale, and position UI widgets on the current device (or now window) size, so we will allow changing resolution from a menu and then we will just reload that menu with replaceScene() after the changing the window frame size. We could build in support for this and attempt to unify the changes into a base class or small set of resize methods, but it would be better done at the first design and creation phase of a game’s development.

/// glview - the cocos2d-x platform OpenGL view reference 
/// frameSize - the desired window size
void OptionsResolutionMenu::static_changeResolution(GLViewImpl* glview, Size frameSize)
{
#if ((CC_TARGET_PLATFORM == CC_PLATFORM_WIN32) || (CC_TARGET_PLATFORM == CC_PLATFORM_MAC) || (CC_TARGET_PLATFORM == CC_PLATFORM_LINUX))
    auto glfwindow = glview->getWindow();
    auto fsize = glview->getFrameSize();
    auto screenSize = glview->getMonitorSize();
   
    int sw = screenSize.width > 0 ? (int)screenSize.width : 800;
    int sh = screenSize.height > 0 ? (int)screenSize.height : 480;
  
    // win position
    int winx = 0, winy = 0;
    glfwGetWindowPos(glfwindow, &winx, &winy);

    Rect viewport = glview->getViewPortRect();
    Vec2 viewcenter = Vec2(viewport.getMidX(), viewport.getMidY());

    // update the cocos2d view frame
    glview->setFrameSize(frameSize.width, frameSize.height);

    int x = int(sw - frameSize.width)/2;
    int y = int(sh - frameSize.height)/2;
    glfwSetWindowPos(glfwindow, x, y);
#endif
}
// call method with desired size (we get this from user options menu)
float resWidth = 800;
float resHeight = 600; 
OptionsResolutionMenu::static_changeResolution(glviewImpl, Size(resWidth, resHeight));
GameManager::getInstance()->runSceneWithID(kSceneOptionsResolution, 0);

[ST.2015.033]

Adding OS X Menu Bar with cocos2d-x 3.3

[todo: convert into a gist, and cleanup post]

I’ll post discussion topics here discussing adding or changing the Menu, but I found out adding MainMenu.xib didn’t work correctly as I have thought during the discussions over on the forum.

Looking into where the menu is created I found out that GLFW3 actually creates its own default menu with only two Menus services(App menu) and Window. The code where it sets this menu up is found in cocoa_window.m over on github.

Once I figured this out I had to investigate how to edit the app or window menu. Looking over the window code, and searching through the various header files from within XCode I was able to add an item to the Window menu.

Update 2015-01-17: I’ve posted up an example project using cocos2d-x 3.3


void STDeviceMac::addMainMenu(GLViewImpl* glview)
{
NSWindow * appWindow = (NSWindow )glfwGetCocoaWindow(glview->getWindow());
if(appWindow)
{
// make your obj-c calls here
NSMenu
menu = [NSApp windowsMenu];
{
NSMenuItem* menuItem = [[NSMenuItem alloc] initWithTitle:@"Check for Updates"
action:@selector(checkForUpdates:)
keyEquivalent:@""];
[menuItem setTarget:[SUUpdater sharedUpdater]];
[menu addItem:menuItem];
}
{
NSMenuItem* menuItem = [[NSMenuItem alloc] initWithTitle:@"Steve's Test"
action:@selector(test:)
keyEquivalent:@""];
[menuItem setTarget:_deviceImpl];
[menu addItem:menuItem];
}
}
}

[ST.2015.025]

Data-Driven Game Development

I ran across a twitter post to check out a new game engine called Spark. It sounds like an over lofty idea, but with the right focus and vision. I signed up and will give it a test drive if I get into the Beta.

They using Haxe as their source language, which is great since it can target many runtime/compiled languages. It’s akin to using CoffeeScript as the source for the javascript a web app uses when run in the browser. It is indeed a better variant of ECMAScript than javascript having derived from ActionScript, but go read up on it yourself if you’re interested. I’ve wanted to try out Haxe during a gamejam or for 1GAM, so hopefully I’ll get invited soon and can do so testing out this new engine.

Data-driven development is something every game developer learns over time when they realize the extra work required to go find and tweak the variable, or create another class for a new enemy. Instead they can move as much as possible into data configuration files or scripts separating it from the game logic and core engine code. This allows changing assets on the fly or pulling them from different sources, adjusting parameters for procedural generation algorithms, or even creating new enemies or modifying their behavior. It can allow simple modding support without requiring full scripting experience.

Now with any new games or prototypes I’ve started to build the data models and configuration first. There’s plenty to be said about this topic, and others have written about it better than I could today, maybe I’ll expand upon this topic in the future once I’ve built up a library of data-driven prototypes as well as continued writing practice.

[ST.2015.005]