hw** commits proposals

hw** commits proposals

Postby Bertram » 10 May 2014, 09:53

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.
User avatar
Bertram
VT Moderator
 
Posts: 1649
Joined: 09 Nov 2012, 12:26

Re: Tile Culling -- SlopeWalk alg. explained

Postby paul424 » 11 May 2014, 12:31

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
User avatar
paul424
OD Moderator
 
Posts: 644
Joined: 24 Jan 2012, 13:54

Re: Tile Culling -- SlopeWalk alg. explained

Postby Bertram » 12 May 2014, 09:28

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?
User avatar
Bertram
VT Moderator
 
Posts: 1649
Joined: 09 Nov 2012, 12:26

Re: hw** commits proposals

Postby paul424 » 12 May 2014, 16:38

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 >_> )
User avatar
paul424
OD Moderator
 
Posts: 644
Joined: 24 Jan 2012, 13:54

Re: hw** commits proposals

Postby paul424 » 12 May 2014, 22:40

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 .
User avatar
paul424
OD Moderator
 
Posts: 644
Joined: 24 Jan 2012, 13:54

Re: hw** commits proposals

Postby hwoarangmy » 12 May 2014, 23:06

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.
hwoarangmy
 
Posts: 567
Joined: 16 Apr 2014, 19:13

Re: hw** commits proposals

Postby Bertram » 12 May 2014, 23:33

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?
User avatar
Bertram
VT Moderator
 
Posts: 1649
Joined: 09 Nov 2012, 12:26

Re: hw** commits proposals

Postby paul424 » 12 May 2014, 23:35

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 */
User avatar
paul424
OD Moderator
 
Posts: 644
Joined: 24 Jan 2012, 13:54

Re: hw** commits proposals

Postby Bertram » 12 May 2014, 23:37

Hmm, let's wait for hwoarangmy's thought about it.
User avatar
Bertram
VT Moderator
 
Posts: 1649
Joined: 09 Nov 2012, 12:26

Re: hw** commits proposals

Postby hwoarangmy » 13 May 2014, 14:05

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.
hwoarangmy
 
Posts: 567
Joined: 16 Apr 2014, 19:13

Re: hw** commits proposals

Postby Bertram » 13 May 2014, 15:33

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,
User avatar
Bertram
VT Moderator
 
Posts: 1649
Joined: 09 Nov 2012, 12:26

Re: hw** commits proposals

Postby hwoarangmy » 13 May 2014, 23:14

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 :)
hwoarangmy
 
Posts: 567
Joined: 16 Apr 2014, 19:13

Re: hw** commits proposals

Postby Bertram » 14 May 2014, 08:04

Cool! :)
User avatar
Bertram
VT Moderator
 
Posts: 1649
Joined: 09 Nov 2012, 12:26

Who is online

Users browsing this forum: No registered users and 1 guest