Not logged inOpenClonk Forum
Up Topic Development / Scenario & Object Development / local vs. global coordinates
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%
- - By Clonk-Karl [de] Date 2010-04-03 15:48
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.
Reply
Parent - By Ringwaul [ca] Date 2010-04-03 18:49
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.
Reply
Parent - By Newton [de] Date 2010-04-03 18:59
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).
Parent - - By Caesar [de] Date 2010-04-06 21:41
[x] local coordinates including rotation
Parent - - By Carli [de] Date 2010-04-06 21:42
planet physics!
Parent - By Asmageddon [pl] Date 2010-04-11 12:00
I'd like that too :D
Reply
Parent - - By Asmageddon [pl] Date 2010-04-11 11:57
I would propose to make all coordinates global by default and variable in function, which sets them to local ones.
Reply
Parent - By MrBeast [de] Date 2010-04-11 12:08
SetCoordinateSystem(GLOBAL);
or what?
Reply
Parent - - By Sven2 [de] Date 2010-04-11 12:32
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.
Parent - - By MrBeast [de] Date 2010-04-11 14:57
State machines ftw!
Reply
Parent - - By Sven2 [de] Date 2010-04-11 15:44
Imo, that's even worse. It will introduce silent bugs into helper functions that internally assume one coordinate state but get another.
Parent - - By MrBeast [de] Date 2010-04-11 17:52
Not if you have proper push and pop thingies.
Reply
Parent - - By Sven2 [de] Date 2010-04-11 19:05
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.
Parent - By Caesar [de] Date 2010-04-13 16:48
The reason to have local coordinates, is that objects usually don't effect a fixed place in the landscape.
Parent - By Isilkor Date 2010-04-14 21:17

> 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.
Reply
Parent - - By Caesar [de] Date 2010-04-13 16:50
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.
Parent - - By PeterW [de] Date 2010-04-19 13:57
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?
Parent - - By Caesar [de] Date 2010-04-19 19:00
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.
Parent - - By PeterW [de] Date 2010-04-19 23:15
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.
Parent - - By Caesar [de] Date 2010-04-20 11:30
And int * is not possible, if I see that right?
Parent - - By PeterW [de] Date 2010-04-21 04:38
It's certainly possible, but takes up even more memory and is slower to access.
Parent - By Caesar [de] Date 2010-04-23 11:58
It will only take up even more memory, if the C4Value is of type Coordinate. In all other cases, it won't take up more memory. A benefit from having C4Coordinate would be, that there were less parameters to pass to functions. C4Value has a size, too.
Parent - - By Isilkor Date 2010-04-20 12:22

> 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.
Reply
Parent - By PeterW [de] Date 2010-04-21 04:36
For 32-bit builds, to be precise ;)

But yes, point taken.
Parent - - By NilsZ [de] Date 2010-05-16 18:47
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.
Parent - By Ringwaul [ca] Date 2010-05-17 02:33
I think, it may be easier to understand for beginners, but it is not the best solution imho.

>it often confused me wheter there are global or local coordinates.


This is why everything should be in a single format.
Reply
Up Topic Development / Scenario & Object Development / local vs. global coordinates

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill