I'd like to know which is faster, I don't care how small the difference is, I need as much speed as I can get.
For games I got one advice on optimization. Don't do it to soon, otherwise you will be just wasting your time in my opinion. When you do decide to optimize your game don't go overboard or else you are just usually wasting your time. Run a profiler on your game and see what functions are taking up the most performance and time in your game. Start at the top of that list and start making optimizations (Just optimizing the top 5% slowest thing will give you a huge performance boost).
If you try and optimize everything in your game you will never finish and it is it not worth it. Don't mistake this as you should just write sloppy code all the time because I am not saying that.
- How should I implement my players
This is a very broad question and really you should decide this since it is your game.
- How should I go on with an RPG combat system
Again this is your game design a combat system you like.
- Is it possible for me to hide data and store it in the GPU memory?
I am not really sure what you mean by "hide" data on the GPU but yes you can store data on the GPU...
Only way to write efficient code is to write inefficient code and learn how to make it efficient. Nothing is ever written efficient right off when you begin, but rather done to get it done and then gone back over to optimize the code and make it efficient. The only thing you can do efficient is to design and lay out the program so you have a basic idea of what you want.
Efficient code comes from experience and well designed documentation to use as a map to create it.
Is it possible for me to hide data and store it in the GPU memory?
Speaking of writing innefficient code. Why do you want to do this? This is a surefire way to write extremely inefficient code, as copying data to-and-from GPU memory can be extremely slow.
Generally, when using the GPU to compute, you copy as much data to the GPU perform your calculations then copy it back to regular memory when it's done computing; unless it's something like a texture but then you should be using something like a Direct3D Surface which will handle this for you.
By hiding data in the GPU, I mean like hiding strings and info in there.
I stand by what I said about only way to make efficient code is by making inefficient code and get it working and then go back and find ways to make it efficient. The more you do the easier it will become to design apps and do it more efficiently at the start, but there is no way to be 100% efficient from the start.
I know it isn't efficient. That part isn't related to the topic, I just wanted to add it to save space.
Wait, that means you derailed your own thread in the first post. Is that even possible? o.O
A simple example of such a tip: use pre increment (++i) rather than post increment (i++) when possible. This is especially important with iterators, as post increment involves copying the iterator. You optimizer may be able to undo this, but it isn't any extra work to write pre increment instead, so why take the risk?
I wouldn't call that an efficiency issue. Pre- and post-increment or decrement for that matter are more determined by your needs rather than efficiency. If you need the data used and then one added/subtracted to/from it then you need to use post, if you want it added/subtracted to/from it before using it then you need to use pre.
[EDIT] 3am, fixing what typos I could read through burning eyes.
Well I want it to be a diablo-ish view. I actually never played diablo, saw gameplay once, but I love the camera style.
I'm confused on how I should use polymorphism, I feel I'm going overboard.
For a diablo-ish view you need a isometric view and unfortunately it is hard to find isometric tiles.
You can create an array of classes to store your enemy types etc. and when you create a new enemy just copy one of that types in your array. I dont know if it is the fastest way but at least I will use it for my game.
std::string is safer and easier to use than char arrays.. and char arrays only outperform them in very limited use cases. Unless you have a very compelling reason to use char arrays... don't. Using char arrays might save you like 2 nanoseconds... which is nothing.
Don't put things on the GPU that are not related to the GPU. This does not "save space" but actually wastes space, as video memory is significantly more limited than main system memory.
Don't worry about trying to optimize things that don't matter (read: pretty much most of what you're asking about in this thread). Worry about optimization if your program runs slow.. or if your design raises red flags (such as unnecessarily moving very large blocks of memory frequently).
If/when you do worry about optimizing.... don't assume/guess as to what is causing your program to be slow. Do profiling and figure out where the slowness is coming from.
Performance things to watch out for:
- Large memory copies
- Moving data from CPU->GPU
- Moving data from GPU->CPU (this is even slower!!!)
- Very large loop iterations (10000+ iterations per frame)
- Looping over expensive computations (calling sin/cos 100+ times in a loop)
Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
So yes, the difference does matter in the sense that no matter how little faster or slower it is, it doesn't matter :P.
Although I agree that it's best not to "sweat the small stuff", I like to microoptimise in ways that don't cost anything, like using prefix increment by default, or passing complex types by reference, or restructuring code in such a way that certain statements are executed less frequently without changing behaviour. My opinion is that micro-optimisation is only bad if you sacrifice something more important, like code clarity or safety. Using C strings instead of C++ strings costs you safety in exchange for performance, and as Benjamin Franklin might have said if he were a programmer, "Those who would sacrifice essential safety for a little micro-performance deserve neither safety nor performance".