From: Filip Volejnik <f.volejnik@ce...> - 2006-10-21 14:49:40
It has been a long time since I last wrote to this list, so I thought it
would be a good idea to drop a message describing the progress of my
I was working to get the documentation of the sources as complete as
possible. I'll commit 0.1.9 version with all the changes hopefully soon.
The water textured polygons are finally working in my non-commited
version. Lightmaps are not used at all for those, even though they are
present in the WR. The underwater effect will require some further work,
but not as much as I feared. I had success running thief DP on my old
notebook, so I tried to understand how the swimming works. The player is
lifted above the water portal, and after putting some force into getting
under water, the camera is switched totally under the water portal. That
means that it never happens that the camera sees the portal splitted or
non-complete. The underwater effect is thus an all-screen overlay
tinting the rendered scene. This could be handled by a transparent
rectangle rendered after the whole scene.
-- Database access
Because the sources should be independent on the file format as much as
possible, the services will probably get a flavour value, describing
which kind of service should the factory produce. This will have a
constant value for original services, but could have a different value
later on, to support other formats.
The database service will have a common implementation, and inherited
versions that will handle the file loads/saves. The first will be the
one handling original tag-files. All the "primitive" chunks will be
handled directly, non-primitive chunks will be handled by separate
services (Wr/Wrrgb, physics, ai, etc.).
The database service will have methods to set/get data based on
keys/paths, as telliamed described in the mails before (something like
windows registry or LDAP). That reduces the property/link/object
services mainly as wrappers around the queries to the database service,
as well as qvars and others.
The filling of the data structure values (which will be based on the
StructInfo code) is up to the descendant of the original implementation.
Binary service will stay separate, as it could be used to read other
format templates too (bin files for example, maybe even the complicated
chunks, I'm not sure yet). Maybe the structreader/structinfo won't be a
service at all, rather base classes.
-- Scene manager
I was doing some optimizations, mainly converting the Ogre::Rectangle to
PortalRect class, changing the type to int (this lifted fps by 10 in
some extreme cases). Still the renderer is a bit slow in bad situations,
but I'll leave this for now, as optimizations are quite possible(*) (now
the bad situations take 50:50 on the visibility determination and
geometry rendering). What I will do, is finishing the scene manager to
allow attaching objects to scene nodes. This is a must before
implementing the object display. This is probably the last coding
required before 0.2.0. The RayScene Queries will be fixed/written later.
(*) The level geometry should be defined by some other class than
ManualObject, because this is a bit slow.
The structreader will pull in expat library as a requirement. This is
the main cause I'm still not commiting, because the windows compiles
will have to be tested first. If the expat distribution is not
compatible with mingw or visual c directly, I'll have to check if it's
license is compatible with GPL, so we could put the sources into the cvs
tree directly, and write cmake rules for them.
That's it for now. I'm hoping that nobody loses faith. I'll be glad for
any comments, patches, coding work, as well as other things from anyone