Return bug for indexing units.

09-05-2004, 08:53 PM

Code:

function unit2Int takes unit picked returns integer
  if(true) then
    return picked
  endif
  return 0
endfunction

I've been using this to get the pointers referring to units in-game and hopefully index them on an array. Of course, the numbers I've been getting back are in the million+ range, but I've been thinking I can simply subtract the index of the first unit registered and work away. Do any of you have experience with this kind of indexing method? Are there potential pitfalls I should look out for? Is the offset something that will remain stable should I restart the game or is it dependant on the game's memory allocation and changes from session to session? Thanks,
Alfryd

EDIT: SHORT ANSWER. YOU CAN'T. Thanks for your time.

09-05-2004, 10:18 PM	#2
Vexorian	you should use mod 8192 but I thik it would be better if you use game cache,

09-06-2004, 11:14 AM

Alfryd

Quote:

Originally Posted by Lord Vexorian

you should use mod 8192 but I thik it would be better if you use game cache,

I guess I'll just have to investigate this myself. Thanks anyway.

09-06-2004, 01:11 PM

Grater

What you need is a hash table/map, a simple modulo operation wont quite do, because then the rare clashes will wreck havoc by creating obscure bugs. So you need a hash table (I've posted the JASS script for indexing units using a hash table in this forum, you could probably search for it)
But the thing is, theres little point in rolling your own hash table system when the game cache basically is one - it uses natives so will probably be faster, it's far more flexible. It's got no strange bugs. The game cache is just one of those things you learn to embrace because it's Just That Good.

09-06-2004, 08:39 PM

Alfryd

After some investigation, I don't think something as complex as a hash table is really neccesary. The first unit registered on the map is typically 1024(X) (6000 something,) the second is 1024(X+1), the third 1024(X+2), etc, though these have been under simplified and standardised conditions. I'd rather look sequentially for gaps in the array and use Set/GetUnitUserData to remember the index than resort to the game cache, which is what I'm doing at present, but I've been vaguely hoping that the game already does something equivalant internally, which I can exploit. I think Weaddar mentioned something similar to this kind of system for indexing items, but it's been a while and I understood less about JASS at the time. I could be wrong.

09-06-2004, 11:10 PM	#6
AIAndy	What is your problem with game cache here?

09-07-2004, 08:27 AM

Alfryd

Quote:

Originally Posted by AIAndy

What is your problem with game cache here?

It's slow, and can't be reliably saved in multiplayer.

09-07-2004, 10:12 AM

Grater

Quote:

can't be reliably saved in multiplayer.

Utterly irrelevant.

Quote:

It's slow,

Using a "virtual custom value" function like this:

Code:

function SetHandleInt takes handle subject, string name, integer value returns nothing
    call StoreInteger(udg_VarCache, I2S(H2I(subject)), name, value)
endfunction

Is maybe 3 times slower than "SetUnitUserData", which is to be expected as it calls 1 user function (H2I) and 2 natives.

And even then you could easily call it 5000 times a second with no noticable lag.

Even if for some reason you need to call functions more often than that (and you don't), I seriously doubt you could write a faster version which is as reliable. And it'll definitely be much less flexible.

09-07-2004, 10:43 AM

Alfryd

Quote:

Utterly irrelevant... Even if for some reason you need to call functions more often than that (and you don't...)

Says someone who knows jack diddly squat about my intended application.

Look, if you don't know how I can do this using pointer values, then fine. But don't spam the thread with comments along the lines of "just use the damned game cache." I know how to use the damned game cache. I am purposefully choosing not to. Now can you help me with what I explicitly stated I wanted to do, or not? Thanks!

09-07-2004, 11:45 AM	#10
AIAndy	Now I am interested what that strange application is that has to lookup values several thousand times a second.

09-07-2004, 01:17 PM

#11

Alfryd

Quote:

Originally Posted by AIAndy

Now I am interested what that strange application is that has to lookup values several thousand times a second.

Not that it has any immediate bearing on the discussion, but I was looking to synchronise the positions of various pairs of units every 25th of a second. There might be hundreds of such pairs. No, I'm not going to give more details, but I was hoping to ensure smooth performance even on relatively low-end processors. Have you anything helpful to add?

09-07-2004, 02:01 PM

#12

Grater

Hmm, I was talking about a scenario involving 5000 operations per seocnd. Your right, I have no idea what I'm talking about. I mean I'm probably talking out my ass and have never tested a thing, and you know that 82% of all statistics are made up anyway.

I'll tell you this much, I guarantee that "SetUnitPosition" will chew up a lot more CPU cycles than a gamecache access (including on hidden/aloc'd units). Also, getting the custom value is very fast (about as fast as a call to a return bug function), I often store return bug references in custom value. I assume your probably using it for something else already? But again I wont know what I'm talking about when I guess that this something else will be less performance intensive than the position synchronisation (which surely has to be graphical in nature? like a roll-your-own special effect attachment?). In other words, use the custom value for the most intensive task and game cache for the other references.

PS. There is no way in hell you can get JASS to perform 25000+ function calls per second on a low end processor, that'd totally stall my XP1600+, even 25000 simple arithmitic operations per second produces very noticable lag . You'll have to revise your definition of low end or your algorithms. The 25000 number comes from 200 (units) x 4 (calls) x 25 (times per second)

09-07-2004, 02:16 PM	#13
Alfryd	This is all very constructive and fascinating, really, I appreciate it, but nevertheless has nothing to do with the stated topic for the thread. Could someone else here please stick with the plot..? Sorry.

09-07-2004, 04:23 PM

#14

Vexorian

Quote:

Originally Posted by Alfryd

This is all very constructive and fascinating, really, I appreciate it, but nevertheless has nothing to do with the stated topic for the thread. Could someone else here please stick with the plot..? Sorry.

well the thing is that you should use mod 8192 or if you are smart use game cache.

09-07-2004, 05:29 PM

#15

Cubasis

Hmm, seems like noone added one concern... eh,

but... Handle addresses increase with all types of handles created. So after a simple trigger has run, the address of the next handle created could be 25 higher, after the trigger created a couple of groups, locations and stuff. In fact, every trigger you create have addresses seperated by 3+. That is, the Trigger gets one handle, the Event gets one, and the actions gets one.

So... it doesn't take long to pass the 8192 cycle. So you're risking tons of bugs.

~Cubasis