potterr on 21/9/2008 at 21:32
Quote Posted by Volca
What we could do is patch both Dromed and thief to store the array bigger, probably, but that would mean unpatched thief would most probably crash. Storing a copy of the light list in mission files would allow us to load greater amount of lights for OPDE, for example (if this is practical is another thing).
Just on this point, if there were to be issues with FMs using the engine not working on the original, would it be an idea to have a reference file of some kind in the FMs? I can get GL to detect these and also determine if the original engine is being used, if so GL won't allow the FM to be installed. Maybe just a simple text file called opendsource.ref or something like that.
Quote Posted by sparhawk
this new engine will be a new standalone application that can run original Thief missions, but it doesn't replace the original engine as in "swap the original". It's just a different executable that does similar things.
Would it be a completely new install to a new location (with additional DLL's, etc) or would it be an additional exe in your T2 install folder?
Volca on 22/9/2008 at 07:01
It's too soon to tell. The current plan is to write the engine without any improvements compared to the original, or close to this situation. Any limit overrides can come later on.
Currently OPDE will sit in a separate directory, and use the installed thief/ss2 resources from an original installation. We're now working on modularization of opde, so there will be:
Code:
opde.exe
opdeLib.dll (please, someone, propose a better name for this lib)
opdePyLib.dll (python interface for the above, the same request applies :) )
- and numerous ogre3d libs and config files
Totally around 10-20 files I think, so it would not be wise to make the current installations dirty with these additional files.
sparhawk on 22/9/2008 at 07:56
Is Thief using a DLL for the engine code? I thought it is all in one exe file, but I never looked into it. If it uses a DLL and dromed uses the same, then it might be indeed possible to swap the engine. :)
Well, we will see. :) But even if limitations from Dromed can not be overcome, this project is still a great thing, because at least you can continue playing existing FMs, without worrying about newer machines making them incompatibel. :)
And who knows? If this engine is finished, maybe somebody would write a Dromed replacement as well. :)
potterr on 22/9/2008 at 08:10
Volca, ok thanks for the info.
As you said it may be too soon to tell, but from an FM loader point of view:
* Would FMs still be installed into the original games install path? (I'm guessing as you said it uses the installed t2/ss2 resource files then I think yes)
* The launch of opde.exe would presumably be the same as that of the existing exe(s)? I.E. any cmd line arguments available.
Volca on 22/9/2008 at 08:11
Unfortunately the dark engine is statically linked into both DROMED.exe and THIEF.exe (the same applies for shocked/shock.exe). Even if it was separate, we could not just replace it, as I did not design (knowing that previous fact) the dark to be interface compatible. The same applies for OSM files, as Dark uses COM, and .dll nature of OSM files would mean portability problems to even x86_64 platform, not speaking about non-CISC architectures.
The bright side of this is that, as we'll rewrite all the osm files in python, anyone will be free to look at them, what exactly they do, etc.
I'm still trying to think about later writing of Dromed replacement, so the code includes some support for such a tool (which will also come handy for people creating tools based on the opdelib.dll).
For example iterators over the property names, link names, dynamic enumeration iterators, property data/link data iterators (all the property fields, which enum if any they use, what data type they are, what name the field has). These are not strictly needed for engine as such, and are written to support tool developement.
Volca on 22/9/2008 at 08:13
Quote Posted by potterr
Volca, ok thanks for the info.
As you said it may be too soon to tell, but from an FM loader point of view:
* Would FMs still be installed into the original games install path? (I'm guessing as you said it uses the installed t2/ss2 resource files then I think yes)
* The launch of opde.exe would presumably be the same as that of the existing exe(s)? I.E. any cmd line arguments available.
Later, we can discuss what command line parameters you'd need, and implement, no problem. I suppose FM's could be stored anywhere, we use ogre's resource system so all needed to do is adding another .zip file as a resource location (or unpacked one as a directory).
sparhawk on 23/9/2008 at 09:32
Quote Posted by Volca
Unfortunately the dark engine is statically linked into both DROMED.exe and THIEF.exe (the same applies for shocked/shock.exe).
Too bad, but not really surprising.
Quote:
Even if it was separate, we could not just replace it, as I did not design (knowing that previous fact) the dark to be interface compatible.
Well, that wouldn't matter, because in this case one could have written a thin layer in between that translates calls tot he original engine to your engine. Similar like Wine works on Linux. Well, it's a moot point anyway, since it's statically linked.
*Zaccheus* on 23/10/2008 at 13:35
Are you supporting wide screen formats in opde ?
Quote Posted by Volca
Code:
opde.exe
opdeLib.dll (please, someone, propose a better name for this lib)
opdePyLib.dll (python interface for the above, the same request applies :) )
- and numerous ogre3d libs and config files
My suggestion would be:
Code:
OpenDark.exe
OpenDark.dll
OpenDarkPython.dll
Does that mean you are writing this in python?
Btw, I have some experience creating installers using (
http://www.innosetup.com/isinfo.php) InnoSetup, if that would be any help to you.
Volca on 23/10/2008 at 13:50
Quote Posted by *Zaccheus*
Are you supporting wide screen formats in opde ?
FOV is currently fixed (all camera related code is testing only - we'll have to implement service for camera handling). No problem later on (I have an access to one widescreen LCD so testing won't be a problem).
Quote Posted by *Zaccheus*
My suggestion would be:
Code:
OpenDark.exe
OpenDark.dll
OpenDarkPython.dll
Good suggestion! Currently the python bindings are built-in. I'll consider renaming the binaries if other members agree, this indeed sounds better :)
Quote Posted by *Zaccheus*
Does that mean you are writing this in python?
Not yet, but will be. There is currently (
http://opde.svn.sourceforge.net/viewvc/opde/trunk/scripts/python/tree.py?view=markup) one example script using Opde python bindings, but plan is to write game-dependent code and OSM script replacements in python. We'll also provide standalone script executor targetted at Dromed users - the one tree.py example can be executed with (also I'd like to create a propper python extension out of Opde dll, later).
Thanks for the offer, I appreciate it. Currently Haplo handles the installer, and is doing just fine. I'll let him decide - if he'd want any help, he'll contact you :)
