Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 19 Oct 2009
Offline Last Active Jul 12 2016 02:09 PM

#5294614 WinAPI + OpenGL: Change window style and/or resolution

Posted by on 02 June 2016 - 04:18 AM

MSDN on SetWindowLong states:

Specifically, if you change any of the frame styles, you must call SetWindowPos with the SWP_FRAMECHANGED flag for the cache to be updated properly.


That flag is added to the SetWindowPos function both in my original and your posted code.


Thanks! Is it necessary to use xor instead of and/or? Besides that your code is similar to mine. Of course the WM_SIZE message is handled.


The main problem is that the client area is not changed. So if the window was in 1296x758 Windowed, it had 1280x720 client area (which is what I want!). So if I change the style only (from windowed to borderless) the client are is the same. If I change both the style AND the size of the window, everything works fine.


So this works:

if (key->GetName() == InputKeys::F1)
    mainWindow->Reshape(1024, 768, WindowMode::Windowed);
else if (key->GetName() == InputKeys::F2)
    mainWindow->Reshape(1280, 720, WindowMode::Borderless);

This isn't:

if (key->GetName() == InputKeys::F1)
    mainWindow->Reshape(viewportSize.width, viewportSize.height, WindowMode::Windowed);
else if (key->GetName() == InputKeys::F2)
    mainWindow->Reshape(viewportSize.width, viewportSize.height, WindowMode::Borderless);

I post a larger chunk of code:

// register class

WNDCLASSEXA wnd = { 0 };
wnd.cbSize = sizeof(wnd);
wnd.lpszClassName = WindowsWindow::WindowName;
wnd.hInstance = GetModuleHandle(nullptr);
wnd.lpfnWndProc = &WindowsApplication::WndProc;
wnd.style = CS_OWNDC; // | CS_HREDRAW | CS_VREDRAW
wnd.hbrBackground = reinterpret_cast<HBRUSH>(COLOR_WINDOW);
wnd.hCursor = LoadCursor(NULL, IDC_ARROW);

if (RegisterClassExA(&wnd) == 0)
    LOG_ERROR("Failed to register class");
    return nullptr;

// ...

// create window

bool WindowsWindow::Create(const GenericWindowPtr& parent, const GenericWindowDefinition& def)
    this->title = def.title;
    this->windowMode = def.windowMode;

    // first, setup styles
    GetStyleFromDef(def, windowedStyle, fullscreenStyle, extendedStyle);

    // then adjust window region and assign the correct style
    int32 x = def.x;
    int32 y = def.y;
    uint32 width = def.width;
    uint32 height = def.height;
    Adjust(x, y, width, height);

    const uint32 style = (def.windowMode == WindowMode::Windowed) ? windowedStyle : fullscreenStyle;

    HWND parentHWND = nullptr;
    if (parent)
        // it's safe to cast here
        parentHWND = (static_cast<WindowsWindow*>(parent.get()))->GetHWND();

    hwnd = CreateWindowExA(extendedStyle, WindowName, def.title.c_str(), style, x, y, width, height,
                           parentHWND, nullptr, GetModuleHandle(nullptr), nullptr);

    if (!hwnd)
        LOG_ERROR("Failed to create window");
        return false;

    return true;

void WindowsWindow::GetStyleFromDef(const GenericWindowDefinition& def, LONG& style, LONG& fullscreenStyle, LONG& exStyle)
    if (def.hasBorder)
        exStyle = WS_EX_APPWINDOW;
        style = WS_BORDER | WS_CAPTION;

        if (def.supportSysMenu)
            style |= WS_SYSMENU;

            if (def.supportMinimize)
                style |= WS_MINIMIZEBOX;

            if (def.supportMaximize)
                style |= WS_MAXIMIZEBOX;
        exStyle = WS_EX_WINDOWEDGE;

        exStyle |= (def.showInTaskbar ? WS_EX_APPWINDOW : WS_EX_TOOLWINDOW);

    if (def.isTopmost)
        exStyle |= WS_EX_TOPMOST;

    fullscreenStyle = WS_POPUP;

// the current Reshape function which works when the size is changed as well
// note that the problem appears when the client area is not changed

void WindowsWindow::Reshape(uint32 width, uint32 height, WindowMode mode)
    // TODO: fix this

    // change style based on window mode change
    if (windowMode != mode)
        LONG currStyle = GetWindowLongPtr(hwnd, GWL_STYLE);

        if (mode == WindowMode::Windowed) // going windowed
            currStyle &= ~fullscreenStyle;
            currStyle |= windowedStyle;
        else // going full-screen
            currStyle &= ~windowedStyle;
            currStyle |= fullscreenStyle;

        SetWindowLongPtr(hwnd, GWL_STYLE, currStyle);

        windowMode = mode;


    int32 x = 0;
    int32 y = 0;

    // adjust window size and position
    //if (windowMode == WindowMode::Windowed)
        flags |= SWP_NOMOVE;

    Adjust(x, y, width, height);

    SetWindowPos(hwnd, 0, x, y, width, height, flags);

// of course after the window is created:

ShowWindow(hwnd, SW_SHOW);

// OpenGL side:
// currently I'm just setting the viewport and calling glClear for testing purposes
// call list from GLIntercept:


#5294508 WinAPI + OpenGL: Change window style and/or resolution

Posted by on 01 June 2016 - 12:06 PM

Thanks Erik, I'll check your solution soon and if it works, I'll try to find the difference which makes it work. :)


An interesting difference: when creating a window I define a style based on the parameters. The return value of SetWindowLongPtr is the previous window style which should be the same as the manually defined style, but it's not. Is that normal?

#5294447 WinAPI + OpenGL: Change window style and/or resolution

Posted by on 01 June 2016 - 05:42 AM

I though something similar, thanks for the feedback!


It solves the resizing issue (which is irrelevant from the graphics API) but unfortunately the strange behavior remains :(

#5214665 UE4-like shaders from materials (theory)

Posted by on 05 March 2015 - 01:09 AM



I've just checked out the new UE4 (Unreal Eninge 4) and its material editor and I'm thinking how it works.

Is a new shader compiled for each material? If yes, isn't the lots of shader switches affecting the performance? How can it be optimized?



According to this paper, the material is compiled into shader code.


This node graph specifies inputs (textures, constants), operations, and outputs, which are compiled into shader code

#5170326 Reconstructing Position From Depth Buffer

Posted by on 30 July 2014 - 07:47 AM

I'm using linear depth rendered into a texture (I'm using 32 bit floating-point texture, so it's a little overhead reduction). From linear depth it's easy to calculate the world space position with the following steps:

- calculate an eye ray, which points from the eye position to the proper position on the far plane

- when you have this ray, you can simply calculate world space position by eyePosition + eyeRay * depth, if the depth is in [0, 1] range.


This method is the same as Styves mentioned in the post above. There are some modifications of this technique, when you use linear depth in range [0, far - near] or [near, far] or something like that, but the "algorithm" is the same.


However, the "basic" stored depth is exponential, so if you'd like to use that, there's a really simple (but not so cost-effective) method to do that:

- if you have a texcoord in range [0, 1], you have to convert it into [-1, 1] by "texcoord.xy * 2 - 1"

- you set the depth value to the z coordinate

- then apply a homogenous matrix transformation with the inverse of the view * projection


Something like (GLS - NOTE: I didn't test it, just write it here) :

// read depth at the coordinate
float depth = getDepthValue(texcoord);

// get screen-space position
vec4 pos;
pos.xy = texcoord * 2.0 - 1.0;
pos.z = depth;
pos.w = 1.0;

// get world-space position
pos = invViewProj * pos; // or pos * mat, depends on the matrix-representation
pos /= pos.w;

vec3 worldPos = pos.xyz;

Since you have to do this for each pixel, this method can be slower than the previous one.

#5160938 Skill/Spell effects

Posted by on 16 June 2014 - 04:46 PM



Well, I've tried to find some simlar topics, but I can't. Probably I can't search :D This topic was my best hit.


So I've just done my basic particle system: I have an emitter which has direction, start/end values (like color, speed, size, ...) and a delay time between emitting particles. However, I'm just wondering how the computer games make their "own effects" for different skills. I mean, I can't use particle system for every spells.


I'm playing with LoL and it has a lot of different skills. For example here is Katarina's abilities. These are not particles. Are they using simple meshes (some quads) with animated textures with alpha blending? How should I handle these kind of effects?


And another one: if I have to use meshes and/or particles, how should I manage the different abilities? Now I have a base class (called Ability) and the different skills are inherited from it. In these classes I can handle the different particle emitters and actions. Is it a "normal" system or is there any better?


Sorry if I missed something or it's a duplicated topic.

Could you please give me some advice?

#4953855 Self shadowing polygon seems

Posted by on 29 June 2012 - 12:48 AM


How do you create the shadow map?

And well... you should use a "normal" shading, like phong shading, which will be smooth.

#4825004 Calling c++ dll from c#

Posted by on 19 June 2011 - 03:25 AM

@MartinsM: Your solution is good for me :) Lots of kiss :D

I post the full code, if someone are interested in it.

Of course, I'll write an class, which will manage this, but it's a pilot version :)

So thanks everyone for the help

I had some trouble with code blocks, so I uploaded the files
Attached File  cpp_in_csharp.zip   1.22KB   86 downloads