I structured my own 2D tile map from tile types, which define all the attributes a tile has (image index to the image array, collision data, special flags, etc.).
The map itself is then a 2D array of indices to the tile types array.
This saves a whole lot of memory both while running the game, and on the disk, though the real intention was to make the map easily editable (I see editing a few tile types a whole lot easier than editing every single tile manually, but maybe that's just me).
To make empty tiles I just start the tile type indices at 1, so that every tile with value of 0 is to say "no tile type".
About collisions - you need only check the tiles around the player. You can get the exact tiles by converting your player coordinates to tile coordinates.
Suppose your player's coordinates are some point (x, y), and suppose every tile has the dimensions (w, h).
To instantly get what tile the player is on, simply divide the player's position by the tile size (x/w, y/h). This will result in the x/y indices of the tile.
For example, if the player's position is (200, 100) and the dimensions of each tile are (50, 50) then the player is on tile (4, 2).
That's converting your player's world space coordinates to tile space coordinates.
You should of course also take care of the player's dimensions. For example, if the above player's dimensions are also (50, 50), it is most likely that the player is intersecting with more than one tile, so take that into consideration.
I would say to just go with a physics engine like Box2D, but I really have no idea how optimal general physics engines are for uniform tile maps, which might have thousands to millions of tiles, yet are very, very efficient in terms of collision if done specifically for them.
You might want to check this out, as I've never yet used a physics engine.
While they are not meant specifically for uniform tile maps, they might have internal buckets (e.g. the well known quad tree) to filter out unneeded collisions, which are not as efficient as writing your own code, but are probably fast enough for you not to care.
Crackers are better. That's all there is to it.
Big companies these days wate so much money and effort on protections that get cracked, usually, a few days after their games get released.
Maybe if they would use the money and time on making the games work better, people would be encouraged to buy them.
Right now, the only people suffering costantly from DRM are the legal buyers, pirates don't even see it.
A simple CD key would stop 5 years old kids from spreading games. Nothing beyond that is worth the effort.
If you want to decouple your objects, why do they handle everything to begin with?
SC2 objects don't control collisions, they have attributes that tell the engine how it should handle them.
It makes a lot more sense (at least to me) that all objects are owned by some logic game class that actually runs the game. That class, then, has access to all the needed components (rendering code, physics code, etc.) and runs them on the objects it owns.
The objects themselves only own attributes to tell the game what they are and what to do with them (which by itself is a whole new topic on how to design this, e.g. Inheritence vs components).
TGA is not supported in any browser.
Had to convert thousands of pictures to PNGs because of it :| (yey for batch operations with ImageMagick using a 5-liner Ruby script)
The browser probably told you that in its console, so you better open up the console when you test your code.
Chrome's console (and JS implementation) is a whole lot better then Firefox's in my experience, so you might want to develop on it.
HTML5 adds some new tags, that is all. Now XHTML just means that you are writing code that tries to not suck too much, it isn't an actual technology or anything.
HTML4 code will almost always work when parsing a page as 5, since hardly anything got removed (a few useless tags nobody uses).
I don't know why anyone would need a book for HTML, CSS, or JS, as they are very simple by design.
Googling skills are more then enough, especially when most problems come from the crappy browser implementation, which you will easily find answers to on the web.
You would probably want to add functions that manipulate a modelview matrix (to "move" your camera). Making them is pretty easy, you can look at how the functions worked in early OpenGL versions (gltranslatef, glrotatef, glscalef).
The end result would be projectionMatrix * modelviewMatrix * vertex in the shader, or you can calculate projectionMatrix * modelviewMatrix on the CPU since it's just extra calculations if you do it for every vertex.