openmw.org

Are we going to do something about the game whimsically defaulting to OpenGL every time you run it?

Do you mean a previous selection of DirectX is ignored? By the Launcher? By OpenMW? Please be more precise in your error descriptions.

On windows, if I set the Rendering Subsystem to Direct X it works the first time. If I run the game again, through the launcher or the binary, rendering defaults to OpenGL, even though the launcher claims it still is Direct X. In other words, in order to use Direct X, I have to unset it and set it again through the launcher every time I have to run the game. This has been the case for a while now, and I think other people have mentioned it as well.

Okay. That is a bug. Probably a launcher problem, which is bad, because our launcher guy is currently not available for a couple more days.

Is this affecting only the renderer selection or also other graphics settings? I assume after running the launcher the second time, your user openmw.cfg file has OpenGL selected?

I thought it was the game doing it but it is indeed the launcher. If I run the launcher, and don't explicitly set Direct X, even if Direct X is already selected, it defaults to OpenGL once the launcher is closed.

BrotherBrick wrote: Please test, I'm getting a segmentation fault on openmw startup.

I'm getting the same issue with your build, and I don't get it with mine, so I assume you are doing something wrong.

werdanith wrote:

BrotherBrick wrote: Please test, I'm getting a segmentation fault on openmw startup.

I'm getting the same issue with your build, and I don't get it with mine, so I assume you are doing something wrong.

Weird thing is that I can compile it on my main machine.. no problems. But when I compile on my chroot env, it gives me a seg fault. Will investigate further... library issue likely, but it seems weird.

In my chroot I get this when running:

root@zwartevogel:/home/openmw# ./openmw
terminate called after throwing an instance of 'std::runtime_error'
what(): locale::facet::_S_create_c_locale name not valid
Aborted

Ever seen this before?

Googled it.. and it seems boost related with patches going into 1.47 to fix it.

https://svn.boost.org/trac/boost/ticket/4688

will validate

update: here are two (workign) packages.... for oneiric 64b. no 32b as of yet.
http://dl.dropbox.com/u/396161/openmw_0 ... _amd64.deb
http://dl.dropbox.com/u/396161/openmw_0 ... d64.tar.gz

@werdanith I think i know what happened, k1ll just informed me he downgraded the packages from the scrawl hackedup 1.8.0 rc1 to the standard 1.8.0rc1. As a result, we AND ALL users who use the ppa have to do a purge to remove libogre-1.8.0 and then do an update, then an install in order to 'downgrade'.

rc3 (oneiric) releases--

deb:
http://dl.dropbox.com/u/396161/openmw_0 ... _amd64.deb
http://dl.dropbox.com/u/396161/openmw_0 ... 3_i386.deb

tgz:
http://dl.dropbox.com/u/396161/openmw_0 ... d64.tar.gz
http://dl.dropbox.com/u/396161/openmw_0 ... 386.tar.gz

Ok, I'm not sure I see the shadows. Wasn't aware of them, but I'll look into it. Are they dynamic? I don't see anything (on the ground) moving when I set the sun to move across the sky very fast. If they are static cast sort of "straight down" I think I see them but they seem to be much softer than I was expecting, sort of like an exaggerated SSAO effect.
EDIT: I've noticed that shadows won't stay enabled in my user openmw settings file. I enable them, save, start the game, exit, open the file again and it says "enabled = false". Any word on this?
Yeah, I just mean the settings manager doesn't have a GUI yet. Bad description on my part, but noted.
I planned to demo the item pick up =)
I will show that pathgrids can be rendered, and say what they are used for when they are functional.

Also question: did Occlusion Query improve the way the sun is obscuring behind objects? Because that seems to be behaving much better for me.

I need some cmake tuning for successful build & packaging, I hope I'll finish today & do pull request and rc build