Port to Ogre 1.11+ while keeping 1.9 compatibility #23

paroj · 2020-01-26T19:14:58Z

~~most maps load with Ogre 1.12, but assert at 25115e6 after some time. Notably "Asphalt" does not load, but asserts immediately.~~

Requires Ogre in full legacy mode as:

OGRE_RESOURCEMANAGER_STRICT=0
OGRE_NODELESS_POSITIONING=ON

for 1.12 additionally this content has to be placed at some known resource location:
https://github.com/OGRECave/ogre/tree/master/Media/ShadowVolume

based on #17

Performance

high peaks went up from 75 to 94 fps, which is quite nice I guess. Flooded stayed about the same.

(higher, 3 shadows, 6 reflections at once)

Remaining Tasks

~~Remaining editor issue is RTT binding. See:~~
https://github.com/OGRECave/ogre/blob/master/Docs/1.11-Notes.md#breaking-non-api-changes nr. 2
Vsync is always on
~~Can't save jpg screenshots, also from RTT causing editor to crash on save F4~~
https://github.com/OGRECave/ogre/blob/45f2531138902414072cbba551b77b11aebb692d/PlugIns/STBICodec/src/OgreSTBICodec.cpp#L112
No MyGui text shadows on HUD (times, damage %)
Occasional crashes on track load (?)

Fixes the following GCC 8 error: error: invalid conversion from 'int' to 'Ogre::Exception::ExceptionCodes' [-fpermissive] Used ERR_INVALIDPARAMS in some places where ERR_INVALID_CALL would be more appropriate, because ERR_INVALID_CALL is new in Ogre 1.10+ and using it would break Ogre 1.9 support.

Fixes the following issue on aarch64 with GCC 8.1: source/editor/TerrainBrushes.cpp:138:1: error: narrowing conversion of '-1' from 'int' to 'char' inside { } [-Wnarrowing] The signedness of 'char' is implementation defined, so we need to be explicit.

…dropped in 1.11 In Ogre 1.9 and earlier, the material APIs were inconsistent with some methods expecting a MaterialPtr& and others a String&. Ogre 1.10+ harmonized this, but that means that we need some version checks in a few places to keep using the old String& setters on Ogre < 1.10.

…h count

paroj · 2020-01-27T14:01:22Z

for whatever reason travis build is not linked here, but it passes:
https://travis-ci.org/stuntrally/stuntrally/pull_requests

cryham · 2020-02-01T19:33:42Z

Wow, cool. Thanks.
I'll give it a try now. I moved to Debian 10. I didn't yet build Ogre from sources here, lets see how it goes.
Got only Ogre 1.9 from repos.

cryham · 2020-02-01T22:19:43Z

@paroj
I got all deps from apt-get.
I did build Ogre, from master 1.12.
I had that known issue with imgui. I did git submodule update, didn't work since there was that config file already, moved it, then got it back.

Any idea why then sample browser is not starting?

Loading library /home/..../_dev/og1-bin/lib/RenderSystem_GL.so.1.12.5
Installing plugin: GL RenderSystem
OpenGL Rendering Subsystem created.
./SampleBrowser: symbol lookup error: /home/..../_dev/og1-bin/lib/RenderSystem_GL.so.1.12.5: undefined symbol: glXGetCurrentDisplay

paroj · 2020-02-01T23:02:37Z

can you verify the following:

$ scanelf -l -s glXGetCurrentDisplay | grep glXGetCurrentDisplay
...
ET_DYN glXGetCurrentDisplay /usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.435.21 
ET_DYN glXGetCurrentDisplay /usr/lib/x86_64-linux-gnu/libGL.so.1.0.0
ET_DYN glXGetCurrentDisplay /usr/lib/x86_64-linux-gnu/libGLX.so.0.0.0

$ ldd RenderSystem_GL.so.1.12.5
	linux-vdso.so.1 (0x00007fff793ff000)
--->	libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x00007f013f6e7000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f013ee40000)
	libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f013eb08000)
	libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007f013e8fd000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f013e574000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f013e1d6000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f013dfbe000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f013dbcd000)
--->    libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 (0x00007f013d99c000)
	libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007f013d6e6000)
...

this is for me on Ubuntu 18.04

paroj · 2020-02-01T23:14:55Z

I could meanwhile track down the ogre release, that introduced the breaking change. It must be one of those:
https://github.com/OGRECave/ogre/releases/tag/v1.10.9

I suspect its one of the pixel format related commits

cryham · 2020-02-02T11:28:52Z

Okay I got scanelf with pax-utils from Apper,
and here are my results:

$ scanelf -l -s glXGetCurrentDisplay | grep glXGetCurrentDisplay
ET_DYN glXGetCurrentDisplay /lib/x86_64-linux-gnu/libvtkRenderingOpenGL-6.3.so.6.3.0 
ET_DYN glXGetCurrentDisplay /lib/x86_64-linux-gnu/libQtAV.so.1.12.0 
ET_DYN glXGetCurrentDisplay /lib/x86_64-linux-gnu/libGLX.so.0.0.0 
ET_DYN glXGetCurrentDisplay /lib/x86_64-linux-gnu/libTKOpenGl.so.11.0.0 
ET_DYN glXGetCurrentDisplay /usr/lib/x86_64-linux-gnu/libvtkRenderingOpenGL-6.3.so.6.3.0 
ET_DYN glXGetCurrentDisplay /usr/lib/x86_64-linux-gnu/libQtAV.so.1.12.0 
ET_DYN glXGetCurrentDisplay /usr/lib/x86_64-linux-gnu/libGLX.so.0.0.0 
ET_DYN glXGetCurrentDisplay /usr/lib/x86_64-linux-gnu/libTKOpenGl.so.11.0.0 

$ ldd RenderSystem_GL.so.1.12.5
        linux-vdso.so.1 (0x00007ffe111d3000)
        libOgreMain.so.1.12.5 => /home/..../_dev/og1-bin/lib/libOgreMain.so.1.12.5 (0x00007f383b716000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f383b6b4000)
        libSM.so.6 => /lib/x86_64-linux-gnu/libSM.so.6 (0x00007f383b6a9000)
        libICE.so.6 => /lib/x86_64-linux-gnu/libICE.so.6 (0x00007f383b48c000)
        libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007f383b34b000)
        libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6 (0x00007f383b139000)
        libXrandr.so.2 => /lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007f383af2c000)
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f383ada8000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f383ac25000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f383ac0b000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f383aa4a000)
        libzzip.so.13 => /home/..../_dev/og1-bin/Dependencies/lib/libzzip.so.13 (0x00007f383aa41000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f383a821000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f383a81c000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f383bd4b000)
        libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f383a813000)
        libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f383a7f9000)
        libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f383a7cf000)
        libXrender.so.1 => /lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f383a5c3000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f383a5b9000)
        libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007f383a3b5000)
        libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f383a1af000)

Wow, libGLX.so is not in my RenderSystem_GL.so 😨

paroj · 2020-02-02T13:57:25Z

Wow, libGLX.so is not in my RenderSystem_GL.so fearful

and neither is libGL.so.
check

OPENGL_gl_LIBRARY
OPENGL_glx_LIBRARY

in cmake

cryham · 2020-02-02T14:14:35Z

I have:
OPENGL_gl_LIBRARY /usr/lib/x86_64-linux-gnu/libGL.so
it's a symlink to: /etc/alternatives/glx--libGL.so-x86_64-linux-gnu
which is a symlink to: /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
that symlinks to file: libGL.so.1.7.0

OPENGL_glx_LIBRARY /usr/lib/x86_64-linux-gnu/libGLX.so
symlink to file: libGLX.so.0.0.0

The final files are there. So, what should I do?

paroj · 2020-02-02T14:36:12Z

I could reproduce your issue by setting OPENGL_gl_LIBRARY="", so it is definitely the cause. Unfortunately I can only guess how to solve this - the solution should involve finding the right libGL I guess. Candidates are: $ scanelf -l -s glLightfv | grep glLightfv.

This might be also related to the newer glvnd you got in Debian 10 which might be incompatible with the ancient glew we have in Ogre. Do you get the same error with GL3+? It does a proper GL symbol resolution.

cryham · 2020-02-02T15:03:04Z

I get the same error with GL3 only (I added # for GL in plugins.cfg):

Loading library /home/..../_dev/og1-bin/lib/RenderSystem_GL3Plus.so.1.12.5
Installing plugin: GL 3+ RenderSystem
OpenGL 3+ Rendering Subsystem created.
./SampleBrowser: symbol lookup error: /home/..../_dev/og1-bin/lib/RenderSystem_GL3Plus.so.1.12.5: undefined symbol: glXGetCurrentDisplay

$ scanelf -l -s glLightfv | grep glLightfv
ET_DYN glLightfv /lib/x86_64-linux-gnu/libOpenGL.so.0.0.0 
ET_DYN glLightfv /lib/x86_64-linux-gnu/libvtkRenderingOpenGL-6.3.so.6.3.0 
ET_DYN glLightfv /lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0 
ET_DYN glLightfv /lib/x86_64-linux-gnu/libTKOpenGl.so.11.0.0 
ET_DYN glLightfv /usr/lib/x86_64-linux-gnu/libOpenGL.so.0.0.0 
ET_DYN glLightfv /usr/lib/x86_64-linux-gnu/libvtkRenderingOpenGL-6.3.so.6.3.0 
ET_DYN glLightfv /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0 
ET_DYN glLightfv /usr/lib/x86_64-linux-gnu/libTKOpenGl.so.11.0.0

But, I got my old SR working with Ogre 1.9 and looks like it is using:

/usr/lib/x86_64-linux-gnu/OGRE-1.9.0$ ldd RenderSystem_GL.so | grep GL
        libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x00007f7148b4f000)
        libGLU.so.1 => /lib/x86_64-linux-gnu/libGLU.so.1 (0x00007f7148ade000)
        libGLX.so.0 => /lib/x86_64-linux-gnu/libGLX.so.0 (0x00007f7147c5e000)
        libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007f7147ba1000)

Should I like, put those paths into cmake (OPENGL_gl_LIBRARY and OPENGL_glx_LIBRARY) and rebuild Ogre 1.12?

paroj · 2020-02-02T15:05:37Z

Should I like, put those paths into cmake (OPENGL_gl_LIBRARY and OPENGL_glx_LIBRARY) and rebuild Ogre 1.12?

its worth giving a try

paroj · 2020-02-02T15:54:21Z

found the bug BTW: the blendmap was incorrectly requested as RGBA but accessed as BGRA. Ogre 1.9 used to always give you BGRA.

cryham · 2020-02-02T16:01:08Z

Ugh. This didn't change, same error. And I did put paths for gl, glx, glu (there is also EGL and opengl?) and rebuilt. Still no libGL in RenderSystem_GL.so nor in GL3.

paroj · 2020-02-02T16:57:22Z

we only do pretty standard stuff there. I guess the breakage is due to the newer GLVND on Debian 10:
https://cmake.org/cmake/help/latest/module/FindOpenGL.html#linux-specific

You could try adding OpenGL::GL OpenGL::OpenGL OpenGL::GLX here:
https://github.com/OGRECave/ogre/blob/65a3bd11143ff32177dd9b31a1249ed919e723b7/RenderSystems/GL/CMakeLists.txt#L64

cryham · 2020-02-02T18:29:50Z

Okay I got Ogre built.
I added message(STATUS ${OPENGL_gl_LIBRARY})
just before that line in CMake and that bloody thing is empty. Then I realized it's an env var not a CMake var (I was setting it in CMake Gui, there is this var there).
Then it was exactly empty again after cmake Configure.
I can't even, so I've just put there:
target_link_libraries(RenderSystem_GL OgreMain OgreGLSupport /lib/x86_64-linux-gnu/libGL.so.1)
and now RenderSystem_GL.so has all 3 linked properly. I can finally see Ogre demos and go into building your fork.

resurrected the relevant parts from Ogre 1.10.12

png will already be loaded by load(fpng) - no further handling needed.

paroj · 2020-12-13T01:04:38Z

I have a strange issue (non blocking) that is in SR editor, in preview camera F7, I should see only square view of track in middle, but I see terrain outside of this square now. It's like terrain mesh didn't follow (viewport constraint, render group or visibility flag) and all else did.
Screen here: https://i.imgur.com/Gy21OF0.jpeg
Could you check if you have this issue too?

can you point me to how/ where you set-up that square-view clipping?

cryham · 2020-12-13T09:31:05Z

maybe your driver settings?

I thought that too but old SR build with Ogre 1.9 does not have this Vsync issue, I can turn it off and Fps goes to max.

can you point me to how/ where you set-up that square-view clipping?

So a few fragments in code:
This toggles Camera View F7 for preview:
All for it is in rt[RTs]

///  Preview Camera mode  - - - - - - - - - - - - - - - - - - - - - - - -
void App::togPrvCam()
...   // enter
	mViewport->setVisibilityMask(RV_MaskPrvCam);
	rt[RTs].ndMini->setVisible(true);

So I hide all on current mViewport and show ndMini with Rectangle2D
these are created in

//  Setup render 2 texture (road maps)
// . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
void App::Rnd2TexSetup()
...
	r.mini = new Rectangle2D(true);  // screen rect preview
	if (i == RTs)  r.mini->setCorners(-1/asp, 1, 1/asp, -1);  // fullscr,square
	r.ndMini->attachObject(r.mini);

And lastly VisibilityFlags (and Render Queue Groups) are set for terrain in:

void CScene::CreateTerrain(bool bNewHmap, bool bTer, bool terLoad)
	terrain->setVisibilityFlags(RV_Terrain);

and defined in: /source/ogre/common/RenderConst.h

	RV_Terrain = 4,	// terrain and fluids, for terrain texture
	RV_MaskAll = 511,

paroj · 2020-12-13T15:33:58Z

maybe your driver settings?

I thought that too but old SR build with Ogre 1.9 does not have this Vsync issue, I can turn it off and Fps goes to max.

it might be SDL2 then. Try reverting this:
3fb3a29

you will lose FSAA, but maybe VSync will be gone as well.

found the Terrain issues. The visibility flags were not properly propagated. OGRECave/ogre@d453756

do you know that you can directly push to my fork instead of posting patches here?

cryham · 2020-12-13T20:43:37Z

I reverted 3fb3a29 but it didn't help, still 60 Fps like Vsync was on and it introduced a crash on Alt-Tab:

X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  12 (X_ConfigureWindow)
  Resource id in failed request:  0x0
  Serial number of failed request:  18
  Current serial number in output stream:  19

Good, terrain visibility got fixed with latest Ogre commits. I changed plugin to:
mRoot->loadPlugin(PATHMANAGER::OgrePluginDir() + "/Codec_FreeImage" + D_SUFFIX);
There was an issue that it can't save jpg if it is RGBA so I added a switch there to create it only for RTTs that need it.

Okay I didn't know I can push to your fork, cool. But I get: ERROR: Permission to paroj/stuntrally.git denied to cryham.
So here is the diff:

diff --git a/source/editor/Render2tex.cpp b/source/editor/Render2tex.cpp
index bfdd02f5..8897004a 100644
--- a/source/editor/Render2tex.cpp
+++ b/source/editor/Render2tex.cpp
@@ -60,9 +60,10 @@ void App::Rnd2TexSetup()
                        
                        ///  rnd to tex - same dim as Hmap      // after track load
                        Real fDim = scn->sc->td.fTerWorldSize;  // world dim  ..vdr
+                       bool noAlpha = i == 2 || i == RTs;
                        texture[i] = TextureManager::getSingleton().createManual(
                                sTex, rgDef, TEX_TYPE_2D,
-                               dim[i], dim[i], 0, PF_R8G8B8A8, TU_RENDERTARGET);
+                               dim[i], dim[i], 0, noAlpha ? PF_R8G8B8 : PF_R8G8B8A8, TU_RENDERTARGET);

One other thing: there are lots of deprecated warnings, I changed #include "OgreVector3.h" (also for 2 and 4) to "OgreVector.h" to get rid of some of them can this go in here, or is it something that would break Ogre 1.9 compatibility?

paroj · 2020-12-13T23:06:40Z

Okay I didn't know I can push to your fork, cool. But I get: ERROR: Permission to paroj/stuntrally.git denied to cryham.

you have to use the https://.. when adding the remote. More details:
https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/committing-changes-to-a-pull-request-branch-created-from-a-fork

One other thing: there are lots of deprecated warnings, I changed #include "OgreVector3.h" (also for 2 and 4) to "OgreVector.h" to get rid of some of them can this go in here, or is it something that would break Ogre 1.9 compatibility?

"OgreVector.h" does not exist in 1.9. While you could #ifdef that, you should rather do as the warning says and use "Ogre.h" instead (which is backward compatible to 1.9).

AsciiWolf · 2021-01-27T21:30:24Z

Sorry for making yet another noise in this PR, but I wonder what is the current state of Stunt Rally running on Ogre 1.11+. Is the game playable? If so, are there any major issues? Thanks!

paroj · 2021-01-29T13:21:40Z

you can try yourself using the edge channel of:
https://snapcraft.io/stuntrally
which is built against Ogre 1.12.10.

The stable channel is built against Ogre 1.9. You can install both in parallel for comparison:
https://www.omgubuntu.co.uk/2019/06/snappy-now-lets-you-install-multiple-versions-of-the-same-snap-app

AsciiWolf · 2021-01-29T14:04:22Z

Thanks, but I don't have Snap on any of my systems. However, I am thinking about making a beta branch of the Stunt Rally Flatpak with changes from this PR.

cryham · 2021-02-03T12:55:15Z

From my side, the only major issue left is (as in 1st post):

Vsync is always on

which means I can't compare or tell how much better it is.
And we don't have any ideas left how to fix it, am I right?
Also, I have almost no free time left nowadays, so I can't do much.

AsciiWolf · 2021-02-03T13:42:08Z

@cryham If vsync is the only remaining (major) issue and there are no ideas how to fix it, would it be possible to merge the current code as it is into master? :-)

cryham · 2021-02-06T20:23:28Z

It is possible.
If I merge will anything change for those who build on Debian (Ubuntu etc.) using libogre-1.9-dev package?
(Just want to be sure, title says it is okay).
If nothing then I'm okay.
(I don't even have libogre-1.9-dev now and I doubt I'll have time to test soon).

paroj · 2021-02-12T16:28:52Z

If I merge will anything change for those who build on Debian (Ubuntu etc.) using libogre-1.9-dev package?

just did another test-build against libogre-1.9-dev and libmygui-dev and everything works fine.

cryham · 2021-02-12T17:39:30Z

Okay great.
There is a conflict in .travis.yml do you know what to do in it? I'm not sure what happened there.

paroj · 2021-02-12T17:43:57Z

you pulled #21 which contained conflicting changes with me upgrading the buld from trusty to xenial here. As travis seems to be dead anyway, I will just drop mine

recent ogre does not like this

Tarek-Hasan · 2021-12-19T18:50:36Z

Will building with ogre 13.x going to work?

AsciiWolf · 2021-12-19T20:22:28Z

Well, in my case (Flatpak package), even 12.x does not work properly.

paroj · 2021-12-19T20:39:16Z

for 13.x, the bundled paged-geometry needs to pull some changes from upstream - but the remaining code should work as is.

If you want to test stuntrally with latest 1.12, you can use the "edge" snap here:
https://snapcraft.io/stuntrally

akien-mga added 7 commits November 19, 2018 11:36

Add missing iostream include

d99e4e1

Ogre: Use Ogre::Box instead of Ogre::Image::Box

3c71359

Ogre: Use ResourceGroupManager instead of Root for addResourceLocation

c5e39d0

Ogre: Use RenderTarget::getStatistics() to get FPS, triangle and batc…

8240534

…h count

paroj requested a review from cryham January 31, 2020 17:10

paroj added 7 commits February 2, 2020 20:47

Ogre 1.10+ resource lookup fixes

971be67

Ogre: Bundle deprecated MaterialSerializer dropped upstream

b2261cd

resurrected the relevant parts from Ogre 1.10.12

CMake: try OGRE 1.10+ CMakeConfig find_package first

ba13627

ConfigOptions are const in 1.12

a4894f2

load generic image plugin on Ogre 1.11+

2285f63

PagedGeom: workaround direct crashes with recent Ogre

594faea

fix wrong impostors resolution

2d53e9c

png will already be loaded by load(fpng) - no further handling needed.

paroj and others added 10 commits February 12, 2021 18:44

we assume BGRA order for blendmap

45dba1f

use parentWindowHandle on Linux to fix FSAA

a751cd4

SDL: actually enable gamepad support

6f844dc

add stubs for Ogre 1.12 core shaders (unused by stuntrally)

f8ed04c

enable vsync by default to prevent burning through GPU

d324fc8

add missing include

23f5567

drop duplicate material definition

83c7f0e

shiny: drop dummy technique

da9ed9c

recent ogre does not like this

pagedgeometry: apply fixes from upstream

35bbfc1

editor: apply RTT fixes

ea0a6af

cryham merged commit 98aa335 into stuntrally:master Feb 12, 2021

paroj deleted the ogre-1.11 branch February 12, 2021 23:02

AsciiWolf mentioned this pull request Feb 13, 2021

Vsync is always on (with Ogre 1.11) #27

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Port to Ogre 1.11+ while keeping 1.9 compatibility #23

Port to Ogre 1.11+ while keeping 1.9 compatibility #23

paroj commented Jan 26, 2020 •

edited by cryham

paroj commented Jan 27, 2020 •

edited

cryham commented Feb 1, 2020 •

edited

cryham commented Feb 1, 2020 •

edited

paroj commented Feb 1, 2020 •

edited

paroj commented Feb 1, 2020

cryham commented Feb 2, 2020 •

edited

paroj commented Feb 2, 2020

cryham commented Feb 2, 2020 •

edited

paroj commented Feb 2, 2020

cryham commented Feb 2, 2020

paroj commented Feb 2, 2020

paroj commented Feb 2, 2020

cryham commented Feb 2, 2020

paroj commented Feb 2, 2020

cryham commented Feb 2, 2020

paroj commented Dec 13, 2020

cryham commented Dec 13, 2020 •

edited

paroj commented Dec 13, 2020 •

edited

cryham commented Dec 13, 2020 •

edited

paroj commented Dec 13, 2020

AsciiWolf commented Jan 27, 2021

paroj commented Jan 29, 2021

AsciiWolf commented Jan 29, 2021

cryham commented Feb 3, 2021 •

edited

AsciiWolf commented Feb 3, 2021

cryham commented Feb 6, 2021 •

edited

paroj commented Feb 12, 2021

cryham commented Feb 12, 2021

paroj commented Feb 12, 2021

Tarek-Hasan commented Dec 19, 2021

AsciiWolf commented Dec 19, 2021

paroj commented Dec 19, 2021

Port to Ogre 1.11+ while keeping 1.9 compatibility #23

Port to Ogre 1.11+ while keeping 1.9 compatibility #23

Conversation

paroj commented Jan 26, 2020 • edited by cryham

Performance

Remaining Tasks

paroj commented Jan 27, 2020 • edited

cryham commented Feb 1, 2020 • edited

cryham commented Feb 1, 2020 • edited

paroj commented Feb 1, 2020 • edited

paroj commented Feb 1, 2020

cryham commented Feb 2, 2020 • edited

paroj commented Feb 2, 2020

cryham commented Feb 2, 2020 • edited

paroj commented Feb 2, 2020

cryham commented Feb 2, 2020

paroj commented Feb 2, 2020

paroj commented Feb 2, 2020

cryham commented Feb 2, 2020

paroj commented Feb 2, 2020

cryham commented Feb 2, 2020

paroj commented Dec 13, 2020

cryham commented Dec 13, 2020 • edited

paroj commented Dec 13, 2020 • edited

cryham commented Dec 13, 2020 • edited

paroj commented Dec 13, 2020

AsciiWolf commented Jan 27, 2021

paroj commented Jan 29, 2021

AsciiWolf commented Jan 29, 2021

cryham commented Feb 3, 2021 • edited

AsciiWolf commented Feb 3, 2021

cryham commented Feb 6, 2021 • edited

paroj commented Feb 12, 2021

cryham commented Feb 12, 2021

paroj commented Feb 12, 2021

Tarek-Hasan commented Dec 19, 2021

AsciiWolf commented Dec 19, 2021

paroj commented Dec 19, 2021

paroj commented Jan 26, 2020 •

edited by cryham

paroj commented Jan 27, 2020 •

edited

cryham commented Feb 1, 2020 •

edited

cryham commented Feb 1, 2020 •

edited

paroj commented Feb 1, 2020 •

edited

cryham commented Feb 2, 2020 •

edited

cryham commented Feb 2, 2020 •

edited

cryham commented Dec 13, 2020 •

edited

paroj commented Dec 13, 2020 •

edited

cryham commented Dec 13, 2020 •

edited

cryham commented Feb 3, 2021 •

edited

cryham commented Feb 6, 2021 •

edited