I don't know if I had gotten it all wrong, so I'm asking for directions here.
Let's take for example, back in college, when you learned C++ and used Turbo C++ or GCC to compile, you get an idea of what a low level programming language is.
Now let's say I want to make a basic 2D video game, just as a personal project, nothing fancy, and I want to develop it using C++ just because. I'd code it using Visual Studio since it's a pretty good IDE.
Is it right to say "I'm going to use MFC" for this kind of project? (Consider the fact that I'd be using OpenGL).
MFC is a C++ framework that encapsulates the core elements of the Windows API. It's primarily intended for creating standard, windowed applications that the user interacts with on the desktop.
It comes with a built-in graphics framework: GDI. The one that was introduced with Windows, revolutionary for its time because it abstracted away hardware-specific details and allowed programmers to write general code that ran on any machine Windows ran on. But it was never particularly good for games; it was designed for Windows-style business applications. It was awesome for text (and is still arguably the best option that there is—have you looked at how Direct2D renders text lately?), and handled simple graphics, but consider that before alternative graphics-specialized frameworks like OpenGL were available, most game developers stuck with DOS, where they could/were forced to interact directly with the graphics hardware at a low level.
So if you want to use MFC and OpenGL together, you can, but I don't really see the point. The only real benefit you'd be gaining from MFC is a reduction of 100-some-odd lines of code that sets up the fundamental skeleton of any Windows application. For example, considering this sample OpenGL program, using MFC would essentially allow the WinMain and the MainWndProc functions to be buried deep in the bowels of the MFC framework code, rather than appearing directly in your code. But, like I said, big deal. The majority of your code is going to be OpenGL-specific, and MFC won't help there.
The only way it might make sense for the two to interact is if you wrote the launchpad/host for the game using MFC and GDI (i.e., the part that displays windows and dialogs on screen), and then the game portion itself in OpenGL (launched once you clicked a "Start" button on the dialog interface).
And of course, even if you wanted to do this, MFC is not your only option. There are tons of C++ frameworks for writing Windows applications. Everyone has their favorite. Despite what some may tell you, there's nothing wrong with MFC if you already know it and/or are comfortable with the Windows API. But don't waste time learning it. Use WTL instead.
You would NOT use MFC simply because it is meant for general application development giving you features and classes that you will most likely never use!
A good start would be to look at SFML http://www.sfml-dev.org/ or (my personal favourite) SDL http://www.libsdl.org/. These libraries were written to develop games or at least multimedia applications using them.
Writing a Game Editor in MFC can be a good idea though!
Related
How can graphics functions be used in Visual Studio 2017 (C++) without using a BGI library? What header file is used? I want to use these functions to do things like drawing a circle.
The header file <windows.h> allows you to use Windows API for many functionalities including but not limited to functions that you will use to do graphics by yourself such as SetPixel and GetPixel and many others you can see the code in this repository which contains C++ implementations for various circle drawing algorthims.
You have quite a few options:
Windows API - Quite difficult to use but runs incredibly fast. This is perhaps the most difficult option due to how complex and no-hand-holding it is.
MFC - Microsoft's tools for C++ graphics. Not too easy to use but certainly easier than WinAPI. A lot of people don't like using this as it's kind of old and there are better stuff out there.
OpenGL/Vulkan/DirextX - These three are very similar technologies. They are based around using your graphics card for drawing, using small programs called 'shaders' which can be edited and compiled on the fly. Most games use one of these, and they run pretty fast. DirectX is Windows only, and Vulkan is pretty low-level. I would recommend OpenGL out of these three.
External library - There are many libraries you can use such as Qt, wxWidgets or SFML. All of these have their own pros and cons, but they all are third party libraries which bridge the gap between commands like 'draw a circle' and the Windows calls that go on under the surface.
Chromium Embedded Framework - CEF allows you to code the guts of your program in C++, then create the GUI using HTML5 and Javascript. Essentially it's a web browser connected to a C++ backend. Looks really nice but some criticise it for its resource usage, which is much larger than the alternatives.
I would recommend staying away from WinAPI and MFC and either use a third-party library (for simple GUIs) or OpenGL (for complex rendering i.e. games). If you're confident in web programming then you can go for CEF.
I want to create a C++ UI framework (something like QT or like ubuntu unity Desktop)
How is programmed , is it using OpenGL or lets take plasma ui of QT (how is this programmed )?
Direct answers , reference links anything will be helpful.
Some interesting opengl based UI I founf on the web
LiquidEngine
http://www.youtube.com/watch?v=k0saaAIjIEY
Libnui
en.wikipedia.org/wiki/Libnui
Some UI frameworks render everything themselves, and work based on some kind of clipping-window-within-the-host-systems-screen. Non-display aspects (such as input event handling) have to be translated to/from the host systems underlying APIs.
Some UI frameworks translate as much as possible to some underlying framework.
wxWidgets can do both. You can choose a native version (e.g. wxMSW if you're on Windows) and most wxWidgets controls will be implemented using native Windows controls. Equally, you can choose the wxUniversal version, where all controls are implemented by the wxWidgets library itself.
The trouble is that typical GUI frameworks are huge. If you want a more manageable example to imitate, you might look at FLTK. I haven't got around to studying it myself, but it has a reputation for being consise.
There are also some GUI toolkits that are specifically aimed at games programming, such as Crazy Eddies GUI. My guess - these are probably as idependent of the underlying API as possible, so that particular applications can implement the mapping to whichever underlying API they happen to target (OpenGL, DirectX, SDL, whatever) and can be the boss of the GUI rather than visa versa.
http://www.wxwidgets.org/
http://www.fltk.org/
http://www.cegui.org.uk/wiki/index.php/Main_Page
"no really, don't write your own wm or toolkit"
The #Xorg-devel guys on irc.freenode.org
doing one anyway means that you have to test against a wide range of more or less buggy WMs and X implementations, and that you have to frequently update to be compatible with the latest Xorg server and X protocol features (like Xinput 2.1)
understandably, the Xorg people are tired to support old, unmaintained toolkits and applications. They already have enough bugs.
The GUI frameworks are very dependant on a windows system, which dictates what is allowed and how windows are created and rendered. For example, pass a specific option to create a borderless or full-screen window.
Since you mentioned opengl and ubuntu, I guess you want to start on a linux platform. You should study xlib, for which you can find reference here.
Since the qt library is open source, you can download it and peek into it's sources.
A UI library isn't developed from scratch. It relies on the OS' windowing system, which relies on the driver from your graphics adapter, which relies on the OS kernel, which relies on... and so on.
To develop any software "from scratch", you can start by writing your own BIOS. Once you're done with that, move on to writing an OS, and then you should be just about ready to write the software you wanted. Good luck.
And this is assuming you're willing to cheat, of course, and use a compiler you didn't write from scratch.
Before you do that, it's worth that you spend one week on thinking:
1, Do you really know how to do it? I doubt that.
2, Do you really need to do it? I doubt that too.
I want to develop native c++ windows application using windows API.
but i find it being difficult because i am unable to render the window and drag and drop components, change the location etc..
How can i view, drag and drop components like i can do in C# ?
May be there is no way to do. if so, what is the fastest procedure to design the application ?
If you like so much the drag and drop of components (and of course for good reason) why would you need to develop it using C++? You can use PInvoke if you need to call some C++ functions from C# code that are not in the .net framework.
But if you really insist, maybe you could try QT.
Using a library framework such as Qt is really the way you want to go. It makes things very simple and still allows you to write code in std c++ to keep most things very fast.
If you EVER have intentions of porting the code to a different platform than windows (whether it be Mac, Linux or even Android ... yes its possible), qt is definately the way you're going to want to go.
I can get an app up and running... smoothly in a few minutes using Qt but much longer and with more confusion using MFC.
Dragging and dropping 'widgets' to form a gui is very easy and possible with Qt's built-in QtDesigner!!! Check it out!!!
http://qt.nokia.com/downloads
Assuming you are using Visual Studio, if your app can be implemented as a dialog box, then you can use the dialog editor to lay things out. Otherwise, you just have to write code to create the windows and place controls. Look at the MFC examples included with Visual Studio.
Jeff Prosise's PROGRAMMING WINDOWS WITH MFC was one of the better books for learning how to do this, but I think it is out of print, and so could be hard to find.
Charles Petzold's PROGRAMMING WINDOWS is the bible for the Win32 API. Again, may be hard to find these days.
If MFC isn't your cup of tea, you could also look at QT, GTK+, or wxWidgets. There are GUI builders for each of those, but they are all pretty primitive compared to what you can do with C#.
As far as I know there is no ide out there that will let you "drag and drop create" standard win api windows like you would with C#.
Personally for that kind of application I always recommend Borland C++ Builder (Which is now Codegear Rad studio)
Although it is not standard API, it allows you to drag an drop and static linking is very easy, so you dont have to worry about redistributables
I'm looking into creating a GUI program for Windows in C++, I have a good knowledge of C++ in the command line and also in game creation. But I'm not sure where to start with GUI application development.
I have Visual Studio 2010 and have created new projects with a GUI but these templates are complex and leaves me not understanding whats happening and how to modify it.
So I'm asking where do I start? Preferably good websites that you can recommend or tutorials, rather than books being a poor student :)
Having written Windows code since Win2.0, I have to say: start with C#. It's a very easy language to learn after C++, and many of the new features (like built-in event handling) were put there to make writing GUI applications easier.
Then, once you're used to the basic concepts of window management and messaging, then drop down into C++.
I say this for the same reason that assembly is not a good first language. There is an enormous amount of housekeeping code in a Windows application, and in C++ you see it all. Better to use a language that hides much of it until you're grounded.
I'd personally recommend using Qt instead to develop your GUI.
Use a GUI framework/library that hides the dirt from the low-level GUI api. MFC is not a solution - it is only a thin layer above the WinAPI. I recommend using QT or wxWidgets. If you use Qt use the Qt creator/Qt designer to design interfaces. If you use
wxWidgets use wxFormBuilder.
I just wondering about this.It is said that .NET is better than MFC in a lot of aspects.But when I use my PEID to recursive scan my 'program files' directory,it turns out there are still a lot of programs written with 'Visual C++ 6'(esp. for security software),whose GUI should be written with MFC.
So my questions are:
Is MFC still the dominating framework
for windows desktop aplication?
What frameworks do IE,firefox,Microsoft office(or other famouse desktop applications,if you'd like to list some) use?
What frameworks do the desktop applications(e.g. explorer,card games) of Windows itself use?
thanks.
I say windows forms and WCF are pretty widespread. C#/VB.NET are well-entrenched in corporate america.
IE is COM-based.
Office is MFC/COM.
Windows Apps are usually native code to demo the platform.
For new projects I don't think MFC is the dominant platform, but mostly because newer platforms shield developers from the idiosyncrasies of Win32 and MFC itself and allow for faster development. MFC applications take longer to develop but are, imo, unmatched in responsiveness.
I will not deny that some parts of the platform are irrelevant in 2010 (for example CArchive and most of the Doc/View foundation); on top of that, the dwindling availability of 3rd party components (mostly GUI) is a bit worrisome. FP1/MFCNext was a step in the right direction, I'm anxious to learn about the new MFC functionality in VS 2010.
For optimal integration with the OS, imo C++/MFC is still the best choice because of the nature of C++ as low-level and the fact that Win32 is still the foundation of Windows and that it can most easily be accessed in C or C++.
By the way, I had to write code to change screen resolution and found that C# could only handle detecting screen resolution but not changing it.
To change resolution you had to do a lot of Interop gobbldygook which I tried but was too complex because the Win32 APIs to do that had too many old style arguments.
So, instead I wrote a quick MFC DLL that accessed Win32 API directly and wrapped all the calls to Win32 in a simple API. Then I did an interop call to my simple API in an MFC User dll.
Everything worked fine.
So, there's still no substitute for Win32 API. That has the ultimate power, and you have full access to it via MFC. So, yes MFC is still relevant and so is ATL and so is direct Win32 all of which I'm forced to use from time to time.
So, you may get 90 percent of your work done with .NET, but you have to go under the covers for a few things. Also, I've done a lot of Qt, and would never use it for quick jobs that are windows only. Qt also has become prohibitively expensive if you're doing anything commercial and also it is very very bloated. It's libraries take up gigabytes.