A few questions about Visual Basic, C++, and starting windows programming

This is a discussion on A few questions about Visual Basic, C++, and starting windows programming within the Windows Programming forums, part of the Platform Specific Boards category; Hi. I've learn how to do DOS C++ (Classes, variables, structures, etc) And trying to get into the world of ...

  1. #1
    Registered User
    Join Date
    Jul 2007
    Posts
    11

    A few questions about Visual Basic, C++, and starting windows programming

    Hi.

    I've learn how to do DOS C++ (Classes, variables, structures, etc) And trying to get into the world of windows programming, and got some questions:

    1: VC++, .NET, MFC, winapi: I understand that these are all windows codes based on C++. I also understand that all apart from winapi are functions that clean up the complicated code in winapi. What I'm asking is for a beginner in windows programming who would be concentrating on games programming, should I learn the winapi to the full extent, or should i jut gain a basic understanding then move on to one of the above?

    2: What is the most commonly used compiler in games programming? I've been using Dev C++ (From bloodshed) But i realise that Visual Basic 2008 is popular/

    3: Anyone got any good tutorials on using Visual Basic 2008? It might sound stupid, but all I can access is the front end and some deeply simplified code on certain files. I can create windows programs, but it sucks if you are trying to learn what to do.

    I know this might be silly/answered before, but I'm new to this

  2. #2
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    The "raw" windows API is not C++ based, it's based on C.

    For GUI programming, Visual Basic or C# are probably good options.

    Games are mostly written in C++ for performance [but as we all know, only 10-20% of the overall code consumes 80-90% of the time. So there's nothing saying you can't mix a large portion of C# or Basic with a small portion of C/C++ for performance].

    As to games programming, you'd be using DirectX or OpenGL if you are going to do 3D games. But producing a full-feature game is not something most individuals can do. It's a group effort. You can obviously write a simple FPS or RPG, but a "proper" game is a multi-person task that probably takes a group of 5-20 people between 3-12 months to perform, depending on the complexity of the game.

    If writing games is what you want to do, then you need to start simple. A text-based RPG or a simple FPS game (e.g. space-invaders style thing) would be a very good start. Even that will give you a few challenges if you haven't done it before.

    --
    Mats
    Last edited by matsp; 11-21-2007 at 04:16 PM.
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  3. #3
    Registered User
    Join Date
    Jul 2007
    Posts
    11
    Quote Originally Posted by matsp View Post
    The "raw" windows API is not C++ based, it's based on C.

    For GUI programming, Visual Basic or C# are probably good options.

    Games are mostly written in C++ for performance [but as we all know, only 10-20% of the overall code consumes 80-90% of the time. So there's nothing saying you can't mix a large portion of C# or Basic with a small portion of C/C++ for performance].

    As to games programming, you'd be using DirectX or OpenGL if you are going to do 3D games. But producing a full-feature game is not something most individuals can do. It's a group effort. You can obviously write a simple FPS or RPG, but a "proper" game is a multi-person task that probably takes a group of 5-20 people between 3-12 months to perform, depending on the complexity of the game.

    If writing games is what you want to do, then you need to start simple. A text-based RPG or a simple FPS game (e.g. space-invaders style thing) would be a very good start. Even that will give you a few challenges if you haven't done it before.

    --
    Mats

    Yea not planning on rushing with the game making. Want to be able to do them good, not just get them done (Never liked Klick and Play for that reason).

    Basicly right now trying to get my head around windows, then going to start adding in Open GL and DirectX ect, eventually making simple games, increasing in complexity has things go on.

    But the first step is choosing what to learn ect, and getting my head around using Visual Basic 2008 instead of Dev C++ (The latter is much more simpler basicly a text editor, hands on .)

  4. #4
    train spotter
    Join Date
    Aug 2001
    Location
    near a computer
    Posts
    3,859
    Do you mean Visual Basic (6 or .NET) the language?

    Or

    Visual Studio 2008 the IDE (compiler) [I think you mean this] also known as MSVC.

    I suggest looking into some simple WIN32 apps in C++ (notepad calculator ect). Move into OpenGL / DirectX

    Visual Basic and MFC are not the best choices for games. They are easier to code in but suffer performance issues (MFC can be hacked to sort of work...).
    "Man alone suffers so excruciatingly in the world that he was compelled to invent laughter."
    Friedrich Nietzsche

    "I spent a lot of my money on booze, birds and fast cars......the rest I squandered."
    George Best

    "If you are going through hell....keep going."
    Winston Churchill

  5. #5
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,985
    Windows API and raw, native Windows programming is a real pain. You better take a framework, like MFC, to make your windows and dialogs.
    Though for a game, a terrible lot of GUI coding isn't necessary. Usually what you'd do is create windows and render onto them. Though I'm not into game coding so I don't really know much.

  6. #6
    Registered User
    Join Date
    Jul 2007
    Posts
    11
    Thanks for the replys.

    So basically since games are generally required to maintain a good performance, using C++ is a must, since everything else is based on this, anything else is an extra layer, causing performance problems. But for programmes that don't require great performance, something like MFC or VC++ might be a good idea after you have learnt to use the basic winapi, due to the ease of use?

    Yea I did mean the Studio, though for some reason the shortcut is called 'Microsoft Visual Basic 2008 Express Edition' yet the folder it is in is called 'Microsoft Visual Studio 9.0' I've had a look for tutorials but all I can find is ways to use the 2006 edition. Is this just because 2008 is very new? Might it be a better idea to use the 2006 edition?

    Has for learning I'm planning on using http://www.winprog.org/tutorial/ for the Winapi. I take it this will still work with new compilers (Just checking, I'm guessing it will)

    Thanks for all your help so far

  7. #7
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,985
    VC++ is not a programming language - it's an IDE.
    You don't usually have to learn windows api to use a framework - since usually building GUI differs from platform to platform so if you want to stay independant, you should use a cross-platform framework and stay away from win api.
    That said, using MFC usually doesn't require much api knowledge (though you should know some basic things, about how windows works). But yes, for applications, using a framework is pretty much a must since pure win32 is just nasty.
    As for games... well, most APIs are also written for C/C++ in mind, so using another language will also slow it down there as well...

    Sure, the tutorial will work, since it's basic win32 stuff, so long as you include the right headers... although if you don't use VC++, you may have to download the platform sdk.
    But generally I would recommend you try to find a framework tutorial first and then interact with the basic win32. Pure win32 is downright nasty, but MFC does like to wrap around it, although making it easier.
    Maybe someone has a better suggestion than that, though...
    It's important to understand how things work, but it isn't important to understand how to do it in win32 apis.
    Last edited by Elysia; 11-22-2007 at 02:08 PM.

  8. #8
    train spotter
    Join Date
    Aug 2001
    Location
    near a computer
    Posts
    3,859
    Quote Originally Posted by Normac View Post
    So basically since games are generally required to maintain a good performance, using C++ is a must, since everything else is based on this, anything else is an extra layer, causing performance problems. But for programmes that don't require great performance, something like MFC or VC++ might be a good idea after you have learnt to use the basic winapi, due to the ease of use?
    Windows (WIN32) apps are 'Event' driven programs. Events (user, OS, timed etc) determine what the app does next. WIN32 apps use a 'message pump' to get these 'events' from the OS (ie the user moves the mouse,
    this is put in the OS message queue,
    passed to the app
    the apps message pump picks it up,
    sends it to the right window, dialog
    which reacts to the mouse move.

    Games and general apps have a different message pump. This is because games want to redraw screens, move objects etc when nothing else is happening.

    C/C++ is not required......but it helps.

    MFC hides the message pump from you, making it hard to change it to a game style message pump.

    [As opposed to a 'structured' program which runs through its code, the program deciding where to go next or waits for input before proceeding.]

    Quote Originally Posted by Normac View Post
    Yea I did mean the Studio, though for some reason the shortcut is called 'Microsoft Visual Basic 2008 Express Edition' yet the folder it is in is called 'Microsoft Visual Studio 9.0'
    Check you have the full series, not just the Visual Basic compiler. Like MS Office (Word, Excel, PP, Access), Visual Studio has 'parts' (MFC, C/C++, VB, C# ASP ect)

    Quote Originally Posted by Normac View Post
    I've had a look for tutorials but all I can find is ways to use the 2006 edition. Is this just because 2008 is very new? Might it be a better idea to use the 2006 edition?
    I suggest one of the older versions (2003 or 2005) as you will find more examples online for these. But use what you can get your hands on.....

    Quote Originally Posted by Normac View Post
    Has for learning I'm planning on using http://www.winprog.org/tutorial/ for the Winapi. I take it this will still work with new compilers (Just checking, I'm guessing it will)
    Forger is a good source, as is http://www.foosyerdoos.fsnet.co.uk/ by one of the mods here Ken Fitlike.

    Also try to learn how to find stuff at MSDN, is hard (especially at first) but required for WIN32 programming.

    For games try http://nehe.gamedev.net/

    Good Luck!
    "Man alone suffers so excruciatingly in the world that he was compelled to invent laughter."
    Friedrich Nietzsche

    "I spent a lot of my money on booze, birds and fast cars......the rest I squandered."
    George Best

    "If you are going through hell....keep going."
    Winston Churchill

  9. #9
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,985
    Quote Originally Posted by novacain View Post
    MFC hides the message pump from you, making it hard to change it to a game style message pump.

    [As opposed to a 'structured' program which runs through its code, the program deciding where to go next or waits for input before proceeding.]
    Not really. MFC, too, is event driven. You specify which what what messages you want to handle them and MFC forwards them to you. Yes, they go through the framework and MFC processes them too, which might not always be ideal for gaming, but in general, it's the same.

  10. #10
    train spotter
    Join Date
    Aug 2001
    Location
    near a computer
    Posts
    3,859
    Quote Originally Posted by Elysia View Post
    Not really. MFC, too, is event driven. You specify which what what messages you want to handle them and MFC forwards them to you. Yes, they go through the framework and MFC processes them too,
    Sorry if I was not clear, MFC is a subset of WIN32 and is totally event driven.


    Quote Originally Posted by Elysia View Post
    which might not always be ideal for gaming, but in general, it's the same.
    Ummmmm.....no.

    There are two main types of message pumps, standard (GetMessage) and game (PeekMessage). [this is a simplification]


    The standard pump gets messages and sends them off.
    If no messages are available it WAITS until there is a message for the app.
    This uses very little CPU unless the app is never idle (always getting input/processing).

    The game message pump checks for a message and sends it off.
    If no messages are available it returns (without waiting) and immediately calls code to update the screen. Thus the screen can be redrawn as many times as possible while proccessing all user input.
    This uses 100% CPU.


    MFC creates its own message loop using a series of PeekMessage calls and a GetMessage call.

    MFC's message loop can not be modified, but limited processing can be done in the OnIdle() handler.
    EDIT: As all OnIdle() processing is done prior to checking for user input and so is out of sequence for a game (which wants to get user input, move objects based on time/input then update screen)

    As MFC uses multiple calls to retreive a single message from the OS queue, it is very slow.

    Code:
    //MFC message pump
    	ASSERT_VALID(this);
    	_AFX_THREAD_STATE* pState = AfxGetThreadState();
    
    	// for tracking the idle time state
    	BOOL bIdle = TRUE;
    	LONG lIdleCount = 0;
    
    	// acquire and dispatch messages until a WM_QUIT message is received.
    	for (;;)
    	{
    		// phase1: check to see if we can do idle work
    		while (bIdle &&
    			!::PeekMessage(&(pState->m_msgCur), NULL, NULL, NULL, PM_NOREMOVE))
    		{
    			// call OnIdle while in bIdle state
    			if (!OnIdle(lIdleCount++))
    				bIdle = FALSE; // assume "no idle" state
    		}
    
    		// phase2: pump messages while available
    		do
    		{
    			// pump message, but quit on WM_QUIT
                                                    //this calls GetMessage
    			if (!PumpMessage())
    				return ExitInstance();
    
    			// reset "no idle" state after pumping "normal" message
    			//if (IsIdleMessage(&m_msgCur))
    			if (IsIdleMessage(&(pState->m_msgCur)))
    			{
    				bIdle = TRUE;
    				lIdleCount = 0;
    			}
    
    		} while (::PeekMessage(&(pState->m_msgCur), NULL, NULL, NULL, PM_NOREMOVE));
    	}
    }
    Last edited by novacain; 11-23-2007 at 12:08 AM.
    "Man alone suffers so excruciatingly in the world that he was compelled to invent laughter."
    Friedrich Nietzsche

    "I spent a lot of my money on booze, birds and fast cars......the rest I squandered."
    George Best

    "If you are going through hell....keep going."
    Winston Churchill

  11. #11
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,985
    Quote Originally Posted by novacain View Post
    Sorry if I was not clear, MFC is a subset of WIN32 and is totally event driven.
    Ummmmm.....no.

    There are two main types of message pumps, standard (GetMessage) and game (PeekMessage). [this is a simplification]


    The standard pump gets messages and sends them off.
    If no messages are available it WAITS until there is a message for the app.
    This uses very little CPU unless the app is never idle (always getting input/processing).

    The game message pump checks for a message and sends it off.
    If no messages are available it returns (without waiting) and immediately calls code to update the screen. Thus the screen can be redrawn as many times as possible while proccessing all user input.
    This uses 100% CPU.


    MFC creates its own message loop using a series of PeekMessage calls and a GetMessage call.

    MFC's message loop can not be modified, but limited processing can be done in the OnIdle() handler.
    EDIT: As all OnIdle() processing is done prior to checking for user input and so is out of sequence for a game (which wants to get user input, move objects based on time/input then update screen)

    As MFC uses multiple calls to retreive a single message from the OS queue, it is very slow.
    Yes, I'm aware of PeekMessage and GetMessage and what they do I was implying that for general apps, it doesn't really matter if you use MFCs "slow" message pu,p or not, but for games, it might not be ideal.
    I can see the logic how games work, but when reading that, I'm horrified at the wasted cpu cycles that goes to do nothing. But some games are generally limited, or capped at a certain FPS, and thus there's no need to update the screen as much as it can.

Popular pages Recent additions subscribe to a feed

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21