HomeUser Control Panel (unavailable in archive)ForumsTutorialsArt GalleryResourcesMaps

System Near Completion

04-29-2007, 11:06 PM#1
MaD[Lion]
After alot of testing and fixing, i managed to make this system as fast as i can still with customizeability.
When running pure system power, without any external functions it can get up to 300 objects with all collisions (object collision and terrain) lagfree. It can handle like 50 object collisions at the same time lagfree, maybe more but not sure.
Still i have to fix the rolling, that part still sux atm. Seems like i have been too arrogant, if i just listened to grim001 and used real physic laws :P but it isnt much to do to fix this anyway.

Anyway, here is my system, it isnt completed, this is just to show how it is so far.
to grim001: using unit group increased object collision performance alot!. But sadly using loop is still faster than using unit group in terrain collision.
Attached Files
File type: w3xOOMS.w3x (55.2 KB)
04-29-2007, 11:22 PM#2
grim001
First of all, please spell "acseleration" correctly within your engine, it is "acceleration"

Collapse JASS:
    local group InRange = CreateGroup()
    set CurrentMotion = M
    //---
    call GroupEnumUnitsInRange(InRange,pX,pY,(MaxRadius+C.Radius+10),null)
    call ForGroup(InRange, function CollisionCalculationLoop)
    call DestroyGroup(InRange)
Don't create a group every time, use a global group instead. Creating and destroying handles is very slow. If you need to have a seperate group for every object you could include a unitgroup as a member of the object.

It seems like you have added bounciness and friction and well as increasing the performance, good job on that. Although the actual sliding and collisions aren't very well shown in the demo map, so I can't tell if it's working correctly.

The biggest problem is that the code is too ugly, so I don't really want to look at it in-depth, it hurts my eyes.
04-29-2007, 11:37 PM#3
MaD[Lion]
i know that it looks very ugly, even i have problems :P But its only the calculation part that looks bad, im not good at naming them.
And thnx for pointing out that acceleration thing... but i dont wanna rename it all now :P
But using global group is nice, i made this in hurry so didnt think much of it.
i even forgot to not double collision check. so here it double check alot! Which means bad for performance.
The sliding doesnt works correctly now, but it does make it hard to climb up the cliffs. I will try fix these things tomorrow and reupload.
04-29-2007, 11:51 PM#4
Whitehorn
Throw the code into Notepadd++ / Textpad / dreamweaver / anything.
Use Find & Replace.

Replace every instance of 'acseleration' with 'acceleration' in 1 second.

Not exactly hard to do..
04-30-2007, 01:36 AM#5
MaD[Lion]
I know that, but i dont want to replace ^^
04-30-2007, 01:58 AM#6
Pyrogasm
Wow; that's just lazy.
04-30-2007, 02:56 AM#7
Vexorian
Quote:
Originally Posted by MaD[Lion]
I know that, but i dont want to replace ^^
You'll eventually have to replace it, better do it right now, than doing it after the 3rd release. Seriously
04-30-2007, 03:35 AM#8
MaD[Lion]
i know i know, sry. But no one care about the name anyway -.- Its just some vars.
Also i just discovered there was a huge bug in my system, not cus of code but cus of wc3. I used 2 hours try figure out, but finally i figured out problem, which is that UnitsInRange does not count units with locust ability, so all my projectiles tat was supposed to collide didnt collide with eachother, but only with mountainking, that is why it was so damn fast. I was surprised too tat it could run over 70 objects lagfree with object collision.
But now when that is fixed by not adding locust, it isnt that fast anymore :(
It is still alot faster than the old one where i used loop, but not like 70 objects. Now it can only handle 15-17 object collisions at the same time without lag. And 23-27 collisions on above 40fps.

And also ExecuteFunc and function interface isnt much different in performance, pretty much the same from my tests.

Also wanna ask if anyone know if there is possible to get units in range even the units have locust?
05-01-2007, 07:14 PM#9
Toadcop
MaD[Lion] well nice sys at all ! i just checked it and well looks nice but i got 5-15 fps (no video stress) =(. in whole i like you don't "give up" and continue modifing ur sys ! now something more about =)

Quote:
Creating and destroying handles is very slow
yes relative slow ! and you have a chance to get bugged =) relative is cause if more objects you have so slower a new one will be created + the speed is about 8-12 var sets. ofc this counts only for noninterface objects (like locations triggers timers etc.) units items mb (maybe) are MUCH slower ! and after 2000-3000 unit's game begins to create new unit amazing slow ! so i got a trigger to create every 0.1 a unit and after 2000-3000 units i may create 1 unit per second !!! or less. so dynamic object creation == evil =). and btw to much local vars are also bad cause to init local var (local integer i for ex) takes ~3 var sets ! but operations with local vars are bit faster than with global. and arrays seems to suxx overall ! (well nothing is better than global arrays for multy instance data) but local arrays have disappoint me =( the are slower than global vars in all (i got ~3000 global vars and arrays on map).

Quote:
Also wanna ask if anyone know if there is possible to get units in range even the units have locust?
ofc no =) you can detect them using EnterRegion event (something of this sort...) but i would not advice it to do! cause it needs stupid calcs + dynamic object creation (or not =) i don't know how event uses this region...) and btw not rect ! a region and region is a more complicated structure than rect. but it works well and how i remember with out delays (after current thread end it must launch). i would suggest to use Vex trick to make unit's "unselectable" add moded Chaos spell and 'Aloc' ability.
Code:
...
  call UnitAddAbility(u,'Caos') // your allterantive unit. the unit id must be different !
  call UnitAddAbility(u,'Aloc')
...
well so it must work... and your unit's will be unselectable BUT they are vulnareable so make them also invulnarable ;) i think this would be better.
and btw i'm not 100% sure what UnitInRange event will work with this unit's but i think it will !

Quote:
And also ExecuteFunc and function interface isnt much different in performance, pretty much the same from my tests
yes it's a myth cause Vexorian simple don't like ExecuteFunc =). it's
1) MORE handly for usage
2) well my current test (just yet tested !) shows what ExecuteFunc() is only ~2.1x slower than to use TriggerEvaluate() // btw i use more realistic conditions for testing so i run it in a loop to show "performance under preasure" and this tests have ever shown logicaly results ! as for me i trust this results...

i thinks thats all ^^
05-01-2007, 10:19 PM#10
Ammorth
Quote:
Originally Posted by Toadcop
you can detect them using EnterRegion event

Wrong. Locust units cannot be obtained from anything, except for variables pointing directly to the unit (kind of like a local unit).

And regions are just a group of rects; you create a rect or more, and assign them to a region.
05-02-2007, 02:55 AM#11
DioD
unit in range event ignore locust units BUT they still in game, enum in rect will group them well.
05-02-2007, 04:33 AM#12
Ammorth
Quote:
Originally Posted by DioD
unit in range event ignore locust units BUT they still in game, enum in rect will group them well.

Seriously? hmm... I don't think so, cause I tried locust units for my pathing system's nodes and I could not add locust units in radius to a group. I also had another map a while back that had locust units move about a board. I could not detect when they entered a region, but I could detect when their order became 0 (hence they arrived) and then move them to the next region.
05-02-2007, 07:04 AM#13
blu_da_noob
Locust units can also be picked up by picking all units of a player and I think all units of type.
05-02-2007, 02:53 PM#14
Toadcop
well
Toadcop - right
DioD - wrong...
Ammorth - wrong...
blu_da_noob - right
// if you don't belive you can simple test it...