win32 programming?
Author
Well I started C++ programming a few days ago. And I think I understand the basic concepts now. - However upto now I only programmed using dos-applications, yet it's much more fun when you're able to create win 32 interfaces etc. So I'm wondering, how do you do this? - Is there any tutorial that explains the basics of those applications? I tried creating a win32 application with msvc++ (that's the abbriviation for microsoft visual c++ right?) - However it generated so much code that I completely lost where to program.. Also I didn't see any 'main()'.
So is there any tutorial that explains how to create those games from scratch?
One word. Don't. [wink]
There is really no magic in it. First, in Windows applications, the main function is replaced by WinMain for historical reasons. That should allow you to create a win32 application although without any windows or graphics.
However, creating windows and all that is just a matter of calling a bunch of functions defined in the windows.h header.
In other words, it's nothing special, and not conceptually different from writing to std::cout defined in the iostream header, or using std::vector defined in the vector header, or......
The point is, it's not some secret extension to the C++ language. You just call some predefined functions, and they do all the magic for you.
At the same time, it is a huge distraction, because you need to focus on things that have nothing to do with programming, and when it doesn't work, you have to browse through Microsoft's documentation of their 20 year old and hugely inconsistent API, instead of learning to fix your programming errors.
That is why people are generally advised to start with text-based applications, and stay with them until they've learnt programming. Which means you'll have to spend more than "a few days", especially in C++.
If you start messing with graphical applications now, the only thing you'll achieve is to slow down your own progress.
You'll be able to make a graphical game much faster if you accept to stay with command-line programs for now, where you can focus on the program logic, on actual programming without needless distractions.
I've got a very simple rule of thumb for when to start poking around with windows/graphics.
Google for win32 tutorials, find an example of how to set up a window, look at the code, and ask yourself it it makes sense. Does it look like complete black magic?
Does it look like the C++ you know? Does it look like it's written in the same language as you're using?
If not, you need to go back and practice programming for a month or two longer.
If you can follow the program flow, even if you don't know what each function does exactly, you might be ready to start playing around with windows.
But don't rush it. You won't lose anything by staying in the text-based world a while longer. The big sticking point is always how well you know programming, and that's the same whether or not you have a graphical component to your programs.
There is really no magic in it. First, in Windows applications, the main function is replaced by WinMain for historical reasons. That should allow you to create a win32 application although without any windows or graphics.
However, creating windows and all that is just a matter of calling a bunch of functions defined in the windows.h header.
In other words, it's nothing special, and not conceptually different from writing to std::cout defined in the iostream header, or using std::vector defined in the vector header, or......
The point is, it's not some secret extension to the C++ language. You just call some predefined functions, and they do all the magic for you.
At the same time, it is a huge distraction, because you need to focus on things that have nothing to do with programming, and when it doesn't work, you have to browse through Microsoft's documentation of their 20 year old and hugely inconsistent API, instead of learning to fix your programming errors.
That is why people are generally advised to start with text-based applications, and stay with them until they've learnt programming. Which means you'll have to spend more than "a few days", especially in C++.
If you start messing with graphical applications now, the only thing you'll achieve is to slow down your own progress.
You'll be able to make a graphical game much faster if you accept to stay with command-line programs for now, where you can focus on the program logic, on actual programming without needless distractions.
I've got a very simple rule of thumb for when to start poking around with windows/graphics.
Google for win32 tutorials, find an example of how to set up a window, look at the code, and ask yourself it it makes sense. Does it look like complete black magic?
Does it look like the C++ you know? Does it look like it's written in the same language as you're using?
If not, you need to go back and practice programming for a month or two longer.
If you can follow the program flow, even if you don't know what each function does exactly, you might be ready to start playing around with windows.
But don't rush it. You won't lose anything by staying in the text-based world a while longer. The big sticking point is always how well you know programming, and that's the same whether or not you have a graphical component to your programs.
Author
Thanks for the advice: the problem is that I can't really think of much to program with only the command line (and files) output (cout,cin). Made a few small things already: like a sorting algorithm of data in files (only using arrays/made my custom bubble sort), some string modify functions (well character-array - modify functions) and a small guess-the-number game. So I wanted to go for a "tetris clone", and I read the example in the stickied topics here, a problem with those is that those guides only say: you need to use this function! - But they never really explain what the functions do. Also I seem to get everytime the same error when following a tutorial:
looking up the lines gives:
first error:
The other 2 problems were actually almost the same: they couldn't convert a "string" to LPWSTR (and LPCTSTR) type. Can anybody explain me how these conversion problems seem to work? - Ow and maybe what those things are/do :P..
Sorry for asking so many questions, but it seems now that the more tutorials I read the more questions I get lol.
EDIT: well I now tried to create an explicit conversion doing things like:
(LPWSTR)WINDOWTITLE - where WINDOWTITLE is a character-string. It didn't give a compiler error, yet the runtime results weren't really satisfying (it actually didn't show any good "marks" in the caption).
Quote:1>...\test_main.cpp(175) : error C2440: '=' : cannot convert from 'const char [17]' to 'LPCWSTR'
1> Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
1>...\test_main.cpp(184) : error C2664: 'CreateWindowExW' : cannot convert parameter 2 from 'const char [17]' to 'LPCWSTR'
1> Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
1>...\test_main.cpp(238) : error C2664: 'BitMapObject::Load' : cannot convert parameter 2 from 'const char [11]' to 'LPCTSTR'
1> Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
looking up the lines gives:
first error:
wcx.lpszClassName=WINDOWCLASS; The other 2 problems were actually almost the same: they couldn't convert a "string" to LPWSTR (and LPCTSTR) type. Can anybody explain me how these conversion problems seem to work? - Ow and maybe what those things are/do :P..
Sorry for asking so many questions, but it seems now that the more tutorials I read the more questions I get lol.
EDIT: well I now tried to create an explicit conversion doing things like:
(LPWSTR)WINDOWTITLE - where WINDOWTITLE is a character-string. It didn't give a compiler error, yet the runtime results weren't really satisfying (it actually didn't show any good "marks" in the caption).
I recommend that you stay away from the Win32 API as it will just give you a lot of headaches. If you want to use "real" graphics and program 2D games, I recommend that you take a look at SDL which is much easier to use than Win32. There are many nice tutorials for it here.
If you are following a book to learn C++, try doing the exercises. All of them. They will reinforce what you know, but also point out what you don't know. Being aware of what you can and can't do (yet [grin]) is a vital part of being a programmer.
To put it bluntly, a few days is insufficient practise before jumping into something complex like graphics.
To put it bluntly, a few days is insufficient practise before jumping into something complex like graphics.
Agreed.
If you're still learning C++ (and believe me... you NEVER stop learning C++... The language takes years to master and you'll find that there's ALWAYS more tricks to learn!) then getting to grips with the HUGE number of Win32 system calls will only get in the way of that vital progress.
However... I would recommend getting to grips with the Win32 API (and perhaps the DirectX API) once you've really covered all the main areas in C++ and then some.
Also... Since the Win32 API is all C based anyway, this will add to the slow down of your C++ development.
I was quite content to develop console applications as I got to grips with C++. After a couple of months, I too had an eagerness to go straight into Win32, but found that it was probably best I learned C too (you DON'T have to of course... But it helps!). After having some experience with C++, getting to grips with C was a bit more straightforward, but I sure did get my fingers burnt here and there LOL!
Once I had gone through a couple of books on C++ and C, it was only then that I delved into the Win32 API (and then eventually DirectX). And believe me, you WILL learn a lot from this experience but it sure takes time.
For future reference, may I recommend "Programming Windows by Charles Petzold". It's an uber book BUT, once you've seen the size of the damn thing, you'll realize that Win32 is quite a BIG nut to crack.
But hey... Take your time dude... No need to rush.
Happy Coding!
If you're still learning C++ (and believe me... you NEVER stop learning C++... The language takes years to master and you'll find that there's ALWAYS more tricks to learn!) then getting to grips with the HUGE number of Win32 system calls will only get in the way of that vital progress.
However... I would recommend getting to grips with the Win32 API (and perhaps the DirectX API) once you've really covered all the main areas in C++ and then some.
Also... Since the Win32 API is all C based anyway, this will add to the slow down of your C++ development.
I was quite content to develop console applications as I got to grips with C++. After a couple of months, I too had an eagerness to go straight into Win32, but found that it was probably best I learned C too (you DON'T have to of course... But it helps!). After having some experience with C++, getting to grips with C was a bit more straightforward, but I sure did get my fingers burnt here and there LOL!
Once I had gone through a couple of books on C++ and C, it was only then that I delved into the Win32 API (and then eventually DirectX). And believe me, you WILL learn a lot from this experience but it sure takes time.
For future reference, may I recommend "Programming Windows by Charles Petzold". It's an uber book BUT, once you've seen the size of the damn thing, you'll realize that Win32 is quite a BIG nut to crack.
But hey... Take your time dude... No need to rush.
Happy Coding!
Quote:Original post by paul23
EDIT: well I now tried to create an explicit conversion doing things like:
(LPWSTR)WINDOWTITLE - where WINDOWTITLE is a character-string. It didn't give a compiler error, yet the runtime results weren't really satisfying (it actually didn't show any good "marks" in the caption).
Don't feel bad about this (it's a common rookie mistake), but "jamming in" a parameter by casting is a bad bad bad thing to do unless you're 100% sure you know what you're doing. In this case you're just covering up a compiler error and trading it for a much harder-to-debug runtime error.
At any rate, the problem here is related to how the Windows API handles character sets and strings. You can see my last journal entry for some explanation as to what's going on here and what you need to do to fix your errors. However I can't guarantee that you'll 100% grasp everything if you don't have a decent working knowledge of C/C++.
Quote:Original post by paul23
Also I seem to get everytime the same error when following a tutorial:Quote:1>...\test_main.cpp(175) : error C2440: '=' : cannot convert from 'const char [17]' to 'LPCWSTR'
1> Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
1>...\test_main.cpp(184) : error C2664: 'CreateWindowExW' : cannot convert parameter 2 from 'const char [17]' to 'LPCWSTR'
1> Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
1>...\test_main.cpp(238) : error C2664: 'BitMapObject::Load' : cannot convert parameter 2 from 'const char [11]' to 'LPCTSTR'
1> Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
looking up the lines gives:
first error:where "WINDOWCLASS" is definded by: #define WINDOWCLASS "FallingBlockGame". Another tutorial I googled also said the same "thing"... So I understand that the variable type is wrong, it should be "LPWSTR", but is it strange I have no idea what LPWSTR is (apart from some obscure class) nor how to convert those?wcx.lpszClassName=WINDOWCLASS;
The other 2 problems were actually almost the same: they couldn't convert a "string" to LPWSTR (and LPCTSTR) type. Can anybody explain me how these conversion problems seem to work? - Ow and maybe what those things are/do :P..
I heartily agree with all the comments above. However, just in case you are curious about the errors you describe...
[EDIT - MJP got there first, and the journal entry he links to looks like a far better and more detailed explanation than mine below].
The reason you are getting these errors is that, by default, Visual Studio creates your projects set to use UNICODE rather than the single-byte character set you are more used to using. However, since C++ is a bit archaic, a quoted string "like this" is always single-byte, regardless of your project settings.
The quick and dirty solution is to set your project to use single-byte character sets. This will allow you to compile most of the older sample code on the internet with VS.
Go to Project->Properties, then in Configuration Properties, and click on General. In the right hand box, under Project Defaults, change Character Set to Not Set.
If you are really interested, the header file <tchar.h> gives a bunch of macros designed to write code that can compile under either configuration. Also, searching the help for 'UNICODE' will give a lot of information.
Or you could take the far more sensible option of using a modern language and library like C#.NET to write Windows applications where stuff like the above is irrelevant.
best win32 resources i've seen
http://www.stromcode.com/
http://www.winprog.org/tutorial/
http://www.functionx.com/win32/
http://www.catch22.net/tuts/
http://msdn.microsoft.com/en-us/library/aa383749.aspx
but SDL works alot better for game stuff, alot simpler
http://www.stromcode.com/
http://www.winprog.org/tutorial/
http://www.functionx.com/win32/
http://www.catch22.net/tuts/
http://msdn.microsoft.com/en-us/library/aa383749.aspx
but SDL works alot better for game stuff, alot simpler
unicode is a big pain in the butt sometimes, at least compared to ascii. hopefully the new c++ standard will fix many of the problems with character strings. They've even got it in the works to extend STL strings with unicode support.
I believe there is something in the new standard that will get around this headcahe once and for all, at least in terms of string literals:
u8"I'm a UTF-8 string."
u"This is a UTF-16 string."
U"This is a UTF-32 string."
"Regular ascii string."
I believe windows api uses "wide characters" (wchar)... which is basically their own version of unicode.
I believe there is something in the new standard that will get around this headcahe once and for all, at least in terms of string literals:
u8"I'm a UTF-8 string."
u"This is a UTF-16 string."
U"This is a UTF-32 string."
"Regular ascii string."
I believe windows api uses "wide characters" (wchar)... which is basically their own version of unicode.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
