ogre branch ? new attempt from scratch

[klauss]

I'll check the status of resources, I may have not committed them because they were temporary, and I didn't want to bloat the repo with temporary stuff.

I'll let you know what I find, but remember I'll be gone a few weeks after new year, so patience, and do try to get some progress made in my absence

PS: will give MyGUI a try, I hear it has something we desperately want: render-to-texture

[strook]

Ya, of course, maybe you'll get a new vs
to be serious -if I don't get it running with the data6.x dir, I could work on a mygui version using the actual vs stuff.

[pheonixstorm]

all the mygui binaries i've tried so far crash under windows. They work ok until you close them then they crap out and make windows act funny.

[strook]

Don't make me weak
we've decided for mygui, or not?
Maybe we cold try it out after linking against mygui and starting an ogre window with it.

[pheonixstorm]

Go for it. Could just be the way the binaries are setup. I haven't looked much into it but I know running them under opengl doesn't play nice with windows. We can see how it plays out though.

[strook]

Installed libois and mygui to vs.
It started up ois and the appwindow in mygui.
I'm now on refreshing the code and setting input.
The directory structure has changed.
There are 2new cmake config files and the CMakeLists.txt has been updated.

[strook]

i have a new path.

it is heavily modified.

an ogre window is now running in mygui but not reacting on input, i don't know why in the moment...

EDIT: the link was broken
ogre demo src branch v. 04.01.11

mygui doesn't work with OpenGL... Yet.
There was a pure virtual func defining the draw func.
That wasn't initialized.
However it can be implemented by the mygui programmers in the future and there could be multiple platforms for the GUI... Maybe.
The ogre imlementation is running though.

[strook]

The app shall only be testing wether mygui works together with windows or not.
Note that you need to install the newest ogre version and mygui version since there were changes with the last versions.
I think the reason why the mygui guys supplied a not complete oengl draw func was that I have to define it myself.
You need to include some resources in order to run it.
Hence I've got not all resources still now.
So the screen remains dark exept the debug overlay.
Also not all of the program code is activated and I think to see something I need to press a key.
But that code is disabled.
In order to run it, copy the sol sector folders and the core mygui folder into the core folder.

[charlieg]

I'm pretty sure the MyGUI devs will welcome bug reports. Or perhaps be able to point out what you may be doing wrong. Given how widely used MyGUI is lately, it seems strange that it would have such severe problems.

[strook]

I didn't do much the last days, however today I took 3hours and corrected the input.
I got an error that is fixable but I can say that the input works now.
Maybe a spaceflight is possible now.

Additionally I contacted the mygui guys and gave a bug report. It is fixed now.
Also I can probably say that mixing OpenGL and ogre is possible.
I compiled my program with the mygui OpenGL platform and linked against ogre.
SUCCESS!
the ogre window was shown and I could draw maybe something with OpenGL, however I didn't get so far cause I was ill the last days a bit and needed to do something for univesity.
I'll post an update when I'll get a working version.
What does a headache to me is the missing data files. Can someone fix the data6.x dir, plz?

What about committing my patches after I up them?
The vegastrike ogre_branch folder could be completely renewed.
Just add the config files to the vegastrike folder delete the rest and create a new src folder containing the vegastrike_ogre_branch_demo folder.
Poenixstorm could you do this after I have a new update?
There must be new .svn folders created cause the directoy structure is completely out of date.
What about upping that to my branch?
It is empty right now.

[charlieg]

Good work strook! Glad to see the MyGUI team is so responsive. That's what is needed for VS. I don't think CEGUI is so actively maintained any more.

I'd sign up for a github account initially whilst svn access gets sorted out.

/0.02c

[strook]

Will do it.

Today I reoganized the vs ogre branch folders again to keep it simple to hold it in sync with the main tree.

There are three subfolders in src now. The rest of the vs folder was deleted.
The first contains new ogre branch specific code the second old vegastrike branch code the third vegastrike branch code that needed to be modified in order to run with the ogre version.

The directory structure of vs is preserved inside theese both folders.

I copied the rare minimum vs files that needed to be in order to run the ogre demo.

[strook]

I got the core app running.
It shows me a yellow planet and is accepting keyboard input.

[charlieg]

Cool.

Here's another source of potential inspiration - an open source city generator for Blender:
http://www.youtube.com/watch?v=HROU3gLcgfg
http://arnaud.ile.nc/sce/

[strook]

I got Keyboard and Mouse Input running.
However, the app is moving the scene far too fast.
And I can't debug it in the moment cause it takes the mouse exclusively and does not show the mouse.
Maybe it is being corrected after I initialize the window correctly and load in the core mygui folder.
I'll ask the mygui guys.

There are 2 draw functions are executed the ogre function(it works) and the mygui function, which is based on OpenGL.
I hope, this works.
If it works, we have a glue layer between ogre and OpenGL.
We could import most of the vegastrike stuff.
In fact I can't imagine how it should work with the coordinates.
Cause the ogre coordinates go up to 3000-5000 or beyond this they won't be drawn.
Maybe it isn't a problem.
Let's see.

[strook]

There is a problem coming up:
how shall I mix OpenGL and ogre objects when drawing?
I think the best solution is to define a mygui layer for every OpenGL object and threat the layers rendered like sprites when overlapping.

[charlieg]

I guess here for hints:
http://ogre3d.org/tikiwiki/MyGUI+quickstart
http://ogre3d.org/tikiwiki/MyGUI+sample

[strook]

ois and ogre already running.

i mean i placed the renderOneFrame func and the opengl draw func into the screen update func.

the result should be that mygui elements are placed over the rendered content.

if i make the vegastrike stations and spaceships act like sprites(like mygui windows), placing them into the scene with the mygui layer mechanism, there should be np.

there should be a collision mechanism implemented handling ogre and opengl.
but i don't know how to handle this in the moment.

in the moment i need to create a mouse pointer and handle the problem with the exclusive mouse input(i think this is an ogre problem).
i don't know if the pointer is shown if i load in the mygui_core.xml
i'll do that tomorrow.

[charlieg]

Sounds promising.

Please don't forget to create a repository somewhere and regularly update your work.

I recommend http://github.com (Git) or http://bitbucket.org (Mercurial).

Mercurial is a bit simpler to use although is a bit slower than Git.

[strook]

Aaah now I understand. Github is also preserving web space for open source code.
I created an account.
But I would be happy if someone could upload the ogre_branch data6.x folder renamed to ogre_data and uploaded inside the original data folder.
Plz , I have only a 12kb upload rate. I would need ages for this.

[pheonixstorm]

https://sourceforge.net/projects/vegaogre/ is one place to host the vs ogre code and w/e else we need for it. I think as long as we keep the same directory structure as VS we shouldn't need to store data anywhere else. The only thing we need to put anywhere is the sourcecode and use an external link to the VS data on this svn (except under file releases)

Something else we should look into under vegaogre is creating a new file type to handle the data. Something like data/units.vso or some such just so we can compress all the current files and have them uncompressed and loaded and runtime using zlib (static or not).

Choice for vegaogre.. do we want one at sf and github? If so do we have a means of keeping both repositories in sync? I know chuck has a way to do that between sf svn and his svn.

[pheonixstorm]

err forgot that ogre uses a different graphics format oops. So yeah, will need to up the ogrefied graphics.

[pheonixstorm]

Last thing. If the data dir hasnt changed just the code then go ahead and svn up the code in branches (on vegaogre svn) you are one of the admins along with myself and klauss since he may be the most help on this when something goes wrong. I am setting up the svn structure now.


Actually it might be better to go ahead and upload all of your code compressed to the ftp first so we can get it organized nice and neat.

[klauss]

I believe the best way to proceed is to divide your work in manageable patches, and submit them to the code review tool.

Not only to review the code, which is a good thing, but also to give us (ie: me and whoever else reviews them) a chance to keep up with the required changes on the branch, discuss the stuff, get on board and eventually contribute if possible.

So code review allows us to make sure the patch builds (and runs?) fine on other platforms (the reviewers can apply the patch and test it a bit before commenting), spot silly bugs, or simply stay tuned to the changes.

For instance, I know the design decisions behind every line of code in the UserInterface folder in the ogre branch, so if you change something and inadvertly stray into a gray area I'll be able to spot the issue way earlier than anyone else, with minimal effort, rather than committing, forgetting, and letting the issue blow in our face months after the fact.

So... don't commit a huge thousand-lines patch, that's unworkable, if you can avoid it. Of course, if you can't avoid it, it's better than no review at all, but do try to divide the patch into chunks, and explain what each chunk does.

The patches are easily generated by using the "svn diff" command ("create patch" in tortoise). You select the files to be included in the patch (ie: "svn diff src/blah.cpp src/bleh.cpp" or using tortoise's GUI), and you're done. "svn diff"/tortoise's diff is better than plain diff since "svn diff" knows not to include metadata in the diff, and uses the proper format (the one the review tool readily understands).

New files have to be added ("svn add") before creating the patch, so that SVN knows to include them in the patch. It's not automatic.

[strook]

here are the configs and diffs from my ogre branch.

however they seem to be incomplete, i'll post the srrc folder again in the next post.

again, i changed the overall directory structure in order to keep it easy to keep the copied unmodified files from vegastrike in sync.

there are three folders: Ogre_branch, Vegastrike_mixed_modified_branch, and Vegastrike_OpenGL_branch.

inside Vegastrike_mixed_modified_branch, and Vegastrike_OpenGL_branch, the directory structure of vs is preserved.

if i need a file from the original vs, i copy it into Vegastrike_OpenGL_branch. if it changes in vs, is just renew it inside there.
if i need to modify an original vs file i copy it into Vegastrike_mixed_modified_branch.

the UserInterface folder is nearly unmodified, i just moved the UIPrecompiledHeaders into the Ogre_branch root folder. i think this should contain all the precompiled headers and we need only one.

There is an OIS folder in UserInterface. it contains the base classes for handling the input from libOIS, which are handled in FrameListener.cpp

i spread up all the Classses in main.cpp and made files from it (FrameListener.cpp, .h)
i renamed ExampleApplication and Tutorial Application and listener to a real name.

i initialized the ogre and opengl user interface (in FrameListener.cpp).

i changed the appliccation loop, i toke renderOneFrame() aand drawOneFrame() from ogre and MyGUI. however, this should be modified sincce i have to implement the z-bufffer myself to handle opengl and ogre.

don't expect too much from the actual app, the input is in the moment not in a release state, the rendering output goes much too fast, and i haven't the correct data6.x folder.

also the mouse pointer is not shown and it is exclusive preserved from the application frame, so i can't debug it.