Cell preloading

[Lagahan]

Threw another 2 videos up comparing vanilla and OpenMW. The NVME SSD brute forces both and they end up fairly similar but when I tested it on a HDD OpenMW pulls ahead on interior load times.
SSD:
https://youtu.be/ujfksMA9HrE
HDD:
https://youtu.be/a5IYDxRrYOg

[scrawl]

Nice! For the record, the OpenMW build you have is from when the preloading feature wasn't completed yet, the latest master should be a bit smoother.
Also, to get an accurate result you should reboot in between tests, to make sure that the files are not cached by the operating system yet.

[psi29a]

This is just a vague guess.

Maybe the compiler (or even just the error checking tool that produces this error message) does not see the function prototype of xine_xmalloc_aligned. This would then implicitly assumed to have a return type of int.

That doesn't match exactly the error description, but it would certainly not be the first misleading error message in the C and C++ space.

Does adding the line

void *xine_xmalloc_aligned(size_t alignment, size_t size, void **base) XINE_PROTECTED;

before the definition of the rgbout_update_frame_format function change anything?

Your guess was on the money! Launchpad is uploading it now. The i386 was no problem but the amd64 build was the one triggering the error. It claims that it would automatically fail on ia64 arch... which well, is a dying architecture anyone. I'm glad this worked.

Any way that this could be sneaked in upstream? For now, I'll carry the patch and hopefully get it included in Debian for now.

Cheers!

[Zini]

Weird. This isn't building for me.

*** No rule to make target `/usr/lib/libosg.so', needed by `openmw'. Stop.

Either it is too early in the morning and I missed something obvious or something is wrong here (and yes, I did a full rebuild).

Any way that this could be sneaked in upstream? For now, I'll carry the patch and hopefully get it included in Debian for now.

This is only a workaround. Not sure if it would be appropriate to push it upstreams. The problem is either some idosyncracy of the xine build system that I didn't notice or a false positive in the detection tool.

Edit: It seems the so files are installed to /usr/lib/86_64-linux-gnu. Since the build script expects to find them in /usr/lib this can not work.

[corristo]

Mac build with cell preloading & fixed physics framerate:

https://dl.dropboxusercontent.com/u/284 ... cs-fix.dmg

[psi29a]

@scrawl & zini: osg 3.4 is now on the PPA, I rebuilt openmw and it seems to work like a charm. Going to do more tests later. This means that OSG 3.4 will be used on travis-ci now.

Thank you again for your help.

[Zini]

As mentioned above your package does not work for me. Completely breaks the build.

[scrawl]

@zini: I often see "No rule to make target..." errors when the cmake configuration is stale. You said that you did a full rebuild, but what does that mean? Run make clean? Try to erase CMakeCache.txt and CMakeFiles/ as well, if you haven't.

If that didn't work, have a look for openscenegraph-osg.pc files on your system, there might be some leftovers of osg 3.2 still around.

As a temporary measure, you can always install osg locally and use CMAKE_PREFIX_PATH, CMAKE_INCLUDE_PATH & CMAKE_LIBRARY_PATH to point openmw to it (I actually do this all the time since I often test changes to osg).

@psi29a: nice, I've hit rebuild on travis to see if the PR builds now.

[scrawl]

This means that OSG 3.4 will be used on travis-ci now.

It looks like there was an upload for Xenial and Wily, but none for Trusty, which travis-ci uses.

[Zini]

Cleaning out the old CMake files did help. However now I am getting a new error:

In file included from /usr/include/osgQt/GraphicsWindowQt:21:0,
from /home/marc/OpenMW/openmw/apps/opencs/view/render/scenewidget.cpp:9:
/usr/include/osgQt/Version:8:2: error: #error "Qt version mismatch detected! Make sure to compile applications using osgQt with the same major Qt version that osgQt has been compiled against."
#error "Qt version mismatch detected! Make sure to compile applications using osgQt with the same major Qt version that osgQt has been compiled against."

Am I reading the version file correctly? It requires Qt5? Not cool.