ogre branch ? new attempt from scratch

[log0]

Disabling WNDTST will result in an exception:

OgreException:
errorcode=3
source=Win32Window::create
file=..\..\..\..\..\RenderSystems\GL\src\OgreWin32Window.cpp
line=420
descr=wglMakeCurrent
fulldescription=OGRE EXCEPTION(3:RenderingAPIException): wglMakeCurrent in Win32Window::create at ..\..\..\..\..\RenderSystems\GL\src\OgreWin32Window.cpp (line 420)
OGRE EXCEPTION(3:RenderingAPIException): wglMakeCurrent in Win32Window::create at ..\..\..\..\..\RenderSystems\GL\src\OgreWin32Window.cpp (

Though I've managed to use createRenderWindow in original vegastrike code following the tutorial without raising exceptions!?

[log0]

@strook
Somehow I have the feeling it is related to the threading. I am surprised that it works for you?

Btw you are copying the rendered content into memory. This is the worst thing you can do, will kill framerate. I don't this this is going to work.

[log0]

Tried to start ogre outside of the thread, but must be missing something. Will exit at core->init()

Code: Select all

	new OgreVSApplication();
	std::string plugins_cfg = VSFileSystem::datadir + "/../vegaogre_data/plugins.cfg";
	try
	{
		Ogre::Root *root = new Ogre::Root( plugins_cfg );
		GalaxyEngine::Core* core = new GalaxyEngine::Core( root );
		core->init();
		VSOgre::ogre_main(argc, argv);
		OgreVSApplication::getSingletonPtr()->startup();
	}
	catch (Ogre::Exception e) {
		std::cerr << "Error occoured during Ogre engine initialisation. Starting old vegastrike Engine." << std::endl;
		VSOgre::PrintOgreExceptionAndTipps(e);
	}
	//createOgreThread(argc, argv);

[log0]

Have got it running:

Code: Select all

	//createOgreThread(argc, argv);
	new OgreVSApplication();
	new VSOgre::OgreThread();
	VSOgre::OgreThread::getSingletonPtr()->setCoreInOgre(VSFileSystem::datadir + "/../vegaogre_data/plugins.cfg");
	VSOgre::ogre_main(argc, argv);
	OgreVSApplication::getSingletonPtr()->startup();

Tried to insert getCore()->getRoot()->renderOneFrame() into void GameUniverse::StartDraw(). This resulted in garbage render output. The next step will be to disable vegastrike opengl calls completely to verify if ogre is rendering into the vs window correctly.

[strook]

ok, but i got it running, now i must synchronize the ogre render output with the vegastrike engine.
i'll write a test on university tomorrow, so i hadn't the time.
i copied the vs orientation to the ogre , but it didn't work. but i know how to use quaternions.

but there is one real big thing:

ok, i could map all the ogre output to a plane, quasi a window. then put the window into the rendering pipeline and check every 3d - model if it is in front or behind the rendered planet.

we would have no collision detection.
and it would be difficult to implement.

so, better would it be to disable ogre rendering, and use the vertex data from the galaxy engine for the planets.

[strook]

note that core is thread local data.

[log0]

ok, i could map all the ogre output to a plane, quasi a window. then put the window into the rendering pipeline and check every 3d - model if it is in front or behind the rendered planet.
we would have no collision detection.
and it would be difficult to implement.

That is the thing i don't get with your render to texture approach. Ogre is issuing opengl calls. Just let it do it. Ideally it should be possible to replace the background/planet vs rendering code with the ogre render call and then continue with vs code. The practical problems are to leave the z-buffer intact and eventually some other state before/after the planet rendering code has run. Right now I am getting a black screen, don't see the planet. Some state must be messed up.

note that core is thread local data.

I am using OgreVSApplication::render() to be more correct.

[log0]

This is what I have right now(vs opengl code disabled) OgreVSApplication::render() call. Means getCore()->getWorldManagerSingletonPtr()->updateWorld();

Code: Select all

glDeleteBuffersARB(1,04204A48)
glDeleteBuffersARB(1,042049C4)
glGenBuffersARB(1,042049C0)
glBindBufferARB(GL_ARRAY_BUFFER,405)
glBufferDataARB(GL_ARRAY_BUFFER,80,00000000,GL_STATIC_DRAW)
glBindBufferARB(GL_ARRAY_BUFFER,405)
glBufferDataARB(GL_ARRAY_BUFFER,80,7ED20024,GL_STATIC_DRAW)
glGenBuffersARB(1,04204A4C)
glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER,406)
glBufferDataARB(GL_ELEMENT_ARRAY_BUFFER,12,00000000,GL_STATIC_DRAW)
glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER,406)
glBufferDataARB(GL_ELEMENT_ARRAY_BUFFER,12,7ED20024,GL_STATIC_DRAW)
glDeleteBuffersARB(1,04204828)
glDeleteBuffersARB(1,0420493C)
glGenBuffersARB(1,04204938)
glBindBufferARB(GL_ARRAY_BUFFER,407)
glBufferDataARB(GL_ARRAY_BUFFER,80,00000000,GL_STATIC_DRAW)
glBindBufferARB(GL_ARRAY_BUFFER,407)
glBufferDataARB(GL_ARRAY_BUFFER,80,7ED20024,GL_STATIC_DRAW)
glGenBuffersARB(1,0420482C)
glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER,408)
glBufferDataARB(GL_ELEMENT_ARRAY_BUFFER,12,00000000,GL_STATIC_DRAW)
glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER,408)
glBufferDataARB(GL_ELEMENT_ARRAY_BUFFER,12,7ED20024,GL_STATIC_DRAW)
glFlush()
wglSwapBuffers(620118F3)

There are no draw calls. Only some buffers are updated, I guess planet segment meshes.

[log0]

I' ve enabled getCore()->getRoot()->renderOneFrame(); in OgreVSApplication::render(). This is what I get if I set a breakpoint after render(). The planet is drawn into vs window.


But the following GFXEndScene() call which is calling SDL_GL_SwapBuffers() breaks it. Need to figure out why.

[log0]

Got it fixed by disabling GFXEndScene(). Means I have a stable planet rendering without garbage. The garbage was created due to an extra SwapBuffers call. The question now is. Where does the second SwapBuffers come from. As we need to be able to control when it happens.

[log0]

Look! A planet. Hehe.



But boy the code needs some cleanup. I'll upload a patch later.

[strook]

GREAT!!! YOU DID IT!!! i need the CODE!!!

[log0]

GREAT!!! YOU DID IT!!!

Just a proof that it works. There is a lot to do to replace the star system renderer. The ogre thread and render to texture stuff can be removed at least.

The patch is against your branch and also contains changes needed to make it run on win32. You will find it here: http://sourceforge.net/projects/vegaogr ... /vega-vc9/

[log0]

I would also opt for --with-ogre-engine logic removal to reduce code bloat. Just run with Ogre, period.

[log0]

Here is a minimal patch containing planet rendering changes only. Won't compile on windows obviously.
https://sourceforge.net/projects/vegaog ... h/download

[ghoulsblade2]

cool, finally sounds more sensical than running 2 rendering engines at the same time %)

[charlieg]

Great work log0!

[log0]

I've hoped strook would take over from here...

Maybe I'll find some time to finish it.

[strook]

I've had just One Message from ACE that it would be committed to the vs code. I made a fast answer and then no reply.

I could find some time, that if a planet is rocky, it will be seamless one.

But I can't imagine that it really works, both engines together...

Also the problem with the size isn't really being worked on, if the planets are going too large, they won't displayed correctly.

So i need now the apologize that the code will be used, and from you, log0 the apologize that the engines are working.

Then I'll move on. (I spent so much time with it, that would be fun developing on a working version that would be used)

[charlieg]

I've hoped strook would take over from here...

Maybe I'll find some time to finish it.

Please keep going log0!

So i need now the apologize that the code will be used, and from you, log0 the apologize that the engines are working.

Then I'll move on. (I spent so much time with it, that would be fun developing on a working version that would be used)

You want an apology then you'll move on? Or you are apologising? What you said made no sense.

It would be good to see you keep moving it forward. I'm sure that if it works, it will be adopted and used.

I'm sure klauss will be eager to tinker with a version of Vega Strike that runs on Ogre, as would many others. However I don't see there being any eagerness to pick up something that doesn't work. The progress by you and now log0 makes that a tantalizing possibility!

[riftroamer]

Hi there
So far I've only been lurking on the forum, mainly following this particular thread with huge interest (even though I am no coder, I'm afraid).

So i need now the apologize that the code will be used, and from you, log0 the apologize that the engines are working.

Then I'll move on. (I spent so much time with it, that would be fun developing on a working version that would be used)

If I am correct English is not the native language of strook, so from my point of view this might simply be a mix-up of some vocabulary?

The lines make sense using the words "commitment" or even more likely "confirmation", I think. Just my humble thoughts on this, though.

@strook and @log0: Please keep up the terrific work you invested into this. This seems to be THE way to get close to an old Vega Strike vision I stumbled upon elsewhere in this forum (on the Vega Strike websites, that is). You know: walking the streets of a planet, hailing a cab to the starport, traveling to another planet for a cup of coffee while observing local life.

[strook]

well ok, then lets make some YASS advertisment - ok it shouldn't be one, but this is the developing state:

- seamless flight with REAL planets like mars etc.
- ego shooter perspective
- space stations
- real physics(PhysX)
- bone animation
- real water,sky (hytdax, skyX)
and many more features i don't accounted, yet.

the solution was that we generate some levels on ground (or in space) can fly or move through them, when we leave them the seamless flight will be activated.
actoally you can step into or out the ship, land and move arround.

there are just tech demos avaiable - ok we'll release a new one soon,
but this code has real seamless flight NOW, sorry but it is in an alpha state, but vs is as far
away from ogre implementation and seamless flight as we are away to alpha centauri.

as it is yet proposed, will YASS be free but closed source, cause there are some real expensive models bought in there with usage for no money earning for free.

i have implemented bone animation now - with parser support - like it is in crysis etc.

now i'll implement my library of mc2 mechs as i wanted long time ago in a game.

[Deus Siddis]

as it is yet proposed, will YASS be free but closed source,

Folks might actually prefer the opposite arrangement, where the code is open sourced after enough donations have been made to that end.

(In other words people pay money to have the YASS source code released into the public domain.)

[gonzo]

http://www.yass-engine.de/
Wow! The video demonstrating different gravity settings was a killer!

[strook]

It could be somehow be 'stealing of code' but vs could be life further on with the yass engine. I have sent an email to the other developers. And vs is free.

I mean the game structure could be used with yass, cause we have only an engine yet.

We could use

- most of the the data branch
- the space station interface
- the dynamic galaxy system with it's races

This way we would have a really new vegastrike, with an different ship handling, but with most of all the vs features that make the game fun playing.

What do you think of it?