Update to support OGRE 1.10 & Bullet 2.86

Update to support OGRE 1.10 & Bullet 2.86

Postby LiamM32 » 18 Jun 2017, 00:27

I have recently been updating Lips of Suna to build with OGRE 1.10 and Bullet 2.86. I started doing this because these are the only versions of OGRE and Bullet available from the Manjaro repositories at the moment. But I also wanted to give Lips of Suna the performance improvements that come from OGRE 1.10.
I have committed my changes to a forked repository;
https://gitlab.com/electric-gecko/lipsofsuna

Although it builds without errors, I have been having trouble running it.
In the folder on my computer in which I was previously working on this, it would build successfully, but the program would segfault immediately when executing. Here is the output as I posted on this thread
{l Code}: {l Select All Code}
[liam@liam-desktop-Manjaro lipsofsuna-xenodora]$ ./lipsofsuna
connect(2) call to /dev/shm/jack-1000/default/jack_0 failed (err=No such file or directory)
attempt to connect to server failed
Segmentation fault (core dumped)

I don't know why Lips of Suna is trying to access JACK. I don't have it currently running.

However, I had to clone the git repository, so I had to make a new folder for the project on my computer. After copying some files from the old folder to the new one, a different problem happens. If I compile it here, it puts the lipsofsuna executable in .build/ rather than the base directory. I can't run it from there, as it wouldn't be able to access the data/ directory. If I move it to the base and execute it, I have the same error as above.

It would be nice if someone could help me with this.

I should note that I have not yet removed the deprecated OGRE functions. I want to get it working before I do that.
LiamM32
 
Posts: 54
Joined: 26 May 2014, 08:09

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby charlie » 19 Jun 2017, 09:57

Good to see you persevere with this. LoS is a project packed with potential, it just needs somebody pushing it.

The more you work with it, the more you'll understand these things. Sadly I can't offer an specific help/advice at the moment.

Also GitLab seems to be down which sucks - hopefully temporary!
Free Gamer - it's the dogz
Vexi - web UI platform
User avatar
charlie
Global Moderator
 
Posts: 2003
Joined: 02 Dec 2009, 11:56
Location: Manchester, UK

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby Julius » 19 Jun 2017, 11:39

Gitlab works for me now.

I agree it is a cool project that should continue... but the spaghetti code that seems to plague all ogre3d projects (see also SumWars, Stunt-Rally etc.) is just too strong it seems. The idea of Orge3D to be just a rendering engine and doing that well sounds good on paper, but for real continued game development you need a game engine. Most Ogre3D based projects seem to fail because it is just too much maintenance effort to keep everything together, resulting in what basically boils down to maintaining your own game engine project next to the game itself.

Maybe it is worth looking for some existing Ogre3D based game engine projects and trying to port LoS over to it if at all feasible?

Edit: Seems like there isn't an activly maintained and freely licensed game-engine project based on Ogre3D... a shame really, but maybe symptomatic of the above. Might be worth a look into Urho3D though, which claims and looks by a quick glance reasonably close to the Ogre3D setup in LoS: https://urho3d.github.io/ For sure not an easy task to port it over though.
“You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete” - Buckminster Fuller
User avatar
Julius
Community Moderator
 
Posts: 1942
Joined: 06 Dec 2009, 14:02

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby LiamM32 » 19 Jun 2017, 20:52

Julius {l Wrote}:I agree it is a cool project that should continue... but the spaghetti code that seems to plague all ogre3d projects (see also SumWars, Stunt-Rally etc.) is just too strong it seems. The idea of Orge3D to be just a rendering engine and doing that well sounds good on paper, but for real continued game development you need a game engine. Most Ogre3D based projects seem to fail because it is just too much maintenance effort to keep everything together, resulting in what basically boils down to maintaining your own game engine project next to the game itself.

Is Ogre3D bad? I never would have known, as I know barely any programming. In fact, I don't really know what I'm doing as I'm trying to upgrade the Ogre and Bullet version; I'm just making adjustments to functions to work with the newer versions, although I don't actually know what they do.

I agree that the Lips of Suna codebase is a mess. If I had some help, I would want most of the codebase to be rewritten, at-least the Lua side. I don't like the awkward combination of Lua and C++. I would want Lua to be replaced with a real object-oriented language like Squirrel, MiniD, or Anglescript.

I'm interested in the D programming language. It has a goal to be readable, and if I have learned anything from struggling to understand the Lips of Suna codebase, it's that readability matters. If I could change the C++ codebase to D, I suppose that I would need a D-compatible engine. Dash might be fine, but the last commit was December 2015. The only game I see that uses it probably has no physics, so I guess I would need to add Bullet support myself. Voxelman has had it's last commit less than 2 months ago.

Julius {l Wrote}:Edit: Seems like there isn't an activly maintained and freely licensed game-engine project based on Ogre3D... a shame really, but maybe symptomatic of the above. Might be worth a look into Urho3D though, which claims and looks by a quick glance reasonably close to the Ogre3D setup in LoS: https://urho3d.github.io/ For sure not an easy task to port it over though.

Interesting, but far from my capabilities.

If you are a programmer, could you please help me with the issue that I am talking about in this thread? I have been getting a segfault, but I don't know what to do about it. If I use GDB than it freezes and I need to go to a separate session to enter "pkill gdb".
LiamM32
 
Posts: 54
Joined: 26 May 2014, 08:09

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby LiamM32 » 26 Jun 2017, 09:21

I have some good news and some bad news.

After failing to make Lips of Suna run on after building on Bullet 2.86 (from Manjaro repositories), or even 2.85 (self-compiled), I got Bullet 2.86.1 from the Arch User Repository. Strange as it sounds, it actually works!

Now my next task was to replace the deprecated OGRE functions. This is where the bad news comes in.
Although it compiles fine, with the deprecated functions replaced with the newer functions, Lips of Suna crashes immediately. This happens even if I replace nothing but the one line in one file that Xenodora explained to me as an example.
xenodora {l Wrote}:The "unspecified_bool_type()" is a obfuscated way of saying it can be used as is in a statement or expression that expects a bool, so
{l Code}: {l Select All Code}
lisys_assert (!model->mesh.isNull ());
becomes
{l Code}: {l Select All Code}
lisys_assert (model->mesh);


Even if I have this changed and leave every other deprecated function as-is, I get the same output:
{l Code}: {l Select All Code}
lipsofsuna: ../../../../include/OGRE/OgreSharedPtr.h:280: T* Ogre::SharedPtr<T>::operator->() const [with T = Ogre::Material]: Assertion `pRep' failed.
Aborted (core dumped)


Anyone have any ideas? Maybe I should get help on the OGRE forum.

Do I need to replace the deprecated functions to get the full performance gains of OGRE 1.10? This is the assumption that I have been making. But the performance that I have gotten leaves much to be desired.

I want to overhaul the graphics later on. But I don't think I'll be motivated to do that without improving graphical performance first.
LiamM32
 
Posts: 54
Joined: 26 May 2014, 08:09

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby NaN » 26 Jun 2017, 11:19

For whatever reason they have an assert in the pointer operator. I guess that is why they have the extra isNull function. Why make things simple when one can make them complicated...

Is isNull deprecated?

Is mesh pointer being NULL expected behavior?
NaN
 
Posts: 150
Joined: 18 Jan 2010, 10:32

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby farrer » 26 Jun 2017, 13:43

As far as I remember there was a deprecation on the way Ogre resources are retrieved. Previously the default is to search on all groups, case insensitive, if a resource isn't found on a specific one. If you changed to the non-deprecated form, it will search on the defined resource group, case sensitively, and won't search on other groups if failed to load it from there.

Check if Ogre 1.10 was build with OGRE_RESOURCEMANAGER_STRICT CMake option (this is the new way). If it was, try disabling it and see if everything works again. If so, to work on the new mode you should check the way Lips Of Suna access resources and fix them to work with the new way - setting the correct group and case sensitive. Or just keep the deprecated.
User avatar
farrer
 
Posts: 77
Joined: 24 Feb 2014, 21:00

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby LiamM32 » 27 Jun 2017, 00:35

LiamM32 {l Wrote}:Although it compiles fine, with the deprecated functions replaced with the newer functions, Lips of Suna crashes immediately. This happens even if I replace nothing but the one line in one file that Xenodora explained to me as an example.

I must correct what I said. I reverted all those changes, and decided to try testing one change at a time, and it's working so far. With only the functions in render-material-utils.cpp and particle-model-system replaced, Lips of Suna runs fine.

I think I was getting confused before because waf was putting the lipsofsuna binary in .build/ rather than the immediate directory. I don't know why it's doing that now. It used to put it in the immediate directory.

There are some identifiers that Netbeans IDE cannot identify, such as "created.resize" in line 58 of particle-model-system.cpp.

I also notice that when I "Quit to desktop" in Lips of Suna, it reports a segmentation fault in the terminal output. Is this a problem, or is it just how programs close themselves?

farrer {l Wrote}:As far as I remember there was a deprecation on the way Ogre resources are retrieved. Previously the default is to search on all groups, case insensitive, if a resource isn't found on a specific one. If you changed to the non-deprecated form, it will search on the defined resource group, case sensitively, and won't search on other groups if failed to load it from there.

What is an example of a "resource" in Ogre? I don't know what lines I must change.

NaN {l Wrote}:Is isNull deprecated?

Yes; it's deprecated.
LiamM32
 
Posts: 54
Joined: 26 May 2014, 08:09

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby LiamM32 » 27 Jun 2017, 09:21

farrer {l Wrote}:Check if Ogre 1.10 was built with OGRE_RESOURCEMANAGER_STRICT CMake option (this is the new way). If it was, try disabling it and see if everything works again. If so, to work on the new mode you should check the way Lips Of Suna access resources and fix them to work with the new way - setting the correct group and case sensitive. Or just keep the deprecated.

You must mean that Lips of Suna should be built with OGRE_RESOURCEMANAGER_STRICT, not the OGRE libraries. Is that right?

I tried building Lips of Suna with this macro, and it builds and runs fine. The performance doesn't seem to be much better. What is it that I must change exactly in the Lips of Suna codebase to take advantage of this? Given my lack of "common-sense" with C++ and OGRE, you will have to be quite specific for me to understand. You will need to describe to me what the lines I must change will look like, and tell me the exact names of the functions, parameters, and variables that I must change.

Edit: It would be very, very nice if someone else here just volunteered to help me with this; someone who actually knew what they were doing (which I don't). I want to optimize the performance of this game before making other changes.
LiamM32
 
Posts: 54
Joined: 26 May 2014, 08:09

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby GunChleoc » 27 Jun 2017, 11:47

LiamM32 {l Wrote}:I also notice that when I "Quit to desktop" in Lips of Suna, it reports a segmentation fault in the terminal output. Is this a problem, or is it just how programs close themselves?

That's a bug https://en.wikipedia.org/wiki/Segmentation_fault

If you're on Linux, the easiest was to debug this is to install gdb https://www.gnu.org/software/gdb/

Then type

{l Code}: {l Select All Code}
gdb build/<name_of_binary>
run


When you get the segfault, type
{l Code}: {l Select All Code}
backtrace

To find out where the segfault is coming from.
User avatar
GunChleoc
 
Posts: 271
Joined: 20 Sep 2012, 22:45

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby farrer » 27 Jun 2017, 12:48

LiamM32 {l Wrote}:You must mean that Lips of Suna should be built with OGRE_RESOURCEMANAGER_STRICT, not the OGRE libraries. Is that right?


No, it's a variable for building Ogre, not LoS. But if it is working now, it for sure isn't it the problem, thus I'll recommend to just leave it as it is.

LiamM32 {l Wrote}:The performance doesn't seem to be much better. What is it that I must change exactly in the Lips of Suna codebase to take advantage of this? Given my lack of "common-sense" with C++ and OGRE, you will have to be quite specific for me to understand. You will need to describe to me what the lines I must change will look like, and tell me the exact names of the functions, parameters, and variables that I must change.


That build macro for Ogre will affect only resource loading times, not performance overall. Almost all changes on Ogre's 1.x branch aren't related to performance. For performance refactoring there's the 2.1 branch, with huge performance gains (the 2.x branch is focused on removing bottlenecks from Ogre's). But, unfortunately, as LoS seems to use a lot of very particular shaders, it'll probably be a HUGE task to port the code to Ogre's 2.1 branch. I wouldn't recommend doing that unless you known both Ogre and LoS very well.

LiamM32 {l Wrote}:Edit: It would be very, very nice if someone else here just volunteered to help me with this; someone who actually knew what they were doing (which I don't). I want to optimize the performance of this game before making other changes.


I would recommend checking which are LoS bottlenecks: CPU or GPU? LoS', Ogre's or Bullet's code? The approach to optimize the performance depends a lot on what is causing the performance lost, and anyone who'll check this must before check what is causing that. Otherwise, you could be trying to optimize something that isn't the current LoS' bigger bottleneck actually.
User avatar
farrer
 
Posts: 77
Joined: 24 Feb 2014, 21:00

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby LiamM32 » 27 Jun 2017, 21:25

farrer {l Wrote}:I would recommend checking which are LoS bottlenecks: CPU or GPU? LoS', Ogre's or Bullet's code? The approach to optimize the performance depends a lot on what is causing the performance lost, and anyone who'll check this must before check what is causing that. Otherwise, you could be trying to optimize something that isn't the current LoS' bigger bottleneck actually.

I think it's very likely CPU-bound, as the FPS counter often reports over 120 but there's an occasional very long frame. How do I actually measure where the bottlenecks lie?

farrer {l Wrote}:But, unfortunately, as LoS seems to use a lot of very particular shaders, it'll probably be a HUGE task to port the code to Ogre's 2.1 branch.

I would rather learn GLSL and write better shaders before porting to OGRE 2.1.
LiamM32
 
Posts: 54
Joined: 26 May 2014, 08:09

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby farrer » 28 Jun 2017, 12:14

LiamM32 {l Wrote}:I think it's very likely CPU-bound, as the FPS counter often reports over 120 but there's an occasional very long frame. How do I actually measure where the bottlenecks lie?


As you believe it is CPU-bounded, either profile with the help of a C++ profiler, or add on the code some timers to measure how much time each relevant code part takes on each frame.

LiamM32 {l Wrote}:I would rather learn GLSL and write better shaders before porting to OGRE 2.1.


I not saying the LoS shaders are good or bad written. I'm saying that porting Ogre's 1.x projects to 2.1 would be a huge task if they rely a lot on custom shaders. You should read some porting reports that are on Ogre's 2.x sub-forum to see the kind of work and common problems people had when porting their code. But, in my opinion, on the near sight future it's better for you to stick with Ogre's 1.x until you have both better understanding of LoS' code and the way it uses Ogre... The better you known both, the easer will be the task.
User avatar
farrer
 
Posts: 77
Joined: 24 Feb 2014, 21:00

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby LiamM32 » 29 Jun 2017, 07:19

farrer {l Wrote}:As you believe it is CPU-bounded, either profile with the help of a C++ profiler, or add on the code some timers to measure how much time each relevant code part takes on each frame.

Could you please help me with this? Feel free to to do a merge request over to my repository on Gitlab, even if you just add the initial support.
I really don't know how to set this up. This project uses waf, which will make it hard for me to find guides on the internet.

farrer {l Wrote}:I not saying the LoS shaders are good or bad written. I'm saying that porting Ogre's 1.x projects to 2.1 would be a huge task if they rely a lot on custom shaders.

What I'm saying is that I don't like the way the game looks. When I overhaul the visuals, the shaders are one of the things I want to change to make it look better.
If I use GLSL, then will it be portable between OGRE versions and even other engines?

I just want to first bring Lips of Suna to OGRE 1.10 and have significantly better performance so that I feel like it's worth upgrading the visuals. I might raise the polycount on models, but I don't want it to have even worse performance than currently. If it ever goes to OGRE 2.0 and beyond, it can happen after I change the graphics.
LiamM32
 
Posts: 54
Joined: 26 May 2014, 08:09

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby farrer » 29 Jun 2017, 12:53

LiamM32 {l Wrote}:Could you please help me with this? Feel free to to do a merge request over to my repository on Gitlab, even if you just add the initial support.
I really don't know how to set this up. This project uses waf, which will make it hard for me to find guides on the internet.


It's not hard to use a profiler. Install vallgrind and kcachegrind in your linux distribution.

Make sure you compiled LoS with debug symbols (-g option of g++, I'm not familiar with waf, but it should have a way to set the gcc flags).

Run the LoS binary with vallgrind callgrind tool (note that I'm not sure of the LoS binary executable name and assumed to be 'lipsofsuna'):
{l Code}: {l Select All Code}
valgrind --tool=callgrind ./lipsofsuna


It will generate a callgrind.out.xyz file. Open that with kcachegrind and have fun! Look at valgrind manual for more complete guide (specially on how to just start the profiler when the main looping is executing, otherwise your output would be dirty with a lot of loading functions, which isn't the main problem for you, I believe). Feel free to ask something you didn't understand, I'll try to answer.

LiamM32 {l Wrote}:What I'm saying is that I don't like the way the game looks. When I overhaul the visuals, the shaders are one of the things I want to change to make it look better.
If I use GLSL, then will it be portable between OGRE versions and even other engines?

I just want to first bring Lips of Suna to OGRE 1.10 and have significantly better performance so that I feel like it's worth upgrading the visuals. I might raise the polycount on models, but I don't want it to have even worse performance than currently. If it ever goes to OGRE 2.0 and beyond, it can happen after I change the graphics.


I would suggest you to not use specific shaders at all (at least for now). It'll make a lot easer to port to 2.1 if you willing to. If you are planing to use another engine, it's better to use the specific engine's way (if it will be glsl, great, but depending of the engine, it could not be the case). One step at a time.
User avatar
farrer
 
Posts: 77
Joined: 24 Feb 2014, 21:00

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby LiamM32 » 30 Jun 2017, 02:47

farrer {l Wrote}:It will generate a callgrind.out.xyz file. Open that with kcachegrind and have fun! Look at valgrind manual for more complete guide (specially on how to just start the profiler when the main looping is executing, otherwise your output would be dirty with a lot of loading functions, which isn't the main problem for you, I believe).

First I tried using callgrind with the exact command that you gave me. Lips of Suna ran far slower than usual. The loading times were dramatically longer. The in-game FPS counter reported 1 FPS, but I feel like it may have actually been even slower (maybe that's the lowest it can report). Anyway, after the scene seemed to be loaded, after a few seconds of moving my character, I exit the game.

Here is a screenshot of KCachegrind:
Screenshot_20170629_180409.png
First view of KCachegrind

Is it saying that lua_pcall is the main bottleneck? This function is in /usr/include/lua.h, so I assume that it's an interface between Lua and C. Does this mean that the main bottleneck is in the Lua side of the codebase, not the C/C++?

Afterward, I went to the valgrind manual and read this. So I tried entering this;
{l Code}: {l Select All Code}
valgrind --tool=callgrind --instr-atstart=no ./lipsofsuna

First I was having trouble because I then entered "callgrind_control -i on" in the same terminal, so I ended up with 0 collected events. It turns out that I had to enter it in a different terminal.

Here is what KCachegrind looks like now:
Screenshot_20170629_190618.png
Second view of KCachegrind


I have attached the Callgrind output file for my second try of valgrind, with the limited range of collected events. I would include the other one, but I had trouble uploading probably because of it's size.
Attachments
callgrind.out.16884.txt
Second try at valgrind, with limited range of collected events.
(1.44 MiB) Downloaded 12 times
LiamM32
 
Posts: 54
Joined: 26 May 2014, 08:09

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby NaN » 30 Jun 2017, 11:27

Going by your screenshot the game spends most of the time in decoding sound (ov/vorbis) and handling physics (bt).

If the sounds are short it might be worth decoding them once and caching.

In physics compound vs compound collisions seem to be the worst offender. Is the game using many compound bodies and how complex are they?
NaN
 
Posts: 150
Joined: 18 Jan 2010, 10:32

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby farrer » 30 Jun 2017, 13:19

I agree with NaN and you should check the complexity of the physics primitives used and the possibility to cache at least some of the small sounds.

Besides that, one more thing seems strange to me:

file: ext-module.c
{l Code}: {l Select All Code}
void liext_parallel_update_physics_and_render (LIExtParallel* self,   float  secs)
{
(...)
   /* Find the components. */
   physics = limai_program_find_component (self->program, "physics");
   render = limai_program_find_component (self->program, "render");

   if (physics != NULL && render != NULL)
   {
      params.physics = physics;
      params.secs = secs;
      thread = lisys_thread_new (private_physics_main, &params);
      liren_render_render (render);
      if (thread != NULL)
         lisys_thread_free (thread);
   }
   (...)
}


This is the function called every frame, and it seems to create - every frame - a new thread for every physics step and wait until it finishes. It makes more sense to just create the thread once and use it to step really in parallel. Otherwise, the frame rendering is limited by the physics thread. Anyway, it worth more now to check the primitives complexity and the sound caching before changing the logic here.

BTW, on a quick look, LoS' code seems well documented/commented: that makes the task of trying to understand it a lot easer.
User avatar
farrer
 
Posts: 77
Joined: 24 Feb 2014, 21:00

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby LiamM32 » 01 Jul 2017, 22:52

I thank both of you for you're suggestions. While the details that you give are much appreciated, I am still in need of another person that can edit the codebase; someone that can write code. I don't really understand how the Lips of Suna or any game engine works. What I have done so far is pretty much removing unneeded parameters from function calls, and replacing deprecated OGRE functions with the suggested drop-in replacements. While I have the very basics of the C++ syntax down (although I still must frequently look stuff up), It's still very hard for me to figure out how the whole system works. I'm not really ready for fairly complex edits.

Please don't feel discouraged from the advice that you have given though. But I still don't expect to achieve much when I'm the only person touching the code. I might learn from seeing the changes that someone else makes.

NaN {l Wrote}:If the sounds are short it might be worth decoding them once and caching.

In physics compound vs compound collisions seem to be the worst offender. Is the game using many compound bodies and how complex are they?

Making a sound cache is definately outside my capabilities. But it would be of very great help if you did this for me.
I should note that the music in the game doesn't have any stuttering issues, unlike the graphics. I would have to listen again to know how the effects sounds are.
Don't some games use uncompressed audio to reduce CPU usage? This may be worth it for short "effects" sounds.

As for the physics, what exactly are "compound bodies"?
I can look at the collision meshes to find if any are too complex.

farrer {l Wrote}:file: ext-module.c
[liext_parallel_update_physics_and_render] is the function called every frame, and it seems to create - every frame - a new thread for every physics step and wait until it finishes. It makes more sense to just create the thread once and use it to step really in parallel. Otherwise, the frame rendering is limited by the physics thread.

I remember when I took the video game programming class at my school that the teacher got us to write code that updates the physics "once per frame". I thought it was strange that the physics are updated synchronously with the graphics, so that the CPU and GPU can slow each-other down. But I just got the impression that this is how it's generally done.

I don't know how to fix this. May you please make an edit?

Here's the page on GitLab: https://gitlab.com/electric-gecko/lipsofsuna
LiamM32
 
Posts: 54
Joined: 26 May 2014, 08:09

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby LiamM32 » 01 Jul 2017, 23:53

I can confirm that the sound is a big slowdown for Lips of Suna.

I am away on a family trip right now, so I don't have my fancy desktop. But on my laptop, I downloaded the latest Lips of Suna from my git repository and compiled without sound "./waf configure --disable-sound". The game is now running without framerate drops, at a stable 60fps (as reported in-game). This is a 1.8GHz dual-core laptop with integrated graphics vs a 3.2GHz quad-core desktop with Nvidia GTX 960.

However, after a minute of playing, it segfaulted. Here's the output:
{l Code}: {l Select All Code}
[liam@liam-laptop-manjaro lipsofsuna]$ ./lipsofsuna
userdata: 0x2b6be08
2017-07-01T15:42:47Z: Started global event "brigand camp"
2017-07-01T15:42:47Z: Started global event "random monsters"
2017-07-01T15:42:48Z: Client login from "localhost" using account "local".
ERROR: ui/widgets/stat.lua:45: bad argument #2 to 'format' (number has no integer representation)
stack traceback:
        [C]: in function 'string.format'
        ui/widgets/stat.lua:45: in function 'ui/widgets/stat.rebuild_canvas'
        ui/widgets/widget.lua:78: in function 'ui/widgets/widget.update'
        ui/widgets/stat.lua:54: in function 'ui/widgets/stat.update'
        ui/ui.lua:670: in function 'ui/ui.update'
        ui/window-manager.lua:103: in function 'ui/window-manager.update'
        ui/main.lua:21: in field 'hook'
        system/hooks.lua:35: in function 'system/hooks.call'
        core/client/client.lua:158: in function 'core/client/client.update'
        core/client/init.lua:38: in field 'hook'
        system/hooks.lua:35: in function 'system/hooks.call'
        main/main.lua:122: in method 'main'
        main.lua:6: in main chunk
Segmentation fault (core dumped)


EDIT: I discovered that LuaJIT wasn't installed on my laptop, so it was using Lua 5.3 instead. It appears to be a type error, like there must of been a floating-point value of a variable that was meant to be integer. Lua 5.3 appears to favour floating points; when I checked the screen resolution options, the numbers all ended in ".0".
Although the screen resolution do not end in ".0" when compiled in LuaJIT, I still have those crashes.
LiamM32
 
Posts: 54
Joined: 26 May 2014, 08:09

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby NaN » 02 Jul 2017, 09:28

Bullet physics has debug drawing support. You have to provide a couple of functions: draw lines etc. It can be used to draw the collision shapes.

Bullet also supports fixed time steps with interpolation. So you can ran physics at some fixed target fps.


One would have to look into how sound decoding is implemented. There is typically some buffering involved. If buffering is done per sound, increasing buffer size so that short sounds are fully decoded might do the trick.

If LOS supports loading uncompressed sounds, you might as well try converting them.


I wouldn't mind to have a look, but the projects looks rather complex (easy to break things if you don't fully understand what is going on).
NaN
 
Posts: 150
Joined: 18 Jan 2010, 10:32

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby NaN » 02 Jul 2017, 11:06

Looking at the code, you should be able to enable physics debug drawing by pressing 'L' key. It will draw collision shape wireframes and contact points.
NaN
 
Posts: 150
Joined: 18 Jan 2010, 10:32

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby NaN » 02 Jul 2017, 11:29

I also had a quick look at the sound code. It looks like the sound samples are always fully decoded, there is no streaming. So the question would be why the decoder appears in the profiler.

It could be that it is constantly reloading them. Btw loading seems to happen in a separate thread.
NaN
 
Posts: 150
Joined: 18 Jan 2010, 10:32

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby charlie » 03 Jul 2017, 09:43

Liam32: I would post in the Showcase & Collaboration. Post a thread asking for programmers and artists, give some background and some information on your own goals with the project. Call it "Lips of Suna Revival" or something to that effect.
Free Gamer - it's the dogz
Vexi - web UI platform
User avatar
charlie
Global Moderator
 
Posts: 2003
Joined: 02 Dec 2009, 11:56
Location: Manchester, UK

Re: Update to support OGRE 1.10 & Bullet 2.86

Postby GunChleoc » 05 Jul 2017, 09:37

LiamM32 {l Wrote}:First I tried using callgrind with the exact command that you gave me. Lips of Suna ran far slower than usual. The loading times were dramatically longer. The in-game FPS counter reported 1 FPS, but I feel like it may have actually been even slower (maybe that's the lowest it can report). Anyway, after the scene seemed to be loaded, after a few seconds of moving my character, I exit the game.

This is normal, because Valgrind itself uses up a lot of performance, slowing down your machine.
User avatar
GunChleoc
 
Posts: 271
Joined: 20 Sep 2012, 22:45

Who is online

Users browsing this forum: No registered users and 1 guest