Posted Friday, 11 December, 2009 - 22:30 by the Fiddler
Quote:
What is the advantage of the current state?
It's simple, really:
usingSystem;
usingOpenTK;
z = Math.Max(x, y);
This didn't compile before the change. Now it does.
Quote:
Then there's .NET's "give classes and namespaces different names". Still, any resulting clashes are restricted inside the library and can be avoided by simply using OpenTK.Math; in affected files.
Not true, see above.
In other words, OpenTK.Math caused a constant and irreversible namespace conflict with System.Math. Weighted against a potential conflict with a 3rd-party library, I think the conflict with a system class is much more significant.
Posted Saturday, 12 December, 2009 - 00:08 by nythrix
Wait, what?
Just to make sure we're on the same wavelength here.
Let's say, I'm developing something on top of OpenTK. Then the following is perfectly valid:
// OpenTK.dllnamespaceOpenTK{publicclass CoreClass {}}namespaceOpenTK.Math{publicclass MathClass {}}// end of OpenTK.dllnamespace MyProgram
{usingSystem;
usingOpenTK;
publicclass Launcher
{publicstaticvoid Main(){int x = Math.Max(1, 2);
}}}
So, the only place where we face the problem is inside the OpenTK namespace/library. Which means half of my statement still holds. But you're right in that, I can't fix it the way I said. I have to specify either OpenTK.Math or System.Math every time.
Now, suppose you're a postman delivering into a building that houses two guys with the same name/surname. In order to make your job easier you certainly don't shoot one of them and deliver all the mail to the other guy's box. But you could ask one of them to tell his mailers to add additional info to his address (apt number).
A nice solution to most problems would be OpenTK.Calc.
Posted Monday, 14 December, 2009 - 08:37 by migueltk
Hello everyone, ...
No math is necessary to move to another assembly, a solution may be provided by nythrix, create a namespace to avoid ambiguity OpenTK.Calc.
This certainly seems the best solution and what is done in XNA should not influence at all in this or another open source project.
Posted Thursday, 17 December, 2009 - 17:50 by JeffM2501
Having math in a seperate assembly would be a benifit for games that uses a network server.
It is rather handy to have access to the OpenTK math on the server, a place where you don't need any kind of graphics or openGL (in fact on a headless machine that may not even have X ). It would make it easier to create simulation components that use OpenTK math that get shared on both the client and server (player/shot positions etc..). Using a third party math lib would make it harder to take the results of said shared components and use them with OpenTK drawing code on the client (i.e. my player sim class on the client feeds it's computed position directly into the drawing system, and on the server it just tracks it in a state).
Math may be heavily used by the graphics, but it's also useful for other things that are totally separate from a drawing app :)
I understand that a minimal OpenTK could be built for the server (using Mono), but that adds more setup cost to the server, and gets away from one of OpenTK's strong points, ease of use/deployment.
Posted Friday, 18 December, 2009 - 10:15 by Hortus Longus
Agreed.
@the Fiddler:
Looks like as if you would have found the ultimative Math-solution. ;-)
@other:
Two things you can do to make it simple:
1.) build your own DLL from the Math-folder; or
2.) copy the Math-folder into your project, add "using OpenTK;" to your project and use it.
Where is the problem?
--
The most fundamental problem in software development is complexity. There is only one basic way of dealing with complexity: Divide and conquer.
Posted Saturday, 25 December, 2010 - 00:09 by golkeeper
My vote is for separate math dll. IMHO if one develop graphical engine/renderer, he or she would prefer to encapsulate opentk/opengl interaction. Client interface of such renderer use various math types to specify transformations and so on. Conventions like "client app should not use any opentk functionality other then math" is not encapsulation.
Writing a math lib specially for this interface is boring and unnecessary:). Building Math lib from part of OpenTK source is not very convenient and looks like a hack.
So, what about leaving OpenTK.dll with math incorporated and providing math-only build option in OpenTK build system?
Comments
Re: Separate Math into assembly
What is the advantage of the current state?
It's simple, really:
This didn't compile before the change. Now it does.
Then there's .NET's "give classes and namespaces different names". Still, any resulting clashes are restricted inside the library and can be avoided by simply using OpenTK.Math; in affected files.
Not true, see above.
In other words,
OpenTK.Mathcaused a constant and irreversible namespace conflict withSystem.Math. Weighted against a potential conflict with a 3rd-party library, I think the conflict with a system class is much more significant.Re: Separate Math into assembly
Wait, what?
Just to make sure we're on the same wavelength here.
Let's say, I'm developing something on top of OpenTK. Then the following is perfectly valid:
So, the only place where we face the problem is inside the OpenTK namespace/library. Which means half of my statement still holds. But you're right in that, I can't fix it the way I said. I have to specify either OpenTK.Math or System.Math every time.
Now, suppose you're a postman delivering into a building that houses two guys with the same name/surname. In order to make your job easier you certainly don't shoot one of them and deliver all the mail to the other guy's box. But you could ask one of them to tell his mailers to add additional info to his address (apt number).
A nice solution to most problems would be OpenTK.Calc.
Re: Separate Math into assembly
Hello everyone, ...
No math is necessary to move to another assembly, a solution may be provided by nythrix, create a namespace to avoid ambiguity OpenTK.Calc.
This certainly seems the best solution and what is done in XNA should not influence at all in this or another open source project.
Re: Separate Math into assembly
... what is done in XNA should not influence at all in this or another open source project.
TRUE
Re: Separate Math into assembly
Having math in a seperate assembly would be a benifit for games that uses a network server.
It is rather handy to have access to the OpenTK math on the server, a place where you don't need any kind of graphics or openGL (in fact on a headless machine that may not even have X ). It would make it easier to create simulation components that use OpenTK math that get shared on both the client and server (player/shot positions etc..). Using a third party math lib would make it harder to take the results of said shared components and use them with OpenTK drawing code on the client (i.e. my player sim class on the client feeds it's computed position directly into the drawing system, and on the server it just tracks it in a state).
Math may be heavily used by the graphics, but it's also useful for other things that are totally separate from a drawing app :)
I understand that a minimal OpenTK could be built for the server (using Mono), but that adds more setup cost to the server, and gets away from one of OpenTK's strong points, ease of use/deployment.
Just my 0.02$USD
Jeffery Myers
3dspeeders
A silly experiment in C#
Re: Separate Math into assembly
Agreed.
@the Fiddler:
Looks like as if you would have found the ultimative Math-solution. ;-)
@other:
Two things you can do to make it simple:
1.) build your own DLL from the Math-folder; or
2.) copy the Math-folder into your project, add "using OpenTK;" to your project and use it.
Where is the problem?
--
The most fundamental problem in software development is complexity. There is only one basic way of dealing with complexity: Divide and conquer.
Re: Separate Math into assembly
The documentation index says "OpenTK.Math" at least :)
http://opentk.com/doc
Re: Separate Math into assembly
My vote is for separate math dll. IMHO if one develop graphical engine/renderer, he or she would prefer to encapsulate opentk/opengl interaction. Client interface of such renderer use various math types to specify transformations and so on. Conventions like "client app should not use any opentk functionality other then math" is not encapsulation.
Writing a math lib specially for this interface is boring and unnecessary:). Building Math lib from part of OpenTK source is not very convenient and looks like a hack.
So, what about leaving OpenTK.dll with math incorporated and providing math-only build option in OpenTK build system?