- Forum
- Windows Programming
- MFC or something else?
MFC or something else?
Pages: 12
So far I've worked on a console based snake game, now that I got understanding with that I'd like to make it more visual, like having images instead of symbols, I've been told MFC would be a way to do this. Does anyone have a tutorials about this? Any I can find are either hard understanting or not working.
And If there is an easier way, which one is it?
And If there is an easier way, which one is it?
Not sure if it's possible anymore with modern compilers to be honest, you could do it before back in the days of DOS by writing directly to the video card using VGA programming.
http://www.brackeen.com/vga/basics.html
If you want to try any of that you'll need a really old compiler like Turbo C++ or Turbo C, because modern compilers just won't allow you to access the video card directly and would just crash instantly if you tried.
It's probably a better idea to just try and use a graphics library like SFML though.
http://www.brackeen.com/vga/basics.html
If you want to try any of that you'll need a really old compiler like Turbo C++ or Turbo C, because modern compilers just won't allow you to access the video card directly and would just crash instantly if you tried.
It's probably a better idea to just try and use a graphics library like SFML though.
Last edited on
MFC is for windows GUI programming and is only available in paid versions of Visual Studio. MFC is a framework used to work with the Windows API in a C++-oriented way. The C++ version of .net if you will.
If you want to move away from console and into windows and if you have a paid version of Visual Studio, go for it. I don't know much about MFC, though, so I cannot comment much about it.
I do imagine, however, that a solid knowledge on Windows Programming is key to successfully use MFC.
If you want to move away from console and into windows and if you have a paid version of Visual Studio, go for it. I don't know much about MFC, though, so I cannot comment much about it.
I do imagine, however, that a solid knowledge on Windows Programming is key to successfully use MFC.
There seems to be some misinformation here. Although MFC is for Windows FORMS programming, this is true. GDI / GDI+ is for Win32.
But almost ALL the major game engines use Console mode ( This includes Ogre / Unity etc etc ). Yes, Console mode. OpenGL / DirectX are using the console to setup their graphics. There is no windows forms involved unless you alter the code for it. They in itself are what design the graphics using the console mode to do it. You can use the same graphics in a form, but they were not made for it. The API's were made for speed, which the console mode gives them. ( In other words, no controls are involved. This is what the Windows Forms was all about, making controls easier to program with. )
Its another reason why OpenGL is cross platform. DirectX, although in console mode, is made for windows only.
Try this : Setup a new console application. Then add the freeGlut libraries ( freeGlut is an openGL wrapper ). [ If your really frisky learn DirectX, you'll still be using Dos Console Mode to do it ] You'll be doing ALL of this in your console main.cpp file. Compile it, you'll see that it works with graphics quite nicely.
You see the issue people misunderstand is that those pretty graphics on the screen are not always from windows Forms, but are graphics made inside of the console mode. Windows forms is for windows only, Linux doesn't have Forms. Neither does OSX. They use console interfaces to make their graphics. Although, some think that Console mode is for 16-Bit dos only, its not like this any longer thanks to the newer windows versions now days. It has a 32Bit interface and in some cases, 64.
Windows and OSX are the only operating systems that will not let you talk directly to the hardware. However, OpenGL was created to do a lot of the functions for you and still be cross-platform.
Old school 16-Bit DOS, no one uses unless your creating an Operating system. But 32-Bit Dos is what most everything is still using unless its 64 Bit. Your DOS Console snake game is 32-Bit. So its not about DOS or windows forms, its about what Bit your using, whether its 16, 32 or 64. Again, in windows, its 32 / 64 Bit now.
Hope this clarifies a few things. Bottom line, people use console for their graphics more then they realize, even if you setup an IDE made for OpenGL or DirectX, its still using a Dos console. Think about it, In debug mode, what pops up, a Dos console, even if your testing graphics.
EDIT : You made your snake game already in DOS console. Now instead of using cout, start changing the code to use OpenGL commands to display your graphics on the screen. ( FreeGlut [ Windows / Linux only ] is the wrapper I would use to make things simpler for you ). If your on a MAC, use Glut.framework and OpenGL.framework. So now your snake game can now be cross platform. :D
But almost ALL the major game engines use Console mode ( This includes Ogre / Unity etc etc ). Yes, Console mode. OpenGL / DirectX are using the console to setup their graphics. There is no windows forms involved unless you alter the code for it. They in itself are what design the graphics using the console mode to do it. You can use the same graphics in a form, but they were not made for it. The API's were made for speed, which the console mode gives them. ( In other words, no controls are involved. This is what the Windows Forms was all about, making controls easier to program with. )
Its another reason why OpenGL is cross platform. DirectX, although in console mode, is made for windows only.
Try this : Setup a new console application. Then add the freeGlut libraries ( freeGlut is an openGL wrapper ). [ If your really frisky learn DirectX, you'll still be using Dos Console Mode to do it ] You'll be doing ALL of this in your console main.cpp file. Compile it, you'll see that it works with graphics quite nicely.
You see the issue people misunderstand is that those pretty graphics on the screen are not always from windows Forms, but are graphics made inside of the console mode. Windows forms is for windows only, Linux doesn't have Forms. Neither does OSX. They use console interfaces to make their graphics. Although, some think that Console mode is for 16-Bit dos only, its not like this any longer thanks to the newer windows versions now days. It has a 32Bit interface and in some cases, 64.
Windows and OSX are the only operating systems that will not let you talk directly to the hardware. However, OpenGL was created to do a lot of the functions for you and still be cross-platform.
Old school 16-Bit DOS, no one uses unless your creating an Operating system. But 32-Bit Dos is what most everything is still using unless its 64 Bit. Your DOS Console snake game is 32-Bit. So its not about DOS or windows forms, its about what Bit your using, whether its 16, 32 or 64. Again, in windows, its 32 / 64 Bit now.
Hope this clarifies a few things. Bottom line, people use console for their graphics more then they realize, even if you setup an IDE made for OpenGL or DirectX, its still using a Dos console. Think about it, In debug mode, what pops up, a Dos console, even if your testing graphics.
EDIT : You made your snake game already in DOS console. Now instead of using cout, start changing the code to use OpenGL commands to display your graphics on the screen. ( FreeGlut [ Windows / Linux only ] is the wrapper I would use to make things simpler for you ). If your on a MAC, use Glut.framework and OpenGL.framework. So now your snake game can now be cross platform. :D
Last edited on
I have no idea whether MFCs are useful for actual visual stuff (it is for plotting graphs, but I've never used them for anything beyond that), but you can always try it out. The MSVisual Studio 2010 IDE has a free trial for up to 90 days, which should be more than enough to get acquainted with MFCs.
There seems to be some misinformation here. Although MFC is for Windows FORMS programming, this is true. GDI / GDI+ is for Win32.No, MFC is a native wrapper around win32api, this has nothing to do with .net framework or windows forms.
Windows and OSX are the only operating systems that will not let you talk directly to the hardware.I really doubt that linux let you talk directly with hardware. I am no expert whatsoever, but it is very bad if it is possible.
Hope this clarifies a few things. Bottom line, people use console for their graphics more then they realize, even if you setup an IDE made for OpenGL or DirectX, its still using a Dos console. Think about it, In debug mode, what pops up, a Dos console, even if your testing graphics.You can alloc a console to a GUI application, in linux it is native support for this, in windows there is a special API like AllocConsole().
Yes, you've provided some interesting info Winword, and much of it is likely correct, but some of your terminology is questionable. For example, modoran is right; MFC has nothing to do with Windows Forms. Also, saying that the snake game is 32 bit DOS is a poor if not completely incorrect statement. DOS, as you know, is a 16 bit OS now only little used. Any console mode programming done now is 32 bit or 64 bit Windows. In fact, a console screen is just another type of window. You can get its HWND this way...
HWND WINAPI GetConsoleWindow(void);
And with that you can draw graphics on it if you like, draw text, etc.
HWND WINAPI GetConsoleWindow(void);
And with that you can draw graphics on it if you like, draw text, etc.
| For example, modoran is right; MFC has nothing to do with Windows Forms. |
You are absolutely correct. Thank you for catching that. In my haste I must have been thinking of something else. My apologies on this mistake.
| saying that the snake game is 32 bit DOS is a poor if not completely incorrect statement. |
I would have to agree and then disagree. You see the Console is also known as the DOS console. Even back in windows 3.11 it could use DOS 32-Bit Extensions at times and has been used for decades. When I am speaking of the Console, its still technically a DOS like interface. Is it 16-Bit, no, not since Windows XP came out. It switched from DOS 16-Bit to DOS 32-Bit. But, with Vista and Windows 7 it is no longer able to talk to the hardware like you used too in the past. So is it DOS ? Technically no, but its still a DOS like interface using command just like the original DOS used to do.
When you boot up XP, Vista or Windows 7, as its loading the Kernel, your actually using DOS 32-Bit mode. From there it switches to Windows Protected Mode. You gotta love the boot signature AA55. :P
Also, Linux has the ability to allow your code to TALK directly to hardware ( Meaning your video card, in windows your never allowed to talk directly to the video card anymore as of VISTA and Windows 7 ). You can look up this info. Linux is fully configurable and programmable.
At times I may not be able to explain things on how I know them to work, so it comes across wrong or as if I don't know what I'm talking about, but Please forgive my terminology of things and please I welcome the corrections. Its how I learn. Thank you guys again for this.
Last edited on
thanks for so many replies, I've forgot to add the part that I'd like to port the game to a more visual type, like a window with buttons that you could click, I've been trying to do this with allegro, but it's not quite what I wanted.
Also there's no need for all of it to be compatible with other than Windows, It's just a hobby game.
Also there's no need for all of it to be compatible with other than Windows, It's just a hobby game.
OK I didn't have much time lately so I barely checked this topic, now I like things said in post, but seems nobody noticed that:
so what would you suggest? I'd realy like to get rid of the console...the game IS kinda atractive but console doesn't have any clicking buttons...
| I've forgot to add the part that I'd like to port the game to a more visual type, like a window with buttons that you could click, I've been trying to do this with allegro, but it's not quite what I wanted. Also there's no need for all of it to be compatible with other than Windows, It's just a hobby game. |
so what would you suggest? I'd realy like to get rid of the console...the game IS kinda atractive but console doesn't have any clicking buttons...
If this is windows ONLY.. DirectX is a windows only API. You can use Ogre as the 3D engine if you wish. Allegro you said you didn't like, I can understand that.
I think the problem is do you want a Graphics Engine, or an API ? There are many APIs that work on windows. There are several Graphic Engines that ALSO work on windows, and in some cases, windows ONLY.
So the question is, do you know the difference between the two ?
I think the problem is do you want a Graphics Engine, or an API ? There are many APIs that work on windows. There are several Graphic Engines that ALSO work on windows, and in some cases, windows ONLY.
So the question is, do you know the difference between the two ?
Well, there are a number of choices. MFC is one, but some consider it a bit dated. Basically, for a lot of years the whole ball game of Windows coding of GUIs has been to develop 'frameworks' that are wrappers around the Windows Api functions that create windows and user interface elements. MFC was one of the early ones created by Microsoft. Another early one was OWL 'Object Windows Library' by Borland. Now the biggest players in the game include the .NET Class Framework, and I guess QT and wxWidgets. These latter are cross platform. Finally, there is the way I do it and also a fair number of regulars here and that is to use the Windows Api directly to create GUI apps. I don't know if there are any links that might provide a couple of paragraphs background on the advantages and disadvantages of each method. If somebody has such links maybe they could post them. I guess it might depend on how much effort you want to put forth, but even that is hard to base anything on. For example, I started with MFC many years ago and gave it up. The idea is that its supposed to be easier than directly using the Windows Api. However, for me I thought the opposite. But that might just be me. That's why I'm saying it might be something you'll want to do some research on. Take a look at various simple programs, for example Hello, World! type programs, using the various techniques, and see what makes most sense to you personally.
| If this is windows ONLY.. DirectX is a windows only API. You can use Ogre as the 3D engine if you wish. Allegro you said you didn't like, I can understand that. I think the problem is do you want a Graphics Engine, or an API ? There are many APIs that work on windows. There are several Graphic Engines that ALSO work on windows, and in some cases, windows ONLY. So the question is, do you know the difference between the two ? |
I only said there's no need to be compatible with other platform than windows, I don't realy care about other platforms. If someone saw minecraft main menu([url=http://www.the-construct.net/forums/attachment.php?attachmentid=4448&stc=1]example[/url]) that is an example of a main menu that I'd like to make, i've thought of some app that would use canvas, then draw shapes, images from files, text...which method would be able to do that?
ahh I love minecraft....
You can use simple GDI calls ( calls the gdi32.dll ). Just look up GDI+. You'll get all kinds of neat tuts and info on it.
You can use simple GDI calls ( calls the gdi32.dll ). Just look up GDI+. You'll get all kinds of neat tuts and info on it.
Last edited on
I've looked up some info but it seems I'll have to read a few tut's about win32 apps first :)
Thanks BTW, seems it has what I need.
Thanks BTW, seems it has what I need.
You may already have found the Forgers Win32 Tutorial....
http://www.winprog.org/tutorial/
Realize when you start with that one you may have issues with unicode if you are using Visual Studio.
Also, I've written up this one. It covers the unicode issue...
http://www.jose.it-berater.org/smfforum/index.php?topic=3389.0
http://www.winprog.org/tutorial/
Realize when you start with that one you may have issues with unicode if you are using Visual Studio.
Also, I've written up this one. It covers the unicode issue...
http://www.jose.it-berater.org/smfforum/index.php?topic=3389.0
Pages: 12