| 04-24-2010, 06:05 PM | #1 |
So I decided to make some natives using nAPI. After thinking about what to make, I decided to make natives for handling vectors. They are called Vec3 to avoid confusion with the vector natives included in RtC. Those are the natives I have made so far. Note that all integer arguments are handles to a Vec3.  JASS:native Vec3Create takes real x, real y, real z returns integer native Vec3Copy takes integer id returns integer native Vec3Destroy takes integer id returns nothing native Vec3Set takes integer id, real x, real y, real z returns nothing native Vec3Compare takes integer id1, integer id2 returns boolean native Vec3GetX takes integer id returns real native Vec3GetY takes integer id returns real native Vec3GetZ takes integer id returns real native Vec3SetX takes integer id, real value returns nothing native Vec3SetY takes integer id, real value returns nothing native Vec3SetZ takes integer id, real value returns nothing native Vec3GetLength takes integer id returns real native Vec3SetLength takes integer id, real len returns nothing native Vec3Scale takes integer id, real factor returns nothing native Vec3Add takes integer id1, integer id2 returns nothing native Vec3Subtract takes integer id1, integer id2 returns nothing native Vec3Rotate takes integer id, integer axisId, real angle returns nothing Now for the cool part: It is possible to use a modified version of Anitarf's vJass vector library as a wrapper for those natives. So you could use Vec3 natives in any map using Anitarf's vectors, by just replacing the library with the modified version (I haven't posted it because I haven't asked him for permission yet). Now you may be wondering, why would anyone want to do that? Well, most method calls would get inlined to native calls, and it doesn't use jass' software floats, etc., hence improving speed significantly. Then you may be wondering how much faster my natives are. I can't offer any high-quality benchmarks yet, because I haven't had enough time to make any, partially because of the bug that sometimes won't let RtC start. But I can offer the next-best thing; Estimations based on initial benchmarks. Creation and destruction: at least 3x faster Add: at least 5x faster Scale: at least 4x faster Calculating length: at least 4x faster Rotation: at least 15x (!) faster; some (rather unreliable) tests indicate as much as 22x As you can see, the rotation operation is a lot faster. I believe other operations such as projection will also benefit greatly when I have made those natives. Now for the slightly disappointing thing: reading and writing to individual elements is slower (about 1.25x slower). That means maps using them a lot could suffer a performance penalty, but hopefully, the speedup of the other operations could outweight that. I will release the source code (and a .dll) soon, but my question now is: What do you think? |