Greetings, I'm in the process of designing an isometric, dungeon-roaming MMORPG (I'm sure this is nothing new here :) primarily as a personal challenge and to broaden my, somewhat lacking in variety, field of interest in programming (Systems). Since I'm relatively new to the field of game programming I would like your input on my design, however critical such may be. (Albeit not game-wise, I've been programming [C++/Asm/Others] for ~8 years) To the point. The world shall be represented as a two-dimensional grid of cells; a cell is precisely 16x16 pixels, measured isometrically in the 2:1 projection scheme. A cell itself is the smallest unit of space that is taken into account for collision detection, and with that said, each object within the world is described initially by a bounding box of cells, and if required, each cell flagged as being a part of the object's footprint or not. Furthermore, in pondering upon how to manage velocity, I figure that I can sacrifice the low byte of each world coordinate (a 32-bit word) to be a sort of 'precision', in that the low byte is used as a fractional measurement of a cell and thus allowing for velocity to be specified in 256th's of a cell (hopefully that makes sense) As far as I can tell, the only actual physics concepts I need implemented is velocity. Although, there is one issue that has been pestering me in regards to collision detection and that is due to my decision to use a constant physics timestep (Graphics shall be free); namely the problem which arises when objects travel faster than 1 cell per sampling which could possibly lead to a missed collision detected. I've thought of things like simply increasing the size of a cell, but I'm convinced that's me avoiding the problem. Maybe someone could shed some light on this for me? Any input you have is appreciated, and I thank you for taking the time to read this.

Thankyou for your replies.

Quote:
This is called fixed-point arithmetic.

I know :)

Quote:
There are many techniques for this. You can either decrease the timestep so that no cells are skipped (and you can do this dynamically so that you don't waste time with timesteps that are too slow), or you can use swept areas by remembering all traversed cells on a given move.

I do plan to have a configurable timestep, but I don't feel it's practical to rely on it. With these 'swept areas', how would I go about implementing it?