[Adonthell-devel] Re: Update on collision work

[Kai Sterker]

On Dec 18, 2007 10:34 AM, Kai Sterker >

New code is checked in, but still far from perfect :-(.

When coming up with the base tile idea below, I didn't look close
enough at the code. Appears that for it to work, we'd need the
extensions of the actual sprite. But at that point we only have the
extensions of the object model, which will often be different.

There needs to be some glue that aligns the sprite with the object
model during rendering. Looking at the examples here
http://lists.nongnu.org/archive/html/adonthell-devel/2007-08/jpg4iqxtf0Ec4.jpg,
it appears that this alignment cannot be computed by the engine, but
must be specified explicitly for each individual object model. (Of
course, an object editor will be able to do that automatically.)

I will have to give that some more thoughts tonight. Suggestions and
ideas welcome!

Kai

> > There is also more work on the rendering ... I vastly simplified it
> > when introducing the 3D object models, but it seems that some of the
> > extra calculations were there for a reason ;-).
>
> Had some thoughts on that as well, but didn't get around implementing
> anything. The solution will most likely be the same as we had in v0.3.
> Each object has a "base tile" that will usually be to the bottom
> right. Objects will be rendered on the cell of the grid occupied by
> that "base tile". Since rendering is from left to right, top to
> bottom, that should assure that everything an object might block from
> sight has been drawn before.
>
> The base tile itself could be automatically set when adding objects to
> the map (area::put), as we know the bottom rightmost tile the object
> occupies at that point. An additional flag in square_info would be
> sufficient to store that base tile information (IsBaseTile = true |
> false). During the rendering phase, where we iterate over all objects
> on a square, we can simply discard those that don't have the base tile
> flag set.
>
>
> With those changes in place, hopefully the rendered world and internal
> model will match up too. That way, the only thing left would be
> tweaking the collision response step to get jumping and climbing
> (stairs, etc.) working again.
>
> Kai
>
> P.S: Some more thoughts need to go into objects that are not solid
> (like smoke, fog, the surface of water, ghosts, etc ...). But that
> doesn't have to happen for an alpha 2 release. Just something to keep
> in mind for later.
>