FreeGameDev

Hi!

hwoarangmy has done two patches, could you try them?
https://github.com/hwoarangmy/OpenDunge ... d98af67621
https://github.com/hwoarangmy/OpenDunge ... 4cbec3dd8e
The second depends on the first.

If it's ok for your build as well, I'll merge all that.

Could you help properly adding h* repository and checkouting ?

[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = https://github.com/Bertram25/OpenDungeons.git
fetch = +refs/heads/*:refs/remotes/origin/*
[remote "hwoarangmy"]
url = https://github.com/hwoarangmy/OpenDungeons.git
fetch = +refs/heads/*:ref/remotes/hwoarangmy/*

[branch "development"]
remote = origin
merge = refs/heads/development

Have you tried this?

{l Code}: {l Select All Code}

[remote "hwoarangmy"]
url = https://github.com/hwoarangmy/OpenDungeons.git
fetch = +refs/heads/*:ref/remotes/origin/*

Will you fix back the vector3i class or should I refix it?

I tried the hw** commits . The code builds and runs , however it is REALLY choppy, as mentioned by hw* ( on the same settings , origin development branch is doing 4x faster >_> )

hwoarangmy !,

Naah there were many people coming in here and asking for help , but in the end it ended up on nothing , as their zeal was based on sand .

paul424 {l Wrote}:on the same settings , origin development branch is doing 4x faster

Are you compiling in debug ? The changes in the Mafiles just uses debug libraries for debug versions (for CEGUI and SFML). With windows, it crashes if you mix release and debug libs. Maybe it is not the case with linux. I never tried.

paul424 {l Wrote}:hwoarangmy !,

Naah there were many people coming in here and asking for help , but in the end it ended up on nothing , as their zeal was based on sand .

Sorry, I don't get what you mean.

About the 4x faster problem.
I wondered. Should the OD_USLEEP define divide t per 1000 just like it does a few lines above or not?

No idea , what that code is supposed to do as it's not mine. ...

{l Code}: {l Select All Code}

/*
 * sleep.h  1.0 02/03/10
 *
 * Defines cross-platform sleep, usleep, etc.
 *
 * By Wu Yongwei
 *
 * All code here is considered in the public domain though I do wish my
 * name could be retained if anyone uses them. :-)
 *
 */

#ifndef _SLEEP_H
#define _SLEEP_H

#ifdef _WIN32
# if defined(_NEED_SLEEP_ONLY) && (defined(_MSC_VER) || defined(__MINGW32__))
#  include <cstdlib>
#  define sleep(t) _sleep((t) * 1000)
# else
#  include <windows.h>
#  define sleep(t)  Sleep((t) * 1000)
# endif
# ifndef _NEED_SLEEP_ONLY
#  define msleep(t) Sleep(t)
#  define usleep(t) Sleep((t) / 1000)
# endif
#else
# include <unistd.h>
# ifndef _NEED_SLEEP_ONLY
#  define msleep(t) usleep((t) * 1000)
# endif
#endif

#endif /* _SLEEP_H */


Hmm, let's wait for hwoarangmy's thought about it.

Hi,

As you know, I am not sleep.h's author. But it is an utility file that helps to make multiplatform programs by redefining the sleep methods so that they do the same. For example, for windows, Sleep(t) sleeps for t milliseconds. For linux, sleeps(t) sleeps for t ms.
With this file, sleep(t) always sleeps for t secs, usleeps(t) sleeps for t usecs...

But in an utility file, it never is a good idea to use in macros such simple words as sleep, wait, push... as it is common to use thoses words for methods names. In that case, it can lead to compilation problems like the one I have been facing (the reason why I changed this file). In utility file, it is better to use macros with name with capital letters and even better to make them start with letters related to the project to make sure they will not conflict with other functions later.
That's why I changed all the sleep macros to OD_SLEEP. And if you want to use sleep, it would be nice to use them as they will be multiplatform.

Bertram {l Wrote}:About the 4x faster problem.
I wondered. Should the OD_USLEEP define divide t per 1000 just like it does a few lines above or not?

Definitely not. OD_USLEEP(t) should always wait for t usecs. If u think it is too much somewhere, you should decrease the argument number.

But again, the changes I've made where only to resolve compilation issues (as explained in the "Typical dev environment under windows" thread). As you can imagine, I have reviewed the code after seeing this thread and AFAIK, this modification doesn't change anything on the sleep times.

The only change I made that can slow down the game is using the CEGUI/OGRE/SFML debug libraries when debugging if they are available. But if you didn't compile them in debug, there should be no change.

Definitely not. OD_USLEEP(t) should always wait for t usecs. If u think it is too much somewhere, you should decrease the argument number

Ok. I must say I didn't check that one carefully.
For the record, please never take my comments as offenses, it was never meant, and will not meant to be ones when speaking of code and such.

@Paul:
Hwoarangmy's changes should indeed not change anything. I don't have any speed changes in release or releaseWithDebugInfo mode (used to get debug info from OD only, in my case).
The debug slowness is no wonder though, since the binary must be completely unoptimized.

Something interesting would be to use gprof on a slow binary btw, we might get some info on interesting bottlenecks.

Regards,

Bertram {l Wrote}:For the record, please never take my comments as offenses, it was never meant, and will not meant to be ones when speaking of code and such.

I didn't take your comments as offense, I was just saying that a function called wait_1_second should wait... 1 second
And your comments are welcome

Cool!