Entries for tag "gui", ordered from most recent. Entry count: 27.
# Immediate Mode GUI - Theory and Example - Slides
Tue
24
Oct 2017
Today I gave a talk at Warsaw GameDev Meetup. Topic of my presentation was: "Immediate Mode GUI - Theory and Example". You can download slides here:
Comments | #gui #teaching #events Share
# Lost clicks and key presses on low FPS
Sun
22
Oct 2017
There is a problem with handling input from mouse and keyboard in games and other interactive applications that I just solved. I would like to share my code for the solution. When your app uses a loop that constantly calculates and renders frames, like games usually do, it may seem natural to just read current state of every mouse and keyboard key (whether it's down or up) on each frame. You may then caculate derived information, like whether a button has just been pressed on released, by comparing new state to the state from previous frame. This is how Dear ImGui library works. So first solution could look like this:
void UpdateFrame() { // Fill ImGui::GetIO().DeltaTime, KeyCtrl, KeyShift, KeyAlt etc. ImGui::GetIO().MouseDown[0] = (GetKeyState(VK_LBUTTON) & 0x8000) != 0; ImGui::GetIO().MouseDown[1] = (GetKeyState(VK_RBUTTON) & 0x8000) != 0; ImGui::GetIO().MouseDown[2] = (GetKeyState(VK_MBUTTON) & 0x8000) != 0; for(uint32_t i = 0; i < 512; ++i) ImGui::GetIO().KeysDown[i] = (GetKeyState(i) & 0x8000) != 0; ImGui::NewFrame(); if(ImGui::IsKeyPressed('A')) // Do something... }
There is one problem with this approach. If user presses and releases a key for a very short time, so that both press and release happens between two frame, it will go unnoticed. This is very annoying. It happens especially when:
First step towards solving this is to react to "real" events that are sent by the operating system:
Comments | #gui #winapi #windows Share
# NoConsole - My C# Project
Sun
26
Feb 2012
Some time ago I started a new personal project. It is called NoConsole. I uploaded it to SourceForge GitHub, with C# source code in Git repository, under GNU GPL. The idea (and name) comes from my aversion to console-based programs. I want to create a framework which enables easy development of GUI over command line tools.
Probably the most interesting part is C# scripting. .NET Framework includes C# compiler, so user doesn't have to install any development environment to be able to compile C# source code into managed EXE or DLL files. So if my program is coded in C#, there was no purpose in including any other scripting language. Scripts that control this program are just CS files. They are compiled into DLL-s on first use. They can execute arbitrary code, but the library shipped with NoConsole simplifies some some common tasks and enables integrating with host application:
The project is in early stage of development. Much can be added or changed. But I already use it to simplify some of the work I do, using my scripts I didn't share here.
Comments | #.net #gui #productions Share
# The Concept of Wait Cursor
Mon
23
Jan 2012
When coding a GUI application, sometimes we have to conduct lengthy operation like loading or saving a file. It would be perfect if every such operation was done on separate, background thread while main thread - the one responsible for windowed interface - would show progress and allow to cancel the operation at any time. But multithreaded programming is hard, so some (not so critical and not so long) operations, like loading a configuration file, are usually done on the main thread, freezing the whole GUI. It's OK as long as the operation takes no longer than a fraction of second or several seconds - just like loading and parsing small configuration file, unless the file is located on a floppy disk :)
But it's good to show to the user that some operation is being performed so he doesn't get angry and terminate your application so quickly. Changing mouse cursor from "Normal" to "Wait" is useful here, so GUI libraries provide functionality for this.
In C#, we do it by setting Cursor property of a Form. Assuming we are inside a method of a Form:
Cursor = Cursors.WaitCursor; // Lengthy process... Cursor = Cursors.Default;
Just don't forget to restore default cursor no matter what's the result of the operation. try-finally section can be useful here to make the wait cursor "exception-safe". Good news is that if you wish to show a MessageBox informing user about an error that happened between setting the cursor to WaitCursor and restoring it, the cursor will change to Default automatically for the time the message window is shown.
It may be tempting to use Application.UseWaitCursor instead, but this method is worse. It requires to go back to main message loop before the cursor change takes effect, so if you set Application.UseWaitCursor = true; then do some time-consuming process inside same function and set Application.UseWaitCursor = false; at the end, user won't see changed cursor at all, whereas setting Cursor property of a form takes effect immediately.
wxWidgets library makes it easy to change cursor to "busy" - as they call it - and restore it at the end of C++ scope by creating an object of class wxBusyCursor on the stack. It will change cursor in its constructor and automatically restore it in destructor of the object.
{ wxBusyCursor busyCursor; // Lengthy process... }
MFC library also has such class. It is called CWaitCursor.
If you know the way to show wait cursor in other GUI libraries, post it in a comment.
Comments | #wxwidgets #.net #mfc #gui Share
# Windows 8 Developer Preview
Thu
15
Sep 2011
News about upcoming Windows 8 appear for some time. Information about the new Windows version directly from Microsoft, including technical details for developers, can be found in this PDF: Windows Developer Preview - Windows 8 guide. Recently Microsoft shared a full, development version of this system to download, install and test on your computer for free. It's a developer preview - it contains the new operating system along with new Visual Studio 11. You can download it as ISO image from Windows Developer Preview downloads. The system works in VirtualBox virtual machine. You can see my first gallery of screenshots here:
My first impressions after testing Windows 8 are... quite weird. Apparently they try to make desktop OS looking like a cellphone, with big fonts and all apps working in fullscreen. But that's only a half-truth. I feel that in Microsoft they always do it this way: a boss comes and tells that "we do it again from scratch only better, redefine everything, but we have to preserve backward compatibility", then a developer thinks how to implement it the simplest possible way and it ends in a new flashy UI containing several shortcuts to the most important commands with the old, good windows hiding somewhere under "Advanced" button. It was the same with Control Panel, with formatting functions in MS Office and now it's the same with the whole Desktop. You are presented a new screen full of colourful rectangles, but as soon as you move your cursor to the bottom-left corner of the screen and click "Start", you are teleported to the normal desktop with a wallpaper, taskbar and the Recycle Bin :)
Other things that attracted my attention: You now login to Windows using your Windows Live ID account. System is integrated with Facebook by providing some application to browse it. Explorer now uses the new Ribbon toolbar, just like new versions of MS Office, Paint or WordPad do for some time. There are lots of new games. New Task Manager is great because it now shows four columns with all most important statistics of every running program: the usage of CPU time, RAM memory, disk transfer and network transfer. Finally the new UI style: flat, colourful, minimalistic, full of solid filled rectangles.
Comments | #windows #visual studio #gui Share
# How to Disable Redrawing of a Control
Thu
18
Mar 2010
When coding Windows application with GUI, there is an issue about how long does it take to add lots of items (like hundreds or thousands) into a list view or tree view control. It is caused by redrawing the control after each operation. I've seen this annoying effect in may programs, including some serious, commercial ones. Apparently many programmers don't know there is a simple solution. But first a bit of background...
When coding games, we constantly spin inside a big loop and redraw whole screen every frame. Calculations are separated from rendering so we can, for example, build a list with thousands of items in the computation function and the visible part of the list will start being rendered since the first rendering function call after that. When coding windowed applications, nothing new is drawn onto the screen unless needed. We have to manually do it and we can call redrawing function any time. So how should a list control be refreshed when we add an item into it? It is done automatically after each insert, which is a good solution... unless we want to add hundreds of them.
So GUI library developers provide a functionality to temporarily disable redrawing of a control.
Comments | #.net #mfc #wxwidgets #winapi #gui Share
# Dialog Layout Manager in MFC
Sat
08
Aug 2009
Sometimes I write some tools using C++ and MFC. In the Linux world it is common that GUI windows are resizeable. In Windows its not the case, but sometimes it would be nice to be able to resize a dialog window to see more information, like more rows and colums in a list. After repositioning and resizing controls in a window with my custom code I've decided to automate this task.
There are many possible approaches to this problem. WinAPI (and thus MFC) does not provide by itself any solution to automatically align controls inside a resizeable window. Each control has just its fixed rectangle (left, top, width, height) inside parent window. Delphi VCL uses Align property to snap selected controls (like Panel containing child controls) to left, right, top or bottom edge of the window. Qt encourages to design all windows with Layouts. For example, Vertical Layout splits the window into rows and automatically adjusts controls inside, one under the other.
But the solution of my choice is the one based on .NET. Controls in Windows Forms have a property called Anchor so they can be anchored to any of four possible window edges: left, top, right and bottom. If a controls is anchored only to left and top edges, it just doesn't change its position or size. If the control is anchored to right and bottom edges (for example: a button), it changes its position as window is resized so it preserves its distance to right and bottom edge of the window. If the control is anchored to all four possible window edges, it is resized to preserve distance to all window edges same as designed (for example: a list occupying central part of the window).
I've written a class which I called DialogLayoutManager. It's very easy to use and automates control resizing and repositioning inside an MFC window. All you need to do at the beginning is to create an object of this class, register your controls with selected anchors and call Save method:
m_LayoutManager->SetControl(GetDlgItem(ID_BTN_CANCEL), DialogLayoutManager::ANCHOR_RIGHT | DialogLayoutManager::ANCHOR_BOTTOM); m_LayoutManager->SetControl(GetDlgItem(ID_BTN_OK), DialogLayoutManager::ANCHOR_RIGHT | DialogLayoutManager::ANCHOR_BOTTOM); m_LayoutManager->Save(this);
Layout manager remembers positions and sizes of registered controls together with starting window size. Now all you need to do when the window is resized is to call Restore method. Layout manager will adjust registered controls according to new window size and specified anchors. For example, two buttons showed above will stay in bottom-right corner of the window.
void CDialog01::OnSize(UINT nType, int cx, int cy) { ... if (LayoutManager && LayoutManager->IsSaved()) m_LayoutManager->Restore(this); }
Here is the code of my DialogLayoutManager class and usage example: DialogLayoutManager.cpp. It's easy to translate this code to pure WinAPI.
Comments | #gui #mfc #winapi Share
# Czcionki z komputera Atari
Tue
09
Jun 2009
Współcześnie "Atari" kojarzy się z wydawcą gier, ale kiedyś pod tą marką produkowane były komputery - w czasach, zanim jeszcze pecet podbił świat. W sobotę byłem na imprezie demoscenowej poświęconej miłośnikom klasycznych platform (przede wszystkim, jak się okazało, 8-bitowych Atari). Na tym spotkaniu m.in. wykłady miał TDC. Dowiedziałem się z nich bardzo dużo o budowie i możliwościach sprzętu tamtej generacji (w tym układu graficznego), ówczesnym oprogramowaniu i rynku gier. Okazuje się, że Wolfenstein i Doom wcale nie były pierwsze i że bardzo dużo działo się już w czasach, kiedy mnie jeszcze nie było na tym świecie :)
Przy okazji trafiłem na polskie strony poświęcone Atari - atari.area i Atari Online, a na nich znalazłem kolekcję czcionek z tej platformy: [1], [2]. W przypływie dziwnej ochoty (zapewne spowodowanej niewyspaniem) postanowiłem dopisać wsparcie dla nich do swojego domowego projektu (pisanego oczywiście na PC i w DirectX).
Specyfikacji formatu pliku FNT nigdzie nie znalazłem, ale udało mi się go rozgryźć samemu. To z resztą nie było trudne, jeśli wiadomo, że taki plik ma 1024 bajty, a zawarta w nim czcionka to 128 znaków bitmapowych po 8x8 pikseli monochromatycznych. W końcu 128*8*8 = 8192 b = 1024 B :) Toteż napisałem samemu specyfikację tego formatu: Atari Font FNT File Format.txt, a czcionki z wyżej wspomnianej strony (razem ze screenami) pozwoliłem sobie spakować i udostępnić jako jedno archiwum, żeby łatwiej było ściągać - Atari_Fonts.zip. Przykładowa czcionka (jedna z 335) o nazwie "Atari" wygląda tak:
A efekt mojego kodowania prezentuje się tak (niezły oldschool :D)
Comments | #events #gui #rendering #gallery #demoscene Share