nife87

Developers on different levels/stages are probably interested in different topics, and the difficulty of those (basic explanation of AO/SSAO vs. latest performance tweaks to a specific SSAO algorithm), since all have different experience and knowledge. Hence there are many popular blogs :-)

One thing everybody loves, however, is an image, whether it contains a screenshot of a game, a colorful model, an IDE or just plain statistical data.

And one other thing programmers love is well-documented/-described source.

If you want top-quality reading material with C++ (specifically C++11 and its standard threading library) and threading in mind, I can recommend C++ Concurrency in Action: Practical Multithreading by Anthony Williams (http://www.amazon.co.uk/dp/1933988770) and Herb Sutter's many articles (http://herbsutter.com/).

 

Pre-C++11 you can use boost::thread (nearly identical to std::thread in C++0x/C++11), so any articles concerning std::thread can also be applied to earlier versions of C++ supported by boost.

This is just an idea, so please inform me if it is totally misplaced  
Even though the speed is slowed, time is not, so the client should be able to detect that time gap/leap and drop the connection itself after a fixed time interval without signal. The key is that the server's time interval must be a little larger to accommodate clients clients wanting to resuming (without luck) after an interval close to their time limit.
For instance, where X is some time interval (the 1.5 is probably way too much, depending on X itself it may be smaller, but you get the idea):
ClientDropTime = X
ServerDropTime = X * 1.5

Most, and hereby I mean practically any game I have every played in release, use the in-game GUI to display the console, not an external window API like Windows' own.<br />Thereby they can toggle all aspects of its appearance - but there is much more to it than just pretty graphics, although ones like Source Engine's is both very pretty and functional (listing all cvars related to the chars you have typed so far and easy help/description for any cvars, for instance) IMHO, though I miss an "in-game appearance" (you cannot type while playing - console must be accessed from the menu).<br />You also need a way to bind console input (like "help", "max_fps 100", "quit", etc.) to actual source in order to command the game to do something.<br />Quake, as you mentioned, uses a system of cvars (console variables and commands) - you can read all about both online and in their released source (the newest edition of id's cvar system in actual source, that I know of, lies accessible in their Half Life 2 SDK).<br />Games like FarCry exposes this functionality via a full fledged scripting system (Lua, in this case) and binds commands/variables and the necessary callbacks this way, since they use it for all other scripting purposes anyways.<br />

The wall bug could be caused by frame spikes (might happen any time, based on many varying factors - that is, some might occasionally or constantly observe it, some might never) if you use "basic/plain" frame delta time movement and collision techniques. That is, one frame the player is close to a wall but not close enough for collision, and the next frame the player is moved based on the frame delta (long frame = high frame delta = long movement). Then a collision is detected with the wall, which stops the player's movement. Unless this is resolved (move the player "out" on the right side of the wall), the player is just stuck in the wall.<br />I observed the issue in some of my early games, but I can only guess as to how you perform collision detection and resolving :-)

Although NULL IS ugly, it cannot be replaced with 0

What? NULL is #defined as 0, meaning there's absolutely no difference except style/personal preference, and Bjarne "C++" Stroustrup was quoted earlier as preferring 0 (or nullptr in C++11 where available) over the NULL macro.

Sorry. I was under the impression that NULL was commonly defined 0, but was not required to be defined as such. Well, that certainly makes life a bit easier.

Iff the hierarchy manager owns the objects in question (or is otherwise guaranteed equal or longer life time), you can pass a HierarchyManager * to every object, like you do with their parents. A simple pointer is fast to dereference and does not waste much space. If the objects are not guaranteed to die before their manager (but be sure of the reasoning of this decision), you might want to look into a std::shared_ptr<HierarchyManager> (or boost::shared_ptr if your compiler is pre-C++0X/C++11) or another form of reference-counting.

I develop for both Linux and Windows pre-8 and primarily OpenGL, but since I use a non-platform-dependent API for these platform-specific parts, which is then compiled (or linked at run-time using DLL's/SO's) into platform-dependent source using macros, I can easily compile for a new platform, say Direct3D or MacOS, should I wish to do so later on. This is a common way of hiding away platform-dependent source. For reference, L. Spiro has posted a neat little article regarding the compile-time macro solution: http://lspiroengine.com/?p=49.

P.S. I fancy CodeBlocks too much to let VS get in my way on Windows :-)

If yes, where should the id be assigned. In the level file? Or it should be generated on runtime(this is the case I used before) .

How would you otherwise differentiate and cross-reference the different objects in a level file (or in any other saved form) if they do not have some sort of ID already? This might just be a unique name, but it is still an ID. You can always switch one ID-method out for another (they all have their strengths and weaknesses). For instance, you can use unique names (strings) in files for simplicity (easy to edit by hand) and then swap them out with integer ID's for performance when loading files using either hashing or a LUT (string->integer). The opposite is required for saving, of course. An editor (level editor) might do the conversion automatically for you - you use string ID's within the editor, but it only saves integer ID's (and possibly a LUT to display the original string ID's within the editor for re-editing the files).

So you want to make a prototype of the GUI, not the actual OS, right?
I see no reason why the interface shown in the video is not just another fancy GUI (probably for mobile units) with network connection and a database of your media attached, but I might have missed something?
For the GUI, yes, you can use pretty much any language, including the now out-dated flash and the newer HTML 5. But you can use pretty much anything that enables you to make a graphical and relational mock-up quickly. So if you already know a language/technology or two, I would certainly investigate if you can use that instead of learning a new one.

I have used Code::Blocks nightlies as my main IDE since one of its first releases in '05 or '06.
Since I use nightlies and not the stable builds (there are not many of them and they are quickly horribly outdated), there have been issues from time to time with certain builds, such as frequent crashes or features not working properly, but the developers have always responded quickly to any feedback on their forums. If one particular build annoys you, you can always use a former until the issues are fixed (usually does not take more than 1 or 2 newer builds iff you report the issue).
For instance, in the current Windows build (8438), I have issues with CB's "image" freezing as a screen overlay when (sometimes) minimizing, forcing me to restart CB (but everything is saved, so not a big deal), though the Debian build (Jens') is working perfectly.
Like JTippets said, just save often enough, make use of autosave, or do as I and use both (since I will never trust autosaving features ).

Be careful when using Win32's Sleep. The call might return instantly or sleep for up to ~15 ms when calling Sleep(n), where 0 <= n <= 15. This happens because the default tick resolution is (1/64) s = 15.625 ms, which can be altered (only for the entire system!) using timeBeginPeriod/timeEndPeriod.
So you might want to consider other alternatives when you need to wait for less than 15 ms.

I might have missed if someone else mentioned this, but you might want to take a look at streaming (only load what you need now plus a little more, then let a background thread load more when needed) and/or compression (if you cannot minimize the tile data further), considering the amount of data you are handling. Since you only load one file sequentially, you do not need to worry about (mechanical head) seeking.
Perhaps, depending on the Type/Background/Orientation variables (whether or not they differ a lot for each tile), you can make these objects flyweights, thereby only having one to load 1 object for each different type/background/orientation and in the file reference them by some identifier (ID/GUID)?
Other than that, use as small data types as possible to describe what you need, which I see you already are in Tile, using bytes/shorts. For instance, an int X can often be reduced to short/byte X if any two X does not differ by more than 2^15/2^7 (or unsigned 2^16/2^8). For instance, if your X's are all in the range [545;668], the difference is at most 668-545=123 (making it a perfect fit for a byte), so serialized is byte bX = (int iX - 545) and deserialized is int iX = (byte bX + 545). Warning to readers, in case I just created arithmetic overflow of converted data types (do not know C# well enough to catch these).

Assume I have a vector that consist of pointers. When the content of this vector is read (one element at a time in order) I should be reducing cache misses (since the pointers would be adjacent to each other in memory). Now if we assume what each pointer is POINTING at also lies in a continuous block of memory then from what I've understood it should also reduce cache misses (corrections here would be welcomed).

Yes and yes. Since you know how cache lines work, I assume that both your vector's data (pointers) and its pointed data is larger than a single cache line (otherwise you are good no matter what you do, since both arrays are contiguous).

But the real question is, unless I missed something, why do you need to swap the pointers in the first place, and how often do you process pointers and/or iterate the array?
And also, how large are these arrays? The cache consists of several cache lines, so if they fits into the collected cache, it might not become an issue at all.

Of course, if you have a real case, and this is not just hypothetical, you really should profile with a profiler that can highlight cache usage/misses.

First hit on Google:
http://www.int80h.org/strlen/

In assembly language finding the length of a C-style string is a snap. The x86 family of microprocessors come with with the scasb instruction which searches for the first occurence of a byte whose value is equal to that of the AL register. The address of the start of the string itself has to be in the EDI register. Technically, it is supposed to be in the extra segment, but we do not need to worry about that in the flat 32-bit memory mode anymore. When used along with the repne prefix, the scasb instruction goes up (or down, depending on the direction flag) the memory, looking for the match.

This is also good:
http://www.csc.depauw.edu/~bhoward/asmtut/asmtut7.html