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

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

> I tried checking the 'Teddy' module out but sourceforge seemed to have

Any luck now later?

> Now, I'm sure that this is too early to start thinking about performance
> (the rest of you seem to be in feature mode anyhow ;-), but it might be

No, it certainly is important to get performance working well. Thats why
I reworked material management and as result there Projection between
ModelInstance/Mesh/Element drawing and View (OpenGL&Graphics context).
It is still missing vertex buffer.

> worthwhile to explore other landscape rendering algorithms besides ROAM
> (which is commonly said to be too CPU-intensive to peg a modern T&L card).

Again, the version of ROAM currently included is a really badly broken.
The newer code uses vertex arrays etc., but it will mean some work before
I can integrate that into current code. Anyone willing to do the
integration?)

> Ideally, the not-ROAM landscape algorithm would produce results that looked
> about the same as with ROAM, but consume less CPU time per vertex while
> possibly generating more vertexes.  Having a second algorithm would also

It is possibly to tweak ROAM a lot. Currently there is a lot of slowdown
caused by the multifractal, which is really calculated in real time. It
would be a much better idea to cache fractal values somehow. Also you can
combine different fractal (or other height functions!); plasma for some
parts could be a lot faster. Also I am not happy with the currently
generated terrain. It is missing features, or something..

> Then again, with the current OpenGL vertex buffer handling, the
> geforce2 GTS won't be a bottleneck with simple (textured & lit)
> primitives...

I'm still using Matrox G400. Until very latest drivers, it's been a real
pain. But now that I upgraded Duron 800 it's not so much pain, and latest
drivers finally have fixed depth culling problems etc.

What I did not tell it the previous mail (about rendering architecture)
was that I wan't to support rendering preferences *per Projection* in
addition to per ModelInstance. This means that I can tell Projection that
'Now use flat shading, no textures' or 'Now use monochorome, wirefrane
rendering with hiddenline removal' and that will apply to all objects.
You can already turn lighting on and off in the Teddy 1.37. Also see
UIobjects.cpp for material / rendering options per ModelInstance.

> powergaming weenies).  Also, this sort of thing would need to be designed
> into the game from day -1, before work starts on the "real" graphical
> client.

My personal opinion at the moment is that we first concentrate on
framework aspects in Teddy. And do that in such way that it is possibly
to use Teddy for both networked and non-networked games. I see no reason
why it would work already that way. You can plug in networking any time
you want.

Networking is tighly coupled to the physics simulation (that is what
I call anything that 'happens' in the game). So far I have only worked
on the rendering engine. There exists a very very primitive physics
simulation, but I have no plans to improve it much in the near future.

It is true that networking affects a lot of design for physics simulation.
Thus we should encapsulate the whole physics simulation as much as
possible from rest of the game. This is how it is possible to make
framework that works for both networked and non-networked games.

> The "getting started" doc is pretty good.  You might want to link
> to Lars Wirzenius' using-cvs document
> <URL:http://liw.iki.fi/liw/texts/using-cvs.html>. A link to the SDL
> homepage would also be nice.

I will be adding links, erm., soon. CVS book is also good one, as you
can freely download and print it, too.

> http ohutsuoli 2*viilto www piste iki piste fi viilto mato ksandstr viilto

^ ..not very international.. ^


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