• All, Gmail is currently rejecting messages from my host. I have a ticket in process, but it may take some time to resolve. Until further notice, do NOT use Gmail for your accounts. You will be unable to receive confirmations and two factor messages to login.

Developing For OpenBOR

Yeah!!
Ok guys, I'm preparing a BIG update!!
ALL getanimationproperty incoming + some fixes!!


Ps. any help to compile openbor for Linux under Windows?
 
I can compile a Linux build when the code is up. Though I'm not sure it will work universally. Last time I shared a Linux build around here I had reports it didn't work, never figured why.
 
Piccolo said:
I can compile a Linux build when the code is up. Though I'm not sure it will work universally. Last time I shared a Linux build around here I had reports it didn't work, never figured why.
Click to expand...

Can you help me to compile the Linux rev on Windows Piccolo?
Tnx
 
Hum nope sorry, I never tried to compile a Linux build under Windows. Not sure it's really possible actually, as they are a lots of deps.

I compile Linux builds from my Linux system (and Windows build from my Windows system).
 
Thank you Piccolo, when I complete some other function to openbor I ask you a Linux version. Tnx.
PS.  If you want to try it I completed all   
Getanimationproperty yet + some fix, a little improvement and the pause.wav on sourceforce
 
Hi White Dragon,

You forgot to check in the new files you created in 4173.

Also, is there an advantage to using our own implementations of the trig functions over using the ones from the standard C library?
 
Plombo said:
Hi White Dragon,

You forgot to check in the new files you created in 4173.

Also, is there an advantage to using our own implementations of the trig functions over using the ones from the standard C library?
Click to expand...

Ok Plombo, check the rev4175.
Tested and working!!

Yes there is a BIG advantage to use these new math functions!! asin, acos, atan are approximated to do fast calculate for game refreshing.
Standard c lib is too slow for a game and the functions of the standard library have a computational cost too high!!
I used the approximations used by Apple  ;)

An IMPORTANT NOTE FOR DEVELOPERS:
Old function searchList used to map the string was bugged (and a computational cost not good).
Now I replaced it with a binary search! More fast.
According to the code all the lists that were mapped from the old algorithm (and new one too), are assumed to be sorted alphabetically!!!!
Very often I found order errors (not sort) which I proceeded to fix. I hope you find them all, but you never know...
That's why sometimes some properties were not working and sometimes worked too for the wrong searchlist algorithm.
Check it.


Ps. Now I'm writing some update for filestream!  ;)
 
White Dragon said:
Ok Plombo, check the rev4175.
Tested and working!!
Click to expand...

I'm on r4175 and they're still not there. It works for you because the files exist in your working copy, but they're not in SVN.
 
Looking good guys. I'll post up a devbuild Wednesday - there are lots of bugfixes and goodies. Thanks to our new contributors!

DC
 
One more question about the new math code: where did it come from? From a quick Google search, it seems to be based on Apple's libm implementation. (Edit: I didn't notice you already said it was from Apple.) Which re-raises my earlier question -- if this code comes from a C library implementation, why is it faster or better than the version in other C libraries?

glibc (Linux), newlib (consoles), and OS X have optimized assembly versions of these functions in libm for each architecture they support, and Windows probably does too.
 
I know that sin/cos/tan and asin/acos/atan for standard lib is precise, because if I remember correctly, the algorithm is developed entirely with the Taylor series taking on a greater computational cost because it uses loops enough to be accurate.
longer loops == more accurately.
look at that code instead. no loops!
it seems that the apple uses a good compromise between accuracy and speed with computational cost O(1).
Fantastic!!
doing some testing with the calculator of my Android, precision sin/cos (standard lib) is really low!
Essentially, that approximations provide an excellent result for me!!

Ps. online new rev with new filestreams flags!  ;)

Damon Caskey said:
Looking good guys. I'll post up a devbuild Wednesday - there are lots of bugfixes and goodies. Thanks to our new contributors!

DC
Click to expand...

Tnx DC!
 
Hey WD, while you are at it, let ask you two things:

1- its possible to fix the weapon block bug? When you are into a weapon, block won't work - even scripted one.

2- can you take a look at some undocumented things like this? http://www.chronocrash.com/forum/index.php?topic=2022.msg40826#msg40826

There are some aimove and other things I that I wanted to know more about.
 
White Dragon said:
I know that sin/cos/tan and asin/acos/atan for standard lib is precise, because if I remember correctly, the algorithm is developed entirely with the Taylor series taking on a greater computational cost because it uses loops enough to be accurate.
longer loops == more accurately.
look at that code instead. no loops!
Click to expand...

The Apple code you're using is from a standard C library implementation. It has the same precision as any standard C library call. And other C library implementations don't use Taylor series - they use similar approximations. For example, this is the non-assembly atan implementation used in glibc, uclibc, and newlib. Note that, just like in the Apple code, there are no loops.
 
Plombo said:
White Dragon said:
I know that sin/cos/tan and asin/acos/atan for standard lib is precise, because if I remember correctly, the algorithm is developed entirely with the Taylor series taking on a greater computational cost because it uses loops enough to be accurate.
longer loops == more accurately.
look at that code instead. no loops!
Click to expand...

The Apple code you're using is from a standard C library implementation. It has the same precision as any standard C library call. And other C library implementations don't use Taylor series - they use similar approximations. For example, this is the non-assembly atan implementation used in glibc, uclibc, and newlib. Note that, just like in the Apple code, there are no loops.
Click to expand...

BTW I made comparisons with the version of Android 4.1.1 and I had my best result.
apple code is better than android code for example.

O Ilusionista said:
Hey WD, while you are at it, let ask you two things:

1- its possible to fix the weapon block bug? When you are into a weapon, block won't work - even scripted one.

2- can you take a look at some undocumented things like this? http://www.chronocrash.com/forum/index.php?topic=2022.msg40826#msg40826

There are some aimove and other things I that I wanted to know more about.
Click to expand...

Can you do an example?
 
Don't worry about the block bug - it was fixed by me and committed to source a long time ago, I just hadn't posted a build.

DC
 
Damon Caskey said:
Don't worry about the block bug - it was fixed by me and committed to source a long time ago, I just hadn't posted a build.

DC
Click to expand...

So It's fixed yet?

Ps. Fixed the NOSAME bug
Now you can use:
NOSAME 1
NOSAME 1 2
NOSAME 0 2

when I finish to work on changeanimationproperty I post a build!
 
You must log in or register to reply here.
Back
Top Bottom