Re: [Opde-devel] Scenemanager water

[Filip V. <f.v...@ce...>]

Writing again, I hope it will be delivered this time... I was thinking about the things more, so the answers differ ;)


>> I've thought the unmap_poly was used to cut away the polygons that are not supposed to be 
>> in a certain sub-object, as Shadowspawn's code does. I speak about this because my meshconvert
>> tool exports door handles (for example) even on places where those should not have been (a
>> bonus to the good placed ones).
>
>I hadn't encountered anything like that yet. Granted, I've only been
>dealing with extremely simple models like unitbox.bin and unitsfer.bin.
>
Maybe I just missed some condition in the shadowspawn's code.

>> 
>> I'm still thinking about what way the Property structures should be
>> defined - structs in a header file or a dynamic definition using XML or
>> something (as DarkUtils did).
>> 
>
>I've got zilch knowledge of Ogre, even after reading the wonderfully
>informative and comprehensive documentation. So I've been sketching some
>plans for the back-end services. Objects, properties, game modes etc.
>
>First of, the avoid confusion, I've taken to calling the Dark-specific
>interfaces "services" since Ogre already uses "managers".
>
>Anyway, property/link data definitely has to be defined outside the
>source. Otherwise, you'd have to recompile separately whether you're
>emulating Thief or SShock2 or whatever. I'm rather proud of structinfo.
>Every property and link can be keyed to a path-like identifier. If the
>data is arranged in a B-tree, searching would be very fast.

Absolutely right! The only problems I see are speed and consistency. Speed can be fixed, and consistency problems (typos in the property path) will just have to be catched and debugged.
Do I get it right when I say that the services would be simmilar to the Dark Engine ones?
This seems to be the only solution that is thinkable. Would you mind to reuse the StructInfo? I would not want to write something like this from scratch if not needed to do so. StructInfo does the job well.

>
>Notice that I'm grouping properties and links together. I think there's
>a benefit to uniting the in-core storage of these. A link can be thought
>of as a class of properties with the fields "from" and "to". (Flavor
>must be part of the key, so you know what the class-specific fields
>are.)

This is a good point!
>
>So all the variable game data: properties, links, qvars, etc. can be
>centralized in a single repository that the various services call into
>to get/set data.
>
>I've also got some ideas for handling game events that is probably more
>flexible than tying everything to Ogre's per-frame callback. Have you
>thought much about using threads? Once I get all my notes into a
>sensible order I'll upload a synopsis. And probably draw a mind-map as
>well.

Well, I was thinking about them, but I can't make a picture of how the synchronisation of the per-frame situations would happen - waiting for physics to finish etc...?
Was the original engine threaded?

I would be very glad to see your design thoughts!

Filip

>
>-- tom
>tel...@fa...
>
>-- 
>http://www.fastmail.fm - Send your email first class
>
>
>-------------------------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job
easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>_______________________________________________
>Opde-devel mailing list
>Opd...@li...
>https://lists.sourceforge.net/lists/listinfo/opde-devel
>