SC2Mapster

@joemart06: Go

I suggest you revisit pointers. The code you posted does not do what you think it does (it will actually cause a decent C compiler to complain about type mismatch).

But all of this is moot, because Galaxy doesnt support pointers. The closest you can get is what JademusSreg posted.

I would not consider loop unrolling until you have a finished version of the script. Stuff like loop unrolling is so low-level, that you should never do it manually. Not until you have exhausted every other algorithmic improvement possible and profiling indicates that that specific loop is a the bottleneck or a big part of it.

And after you tried optimizing code at such a low level do another performance test to see if what you changed actually improved things.

Reasons for this are that undoing loop unrolling is harder than unrolling a loop, the overhead of loops is minimal at best, so only the tiniest loop bodies are worth unrolling, and you might be focusing on these micro-optimizations before actually having exhausted algorithmic improvements, which usually provide far better benefits.

Ill just leave this here: http:deaod.de/GalaxyTypes.txt

If i remember this correctly, handle variables can hold values of types that extend handle. Also, variables of types that extend handle can be assigned values of type handle, but those variables will become null if the value is not of a matching type.

Short answer: Yes.

Long-ish answer: You can look at what StormLib supports (feel free to contribute) here: http://www.zezula.net/en/mpq/stormlib.html

http://www.sc2mapster.com/forums/development/galaxy-scripting-and-trigger-lib/38374-passing-arrays-as-parameters/

IIRC, the origin of the coordinate system is in the lower left corner. A photon cannon for example has a footprint size of 2x2 in in-game units.

@Renee2islga: Go

Typedef seems to be the only way. I suspect its an error in their grammar for galaxy, ie. the grammar only allows Identifiers to be used inside arrayref<>, and not Identifiers + Array Dimension sizes. It might not be an error, but rather a deliberate omission.

I gather this might be unknown to some, so heres a demonstration of how to use arrayrefs to pass arrays to functions. The trick is to use typedefs to mask the array.

typedef int[2] array_int_2;
array_int_2 array; // could be int[2] array; as well

void Test(arrayref<array_int_2> instance) {
    instance[0]=instance[0]-1;
    if (instance[0]>=0) {
        Test(array);
    }
}

void Init() {
    array[0]=50; // makes Test call itself 50 times
    Test(array);
    // after this, array[0] should be == -1
}

Notes:

• arrayrefs check the size of arrays. You cant pass arrays of different sizes to arrayrefs.
• You cant use non-array variable types for arrayrefs.

Notes on other reference types:

• funcrefs cant be used as an array when the return-type of the prototype is void (JademusSreg discovered this).
• structrefs and arrayrefs cant be used outside local variables and parameters (as the editor will happily inform you).

How is DistanceZ implemented on your end? Maybe there are some possible implementations that cause an overflow (thank Blizzard for that) for stationary objects that are very far apart.

EDIT: Or, of course, there really are stationary objects that somehow overlap.

Galaxy doesnt allow locals to be declared after the first non-declaration statement.

The variables uh and ch are not read inside the function. But anyway, how often do you call this function? How many units are active? Unless you can get high values for i, this function shouldnt be that costly for a single pair of units.

Galaxy has an internal limit for how many instructions can be executed by a single thread in a single frame. If you get the Taking Too Long error, youve exceeded the limit.

Yes, splitting the work up into multiple threads (triggers usually start a new thread, but maybe there are other ways as well, someone with more experience should know) would solve the issue. But maybe you can optimize the function that gets called for every unit, so that it doesnt take as long to execute.

Think about how your algorithm is structured. Maybe sacrifice some memory for speed (caching or indexing results). If you provide your code, we can be more specific about how you could improve your code.

Quote from Eiviyn: Go

Photon Cycles gameplay is not based on Tron lightbike gameplay

I never claimed that.

Edit:

Jademus brings up the valid point that maps abusing the popularity of a particular IP has barely ever produced good results. Others (noone on this site, but professional critics) have brought up how cash-ins typically fail, while products in other mediums produced independently can have high quality.

You and others come in and accuse Jademus of hypocrisy without addressing the point he brought up. Classic Tu Quoque. I point out how even your Tu Quoque is based on a Strawman.

You of course dont like to hear that and first use an Ad Hominem to discredit my point.
Then you keep using literal meanings of words (to deny the points i brought up), inferring meaning into other words (Lightbikes is not a term exclusively used by Tron), and a good dose of insults to pander to your audience.

Quote from Eiviyn: Go

First it was "Photon Cycles doesn't reference Tron", which it clearly does.

It doesnt. I havent seen Tron written anywhere in that map. Since youre going to use this against me, ill just mention it right now: I did make claims to the contrary (that Photon Cycles does mention Tron to explain gameplay). Sreg did a good job of explaining the gameplay without mentioning Tron in his announcement post, so i dont think hed have to mention Tron in the map itself.

Quote from Eiviyn: Go

Then it turned into "Photon Cycles copies gameplay, not content.", which it also clearly does.

Which again, it doesnt, since bike design bears no resemblance, and floor design is so minimalistic that its hard not to have some kind of resemblance when going for minimalistic visuals. The walls use the users color, yes, but they too are so minimalistic that one could argue its a gameplay feature.

Quote from Eiviyn: Go

Now it's "that copying gameplay and copying lore are two very different things and that Photon Cycles doesnt copy lore, since Photon Cycles doesnt need and have any", which makes an unfalsifiable claim out of lack of information.

Yes, because gameplay and lore are such loaded terms that you cant decide whether or not Photon Cycles uses Tron lore. If you werent too busy proving me an idiot you might also notice that i even mentioned Tron lore in my initial post (i used dismember then).

Bonus: http://en.wikipedia.org/wiki/Tu_quoque

I can pull informal fallacies out of my ass as well. Only this one is actually relevant to what started this argument.

Youre great. Just keep going. Maybe some day youll actually address the point i was making (that copying gameplay and copying lore are two very different things and that Photon Cycles doesnt copy lore, since Photon Cycles doesnt need and have any).

We can of course quibble about my usage of "reference", and id concede that its the wrong word to use. Photon Cycles does reference the visuals of Tron, in that its a vehicle resembling a bicycle spawning an impenetrable wall behind it. But this is very basic and is a good working explanation for the gameplay.

Your snide remark about admitting when one is wrong works both ways, remember that.

Yes, Photon Cycles followed Tron Legacy. But my central argument is that Photon Cycles copies gameplay, not content. While a Hunger Games based map would copy content, not gameplay.

I can call you stupid as well. But that doesnt further an argument, it just derails it. So either tell me where my argument falls down or shut the hell up. This is just noise injected into a discussion.

Edit: I read the announcement post of Photon Cycles again, theres one mention of Tron, and that one is part of the name of another map with similar gameplay.