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

Printable View

11-21-2007
Normac

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 :D
11-21-2007
matsp

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
11-21-2007
Normac

Quote:

Originally Posted by matsp

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 :D.)
11-22-2007
novacain

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...).
11-22-2007
Elysia

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.
11-22-2007
Normac

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 :D
11-22-2007
Elysia

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.
11-22-2007
novacain

Quote:

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

Quote:

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)

Quote:

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

Quote:

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!
11-22-2007
Elysia

Quote:

Originally Posted by novacain

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.
11-23-2007
novacain

Quote:

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.

Quote:

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)); } }
11-23-2007
Elysia

Quote:

Originally Posted by novacain

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.