[System] Custom Projectiles

[Tukki]

This is actually pretty good!

Critique:

Firstly; don't care about Anachron's negative comments, there's a lot of people like him
Secondly; you should, as a system-designer, consider the fact that your audience would like to have that onLoop method.
Thirdly; but since many users who would have used that onLoop method to something probably would have scripted their own plug-in; I think you are fine without it
Fourthly; you should be rewarded with a mountain of cookies for those comments

In your onDestroy method you do the following, among other things:

....
        if (.toRemove) then                 // If .toRemove is flagged, then remove the unit associated with
            call RemoveUnit(.toUnit)        // the projectile.
        endif

I'd suggest that you use the ShowUnit(.toUnit,false) + KillUnit(.toUnit) trick. Mainly because AutoIndex hooks the RemoveUnit() function, which isn't all too efficient.

However, it's nothing seriously, just a minor suggestion.

------------------------------------------------------

Another thing is the projectilegroup enumeration method.

...
    static method enumNearby takes projectilegroup g, real x, real y, real z, real radius returns nothing
        local integer i=0
        local real x2
        local real y2
        local real z2
        loop
            exitwhen (i==.priv_stackDex)
            set x2  = .priv_stack[i].posVec.x
            set y2  = .priv_stack[i].posVec.y
            set z2  = .priv_stack[i].posVec.z
            if ((x2-x)*(x2-x)+(y2-y)*(y2-y)+(z2-z)*(z2-z)) <= (radius*radius) then
                call g.add(.priv_stack[i])
            endif
            set i=i+1
        endloop
    endmethod

I'm not a fan of doing several o(n) searches every second. I can understand it if your system only handles locusted units, but since your projectile.create(unit u) method requires a specified unit, I would organize it a bit differently.

Instead of having one major group with all projectiles in (which is what you have atm I believe), get two. One will be used to store ALL projectiles, while the other one will be used to store locusted units.
eg: ProjectilesAll, ProjectilesAloc

When you allocate the projectile instance, you check if the passed unit has locust. If it has you add it to the ProjectilesAloc group, but if it doesn't has the ability, you'll add a unit-type to it - which should be a global constant btw.

Then you could rewrite the enumNearby method to only do the position-search for projectiles in the ProjectilesAloc group. But since you'd lose the non-locusted units, a normal GroupEnumUnitsInRange would be needed with a filter that adds unit-projectiles to the projectilegroup if they have the unique unit-type.

This is just a suggestion and I have no clue if it would improve overall performance, because it would only improve performance if you had a lot of unit-projectiles flying about.

Still, doing that o(n) search multiple times a second shouldn't be an all too big performance-hit, since many computers have more than enough computing power and because of the fact that n won't exceed 300 in most cases.
​

Edit: With 6 spheres (Time Slow) up simultaneously i got these values:

@ 900 missiles fps was: 3,4
@ 600 missiles fps was: ~10-13
@ 400 missiles fps was: 30-31
@ 300 missiles fps was: 51​

so I think you'll be fine with your current o(n) method.

Worth noting that this test was run on a computer with the CPU: i7 920, OC'd to 3,2GHz from 2,66 GHz
Graphics card was an ATI Radeon HD 4890.

 

[Berb]

I appreciate you running these tests. Also, the only reason I have that toRemove flag is because when a unit is killed it leaves a corpse, which is enumerated when projectiles pass nearby it. Having dead projectiles bog down the performance of the system isn't desirable, and the toRemove prevents that from happening.

Though, are units that are not "shown" (as in ShowUnit(unit, false)) still subject to enumeration by the group enumeration functions (the native ones)?

Fourthly; you should be rewarded with a mountain of cookies for those comments

You should look at the Time Travel library hosted above mine by Bribe, he copies my layout lol. Thanks though.

I'm not a fan of doing several o(n) searches every second. I can understand it if your system only handles locusted units, but since your projectile.create(unit u) method requires a specified unit, I would organize it a bit differently.

Me neither.

This is just a suggestion and I have no clue if it would improve overall performance, because it would only improve performance if you had a lot of unit-projectiles flying about.

Still, doing that o(n) search multiple times a second shouldn't be an all too big performance-hit, since many computers have more than enough computing power and because of the fact that n won't exceed 300 in most cases.

Though you may be headed in a "good" direction. I'm thinking perhaps I should add projectiles to a static group so that I don't have to do iterate through a loop, instead I could just use a ForGroup. I really don't know how much performance that will save, I'm always looking for ways of increasing performance though.

Edit: With 6 spheres (Time Slow) up simultaneously i got these values:

There are lots of factors that affect how many projectiles can be simultaneously existent. The model that is used for the missile is one, but that only scrapes a little off the top. What really needs optimizing is collision detection and projectile enumeration.

I really wish JASS wasn't so slow.

Sounds like you've got a pretty sick video card, but I think that the processor is the most essential element for this. There isn't much graphics memory required. Damn I looked at you i7 online, you've got a nice ass computer. I've got a piece of crap.

 

[Lambdadelta]

No two units are ever going to be directly on top of each other. Either way, I only set it this way because I thought that's how WarCraft III missiles work. If you have two units that are directly on-top of each other, I'm pretty sure you won't be able to see their missiles.

Well, if you had a dragonhawk riding above a Huntress directly below him, it wouldn't be unseen...

Is it a problem to add?

 

[Berb]

Not really, but what do you mean? If a Dragon-hawk is riding above a huntress only the explosion will be seen (from the Dragon-Hawk's missile) which is exactly the same as what happens in this system. I purposely only interpret projectile distance in 2 dimensions because that is how Warcraft III projectiles work, to the best of my knowledge. Obviously I don't know this for a fact, but I need some good evidence before I change something like that.

 

[Bribe]

Many missile effects have weird bugs in the game, like going invisible sometimes for no apparent reason. Flying units are the number one causes of this; often there is no missile art to speak of (predominantly with Chimaeras).

 

[Lambdadelta]

That's so strange. I just remember in the Halloween map from way long ago, it was triggered that units were created above and attack with Searing Arrow missile and it didn't just move instantly. I even opened to check

After testing myself... I'm surprised. Wow. But that was ages ago and they probably did something different, actually, they probably just missile speed to low :|

 

[Berb]

After testing myself... I'm surprised. Wow. But that was ages ago and they probably did something different, actually, they probably just missile speed to low :|

I really didn't follow this much.

 

[Lambdadelta]

Yeah, my bad, messed up sentence.

I was playing around with setting missile speeds of Warcraft's engine and having the source target directly below. Gives some strange results. I don't think they will be of any use though.

 

[Berb]

So then you're happy with how this system handles those cases?

 

[Lambdadelta]

I'd actually like an option for 3D movement. Seperately may work if the aim is to keep the system closely related to Warcraft engine's missiles.

 

[Berb]

Updated the test-map to the most recent version, 1.6c. Also updated the code in the first post.

The update includes a few performance optimizations. A couple of unnecessary SquareRoot calls have been removed along with an unnecessary Filter call when enumerating units (which occurred on each iteration).

This doesn't handle 3D movement does it? 0 ground distance but 700 height distance is instnat ?

The only element of these projectiles that uses the 3rd dimension (height, or the "z" axis) is the arc. There is nothing else that interferes with the height of the missile. The way the arc is setup it uses certain data to calculate the required "gravitational" acceleration to achieve the result of the designated arc. If you're going to start making projectiles fully move in 3-dimensions, it will completely eliminate the whole idea of "arc". I'm going to stick to using only two dimensions, as that is what Warcraft III is built around. If you're trying to use this for complex and realistic missiles then I highly suggest you use a physics engine. This isn't supposed to be able to defy Warcraft III.

 

[azlier]

Quit poking me.

 

[Berb]

I'm not poking you. But you should approve

 

[Darkt3mpl3r]

Haha. Anachron realized that he cannot impose his thinking to Berg and left. Great. Its funny that he tries this to everyone. Good that some people are immune to this. Oh by the way, great system. I'm looking forward to rip use this system

 

[De.Facto]

Oh by the way, great system.

Indeed.

 

[Hanky]

Oh by the way, great system.

Indeed.

Yes.

 

[Berb]

Yay feed-back.

Yay approval!

 

[CHA_Owner]

Yea i find this to be a really well made system which Anachron's system has much more functionality yours pulls ahead thanks to your core systems being so well made without any bugs/glitches/or shakiness in the missiles.

 

[Element of Water]

I think this system is really well made. Although Anachron's CustomMissile has much more functionality, yours pulls ahead thanks to the core system being so well-made and free of any bugs/glitches/shaky missile.

^^
I made it understandable.

 

[SlayerII]

nice made, but wy this in in jass function? isnt it a system?

I thought this section belongs to things like GetClosestUnit or EnumLocustInRange.
Just simple , but helpfull stuff.

Most people which look in this section wont use it.Maybe just for learning from it.

 

[Berb]

Well that's entirely up to them. This system can help you do a lot of things, and I was actually thinking about releasing a spell-pack that uses it just to show how useful it can really be. So far I've got a couple of fire spells and they all benefit greatly from this.

 

[SlayerII]

umm well...
there is still the prob that some people(at least me) dislike using systems which do all the work. Sure i may use it, and sure it would be better than my crappy, z ignoring and sometimes game crashing(if you should outside of bounds... yea easy to solve, but im lazy) projectile system, but i just like to write the big systems myself.

The only people which may use it, are normally the ones, who cant use it =/

well, still nice to learn from it.

edit: im not too much into structs, does .max mean thistype.max ?

 

[Bribe]

The only people who may use it are the ones who can't use it?

You don't know what you're talking about. Not everyone has to build the same library over and over. I use Berbanog's system quite a lot even though I am fully capable of building huge libraries on my lonesome. There just is no point because he's put a lot of testing into this system which I do not need to do.

 

[SlayerII]

lol
you re lazy =/

it was just my point of view.

 

[Bribe]

lol
you re lazy =/

it was just my point of view.

Lazy has nothing to do with it, it's called intelligence. When you get older you'll realize you don't have that much time on your hands. And you're one to talk about laziness.

lol? -> Lazy, horrible typing.

you re -> Ever hear of apostraphes or punctuation?

it -> Three sentences starting with lowercase letters? Terrible.

Stop labelling people.

 

[SlayerII]

(Being amused)
You are lazy,
and its just my point of view

Sorry, wrote this while i was cooking.
(Since when lol is a sentence?)

And still, i dislike using big Systems. I mean, mapping is my hobby. If i would use a robot to play soccer for me, wouldnt that be crazy?

And learning by doing is the best way to learn something. Everytime i wrote a system, i learn something new. I never discovered the usefullnes of librarys and scopes by reading about them, or using systems containing them.
But just by writing a bigger system, i suddenly got wy people use them-they are jsut great if you have huge amount of code. Especialy for me, who cant remember a single fucntion name.

BacktoTopic: still , most people who would need such a system , cant use it. And its wrong placed here, cause the section is called "functions" and not "systems". I thought we have a "spell and systems" section.


And sorry if you feeled offended.

 

[Bribe]

And sorry if you feeled offended. Don't go drama. Also, there is no such forum, and this is a bunch of JASS functions, and they work together with efficiency so it got approved to JASS function.

Anothing thing is that I have created projectiles for single-spells, though they never turn out very good.

You like to make your own libraries. So do I, that's why I made Time Travel, and it's no tiny system, that thing is huge.

Thing is, I am better at building a Time Travel system than I am at building a Projectile system. Every person has their own job in life, and you'll realize that if you look at software development teams -- sounds cheesy but there is no "I" in "team".

My dad builds computer servers, I don't. I write software, he doesn't. Is either one of us missing a learning opportunity? Not at all. We are each dilligently studying our areas of expertise.

 

[Element of Water]

Also, there is no such forum

http://www.hiveworkshop.com/forums/spells.php

Erm, yeah.

 

[Bribe]

Projectile is a system, not a spell. It would be just as out of place there.

 

[YourNameHere]

Projectile is a system, not a spell. It would be just as out of place there.

Have you ever submitted something there? There is a category especially for systems.

 

[Berb]

It really makes no difference. If a moderator wants to move it then he/she can move it.

 

[Berb]

Updated the script. Pretty much just added operators for the target X/Y/Z values since you're not allowed to reference the vectors. Also made a couple of syntax updates, but nothing serious.

Make that two script updates. I also updated the test-map to the most recent version (1.7).

Things to notice in this version:

• Unit collision has been reduced to X/Y coordinates, height has been omitted which will (in many cases) speed things up due to the elimination of some function calls.
• Another square-root call has been replaced with a simple multiplication.
• There were a few logic errors regarding some of the calculations for Pitch Rotation that have been corrected.
• Added a way better projectile-count interface that shows how many projectiles are currently active.

Performance is doing good, too:



As you can see there is a minimal drop in frame-rate caused by almost 200 projectiles. I believe this completely obliterates what other projectile systems are capable of.

 

[Berb]

I think some of the corners that I cut earlier to eliminate a square-root somewhere along the lines has screwed with some aspects of motion. At high levels, there seems to be a problem with "arc" that I can't seem to figure out and also when projectiles reach their target it always seems like they have to move slightly at the very end of their path. It happens so quickly, but does anybody else notice these things?

I don't know if it was like this before, or if this is new, some of my older versions seem to suffer from this as well. I calculate which animation index to use properly, accordingly to the velocity of the projectile. I was thinking it may be from the 0.025-second period after being launched that was causing a delay in the pitch being adjusted, but with high values it seems like even that is not the problem. Can someone help me out here?

Okay, these problems seemed to have been fixed simply by setting the dummy's Animation Blend time to 0.00 (it was default before). This caused projectiles not to be updated as instantly as was required of them by the system. I'd like to take this time to point out some very necessary Object Editor settings you'll want to be sure you check off:

• Animation Blend - 0.00 (so that animations are updated immediately)
• Pitch/Roll Maximum Rotation - 0.00 (so that the game-defined roll/pitch values do not interfere with the calculated values)

Well, I guess that's it, but these are only for projectiles that are made using the dummy.mdx model from xe. By the way, since I am using the dummy-unit from xe (though that is all I am using) should I make xe a required library? Actually, I take that back, it is only optionally supported (on the user's request) whether they want to use the dummy, so I'll leave it as it is.

 

[Prince.Zero]

Updated the script. Pretty much just added operators for the target X/Y/Z values since you're not allowed to reference the vectors. Also made a couple of syntax updates, but nothing serious.

Make that two script updates. I also updated the test-map to the most recent version (1.7).

Things to notice in this version:

• Unit collision has been reduced to X/Y coordinates, height has been omitted which will (in many cases) speed things up due to the elimination of some function calls.
• Another square-root call has been replaced with a simple multiplication.
• There were a few logic errors regarding some of the calculations for Pitch Rotation that have been corrected.
• Added a way better projectile-count interface that shows how many projectiles are currently active.

Performance is doing good, too:



As you can see there is a minimal drop in frame-rate caused by almost 200 projectiles. I believe this completely obliterates what other projectile systems are capable of.

You should also post your system specs
Other users dont use dual core i7 or greater cpu's and monster GFX's you know.

i'll give this a try on my laptop

EDIT:

Results were quite bad

System specs:
AMD Turion 64 x2 ~2Ghz
ATI Radeon x3200
1.3Gb ram

also i used a projectile that has no animation particles which could make the performance better.
still 9 fps is unacceptable.

I'll give it a try as well at my big computer
My laptop runs DotA mostly at 50-63 FPS

I tested Anachron's system, it has a better performance, let's say at 150~ projectiles i had an FPS of 40.3
For heavy system like these i wouldn't trust vJass or any external compiler.
Use jass instead

EDIT:

I don't know where to start with all this mass code...
I don't want you to touch it yet. Just try some improvements instead of making the script look more readable and beautiful
This isn't a spell after all, it's a huge system.


For performance i'd recommend improving some lines, like not using so many methods
You know methods are heavier than BJ's in the compiled script.
We have to stop looking at our nicely organized and readable vJass and start looking deeper into the ugly truth

    method add takes projectile p returns boolean
        if .max < PROJ_ENUM_COUNT_MAX then
            set .at[.max] = p
            set .max = .max + 1
            call SaveBoolean(table, this, integer(p), true)
            return true
        endif
        return false
    endmethod

    method remove takes projectile p returns boolean
        local integer i=.max-1
        call RemoveSavedBoolean(table, this, integer(p))
        loop
            exitwhen(i < 0)
            if (.at[i]==p) then
                set .max   = .max-1
                set .at[i] = .at[.max]
                return true
            endif
            set i=i-1
        endloop
        return false
    endmethod

    method removeIndex takes integer index returns boolean
        call RemoveSavedBoolean(table, this, .at[index])
        if (index < .max) then 
            set .max        = .max - 1 
            set .at[index]  = .at[.max]
            return true 
        endif
        return false
    endmethod

    method inGroup takes projectile p returns boolean
        return HaveSavedBoolean(table, this, p)
    endmethod

all these can be done in a more efficient way instead of calling the methods constantly.
You do realize that we are calling these methods more than 1000 times a second for 100+ projectiles right?
Do the maths.

    method operator x takes nothing returns real
        return .posVec.x
    endmethod
    method operator y takes nothing returns real
        return .posVec.y
    endmethod
    method operator z takes nothing returns real
        return .posVec.z
    endmethod
    method operator collision takes nothing returns real
        return .priv_collision
    endmethod

    method operator source takes nothing returns unit
        return .priv_source
    endmethod
    method operator source= takes unit who returns nothing
        if (.priv_source==null) then
            set .priv_source=who
        endif
    endmethod
    method operator target takes nothing returns unit
        return .priv_target
    endmethod
    method operator target= takes unit who returns nothing     
        if (.priv_target==null) then
            set .priv_target=who
            set .priv_unitfollow=true
        endif
    endmethod
//*
    method operator targetX takes nothing returns real
        return tarVec.x
    endmethod
    method operator targetY takes nothing returns real
        return tarVec.y
    endmethod
    method operator targetZ takes nothing returns real
        return tarVec.z
    endmethod
    method operator timescale takes nothing returns real
        if (.priv_paused) then
            return 0.00
        endif
        return .priv_timescale
    endmethod

these are a lot of redundant methods.
You use methods to return obvious values.
It wouldn't be smart if i tried to get number '5' by using a function, right?

hmmm.... Furthermore tests are needed. I'll try to optimize this with vexorian's map optimizer to full optimization and test again. I'll edit the post shortly if there's no reply.

EDIT:

Very good, with vexorian's optimizer i achieved an increased performance.
On a normal computer this could run just ok.
But i don't trust it for maps that use a lot of code in them.

Results:

Sheeps? XD

 

[Berb]

I'll give it a try as well at my big computer
My laptop runs DotA mostly at 50-63 FPS

DotA isn't a good comparison. That is like saying "I run sheep-tag at full FPS".

I tested Anachron's system, it has a better performance, let's say at 150~ projectiles i had an FPS of 40.3
For heavy system like these i wouldn't trust vJass or any external compiler.
Use jass instead

In no way does Anachron's system out-perform this one. I have tested them both. Also worth mentioning is that my computer is probably below average, I'm using a computer from 3 years ago now.

To be honest I don't really think you know what you're talking about, vJass is the most efficient way of meshing data together in JASS - and the most effective when trying to associate different types of data. In JASS I would just be writing out the parallel arrays myself, but why do this when vJass is available.

I'm going to go ahead and say that you definitely had something running while you were doing these tests. If your computer is dropping to 9 FPS when 100 units are being moved around and my computer can handle 300 units while still being at 40 FPS then it's definitely a flaw in your testing.

For performance i'd recommend improving some lines, like not using so many methods
You know methods are heavier than BJ's in the compiled script.
We have to stop looking at our nicely organized and readable vJass and start looking deeper into the ugly truth

First of all, methods are not "heavier" than BJ's I don't think you even know why BJ functions are bad. What do you mean "into the ugly truth" I'm quite certain you don't know what you're talking about. You haven't explained or given any example as to any of the problems that arise with vJass syntax yet you keep on saying that it isn't good - please provide specific examples or your word isn't going to be worth much.

all these can be done in a more efficient way instead of calling the methods constantly.
You do realize that we are calling these methods more than 1000 times a second for 100+ projectiles right?
Do the maths

What the hell are you talking about? None of the methods you listed are being called at all in projectiles that are simply launched (as they are in the test-map) - so no they are not being run 1000 times a second. They aren't being run at all. The internal iteration loop that handles the projectile motion uses a minimal amount of function calls.

all these can be done in a more efficient way instead of calling the methods constantly.

Yet you haven't given example as to what exactly you think is more efficient. Typical.

these are a lot of redundant methods.
You use methods to return obvious values.
It wouldn't be smart if i tried to get number '5' by using a function, right?

There isn't a single constant other than 1 and 0 (used for iterations and such) in any of the code you've posted. You don't make any sense at all. I think it's just your lack of understanding on how vJass works. Notice how those values that I'm returning are private variables? They can only be referenced inside the struct - this means that if the user wants to reference them he's going to need some access to them, which I give explicitly with method operators. If you don't know what you're talking about don't impose as if you do.

Very good, with vexorian's optimizer i achieved an increased performance.
On a normal computer this could run just ok.
But i don't trust it for maps that use a lot of code in them.

Do you have any computer science background? Do you know anything about how a computer works? You don't sound like you do.

---------------------------------------------

Okay I just tested the map after optimizing it and it runs even better. In order to push my FPS down to 20 as you have yours I need almost 400 projectiles. The FPS seems to go down by a little less than 1 FPS for every 12 projectiles that are launched (and it shoots back up as soon as the projectile is cleaned). Until about 250-270 projectiles the FPS change is completely unnoticeable, and in order to get 9 FPS as you have shown (with only 113 projectiles) I need almost 500 projectiles.

Since you gave DotA as an example, I'll stick with it; in a game like DotA you're only going to have 20-30 visible units that are capable of launching projectiles at any given time. This means that even if those 20-30 units launch 5 projectiles all within the same time-frame you're only going to run 100-150 projectiles. This is also given that every projectile being launched is going to be capable of colliding with in-game units. Most projectiles that are launched do not have that capability, and simply connect a source to a target (in which case I will give the output performance shortly).

Without unit-collision enabled (and optimized) in order to get 11 FPS I need to run over 600 projectiles. Even when 400 projectiles are moving through the air the drop in frame-rate is completely unnoticeable. Need proof?



If you were to run this on a computer that is capable of running Starcraft II you would probably be able to get up to 650-700 projectiles without dropping below 40 FPS.

Okay, here's another screen-shot of the performance output when the script is optimized and unit-collision disabled.

 

[Prince.Zero]

Your screenshot is totally lame and your statements as well.
The screenshot doesnt even SHOW the projectiles, only a few of them.
I'm not gonna discuss this further as you have no idea about what vJass becomes when it is compiles.

Go download an mpq extractor, extract your map script and rub it on your face.
Then state that vJass is better than JASS.
Afterwards you can also state that GUI > Jass

I'm not gonna feedback on this thread anymore as you have no signs of reasoning. What good is a thread when you decline every single approach?

You remind me of Icefrog

 

[Berb]

Your screenshot is totally lame and your statements as well.
The screenshot doesnt even SHOW the projectiles, only a few of them.

So you're suggesting that I'm lying? The screen is over the area which I targeted the projectiles, that way I can shoot off hundreds at a time. Why don't you look at the screen-shot right below it with 333 projectiles at 46 FPS - that was is quite clear.

I'm not gonna discuss this further as you have no idea about what vJass becomes when it is compiles.

You haven't presented a single fact, or any evidence that what you say is correct - from what I can tell you're just bullshitting and making things up for your own sake.

Go download an mpq extractor, extract your map script and rub it on your face.
Then state that vJass is better than JASS.
Afterwards you can also state that GUI > Jass

I've done that many, many times, in the several years that I have been modding. You don't know what you're talking about and don't tell me to "rub it in my face" you just make yourself sound stupid.

'm not gonna feedback on this thread anymore as you have no signs of reasoning. What good is a thread when you decline every single approach?

I'm not going to submit to the approach of a newbie who just recently joined the site and thinks that vJass is the devil - sorry but to me you sound like you don't know a damn thing about what you're talking about.

Oh, and just for piece of mind I ran some tests on Anachron's system which you say completely out-performs mine by a lot. Just take a look at the result:



You were either lying or you just don't know how to operate a computer. Either way I could care less if you don't respond here anymore you have nothing to offer but bogus information. Just for clarity I am running 47 projectiles and it's running at 38 FPS. That is light-years behind mine.

 

[Nestharus]

*declares Berb the winner*

Now cut it out guys (Prince), let's get back to constructive criticism = ).

 

[Prince.Zero]

Okay, Nestharus

I'll give this system a rating of 4.7/5
I may be harsh, but i'm also honest.
Some people tend to call me dellusional but my statements are only linked to details.

I'll try and make a system like this in the near future out of curiosity.

 

[Berb]

also i used a projectile that has no animation particles which could make the performance better.
still 9 fps is unacceptable.

First it's unacceptable - now it's 4.7/5.

--------------------------------------------------------------------------------------------

Okay, I'm going to release an update soon (version 2.0) that cleans up the mess I made with the projectilegroup struct. I've renamed two of the public members to better suit the occasion (and the purpose of their reference) and removed the removeIndex( ) method; instead I revamped the regular remove method so that it is just as fast (so no loop is required to remove a projectile from a group). In addition to that I fixed one of the bugs in the test-map that would cause the projectiles to not regain their velocity after they exit the "Slow Time" bubble.

I have also made some of the documentation look nicer, and used better style constraints to achieve nicer looking code. It should be easier to navigate than before, if not by much then by some. I just couldn't stand looking at my old code any longer. There is still a size limit to the amount of projectiles that can be in a group, though I'm looking for a way of removing the necessity of a projectile array in the projectilegroup struct.

 

[Anachron]

First of all, Berb, stop being harsh and for gods love, stop making tests of things that you have no idea about.

My test spell uses MANY of my enumerating function, which we all know, are slow.
Your test spell does not EVEN pick ANY unit at ANY time, so how DARE are you to call my system slow?

If you would do some real tests you'd figure out why I am NOT lightyears behind you.

 

[Berb]

First of all, Berb, stop being harsh and for gods love, stop making tests of things that you have no idea about.

What do you mean, I have no idea about? You were following my footsteps, not the other way around. Please remember that next time.

My test spell uses MANY of my enumerating function, which we all know, are slow.

Then don't make shitty test maps. By default I wasn't even able to fire off more than 1 arrow at a time, your map isn't setup to test it's performance at all, maybe instead of hiding that you should openly display it as I do in mine. Though please explain what you mean by "many of your enumerating function" - you mean unit collision detection is active?

Your test spell does not EVEN pick ANY unit at ANY time, so how DARE are you to call my system slow?

How dare I call your system slow? I dropped over 20 FPS without even having 50 projectiles on the screen. Not to mention you don't know what settings I ran those tests on, as I posted screen-shots. How dare you come here and tell me I don't know what I'm doing when you haven't the slightest clue.

If you would do some real tests you'd figure out why I am NOT lightyears behind you.

I don't care to decipher your undocumented code just so that I can try and optimize the performance output so that your system doesn't look so bad. At least I have shown you the capabilities of my system you haven't done anything of the like instead you sit on your ass pointing fingers and claiming that you know what you're talking about. I've posted proof. You have nothing.

{EDIT}
Okay, I've updated the submission to version 2.0.

Okay, I'm going to release an update soon (version 2.0) that cleans up the mess I made with the projectilegroup struct. I've renamed two of the public members to better suit the occasion (and the purpose of their reference) and removed the removeIndex( ) method; instead I revamped the regular remove method so that it is just as fast (so no loop is required to remove a projectile from a group). In addition to that I fixed one of the bugs in the test-map that would cause the projectiles to not regain their velocity after they exit the "Slow Time" bubble.

I have also made some of the documentation look nicer, and used better style constraints to achieve nicer looking code. It should be easier to navigate than before, if not by much then by some. I just couldn't stand looking at my old code any longer. There is still a size limit to the amount of projectiles that can be in a group, though I'm looking for a way of removing the necessity of a projectile array in the projectilegroup struct.

There was a lapse of time when I made versions 1.8 (and then version 2.0) which I added a ProjectileArt module that is an optional requirement. The module can be found on the first page near the library script; it is also included in the test-map. What it does is give projectiles two bonus instance-methods, setModel( ) and killModel( ) which control the model that is displayed over the projectile. The killModel( ) method is automatically called when a projectile is destroyed.

I've tried to do some more clean-up on the code, and I've done a lot of reorganizing and renaming. I've left most of the public interface members the same, only the private members have had notable name changes; for example instead of velVec it is now VECTOR__velocity which I find is a lot more clear when navigating through the code.

As time passes I'll probably release version 2.0b with some more code cleanup - I believe in terms of efficiency this is about as good as it will get.

 

[Berb]

Even if we were to match our testing methods (putting Warcraft III on the same graphics settings and everything) and use the same model, moving at the same speed at the same arc; it would still not improve the performance that dramatically. The game runs at 63 FPS on average, sometimes it jumps up and down; in order to reduce that to 38 FPS I need to run over 250 projectiles. In his test-map I was only able to launch 47 before dropping that low.

The difference between 250 and 47 when we're talking about objects being frequently updated in a sluggish loop is a lot, I'm getting more than 5x the amount of projectiles while matching his performance - running through the different models in the buffs section (particle emitters galore) I couldn't find anything (at any camera angle) that slowed things down so much. Even when I've got unit collision detection active it won't run it down that much.

At that point if they want to prove me wrong then go ahead; I just don't think the effort put into it will be worth the result.

Here; I'll use the same model and show you how mine runs more, with unit collision, with 20 frames per second to spare. Also, despite me not doing this in Anachron's test, I shot the projectile (with unit collision detection) over a group of units (they are mildly visible in the screen-shot) - remember I didn't do this in Anachron's test.

For The Avid Listener

 

[Anachron]

What do you mean, I have no idea about? You were following my footsteps, not the other way around. Please remember that next time.

**** off, I am not following anyone, I am just doing things on my own.

Then don't make shitty test maps. By default I wasn't even able to fire off more than 1 arrow at a time, your map isn't setup to test it's performance at all, maybe instead of hiding that you should openly display it as I do in mine. Though please explain what you mean by "many of your enumerating function" - you mean unit collision detection is active?

Firstly, yes, unit enumerating is on by default. Secondly, please remake the spell with your engine or make a new spell with my engine to test it's stuff. You did not even prove one time WHICH code you used to generate the tests, so I doubt that anything that the screenshot say is correct.

How dare I call your system slow? I dropped over 20 FPS without even having 50 projectiles on the screen. Not to mention you don't know what settings I ran those tests on, as I posted screen-shots. How dare you come here and tell me I don't know what I'm doing when you haven't the slightest clue.

Stop trolling, you are just saying a bunch of irrelevant stuff nobody cares about.

I don't care to decipher your undocumented code just so that I can try and optimize the performance output so that your system doesn't look so bad. At least I have shown you the capabilities of my system you haven't done anything of the like instead you sit on your ass pointing fingers and claiming that you know what you're talking about. I've posted proof. You have nothing.

I don't have wc3 installed on any of my pcs so I can't post any prove, so what the hell is wrong with you?

Even if we were to match our testing methods (putting Warcraft III on the same graphics settings and everything) and use the same model, moving at the same speed at the same arc; it would still not improve the performance that dramatically. The game runs at 63 FPS on average, sometimes it jumps up and down; in order to reduce that to 38 FPS I need to run over 250 projectiles. In his test-map I was only able to launch 47 before dropping that low.

Just rebuild my spell with your engine and show me how fast it is. Seriously. JUST REBUILD IT.

The difference between 250 and 47 when we're talking about objects being frequently updated in a sluggish loop is a lot, I'm getting more than 5x the amount of projectiles while matching his performance - running through the different models in the buffs section (particle emitters galore) I couldn't find anything (at any camera angle) that slowed things down so much. Even when I've got unit collision detection active it won't run it down that much.

Here; I'll use the same model and show you how mine runs more, with unit collision, with 20 frames per second to spare. Also, despite me not doing this in Anachron's test, I shot the projectile (with unit collision detection) over a group of units (they are mildly visible in the screen-shot) - remember I didn't do this in Anachron's test.

You never gave us any of the test data that you used, so why the hell should anyone believe yours could be any better?

 

[Brambleclaw]

I don't make systems for morons who are lazy and don't know how to do anything themselves. What I've done serves as a concise manner of allowing users control over projectiles that they would not normally have by hard-coding the motion of the projectile. This is what a projectile library is supposed to do.

Besides that, neither you, Anachron or YourNameHere are moderators and if all you're going to suggest is that I dumb it down for the idiots out their then save your suggestions.

Wow very angry there jeese give a guy a break. Also what your really mean is that you don't make systems for morons who are lazy...HOLD ON A MINUITE JUST BECAUSE SOMONE CANT CODE IN VJASS doesnt mean there lazy. You could at least make a basic structure or module for the user so they have some kind of use.
Otherwise the majority of people will not be able to use this system. I thought the whole idea of this system was to help people. Instead of saying here is the basic outline now you do the rest, without any instructions of guidelines.
Effectively your giving a monkey a computer and asking it to use it.
Please at least make is somwhat usable to the average person.
Just a suggestion. You wouldn't need modules everywhere. Just be nice to have 1 single module to show how to implement diffrent projectiles.

 

[Anachron]

Brambleclaw, that is exactly the thing that Berb is aiming for. A system that a high-end programmer should use while in fact he wouldn't because there are better ones out there.

 

[Berb]

**** off, I am not following anyone, I am just doing things on my own.

Don't tell anybody to **** off; and do you forget that comment where you've mentioned how you have your interfacing setup exactly like mine? Furthermore if you actually did leave the modding community then why are you still arguing with me and telling me to **** off.

Secondly, please remake the spell with your engine or make a new spell with my engine to test it's stuff. You did not even prove one time WHICH code you used to generate the tests, so I doubt that anything that the screenshot say is correct.

To be quite honest I don't care if you believe me or not. How about you post some screen-shots with some solid factual data on them instead of just calling everything I say @ and requesting that I do it myself. You have yet to provide any solid fact with any argument you have made, so before you can tell anybody to "post the code and crap" why don't you do it, and prove me wrong?

I put in so much effort in this thread trying to show you in an unbiased fashion (screen shots don't lie) and you still manage to whine about how my tests aren't accurate. You have not done anything, whether it be giving a factual presentation of where I am making mistakes (that you claim I am) or a screen-shot to show how my system does something incorrectly or inefficiently at some point.

Stop trolling, you are just saying a bunch of irrelevant stuff nobody cares about.

You're calling my performance comparisons between your system and mine an act of trolling, grow up and stop harassing me; at least I take the time to stress-test both of our systems, you haven't provided any fact or proof that backs up anything you're saying, yet you repeatedly call me wrong and I repeatedly put in more effort to make it even more clear - to which you simply discard my findings as trolling? Just leave this thread. Do not reply back here or I'm going to report you for harassing.

Brambleclaw, that is exactly the thing that Berb is aiming for. A system that a high-end programmer should use while in fact he wouldn't because there are better ones out there.

Now that's trolling; but notice how you still haven't actually proven anything your argument is still based on word-of-mouth, the mouth being yours.

don't have wc3 installed on any of my pcs so I can't post any prove, so what the hell is wrong with you?

So then what are you doing here? I find it outrageous that you seem to think you can come here and call the information I show in this thread inaccurate measurements while you don't even have Warcraft III installed. If you can't prove what you are saying is true then you are as good as harassing; since nothing you say has any real factual basis it's all just coming out of your @.

Just rebuild my spell with your engine and show me how fast it is. Seriously. JUST REBUILD IT.

Ah yes, telling me to do more work. Figures, even after I've gone through the effort of setting up a test-map for your "spell" because you didn't even do that in your test-map. I'm not going to do the work that you failed to do in the first place, just to prove a point that I have already proved time and time again.

You never gave us any of the test data that you used, so why the hell should anyone believe yours could be any better?

I've posted screen shots, I've posted factual output gathered from the game on my machine, you have posted nothing. The only thing you have posted is paragraphs explaining how yours is better without even giving me the things I have provided to you. You have been telling me that your method of doing things is better than mine and that your system is in every way better than mine without even giving me the things that I have mentioned, that I have given to you. I'm not going to go on your @%* goose-chases Anachron I have posted enough - it's time for you to actually back up the things that you say with facts, instead of hiding behind possible uncertainties and just throwing words at me.

At this point unless you can give me numbers, facts, or a picture, I do not want to have anything to do with you - your word means absolutely nothing to me at this point.

You could at least make a basic structure or module for the user so they have some kind of use.
Otherwise the majority of people will not be able to use this system. I thought the whole idea of this system was to help people. Instead of saying here is the basic outline now you do the rest, without any instructions of guidelines.
Effectively your giving a monkey a computer and asking it to use it.
Please at least make is somwhat usable to the average person.
Just a suggestion. You wouldn't need modules everywhere. Just be nice to have 1 single module to show how to implement diffrent projectiles.

There is a detailed manual in the very first thread, and I have recently added a module that allows users to use setModel and killModel methods. I'm not really sure what you mean by "1 single module to show how to implement..." though, please explain. I really don't see why it is my responsibility to make this usable for people who don't know how to use vJass in any way/shape/form.

As for Anachron, I would just like to remind you that unless you reinstall Warcraft III, and provide real information and evidence that supports what you're saying (perhaps even a screen-shot will be necessary) then you are not to post back in this thread. I am sick of your delusional accusations and sick of constantly proving you wrong only for you to find other things to whine about. I'm sick of words being thrown around in this thread as if that proves anything, because it doesn't.

 

[Anachron]

Berb, your points do not make even sense.

You are claiming your engine as fast and flexible, but when it comes to comparisms to other engines your tests claim to be not even fair.

And now from that test data you take your informations to call your system fast, while nobody knows with what you tested?

I am just trying to say that your tests don't prove anything unless they actually to the same thing with both engines.

If they don't, you are not allowed to claim your engine as faster and should seriously just stop compare our both systems.

I stopped mapping, that's true, but I never said I will stop posting, in fact I told you already 2 times that I will still continue this.

You just want me to stop posting so its easier for you to tell lies about my systems in order to make yours better, now that is what I call unfair.

If you don't prove evidence that the spell I've build is faster with your engine, you are not allowed to say anything related to the speed and flexability of your system compared to mine.

As for now, I will wait for the new test (attached with the 2 test maps ofcourse).
If you don't make that test, people can ignore the points of your argueing because they don't mean anything.

 

[Berb]

You are claiming your engine as fast and flexible, but when it comes to comparisms to other engines your tests claim to be not even fair.

No, they claim to be accurate enough to prove my point. I'm not trying to make yours look @*# these are not rigged comparisons, it is offensive that you believe I'm trying to do that.

I am just trying to say that your tests don't prove anything unless they actually to the same thing with both engines.

If they don't, you are not allowed to claim your engine as faster and should seriously just stop compare our both systems.

I stopped mapping, that's true, but I never said I will stop posting, in fact I told you already 2 times that I will still continue this.

You just want me to stop posting so its easier for you to tell lies about my systems in order to make yours better, now that is what I call unfair.

If you don't prove evidence that the spell I've build is faster with your engine, you are not allowed to say anything related to the speed and flexability of your system compared to mine.

If you don't have anything further to say about the system itself, then I'm not going to read your arguments. As I said before unless you've got pictures or some data to show me I'm not going to hear it.

 

[Anachron]

That's funny, you are ignoring arguments just because you don't want them to be true.
In fact I've proven more points that my system is better.