Fredericvo

People seem to make it sound like in C/C++ you could potentially blow your PC up in a puff of purple smoke. Don't let the word "dangerous" scare you forever into higher level languages such as python or java. Dangerous simply means if your program compiles fine but behaves wrong you'll get a little popup telling you the program hung. Big deal. It used to be worse with blue screen of death (even that wasn't lethal to HW) but that currently requires bad kernel code (drivers)

I think one advantage we older programmers have over younger ones is that we had simple computers like the C64 to get started on. There wasn't really a need to start with text, though of course first programs would have been like that too, because with the help of hardware sprites it took a line or two (without the concept of library or framework) to get a sprite on your screen. One or two more lines to actually move it. On the downside BASIC was way too slow to code a useful game with and assembler forced itself upon you.
The lack of hardware sprites made me shun PC's during almost the entire nineties and I desperately clung to my Amiga. LOL

DeleD is simple & free. Can import/export x-files, 3ds, obj, collada

It sure seems silly for such simple geometry but imagine a house and a car for example. You would set all settings and renderstates for the house, draw it, do it again for the car and draw it. You're right that it requires creating 2 VB's and possibly 2 index buffers as well if you use that which you should.

One draw call per object.
I.e. Set world, view,projection, material/texture and vertex buffer for object 1. Draw.
Set whatever changed I.e. World, vertex buffer 2 (if different object) and draw.

I think there are 2 nice free C++ tutorials online
1. www.cplusplus.com (easy)
2. www.learncpp.com (bit more detailed)

On YouTube there are more.
Learn that first before you even think about creating a videogame.

If the idea that globals are bad because you need to keep track of so many potential modifications in different functions then I can hardly see how passing a reference to them solves this problem since you can still modify the original value from different places. At some point you'll have states that the entire program needs to keep track of so this jihad seems a bit too dogmatic. Not all programmers have a phd in computer science so these considerations seem to paralyse by over-analysis rather than just let you code away. I'm victim of this.

OK I'm back on my PC.
Let's say yo want to embed an image, image.bmp into an exe file
First you need to create a small text file named i.e. assets.rc
This file should contain the following

#define RT_RCDATA 10

101 RT_RCDATA image.bmp
102 RT_RCDATA image2.bmp
103 RT_RCDATA image3.bmp
...

Open a command line in your C:\Program Files\Microsoft Visual Studio 10.0\VC\bin
and issue the following first: vcvars32.bat (without this it can't find the path to rc.exe)
Then issue: rc assets.rc from the dir where assets.rc which you just created lives. For simplicity sake put it in the bin dir where you just issued vcvars32.bat

If you successfully managed the instructions above you should now have an assets.res file (maybe also assets.obj)
This one should be linked by your linker with your whatever.cpp file.
i.e. from the command-line I usually isse the following cl myprog.cpp assets.res and it will link both files.

If this succeeded you still need a way for your code to find the resource and point to it.

Yo need to create a few variables first:
HRSRC hres=NULL; //you can of course name them anything you like
HGLOBAL hgbl=NULL;
DWORD numbytes=0;
VOID *pimage;
hres = FindResource(hInst, MAKEINTRESOURCE(102), MAKEINTRESOURCE(10)); // suppose you wanted the second image (second param should always be 10 for custom binary (RT_RCDATA))
hgbl = LoadResource(hInst,hres);
numbytes = SizeofResource(hInst, hres); // optional if you need the "file" length
pimage = LockResource(hgbl);

pimage from now on is the pointer which you can feed SDL_LoadBMP_RW()
This function has a second parameter which I don't know the use for since,like I mentioned, I'm not familar with SDL.

When you think of it you can manage very large programs in plain old C. Look at Linux.