Poll
Switch to only local or only global coordinates?
Leave things as they are | 5 | 14% | |
Use local coordinates everywhere | 20 | 57% | |
Use global coordinates everywhere | 10 | 29% |
In CR and previous titles there was often confusion between local and global coordinates because some engine functions use local coordinates (CreateObject, FindObject, ...) and others use global coordinates (PathFree, SetCommand, ...). So we should consider changing all functions to use the same kind of coordinates. This is an informal poll to find out whether scripters prefer local or global coordinates for everything.
Local coordinates require less typing in typical situations but global coordinates have the advantage that coordinates are the same for everything in C4Script especially including the scenario script.
Local coordinates require less typing in typical situations but global coordinates have the advantage that coordinates are the same for everything in C4Script especially including the scenario script.
I think that it seems more logical to make everything in a single fomat, as you have suggested. Personally, I would prefer everthing to be local.
Local coordinates are used by the vast majority of functions and in my opinion, this is the right way to go. The standard use case of any object is just that it searches/does/checks for things that are relative to their object position. For any other cases, there is AbsX() and AbsY(). If you search in the source, you will find that it is used in something like 2% of all cases where positions are given. I imagine that to use global coordinates everywhere will just introduce another source of error to which all scripters and actually especially the experienced scripters are highly prone to.
In scenario scripts (when no object context is available), the functions just work like with global coordinates (as if the object were at 0,0), I see no problem with that.
As a result, I am strongly against option three while option 1 or 2 look equally OK (as it is really a minority of functions which use global coordinates everywhere).
In scenario scripts (when no object context is available), the functions just work like with global coordinates (as if the object were at 0,0), I see no problem with that.
As a result, I am strongly against option three while option 1 or 2 look equally OK (as it is really a minority of functions which use global coordinates everywhere).
I would propose to make all coordinates global by default and variable in function, which sets them to local ones.
Having an additional parameter to remember for each function would suck. It's easier to have them all local and use AbsX/AbsY when needed, or to have them all global and use +GetX and +GetY when needed. At least, then the "switch to global" marker is directly visible on parameter passing, as opposed to another ", true, " or ", false" in the parameter list.
Imo, that's even worse. It will introduce silent bugs into helper functions that internally assume one coordinate state but get another.
It's still a concern everyone would always have to think about whenever a function uses coordinates. And to be consistent, anyone writing a helper function would have to implement both local and global coordinates, too. Because otherwise, there would be *three* possible coordinate system: Local, global and the "local or global depending on state".
It's just that: Added complexity. It's also the reason I wouldn't mind just making all coordinates global. The onlky reason I can think of that local coordinates are useful is e.g. in functions like CastObjects, where you can just leave out the coordinate parameters to create stuff at object center.
It's just that: Added complexity. It's also the reason I wouldn't mind just making all coordinates global. The onlky reason I can think of that local coordinates are useful is e.g. in functions like CastObjects, where you can just leave out the coordinate parameters to create stuff at object center.
The reason to have local coordinates, is that objects usually don't effect a fixed place in the landscape.
> The onlky reason I can think of that local coordinates are useful is e.g. in functions like CastObjects, where you can just leave out the coordinate parameters to create stuff at object center.
We could check if the coordinates are nil, and default to the current object center.
Oh, let's introduce a new type. C4V_Coordinate . Knowing where it is, and behaving local whenever it comes into object context. + Easy transformation when rotating.
Have been thinking about that, too. A couple of ideas about that:
* How to fit into C4Value? Use higher and lower word? FIXED is already capped at 2^15, but:
* Could actually use FIXED directly? Might solve the whole precision confusion as well.
* Simply use 2-element array? Might be costly for something used so frequently.
* How to write it? "localXY(x, y)" for object-local coordiantes and "globalXY(x, y)" for global ones?
* How to fit into C4Value? Use higher and lower word? FIXED is already capped at 2^15, but:
* Could actually use FIXED directly? Might solve the whole precision confusion as well.
* Simply use 2-element array? Might be costly for something used so frequently.
* How to write it? "localXY(x, y)" for object-local coordiantes and "globalXY(x, y)" for global ones?
Internally: int [2] coords; (That's what coordinates are right now, two ints)
Written: Coord() and GlCoord() I still think, global coordinates in object context are unusual.
But, this was more or less a joke. It would be handy, but not that important. SoftFloats are much more important, imho.
Written: Coord() and GlCoord() I still think, global coordinates in object context are unusual.
But, this was more or less a joke. It would be handy, but not that important. SoftFloats are much more important, imho.
The problem with int [2] is that it will double the size of the data-portion of all C4Values the engine uses. We have always tried our best to avoid that, even though we lack proper benchmarking to back the theory with numbers.
It's certainly possible, but takes up even more memory and is slower to access.
> The problem with int [2] is that it will double the size of the data-portion of all C4Values the engine uses.
"Only" on 32-Bit systems.
I think global coordinates are easier for beginners. Because when i tried to script in clonk the first time, it often confused me wheter there are global or local coordinates.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill