So who is an expert at making a Windows GUI?
Moderators: hgm, Rebel, chrisw
-
- Posts: 7220
- Joined: Mon May 27, 2013 10:31 am
Re: So who is an expert at making a Windows GUI?
Looks like our free visual studio 2015 community does not support all new features of C# 7.0
-
- Posts: 27811
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: So who is an expert at making a Windows GUI?
Although I did a lot of work on WinBoard, I did not have to touch the GUI part much, as it already existed before I got involved. It uses the low-level Windows API, which is awful. (But it gives a comparaively small program, which does not have to rely on huge on-standard DLLs.)
My only advice is: try to separate the engine from the GUI. Just make the engine a console application that communicates through stdin and stdout by means of a standard protocol with the GUI. Then it can also run under other GUIs, and it becomes easier to play it against other engines. The WinBoard Alien Edition does support Checkers.
Beware that writing a GUI requires typically between 10 and 100 times more effort than writing an engine, depending on the number of features you want to support.
My only advice is: try to separate the engine from the GUI. Just make the engine a console application that communicates through stdin and stdout by means of a standard protocol with the GUI. Then it can also run under other GUIs, and it becomes easier to play it against other engines. The WinBoard Alien Edition does support Checkers.
Beware that writing a GUI requires typically between 10 and 100 times more effort than writing an engine, depending on the number of features you want to support.
-
- Posts: 179
- Joined: Fri Feb 14, 2014 10:53 pm
- Location: the Netherlands
Re: So who is an expert at making a Windows GUI?
For something with the complexity of Winboard or Arena sure, that takes years. But Ed seems to want something fairly straight forward that you can play against. "A one-window app with the board, search info, and scrollable move list is my final aim." That should be a matter of a week with modest effort.hgm wrote: Beware that writing a GUI requires typically between 10 and 100 times more effort than writing an engine, depending on the number of features you want to support.
For Nemeton I do a bare bones Windows API setup with an OpenGL window on top to give me some sort of fast direct pixel acces and then I draw to my internal screen buffer like in the old days. It gives total freedom/creativity and can be ported to any platform but you don't get the shiny Windows buttons.
-
- Posts: 100
- Joined: Fri Sep 19, 2014 5:03 am
Re: So who is an expert at making a Windows GUI?
That sounds like a good solution. Do you have a screenshot of your program? I searched lazily but couldn't find anything but treesStan Arts wrote:For Nemeton I do a bare bones Windows API setup with an OpenGL window on top to give me some sort of fast direct pixel acces and then I draw to my internal screen buffer like in the old days. It gives total freedom/creativity and can be ported to any platform but you don't get the shiny Windows buttons.
-
- Posts: 179
- Joined: Fri Feb 14, 2014 10:53 pm
- Location: the Netherlands
Re: So who is an expert at making a Windows GUI?
Yeah,Ed Trice wrote: That sounds like a good solution. Do you have a screenshot of your program? I searched lazily but couldn't find anything but trees
http://talkchess.com/forum/viewtopic.ph ... 05&t=62588
though I uploaded new versions to that archive since then and there are now a bunch more options. (Coordinates next to the board, move list, some default timecontrols, black background option, uses about 80MB less RAM, better proportioned pieces etc.)
Some minimal WinAPI and OpenGL code to do this. I use (Free)Pascal but the API and OpenGL calls should be close to identical in any C variant.
Pretty sure it won't get any Windows or OpenGL expert seal of approval but it seems to work.
It creates a dynamic chunk of memory at pointer screen^ that is spixx wide and spixy high starting in the upper left corner. Starting at 0 so you can draw to spixx-1 and spixy-1.
Here a pixel is 4 bytes/32 bit but OpenGL also lets you choose different pixel types such as floating point etc.
Code: Select all
Uses Windows,GL;
Code: Select all
Type screent=array[0..68000000] of longword; {Ready for ultra mega wide 8K..}
Var
screen:^screent;
WindowClass:WndClass;
hWindow:HWnd;
wMessage:Msg;
scrnrect:Rect;
contextw:HDC;
contextgl:HGLRC;
spixx,spixy:longword;
stopit:byte;
Code: Select all
procedure resize;
begin
freemem(screen,spixx*spixy*4);
GetClientRect(hWindow,scrnrect);
spixx:=scrnrect.right-scrnrect.left;
spixy:=scrnrect.bottom-scrnrect.top;
getmem(screen,spixx*spixy*4);
glViewport(0,0,spixx,spixy);
glMatrixMode(GL_PROJECTION);glLoadIdentity;
glOrtho(0,spixx-1,spixy-1,0,-1,1);
glMatrixMode(GL_MODELVIEW);glLoadIdentity;
glRasterPos2s(0,0);
end;
Code: Select all
function WindowProc(Window:HWnd;AMessage:UINT;WParam:WPARAM;
LParam:LPARAM):LRESULT;stdcall;export;
begin
if AMessage=wm_Destroy then begin PostQuitMessage(0);stopit:=1;end;
if (AMessage=wm_Sizing)or(AMessage=wm_Size)or(AMessage=wm_Move) then
resize;
WindowProc:=DefWindowProc(Window,AMessage,WParam,LParam);
end;
Code: Select all
procedure windowsmessagepump;
begin
while PeekMessage(@wMessage,0,0,0,PM_REMOVE) do begin
TranslateMessage(wMessage);DispatchMessage(wMessage);end;
end;
Code: Select all
procedure startup;
var PixelFormat:GLuint;
h_Instance:HINST;
pfd:TPIXELFORMATDESCRIPTOR;
begin
stopit:=0;spixx:=1024;spixy:=768;
getmem(screen,spixx*spixy*4);
WindowClass.Style:=cs_hRedraw or cs_vRedraw;
WindowClass.lpfnWndProc:=WndProc(@WindowProc);
WindowClass.cbClsExtra:=0;
WindowClass.cbWndExtra:=0;
WindowClass.hInstance:=system.MainInstance;
WindowClass.hIcon:=LoadIcon(0,idi_application);
WindowClass.hCursor:=LoadCursor(0,idc_arrow);
WindowClass.hbrBackground:=GetStockObject(BLACK_BRUSH);
WindowClass.lpszMenuName:=nil;
WindowClass.lpszClassName:='Test';
if RegisterClass(WindowClass)=0 then exit;
hWindow:=CreateWindow('Test','Test',ws_OverlappedWindow,cw_UseDefault,
cw_UseDefault,spixx,spixy,0,0,system.MainInstance,nil);
if hWindow<>0 then begin
ShowWindow(hWindow,CmdShow);ShowWindow(hWindow,SW_SHOW);
UpdateWindow(hWindow);end else exit;
contextw:=GetDC(hWindow);
pfd.nSize:=SizeOf(TPIXELFORMATDESCRIPTOR);pfd.nVersion:=1;
pfd.dwFlags:=PFD_DRAW_TO_WINDOW or PFD_SUPPORT_OPENGL;
pfd.iPixelType:=PFD_TYPE_RGBA;
pfd.cColorBits:=32;pfd.cRedBits:=0;
pfd.cRedShift:=0;pfd.cGreenBits:=0;
pfd.cGreenShift:=0;pfd.cBlueBits:=0;
pfd.cBlueShift:=0;pfd.cAlphaBits:=0;
pfd.cAlphaShift:=0;pfd.cAccumBits:=0;
pfd.cAccumRedBits:=0;pfd.cAccumGreenBits:=0;
pfd.cAccumBlueBits:=0;pfd.cAccumAlphaBits:=0;
pfd.cDepthBits:=16;pfd.cStencilBits:=0;
pfd.cAuxBuffers:=0;pfd.iLayerType:=PFD_MAIN_PLANE;
pfd.bReserved:=0;pfd.dwLayerMask:=0;
pfd.dwVisibleMask:=0;pfd.dwDamageMask:=0;
PixelFormat:=ChoosePixelFormat(contextw,@pfd);
SetPixelFormat(contextw,PixelFormat,@pfd);
contextgl:=wglCreateContext(contextw);
wglMakeCurrent(contextw,contextgl);
glClearColor(0,0,0,1);glShadeModel(GL_FLAT);
glDepthFunc(GL_ALWAYS);glDisable(GL_DEPTH_TEST);
glPointSize(1);glLineWidth(1);glpixelzoom(1,-1);
glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);glLoadIdentity;
resize;
end;
procedure stoppen;
begin
freemem(screen,spixx*spixy*4);
wglMakeCurrent(contextw,0);wglDeleteContext(contextgl);
ReleaseDC(hWindow,contextw);DestroyWindow(hWindow);
end;
Code: Select all
procedure drawscrn;
begin
gldrawpixels(spixx,spixy,GL_RGBA,GL_UNSIGNED_BYTE,@screen^);
glflush;
filldword(screen^,spixx*spixy,0);
end;
Code: Select all
begin
startup;
repeat
{do and draw something..}
drawscrn;
Windowsmessagepump;
until stopit=1;
stoppen;
end.
-
- Posts: 100
- Joined: Fri Sep 19, 2014 5:03 am
Re: So who is an expert at making a Windows GUI?
Holy Schmoly!Stan Arts wrote: Some minimal WinAPI and OpenGL code to do this. I use (Free)Pascal but the API and OpenGL calls should be close to identical in any C variant.
Pretty sure it won't get any Windows or OpenGL expert seal of approval but it seems to work.
You even draw the digital chess clocks in 3D?? That must have taken a great deal of trial and error to get just right.
I saw in your GL parameters list where you had the x and y dimensions in pixels the parameter to follow was 4. Is that the color depth exponent? Like 2^4 = 16 colors on the palette? Just wondering.
I have 3D-ish graphics going back to the 1996 Macintosh version:
But I'm trying to really make the new version more visually appealing:
Rather than rendering from scratch based on a changeable 3D origin and "view" location as you have done, I'm taking the easy way out. I'll only need to:
1. Create the offscreen graphics buffer
2. Draw my empty board by reading one png file.
3. Determine the rectangular bounds for each checker and King relative to the board's offscreen origin
4. Draw the proper "crown up" or "crown down" orientation of each red/white checker and King.
5. Stamp the offscreen buffer to the main graphics device.
And once I learn how to do steps 1 through 5 above, I can begin coding
Thanks for sharing your code. I may need to steal some of your OpenGL code at a later time.
-
- Posts: 179
- Joined: Fri Feb 14, 2014 10:53 pm
- Location: the Netherlands
Re: So who is an expert at making a Windows GUI?
Nice board! Especially for 1996. What kind of resolution did that run at and do you keep this paper version on your wall as a poster?
The new stone looks very realistic and the deep red reminds me of a wax seal.
Do you mean the *4 multiplier? That's the 4 bytes per pixel so to reserve memory it needs the resolution *4. It's RGBA so the bytes are Red, Green, Blue and Alpha. I access them as one double word instead of 4 separate bytes which I imagine speeds things up a bit.
In the current orientation say I want to make a pixel blue 100, green 200 and red 200. Alpha is 0. I shift left blue 100 16 bits, green 200 8 bits and add red 200 so the pixel value is 6605000.
From your 1-5 points reading the png file seems the tricky part. But it also seems the internet is rather helpful there so you can just load them into memory and manipulate them however you like. (Much easier than with regular Windows graphics anyway) Note that if the screen or part of it doesn't change you don't need to keep redrawing the screen (like I do in Nemeton) but can cut back on system resources a lot and make it quite light weight.
The new stone looks very realistic and the deep red reminds me of a wax seal.
Ed Trice wrote: I saw in your GL parameters list where you had the x and y dimensions in pixels the parameter to follow was 4. Is that the color depth exponent? Like 2^4 = 16 colors on the palette? Just wondering.
Do you mean the *4 multiplier? That's the 4 bytes per pixel so to reserve memory it needs the resolution *4. It's RGBA so the bytes are Red, Green, Blue and Alpha. I access them as one double word instead of 4 separate bytes which I imagine speeds things up a bit.
In the current orientation say I want to make a pixel blue 100, green 200 and red 200. Alpha is 0. I shift left blue 100 16 bits, green 200 8 bits and add red 200 so the pixel value is 6605000.
From your 1-5 points reading the png file seems the tricky part. But it also seems the internet is rather helpful there so you can just load them into memory and manipulate them however you like. (Much easier than with regular Windows graphics anyway) Note that if the screen or part of it doesn't change you don't need to keep redrawing the screen (like I do in Nemeton) but can cut back on system resources a lot and make it quite light weight.
-
- Posts: 100
- Joined: Fri Sep 19, 2014 5:03 am
Re: So who is an expert at making a Windows GUI?
That was my first software title I got published on both the Mac and PC. I printed that out on a Textronix color laser, I forget the model number, but it was a CMYK solid-ink printer, like laser wax almost. Every printout was shiny. I recently found it, couldn't believe it, 21-year old printout next to my original patent application for what eventually became US 6,481,716.Stan Arts wrote:Nice board! Especially for 1996. What kind of resolution did that run at and do you keep this paper version on your wall as a poster?
Ed Trice wrote: I saw in your GL parameters list where you had the x and y dimensions in pixels the parameter to follow was 4. Is that the color depth exponent? Like 2^4 = 16 colors on the palette? Just wondering.
Ah, thanks. Encoding the data for shift operations, I'm used to thatStan Arts wrote: Do you mean the *4 multiplier? That's the 4 bytes per pixel so to reserve memory it needs the resolution *4.
From what little I know at present, there's an API call to read .png files into a RAM buffer that's pretty straightforward. The "hard part," as I understand it, will be taking the 600 dpi resolution, finding the "correct constant" in the sea of Microsoft constants that will allow for scaling it down with maximum retention of detail, setting up the 2015 equivalent of BitBlt(...), computing the destination rectangle for the offscreen board, then transferring the image like an old school "iron on" decal. I do this for each piece, then I BitBlt(...) the offscreen image to the main monitor to get a nice flicker-free update.Stan Arts wrote: From your 1-5 points reading the png file seems the tricky part.
The only problem is, Microsoft stoped documenting this stuff, and there's no good single volume reference around anywhere.
-
- Posts: 2559
- Joined: Fri Nov 26, 2010 2:00 pm
- Location: Czech Republic
- Full name: Martin Sedlak
Re: So who is an expert at making a Windows GUI?
Not at all, Sean Barrett and his header-only public domain stb_image.h solves the problem easily. https://github.com/nothings/stbStan Arts wrote:From your 1-5 points reading the png file seems the tricky part.