kunos

my advice is to learn by doing, not learn to learn.

It's pointless to sit down with a C++ trying to understand everything without a final target.

Once you have the concept of functions and flow control you have all you need to create whatever program you want.. yes, the code will be ugly but it is important you get something done... only by doing messy programs you will really understand why higher abstractions are good and useful.

Learn to learn, in something as practical as programming, is just wasting time imo. Knowing a programming language is only a small part of being a programmer, the real skills are problem solving and the ability to find the info needed to solve a problem... that is where the line really is.

behold the magic trick 1:

D3DX11CreateShaderResourceViewFromFileA(device, filename.c_str(), NULL, NULL, &texture, NULL);


Notice the final A? That will give you the (char*) version of the function as opposed to the WCHAR* version of it.

If you really want to use the WCHAR* .. the code is quite easy:

wstring l_filename(filename.begin(),filename.end());
D3DX11CreateShaderResourceViewFromFile(device, l_filename.c_str(), NULL, NULL, &texture, NULL);

You need a MainMenu constructor that gets the required RenderWindow* as parameters and use it to construct its base class.

Transate into code:

 

your declaration becomes:

 

MainMenu(sf::RenderWindow* rw);

 

your implementation becomes:

 

MainMenu::MainMenu(sf::RenderWindow* rw) : Collision(rw)

{

// bla bla
}

 

I suggest you to study constructor initializer lists.

XNA, which I think was one of the main reasons C# gained traction

 

I hope you meant to add "in the game development community". Because if you are suggesting that C# is popular in general development BECAUSE of XNA then please, share the good stuff you're smoking.

Wouldn't it be better to find a book on the subject in your native language?

 

not as easy as you think. Most books with very specific topics don't get translated at all.

 

To answer the question.. it's all a matter of experience, you try a way and sooner or later in the project it'll fall apart under the weight of the project... from that point it's hackage time.. you can't plan for the unknown. The good news is that your next project will be better, because you know more about what you'll eventually need and the level at which the structure will fall will get higher.

 

The best bet is to have a look at what others are doing.. I found Unity3D a very good inspiration point for what I wanted my engine to "look like" from the outside.

 

Some books I'd recommend are Game Coding Complete and Game Engine Architecture... plus, the usual good practices and pattern books from the usual suspects.

The CBullet constructor does store this though (in m_body), so it could feasibly be used to later delete it. Not a design I would use...

 

that's really beyond hacky .. but I expect nothing less from a juventus fan

 

I would say Columbo's is the right diagnosis... I bet there is a compiler warning saying something in the lines of "delete called on undefined object, no destructor called".

Personally, I also turn off all autocomplete or auto-anything because it drives me nuts. I prefer total control over what I'm typing, rather than having the IDE guess at what I'm trying to do.

 

you must have a very good memory

If you have need to play sound in the depths of physics code, global access to sound resources doesn't endanger modularity any more than explicitly passing the resources. In both cases you need to #include sound code in your physics code, which should be enough of a red flag.

 

 

infact there are better solutions. Your physics subsystem could just expose an "onCollision" event with subscribers and the connection between audio and physics is then handled much higher in the code thus maintaining total modularity and independence.

 

The point is that making everything global like a big lump of memory makes things very comfortable because, basically, you need no design at all... but that is not how you create maintainable clean software, that way you just hack away. That might be perfectly fine for small software projects but it's a recipe for disaster for bigger projects.

couple of years ago , at the beginning of our current project we did experiment with Unity. At the beginning we were all happy, the artists were happy because they had their nice environment to work with shaders, illumination and what not, I was happy looking forward to a relaxing development year full with lots of vacations and no graphics programming involved.

After a couple of months, the pretty picture started to fall apart.. loading time went biblical (>60 seconds), shadow quality wasn't good enough and untweakable for our needs, the entire working pipeline was VERY different (I wouldn't say bad.. but way different) from what we were used to, motion blur was more like LSD-acid effect. Luckily I had a DX11 pet engine that I was working on for fun and one sunday, for fun I imported the track and car we were developing as example in, and got the thing loaded in 7 seconds with the shadows just as I needed... after a couple of meeting with the entire team, Unity was out of the window, and my holidays were canceled 

 

I look forward to the day I will be able to pick up an engine and be able to use it for my work.. it is the proper, sane and smart thing to do. Sadly, for the moment, we're not there yet for the kind of projects I do. But, if I were to start a new project tomorrow, my first move would be to check out a 3rd party engine first and evaluate if that could be of any use.

Windows XP wasn't supported as target in Visual Studio 2012. They have released some patches for this anyway so you might want to google for that.

you dont seem to understand how C# runtime works at all, so your claim are as wrong as it gets.

Every single C# function gets compiled to native code by the JIT the first time it is invoked, from that point on, that function is running native code period. So the "more work to do for every instruction" is just... uninformed and uninformative.

This has been the case for ages, since Java started doing it loooong time ago.

GC is another topic that always pops up in these kind of discussions... IMO is pure non-sense. GC won't trigger if you don't "new" stuff, and will be VERY fast if you don't have objects with medium life expectancy.. it's just a matter to take some time to understand how the system works and how you can make it work for you... it's much easier to learn to deal with .NET's GC than learning proper memory management in C++, simple or through the 6-7 "smart" pointers available.
Just as you try to avoid new and delete in your game loop in C++, avoid newing class objects in C# and GC won't cause any troubles.

 

But really what you're suggesting here is that to "solve" the problem of the GC needing to halt all threads and needing an unknown amount of time to complete, that you do "manual memory management" and try to avoid invoking the GC, which also means designing around ctors/dtors and doing init/cleanup of your objects yourself so you can reuse instances. IMO that's a lot easier to do when there is no GC to worry about, and you reintroduce the problems GC was meant to solve (ie dangling pointers).

 

I am not suggesting that. "Young" objects are collected by the GC without stopping the world... so those shouldn't create problems at all.

What I was saying is: be sensible... just as you are sensible with C++. And, if you really get in trouble with the GC, use the available techniques to avoid that (ie. object pools). Again, I don't see this being any more difficult than writing a custom allocator in C++.

I wrote a quite complex simulator using C# and never had any problem whatsoever with GC and/or stutters.. actualy, scratch that, I have never had any problem with any of my C# stuff with GC stutters... and I don't use object pools or any other trickery.. just try to be sensible in what I do.. understand the differences between structs and classes in C# goes a long way.

GC is another topic that always pops up in these kind of discussions... IMO is pure non-sense. GC won't trigger if you don't "new" stuff, and will be VERY fast if you don't have objects with medium life expectancy.. it's just a matter to take some time to understand how the system works and how you can make it work for you... it's much easier to learn to deal with .NET's GC than learning proper memory management in C++, simple or through the 6-7 "smart" pointers available.
Just as you try to avoid new and delete in your game loop in C++, avoid newing class objects in C# and GC won't cause any troubles.

there is no particular reason other than language age and general direction. C++ compilers are older and always had performances as their main objective where C# compilers are younger and never had raw performances as their main objective.
The 2 systems have just different agendas.. C++ favors runtime performance over programmers' productivity, C#'s balance is more to favor productivity over runtime performance.

Final note.. no language will make an engine "faster". Programmers write engines, good programmers will write a "faster" engine in C# than some inexperienced programmer using C++. I don't think the reason to adopt C++ in game programming has much to do with performance at all, it's more down to easiness to interact other low level libraries, existing code and resources (developers) reuse and lack of a performing C# runtime on consoles.

When is it acceptable to use global variables?

 

every time you can't come up with a better solution. So it is all up to the level of the programmer involved. For experienced and educated programmers, the answer is "never" or "never with some very rare exceptions (ie. logs)".. for programmers with less experience, education and time the answer changes accordingly.