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

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

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...).

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.

Originally Posted by Normac

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.]

Originally Posted by Normac

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)

Originally Posted by Normac

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.....

Originally Posted by Normac

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!

Originally Posted by Elysia

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.

Originally Posted by Elysia

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));
	}
}