You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(21) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(5) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
(26) |
Aug
(10) |
Sep
(11) |
Oct
(6) |
Nov
(3) |
Dec
(2) |
2007 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
(11) |
May
(6) |
Jun
(5) |
Jul
(11) |
Aug
(23) |
Sep
(3) |
Oct
(3) |
Nov
|
Dec
(4) |
2008 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
From: Nicolai S. <ko...@sc...> - 2010-12-09 19:43:32
|
http://www.systemshock.org/index.php?topic=1947.msg22406#msg22406 |
From: Jake A. <jac...@gm...> - 2010-11-30 04:39:17
|
Have you considered having a PayPal link somewhere on your page? I would love to kick in some money to help move this project along, since I'm nowhere near a competent enough programmer to ge directly involved. |
From: Felix <fel...@ya...> - 2010-06-25 21:54:40
|
Hello, I am sorry for sending so much emails to the OPDE team. I did not find out earlier, that my first email was answered in the SourceForge mailing list. I have compiled OPDE now, but have problems with starting the engine. I set up the .cfg files, like the examples in the OPDE wiki, but it didn't work. Now it reads: ~/opde-build/src/main$ ./opdeMain An exception has occured: OGRE EXCEPTION(7:InternalErrorException): /usr/share/doc/ogre-1.2.2_p1/Samples/Media/packs/OgreCore.zip - error whilst opening archive: Unable to read zip file. in ZipArchive::checkZzipError at OgreZip.cpp (line 259) I do not even have a directory called /usr/share/doc/ogre-1.2.2_p1. The only OGRE doc files I found did not contain a Samlpes directory. |
From: Filip V. <f.v...@gm...> - 2010-06-16 06:47:17
|
Hi, I sometimes develop on Ubuntu 10.04 too and cmake passes without problems - are you sure you have python 2.6 installed? python2.6-dev package will probably also be needed... On Tue, Jun 15, 2010 at 10:59 PM, Felix <fel...@ya...> wrote: > Hello, > > I am trying to compile opde with linux, but I always get: > CMake Error at > /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:70 > (MESSAGE): > Could NOT find PythonLibs (missing: PYTHON_LIBRARIES PYTHON_INCLUDE_DIRS) > Call Stack (most recent call first): > /usr/share/cmake-2.8/Modules/FindPythonLibs.cmake:110 > (FIND_PACKAGE_HANDLE_STANDARD_ARGS) > CMakeLists.txt:194 (FIND_PACKAGE) > > Cmake-Support said, it might be an OPDE internal problem. Is there a way > to fix it? > > > I am using Ubuntu 10.04-AMD64 > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Opde-devel mailing list > Opd...@li... > https://lists.sourceforge.net/lists/listinfo/opde-devel > |
From: Felix <fel...@ya...> - 2010-06-15 20:59:43
|
Hello, I am trying to compile opde with linux, but I always get: CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:70 (MESSAGE): Could NOT find PythonLibs (missing: PYTHON_LIBRARIES PYTHON_INCLUDE_DIRS) Call Stack (most recent call first): /usr/share/cmake-2.8/Modules/FindPythonLibs.cmake:110 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:194 (FIND_PACKAGE) Cmake-Support said, it might be an OPDE internal problem. Is there a way to fix it? I am using Ubuntu 10.04-AMD64 |
From: Inso R. <ins...@gm...> - 2009-10-23 09:18:26
|
Hello, Thanks for the welcome.) I will start to dig in on this weekend. Hope to make myself useful ASAP. Best regards, Inso. |
From: Filip V. <f.v...@gm...> - 2009-10-21 07:24:41
|
Hi Inso, welcome and thank you for letting some fresh air into this rusty mailing list :) I will gladly help you out with setting up. I think you're best looking at the current SVN source first, trying to compile it, build documentation (it should be possible now with make doc, manual and pydoc make targets, but it is still a bit fresh). Also reading about original dark engine is quite helpful, although our source code structure is way different (original engine is a mixture of COM, C++ and plain C code, whereas we have the whole engine based on C++). Here are some links to get you started (order is random): Telliamed's Thief Tech <http://www.thiefmissions.com/telliamed/> Nameless Voice's Nameless Tower <http://www.geocities.com/nameless_voice/> Thief Dev Articles thread at ttlg.com<http://www.ttlg.com/forums/showthread.php?t=119925&highlight=thief+technical> Displacer's reversing notes around ShockED<http://systemshock2.wikispaces.com/> A list of services of original Dark, quoted by Nameless Voice<http://www.ttlg.com/forums/showthread.php?p=1808329#post1808329> Telliamed's newer, Dark Related page<http://whoopdedo.org/projects.php?dark> And some unsorted docs for inspiration: http://www.gamasutra.com/features/gdcarchive/2003/Duran_Alex.ppt http://www.drizzle.com/~scottb/gdc/game-objects.ppt<http://www.drizzle.com/%7Escottb/gdc/game-objects.ppt> There are some random tasks listed in the TODO file in SVN trunk, but those are mainly ideological guidelines... We also have some bugs listed in the bug tracker, but those may be too much for a newcomer (but you're free to try anyway). If there is a particular subject you'd like to start with and we find it fitting into the current plan (which is introduction of simulation and interactivity) we can try fitting it in. I can imagine particle rendering (or sound) as non-conflicting for example... Cheers, Volca On Wed, Oct 21, 2009 at 8:31 AM, Inso Reiges <ins...@gm...> wrote: > Hello, opde. > > My name is Inso Reiges, i am 23, native russian and would like to lend > a hand in this project. > I am a professional programmer with experience mostly in operating > systems, device drivers and systems programming as well as general > software design and methodologies. I think it would also be good to > mention that my experience with practical 3d graphics is quite > limited, although i do know a lot of purely theoretical stuff. > > I absolutely love classic thief games and replay them regularly.) > I have access to windows, linux and osx platforms with extensive > experience mostly in the latter two. > > If you are interested, please advise me with a starting point, maybe > some kind of a task to get myself familiar with opde. > > Best Regards, > Inso. > > P.S. Sorry if this message looks like a resume) > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Opde-devel mailing list > Opd...@li... > https://lists.sourceforge.net/lists/listinfo/opde-devel > |
From: Inso R. <ins...@gm...> - 2009-10-21 06:31:18
|
Hello, opde. My name is Inso Reiges, i am 23, native russian and would like to lend a hand in this project. I am a professional programmer with experience mostly in operating systems, device drivers and systems programming as well as general software design and methodologies. I think it would also be good to mention that my experience with practical 3d graphics is quite limited, although i do know a lot of purely theoretical stuff. I absolutely love classic thief games and replay them regularly.) I have access to windows, linux and osx platforms with extensive experience mostly in the latter two. If you are interested, please advise me with a starting point, maybe some kind of a task to get myself familiar with opde. Best Regards, Inso. P.S. Sorry if this message looks like a resume) |
From: Filip V. <f.v...@gm...> - 2008-12-16 13:01:19
|
Hi Everybody! It's been a long time since anyone posted to this mailing list, so I took the liberty of resurrecting the opde-devel back again. There was so much happening since the last post, better let me first llist a few points that we have achieved with this project so far: * We have a well working development environment for both linux and windows, OSX is not currently supported, no one seems to own the system and no one so far wanted to participate as a OSX maintainer * The rendering part has a good shape now, not everything is clean code-wise, but at least we get a decent framerates and the output is getting close to the original * Python was chosen as scripting language for Opde. It is widely used language which has been in use as a scripting language for games in the past, and is scalable * Object system was implemented, although not totally complete yet * Python bindings for great part of Opde were written, it is now possible to use python code to access gamesys objects for example * There are some rough sketches of input, gui and loop services present, some are already at work in the recent SVN version * we have migrated from CVS to SVN * domivogt has left the project (thanks to him again for helping with the start!) * Patryn and displacer joined the project, as well as duzenko did. * Patryn now maintains the win32 build of Opde and takes care of the installer preparations, see below. * We have some basic documentation generatable Now the plan: There will be, a sort of beta quality, release of the 0.3 version of the code. Patryn prepared an nsis installer for windows, that finds the existing game installations with or without assistance. This one will be released as well. Maybe we won't manage the release before the year's end, but I'd like to try. We'll se how it goes, christmas come in the way a bit, as did a sudden failure of my new harddrive (I was lucky to have the old one prepared for swap!). After the release, there will be a new set of positions open for various parts of the new code - there are about 6 different those planned now (2d rendering/gui, physics, sound, scripting, etc.). The openDarkEngine now has it's updated Ohloh page, so if you're one of the developers feel free to register and attach your account to it! Link: https://www.ohloh.net/p/opde That's it for now, cheers Volca |
From: Filip V. <f.v...@gm...> - 2008-05-26 06:53:56
|
Hi everybody, I'm just dropping a mail to let everybody know I'm alive and am still working on the project. I had a very little free time lately but it's likely over now, so I'm back to the renderer service and scene manager to finish rendering before 0.3. As both the original rendering method and the new one both sucked performance-wise, I'm now doing a new rewrite that should be extensible enough to allow different approaches be tested and also reskinning of the level geometry - something that needs to be done in order to let Windowshade/TrapTexture scripts to work. You might have noticed that some levels (mostly T2) refuse to load now and that the rendering is VERY slow on the rest of them. I'm focusing this. It seems that the portal traversal is too greedy in our approach (original dark might have used a screen space polygons [or at least trapesoids(?)], not bounding rectangles). The rendering is slow because of a massive overdraw now (and the traversal takes some time as well). One reason is that with Ogre::StaticGeometry, the renderer sometimes overdraws as much as a half of the level. Door vision blocking not implemented is one of the reasons as well. That one will be implemented within the new level geometry code (see bits 3,4 in the cell flags - 3 being open/closed flag, 4 informs that the cell is a part of a doorway). I'm sorry to have let everyone hang in the air (as usual) That's it. Filip |
From: Filip V. <f.v...@ce...> - 2008-01-24 21:46:16
|
Hi Everyone! Long time, no post! Well, everything is ok, just a little busy at the moment. I expect OPDE to reach 0.3 version in a month or so, we'll se what finally get's in and what does not (QuickGUI, I'm looking at you!). So what is happening these days? Mainly, I was working on Object service. It should be capable of creating/destroying objects (based on archetype), adding/removing/querying MetaProperties on them, and it also manages object's position and orientation (together with it's SceneNode, so we can decentralize the rendering into more services, and this can maybe help that). Yesterday, I decided it is finally a good time to clean up the junk in scenemanager directory, and then in the WorldRep service's directory. The status is now that I dropped the old rendering method altogether as it was smelly and dirty. I Dropped the whole scenemanager class and written a new one from scratch, it renders as before now, using the StaticGeometry class as a backend. If we find this not to be optimal, I'm sure we can find a different way to organize the geometry to be rendering friendly, but unfortunately the fragmented nature of WR does not help VBO usage much - but as VBO's are here to stay, I say let's overcome some rendering slowness encountered, the graphics HW improves with time. I'm finally adding the support for Lightning into the scenemanager. I hope to finish this next week, but shadows will probably be possible only with some extra work (two options are possible - sencil shadows and shadow mapping, each with it's problems for realization). I'll also clean up the WorldRep service, and migrate it to be able to load on Big and Little endian platforms respectively without issue (Hey, there was some guy a year or so ago trying to compile opde on non-intel Mac, is he still listening? I'd like to test it after finishing - well the DTypeDef code needs a change as well). Maybe I'll even move the lightmapping as a core capability of DarkSceneManager, that would make things quite easier... After this cleanup, I'll continue creating bindings for Python, so we'll be able to start coding event management and Physics after 0.3 is released. I'm really looking forward to that. Well, that's it for now! Volca |
From: Filip V. <f.v...@ce...> - 2007-12-22 12:20:32
|
Hello everyone! First, sorry for me not writing here much lately. Everything is ok and work is done, but I did not find time to write some of these pseudo-periodic reports to let everybody know what's happening. My fault, sorry. *So what's happening these days?* Well. First of all, it's been another year for Opde already, so the project is now 2 years old. Let's hope more years will come at least as successful as the previous two. This year was about object system, all filled with links and properties. We have a working object database loader (and saver, which is not used yet, but will be for savegames). We can merge gamesys with mission databases while loading, or with savegames (not tested, should work). A work has started to expose all the services to python, which is finally the chosen language for the specific things like scripts or in-game GUI interfaces. Some graphic improvements were implemented as well, for example the STATIC_GEOMETRY, and we finally are able to display objects. We have 3 new active members this year: Displacer, Duzenko and Patryn. Finally, I don't feel alone in this project :) Force wanted to join the project, but then realized he won't have time. This means the physics are free if anyone would like to look at that. Ali showed some interest already. *What's next?* The big target now is the 0.3 release. Three things are basically missing till we can say it's done: 1. Cleaning up the temporary code, finalization of the existing services as possible (mainly the newcomers - LoopService and InputService). 2. Complete python bindings, with a new bootstrap script written in python (that'll load dtype and pldef scripts, initialize graphics, show menus, etc). 3. QuickGUI bindings, GUIService For the 0.3-0.4 version span, the plan is bit unclear, but let's say it should be this: 1. Physics (with collisions) 2. Script subsystem (ScriptService, ScriptMessage classes), a propper way to describe script messages, message routing 3. InheritService modifications : Methods to work with metaproperties (code to handle those is there, but have to expose addMetaproperty, removeMetaproperty methods) 4. ObjectService - finally. Name to ID, ID to name. 5. DamageService - this thing is new. Handling of object damaging (and slay). 6. Sound (?) 7. Finally - interaction. The 0.3 - 0.4 will probably take another year or so. Final product of it should be a basically functional engine (some script messages and scripts implemented), without the AI. AI is planned for 0.4-0.5. This may change, sure. Just to describe the plan even further: 0.5-0.6 : finalization of scripts, stabilization (we should have a working game then, with some bugs to be squashed). 0.6 - 0.7 Improvements... Loader for FM's, starting work on Dromed successor if interest is shown. Squashing bugs. 0.7 - 1.0 : improvements and fixes, editor work. Well, that's it! I'm looking forward to see some interaction in the upcoming months :) Volca |
From: Filip V. <f.v...@gm...> - 2007-12-21 08:16:50
|
Hello everyone! First, sorry for me not writing here much lately. Everything is ok and work is done, but I did not find time to write some of these pseudo-periodic reports to let everybody know what's happening. My fault, sorry. *So what's happening these days?* Well. First of all, it's been another year for Opde already, so the project is now 2 years old. Let's hope more years will come at least as successful as the previous two. This year was about object system, all filled with links and properties. We have a working object database loader (and saver, which is not used yet, but will be for savegames). We can merge gamesys with mission databases while loading, or with savegames (not tested, should work). A work has started to expose all the services to python, which is finally the chosen language for the specific things like scripts or in-game GUI interfaces. Some graphic improvements were implemented as well, for example the STATIC_GEOMETRY, and we finally are able to display objects. We have 3 new active members this year: Displacer, Duzenko and Patryn. Finally, I don't feel alone in this project :) Force wanted to join the project, but then realized he won't have time. This means the physics are free if anyone would like to look at that. Ali showed some interest already. *What's next?* The big target now is the 0.3 release. Three things are basically missing till we can say it's done: 1. Cleaning up the temporary code, finalization of the existing services as possible (mainly the newcomers - LoopService and InputService). 2. Complete python bindings, with a new bootstrap script written in python (that'll load dtype and pldef scripts, initialize graphics, show menus, etc). 3. QuickGUI bindings, GUIService For the 0.3-0.4 version span, the plan is bit unclear, but let's say it should be this: 1. Physics (with collisions) 2. Script subsystem (ScriptService, ScriptMessage classes), a propper way to describe script messages, message routing 3. InheritService modifications : Methods to work with metaproperties (code to handle those is there, but have to expose addMetaproperty, removeMetaproperty methods) 4. ObjectService - finally. Name to ID, ID to name. 5. DamageService - this thing is new. Handling of object damaging (and slay). 6. Sound (?) 7. Finally - interaction. The 0.3 - 0.4 will probably take another year or so. Final product of it should be a basically functional engine (some script messages and scripts implemented), without the AI. AI is planned for 0.4-0.5. This may change, sure. Just to describe the plan even further: 0.5-0.6 : finalization of scripts, stabilization (we should have a working game then, with some bugs to be squashed). 0.6 - 0.7 Improvements... Loader for FM's, starting work on Dromed successor if interest is shown. Squashing bugs. 0.7 - 1.0 : improvements and fixes, editor work. Well, that's it! I'm looking forward to see some interaction in the upcoming months :) Filip |
From: Ali P. <dud...@ya...> - 2007-12-05 12:19:07
|
Hi all=0A=0AThe migration to Subversion is complete. From now on we should = only be using the svn repository, nothing should be committed to cvs anymor= e. Please contact me or Vol=C4=8Da if you require any help with svn.=0A=0AC= heers,=0AAli=0A=0A=0A ________________________________________________= ____________________________________=0ABe a better friend, newshound, and = =0Aknow-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_= ylt=3DAhu06i62sR8HDtDypao8Wcj9tAcJ =0A |
From: Ali P. <dud...@ya...> - 2007-12-05 11:21:12
|
Hi guys We are in the process of migrating the openDarkEngine repository from CVS to Subversion. Please do not make any commits to the CVS until the conversion is complete. We will inform you by email when all is done. Cheers, Ali ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs |
From: Filip V. <f.v...@ce...> - 2007-10-29 20:13:31
|
Hello everyone! I'm just dropping an e-mail to say that we have a new member, with SF nickname patryn! I'm glad our small community slowly grows. Welcome, new member! Volca |
From: Filip V. <f.v...@ce...> - 2007-10-18 20:25:59
|
Hello everyone, I'm still quite busy, but I found some time today, so I've written the loop service. It may change it's behavior (to stack based comes to my mind), but the overall design should be the one you can all see in CVS now. I did not test it on windows, so hopefully it is ok there too (compiling with VS). This is one of the last things needed before the version 0.3 release. Now the GameStateManager and it's servants could be removed, which I'll do soon. The input service is in CVS as well, and should be used together with the loop service since 0.3 exclusively. What is my plan now? (After 0.3 is ready that is...) * Some small UI preparations, so we can finally get menu and loading screens, etc. * Preparations for scripting - squirrel seems to be the final choice. We'll need some script language interface defined in base, and the bindings for the chosen language so it will be able to setup game specific stuff. This is what seems like the best idea - the services will be written to be universal, and the scripts will handle all the differences. I'm not talking about the scripts that form the game object behavior, but about a bootstrap script that defines the game's look and feel. * The object service needs to be written (handling object creation / death). There is a need for a good overlay service (GUI service), that would handle switching mapped/direct input (game/gui mode), mouse cursor and GUI sheets. We had a discussion with duzenko, and it seems that the old gui's could be replaced with some nicer gui system, but there are some things that will have to be implemented anyway, so the first to come will be the old one (I'm talking about thiefs map screen for example, or SS2's mfd screens). Ok, that's it. Please be patient, everything will clear up after I finish this operation Be sure to ask questions, or reply with any comments. I'd like a discussion to happen here more often :) Volca |
From: Filip V. <f.v...@ce...> - 2007-10-10 21:36:32
|
Hello everybody! Sorry for letting everyone hang in mid-air without any information. I'm finishing input service this week, it is now able to parse bnd files, but needs the callback mechanism placed in (and bnd writing as well). The thing complicating it is that the input system in dark is kind-of weird (or I do not fully understand it). There are commands bound to keys, that is ok, but you can prefix the command with '-' or '+', then the walk/look commands only seem to receive on and off events (+walk will walk on pressed, -walk on unpressed), when this character is omitted, the code seems to oscillate with on/off events per 2 frames (for commands that get this prefix). Hmm. Weird thing is that some commands are not prefixed with this char, and yet do not oscillate. (I hope you get my point). It seems there are two modes of input - traditional with repetitions, and filtered with on/off signals. Maybe I can get around this somehow, but I want a compatible implementation... I'll do more testing to ensure compatible behavior, then test the code on windows and commit. Next to work on for me is loop service. About 80-90% of the input service is coded, so only some of this finalization needs to be done. The code is in CVS, but should not build (CMakeLists.txt is commented out for the input dir). Sorry again for all this waiting for me. I need to make the code stable and clean for 0.3 to let everybody do their job without the need to constantly fix something in a code that is going away anyway. Keep tuned, few days to finish these (Hopefully). BTW: I discovered a bug in the worldrep service, that causes custom materials to not have correct alignment. Scale is ok. I'll try to fix this as well. Filip |
From: Filip V. <f.v...@ce...> - 2007-09-11 18:52:24
|
Hi everybody! Today, I sort-of finished the quest for object mesh loading and display. It works, with a few glitches and exceptions... (Mainly - why is there a third handle inside the door objects?, also, the rotation of object is sometimes off). Everyone who wish to try it: Add obj.crf to the resources.cfg. I did not test ss2, but it should work ok too. I'll try to send some screenshots of the current state to clearing, as he asked about the progress a week ago. For those who do not know him, he is one of the guys behind the Russian site http://darkfate.ru/. We already have some screenshots there. Some remarks: *The render service will probably have more features in the feature, and some will be moved to mesh service (mesh loading, that is). *There is no lightning now, because the light service is not written, and the scene manager has no support for lights. *The "src/main" directory will vanish some time in the feature. All features will be implemented in the services. Only some initialization will take place in some main.cpp file. *My plan is to implement loop service (probably mentioned earlier), which should have a prioritized listeners. That one would handle per-frame updates. *I do not know yet how to implement the state machine needed to skip between different screens/states of the engine, any advice is welcome (GameManager will also be removed) *Another plan is to implement input service, the source of translated events. For example if key 1 will be bound to command "inv_select sword", this command will be emited. This should be compatible with thiefs (shock 2 too?) BND files. Menu items will also emit such commands through an injection, and console will also inject those commands into input service. Thus, there will be a single place for input events. *The input commands will probably be processed with the master script, as mentioned in the TODO file. The script will implement subroutines for all such commands, and will perform some kind of registration. Thus, all the commands will be scripted. This makes the engine pretty flexible. * A database loading service will have to be created (will broadcast about database unload, load of gamesystem, mission and savegame, and also the save of the savegame). Will have priorities for listeners to handle the loading properly. If some of you guys have some knowledge about rendering effectivity, batching and such, I'd like to discuss the planned changes on the DarkSceneManager, as it starts to be not sufficient, and of course we want the graphics to be up-to-date with the current technology - shaders, dynamic lightning and shadows. Don't we? ;) I hope everyone is ready to program, because, after some cleaning work on the sources, together with the implementation of the core services (object, loop, input, database), everything will be ready for the main work! The mentioned services are about a month (max. two) of work. And, as a last note: There will probably be a version bump soon. Let's say loading the VHOT and some small fixes/improvements will be sufficient. Keep tuned, more to come! Filip |
From: <dis...@ex...> - 2007-09-05 20:11:59
|
Sounds good, and welcome to the new member. I've been taking a small break, got a copy of Bioshock and its been eating up most of my time, but I'll be back to work on this before long. --- On Wed 09/05, Filip Volejnik < f.v...@ce... > wrote: From: Filip Volejnik [mailto: f.v...@ce...] To: opd...@li... Date: Wed, 05 Sep 2007 12:48:55 +0200 Subject: [Opde-devel] Small update Hello to everybody!Just a small update to keep those interested informed.First of all, Anton Duzenko has joined the team, and already has fixed the CVS so that it compiles under Visual Studio (2005?). Kudos to him!Next, I'm fixing a lot of bugs and stuff like this, so in the end, probably next week, a big commit will happen, that will update the opde so it renders objects (Hooray!). It works for me here, but is not 100% bullet-proof at the moment (and it does not handle creation of subobject skeletons at the moment).After this, I'll be up to the ObjectService and finalization of all four services connected to it (Namely LinkService, InheritService, PropertyService and ObjectService). The word here is STABILIZATION, not feature fullness.Next, there will be a possibility for all you people to start contributing some small portions of code, if you'll like to, of course, because there should be a stable code base for your work. ParticleSystemService would be a nice project for someone for example.Side notes:1/ Current GameStateManager is just a sketch. It will be replaced/rewritten to LoopService. 3 things will be enabled by this. Sorting of the loop listeners (prioritization), loop listener masks (bitfield), input event routing (probably), or cooperation with a newly created InputService. The result is that nearly no code will be outside the services.2/ I finally got the feeling I know how to rework the whole rendering system. It is currently a bit slow, because the index buffer is filled dynamically, meaning memory->graphics card transfers. Let's wait for PortalConnectedZonesSM to be merged into the ogre release, then let's try converting the renderer to use it. It won't use the WR portals, that would mean no improvement. Instead, I thought it should be possible to use room database to group geometry into larger batches. Using that in combination with static geometry should do the work nicely. If not, this is a project for a week or two, so no big deal...3/ Opde needs a good configuration storage. I think the best way is to write ConfigurationService (which should be compatible with Dark's config files). Using DVariants for return values of it should enable writing all sorts of values inside. The big + here will be that after necessary updates to the code, all initialization could be parametrized the same as Dark's. Meaning resource paths, resolution settings, you name it.Please keep me informed, be it your progress or questions...Filip-------------------------------------------------------------------------This SF.net email is sponsored by: Splunk Inc.Still grepping through log files to find problems? Stop.Now Search log events and configuration files using AJAX and a browser.Download your FREE copy of Splunk now >> http://get.splunk.com/_______________________________________________Opde-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/opde-devel _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! |
From: Filip V. <f.v...@ce...> - 2007-09-05 10:50:16
|
Hello to everybody! Just a small update to keep those interested informed. First of all, Anton Duzenko has joined the team, and already has fixed the CVS so that it compiles under Visual Studio (2005?). Kudos to him! Next, I'm fixing a lot of bugs and stuff like this, so in the end, probably next week, a big commit will happen, that will update the opde so it renders objects (Hooray!). It works for me here, but is not 100% bullet-proof at the moment (and it does not handle creation of subobject skeletons at the moment). After this, I'll be up to the ObjectService and finalization of all four services connected to it (Namely LinkService, InheritService, PropertyService and ObjectService). The word here is STABILIZATION, not feature fullness. Next, there will be a possibility for all you people to start contributing some small portions of code, if you'll like to, of course, because there should be a stable code base for your work. ParticleSystemService would be a nice project for someone for example. Side notes: 1/ Current GameStateManager is just a sketch. It will be replaced/rewritten to LoopService. 3 things will be enabled by this. Sorting of the loop listeners (prioritization), loop listener masks (bitfield), input event routing (probably), or cooperation with a newly created InputService. The result is that nearly no code will be outside the services. 2/ I finally got the feeling I know how to rework the whole rendering system. It is currently a bit slow, because the index buffer is filled dynamically, meaning memory->graphics card transfers. Let's wait for PortalConnectedZonesSM to be merged into the ogre release, then let's try converting the renderer to use it. It won't use the WR portals, that would mean no improvement. Instead, I thought it should be possible to use room database to group geometry into larger batches. Using that in combination with static geometry should do the work nicely. If not, this is a project for a week or two, so no big deal... 3/ Opde needs a good configuration storage. I think the best way is to write ConfigurationService (which should be compatible with Dark's config files). Using DVariants for return values of it should enable writing all sorts of values inside. The big + here will be that after necessary updates to the code, all initialization could be parametrized the same as Dark's. Meaning resource paths, resolution settings, you name it. Please keep me informed, be it your progress or questions... Filip |
From: Filip V. <f.v...@ce...> - 2007-08-13 10:59:31
|
Hello everybody, as I promised, I started working on the InheritService. A working skeleton is present in CVS, currently only listening to MetaProperty relation messages, and updating it's internal source/destination inheritance maps. It does broadcasts too itself, which will be used by caching inheritors, so those will be able to rebuild the internal map of effective object id's. Now I would like to finish this soon, hopefully this week (But I know that this is little bit too optimistic). After this, All the modifications to the property service will be made. I do not know yet if even the inherited property should be a source to the property change broadcasts. It seems that Dark handles this in a sorta fuzzy way, because some key properties are not concrete inherited - only archetype inherited. That means that the property itself (not an inherited one) is used on concrete objects (copied upon instantination of the archetype), so maybe broadcasting inherited property asignments will not be needed. If it will, the change will be rather simple really. I'd like to split the properties to active/passive (only active would broadcast), but this probably won't fit... Object service will be next. That one will handle: createFromArchetype, create, nameToID, idToName, object death, pre-death, object creation messages, some clever ID mapping for objects, etc. I really wish to finish this soon, because the main work on the engine will then be possible - all those fancy core features, such as tweq's, frobbing, particle systems, etc. Please report any compilation problems to me if you try to build opde now, it may be inconsistent (mainly as I have some pending modifications in the DarkSceneManager, and won't commit those till I have a working stencil/lightmap global shadows - and that will take some time to do). As a side note: I migrated to Code::Blocks, as SVN version of it finally works like a charm, and CMake CVS version can generate project files for it. If somebody want's cmake cvs ebuild for gentoo, I can send it. The C::B really is a nice dev. platform, finally the code completion works as it should (with one exception - completion over the -> operator, which is used in shared_ptr template). Filip |
From: Filip V. <f.v...@ce...> - 2007-08-12 10:21:15
|
That should be easy. Room database is a set of room brushes, which are connected to each other using portals. Those are not the same portals as in the case of WR, where those are used for visibility determination, but rather doorways enabling sound/AI/whatever to pass from one room to another. There is even a script message associated with entering/leaving a room. This message is used quite often (for example for mission ending determination in Thief - "leave the building when finished"). So the room portals are the connecting points for two rooms. Those are defined, if I'm not mistaken, in some door property field - src/dst room. Those may be hidden in shocked/dromed, because those are probably generated automatically. See RotatingDoor/TranslatingDoor - int32 room[2]; Filip dis...@ex... wrote: > Can someone clear up what exactly a room portal would be? In the original aidatabase structure, it has as the first entry in struct cell as sint16 first_vertex, but the software uses this entry for a call to a function named cDABase<cRoomPortal *,4,cDARawSrvFns<cRoomPortal *>>::operator[](int) > > > > which I assume uses this entry for a pointer to cRoomPortal data, which is a structure 0x10 in length. It uses this data in a function called cDABase<sAIPathVertex,1,cDARawSrvFns<sAIPathVertex>>::operator[](uint), which I assume is the actual vertex data. > > > > > > > > _______________________________________________ > Join Excite! - http://www.excite.com > The most personalized portal on the Web! > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Opde-devel mailing list > Opd...@li... > https://lists.sourceforge.net/lists/listinfo/opde-devel > > > |
From: <dis...@ex...> - 2007-08-11 15:01:46
|
Can someone clear up what exactly a room portal would be? In the original aidatabase structure, it has as the first entry in struct cell as sint16 first_vertex, but the software uses this entry for a call to a function named cDABase<cRoomPortal *,4,cDARawSrvFns<cRoomPortal *>>::operator[](int) which I assume uses this entry for a pointer to cRoomPortal data, which is a structure 0x10 in length. It uses this data in a function called cDABase<sAIPathVertex,1,cDARawSrvFns<sAIPathVertex>>::operator[](uint), which I assume is the actual vertex data. _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! |
From: <dis...@ex...> - 2007-08-09 20:43:50
|
--- On Thu 08/09, Filip Volejnik < f.v...@ce... > wrote: From: Filip Volejnik [mailto: f.v...@ce...] To: opd...@li... Date: Thu, 09 Aug 2007 19:32:28 +0200 Subject: Re: [Opde-devel] Path flags dis...@ex... wrote:> Hmmm, is there a line block feature in the engine that AIs can't cross? Like you can lay lines down to keep them out of certain areas. I'm also wondering if this may be an unused flag, and the code was never removed that checks for it. I have yet to find a cell that has this bit set.>>> None I know about. You can modify a certain object to be blocking the AI path, but that one is already mapped in the flags. It sure can be a flag which is not used.Another idea that popped in my head just now: It can be a flag specifying movable terrain or something releted to that.-------------------------------------------------------------------------This SF.net email is sponsored by: Splunk Inc.Still grepping through log files to find problems? Stop.Now Search log events and configuration files using AJAX and a browser.Download your FREE copy of Splunk now >> http://get.splunk.com/_______________________________________________Opde-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/opde-devel _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! |