Re: [Glelite-deve] Re: Things to do

[Timo K S. <tks...@cc...>]

> Perhaps we should also prepare for the (IMO) inevitable addition of
> graphics-card side vertex buffers by providing a kind of abstraction for it.
> Nvidia, at least, seem to have their own extension for this.

Yes, I would like to have support for NVidia AGP vertex arrays,
normal vertex arrays, compiled vertex arrays, displaylists etc.

> the design...  Maybe when I have more time I'll do something about the
> physics engine.
>
> > It is possibly to tweak ROAM a lot. Currently there is a lot of slowdown
..
> You mean it looks like a badly cut block of moldy cheese?-) No offense,
> of course...

Not; ROAM in 1.37 is simply broken. It does not adjust the level of
detail based on camera correctly. I should recopy this code from
1.27, but I haven't bothered, since the new version of ROAM would be
more important.

> One thing that I learned while writing one of my failed prototype 3d
> engines was that you can't really keep material handling separate from
> geometry handling. At the very least, for multitexturing (primitive per-pixel
> point lights, that sort of thing), you'd need some kind of an interface for
> the geometry to draw itself multiple times in a certain order, etc...

The current rendering architecture in Teddy does indeed have multiple
pass rendering.

http://glelite.sourceforge.net/doc/Mesh_cpp-source.html

See drawImmediate() and drawElements(). It currently does not support
multitexturing, which potentially would require a lot of changes to
the current architecture. I hadn't thought much about multitexturing
until this mail, since there is no textures in glElite / Teddy yet
at all.

The current implementation simply redraws every element multiple
times if required. For example, for hidden line removal to happen
when drawing wireframes, you have to first draw with filled polygons
and polygon offset, and then do a second pass with lines and no
polygon offset. You can also enable borders by using second pass.

Actually I think multitexturing is slightly different from multiple
passes like border lines above. With multitexturing you may not have
to actually render multiple passes, but I know no good method that
could do border lines in a single pass. Applying multitextures might
be simple to add to current Projection <-> Mesh architecture I think..

> Perhaps a good design would be to keep the "what happen ?" code
> separate from the "main screen turn on" stuff, so that if the game were
> run without networking the server object (or some such) would run on the
> local computer in a separate POSIX thread.

Yes, something like that. The simulation already runs in seperate
thread as SDL timer. Nope, I haven't protected anything with semaphores
as I should have.. yet :)


-- Timo Suoranta -- tks...@cc... --