Ogre Direct3D 9Ex plugin: What's the best build process?

Currently I'm working on the MogreBuilder tool.
If possible it would be useful to extend the builder to create your extended plugin version.

Yeah that would be nice. I was also thinking of submitting a patch to Ogre, since this doesn't need to involve Mogre. (Someone else I was chatting with was looking into it but I think he gave up too soon.) I'm not sure how willing they'd be to accept it though. I was hoping to make it a zero impact thing that is only turned on via a config option, but it does also need a different pointer ID3D9DeviceSomethingEx. I guess 4 bytes of RAM isn't too much to waste I guess a few bool checks based on the option might be involved too -- probably very minor impact though.

I'm not sure what's best though. Maintaining a patch against Ogre? Or for my bitbucket repository I could keep pulling the latest Ogre. Or ...?


To be save, perhaps the MogreBuilder could build the common DX plugin and your one as additional one.
So the end user can choose by the plugins.cfg file, which versions he want to use.

Yeah I think people would appreciate keeping the official D3D9 plugin. Whether or not 9Ex into the official plugin might take a while (too long?) to determine, in which case a separate plugin might be best.


To add it to the Mogre builder we need more information.
For writing this (and the following discussion) you could create a new topic called "Extended Directx 9 plugin".

If you are interested, you also can try to extend the MogreBuilder with your extended plugin.
If you have questions for it, just ask in the MogreBuilder forum topic.

For my Hg fork of the ogre on bitbucket, I don't really know how to keep it up to date, but I did just try a merge to ogre's 1-7. (Maybe I should have merged to tip, I don't know.)

https://bitbucket.org/JaredThirsk/ogre-d3d9ex/compare/..sinbad/ogre

Thanks for creating this topic and your intention to improve Mogre.

I was also thinking of submitting a patch to Ogre, since this doesn't need to involve Mogre. [...] I'm not sure how willing they'd be to accept it though.
If the Ogre code needs modification for 9ex support, it's no problem with the MogreBuilder.
It creates a cloned repository of the Ogre repository. So on the local hard disk your patch could be applied (without the need to be accepted by the maintainers of the official Ogre repository).
This step would depend to the users choice. (If he enables 9ex support for the MogreBuilder)

I'm not sure what's best though. Maintaining a patch against Ogre? Or for my bitbucket repository I could keep pulling the latest Ogre.

Maybe do it like this:

1. Put your modifications into your private repository[/*:m]
   
2. Create a copy of the MogreBuilder config file and let the parameter "OgreRepository" point to your private repository (URL or local path)[/*:m]
   
3. Run the MogreBuilder. It will "download" and build your modified sources.[/*:m][/list:u]
   
   
   Note:
   Currently the MB runs HG if there is no cloned repository.
   It does NOT update it, if it still exists.
   So either delete the Ogre source directory before running MB again.
   Or make your further modifications inside of the Ogre clone, which was created by the MB
   Or (the best way) is to improve the MogreBuilder to perform repository updates.
   
   It should be very easy to add repository update support to the MB.
   The modification has to be done in file Source\Tasks\CloneOgreSource.cs
   Just look how the clone job is called. The same way you can perform the update.
   
   I'm not shure how to call an update the correct way with HG calls. (I also didn't searched for it. I put my focus to other features.)
   
   
   in which case a separate plugin might be best
   This should be a good way.
   I suppose plugins have a defined interface and the API of your 9ex should be similar or equal.
   The plugins code is in seperate DLL files. So I think there should be no conflict between both (if only one is loaded by the plugins.cfg).
   An advantage would be: Common Ogre users/maintainers don't have to be afraid, because the current DX plugin will not be touched. As extra/optional plugin you also would have better chances to get the agreement to get your improvements into the official repository.
   A further advantage: In the binary file names you can see, it it's DX9 or DX9ex. (This would avoid confusions if plain binaries are uploaded/offered somewhere.)
   
   For my Hg fork of the ogre on bitbucket, I don't really know how to keep it up to date, but I did just try a merge to ogre's 1-7.
   I also have too less Mercurial knowledge for such topics.
   For the current state of the MogreBuilder you have to check it into the 1.7 branch, because this will be build by the MB.
   Or you change the config file parameter "OgreBranch". (Until today only the branch "v1-7" was used/tested.)
   
   
   I gave you write access to the MogreBuilder repository.
   Have fun!