objarni's picture

GL.LoadMatrix(Matrix4) overload..?

I wanted to use the LoadMatrix method of the GL class.. found lots of overloads, but none of them taking a Matrix4 (or ref to it ..) as an argument.

Is this a known issue or should I put up an item about it somewhere..? (where?)

Overall I'm so far very pleased with my OpenTK experience.. Keep up the good work!


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Inertia's picture

I guess you can see why I dislike 'ref' -- it is already passed by reference to me!
For classes that is true anyway, if it really bothers you with structs you could wrap them into classes. Maybe that's just what you need? You could assign only get {} properties to make it immutable, so the constructor is the only way to change any members.

[Dogfight]
Indeed, the old Amiga games had usually very good controls and much more focus on gameplay mechanics than graphics. My first game for XNA was a remake of a classic too, those kind of games are achievable and a rather good motivation.

[VS2005]
Upgrading projects from 2005 to 2008 is uncomplicated (wizard helps). Just asking because I'm occasionally having trouble using the online-help (it will just show "topic not found").

objarni's picture

For classes that is true anyway, if it really bothers you with structs you could wrap them into classes. Maybe that's just what you need? You could assign only get {} properties to make it immutable, so the constructor is the only way to change any members.
Wrapping a basic API-level type as Matrix4 into an immutable class, say Matrix4c where 'c' stands for 'constant', is one possibility. But writing expressions using that type soon become cumbersome, unless I overload all operations used. Not elegant and error-prone too. But of course, once it's done it's done; matrices and their operations have been the same for the last couple of hundred years I hazard :). Maybe I'll consider this once OpenTK0.3.14 is out with a corrected Matrix4 implementation. Thanks!

But anyway right now I've followed your previous advice and I'm staying with GL.Translate/Rotate instead of sending the transform matrix in the method MeshAt (which I've renamed to DrawMesh simply), and this is working out great. It is also more natural since I'm used to this method.

Now onto Text rendering!

Inertia's picture

Indeed that's one of the great things about OOP, it allows constructs that are much closer to human ways of thinking. Sure you will have to write quite some overloads to get this working, but if using structs really bothers you that much it *can* be done :)

btw. did you see the OpenGL Articles in the Documentation? http://opentk.sourceforge.net/home/?q=node/141
I think Fiddler is in jail and only has 5 mins inet per day or so ;-) I could really use some feedback if they are on the right track or totally off? One issue is: things are rather simple using C# and OpenTK, I don't really know what else to cover in most topics, without artificially stretching the pages by quoting or adding pictures?

objarni's picture

btw. did you see the OpenGL Articles in the Documentation? http://opentk.sourceforge.net/home/?q=node/141
I think Fiddler is in jail or so

Yeah where is the Fiddler :) I'm really eager for the new OpenTK version to be downloadable hehe

and I could really use some feedback if they are on the right track or totally off? One issue is: things are rather simple using C# and OpenTK, I don't really know what else to cover in most topics, without artificially stretching the pages by quoting or adding pictures?

Well I liked the fast-read through I did now, especially that about VBO's (http://opentk.sourceforge.net/home/?q=node/144). But I guess that is because I've wondered how VBO's are used/thought of by someone with the knowledge. For Dogfight I'll go with good-old Display Lists though, but for future enterprises it might be nice.

In general, I think the documentation of OpenTK should be about "the glue" inbetween GL/AL and C#. That is: how do you use the classes, how should you think while developing a GLControl application / GameWindow application, more than how to draw OpenGL primitives. There are TONS of documentation about GL out on the net, and replicating that information is just a waste of resources. If OpenTK is close enough to the C API OpenGL, all that is needed is a way of mentally translating C-API info about GL into OpenTK's lingua, if you know what I mean. For example:

http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/gl/...

That is quite easy for me to translate into OpenTK lingua, since I know all gl* method are in the GL class:

GL.DepthMask(true);

I really don't need this translated into exact OpenTK lingua, and as a high-level user of OpenTK (programming games using OpenTK) I can't see anything wrong with OpenTK's documentation lacking that piece.

What would be really nice would be lots of examples of specific techniques to be well documented, for example the last few days I've been spending lots of time searching/traversing files in order to get the following (rather simple) things to work alright in OpenTK:

* How to render Hello World on a Windows.Forms/GLControl
* How to render Hello World on a GameWindow
* How to achieve frame rate independent animation (measuring time) in a Windows.Forms/GLControl application
* How to achieve frame rate independent animation (measuring time) in a GameWindow application

That kind of pragmatic and hard-to-find information is really useful as OpenTK documentation. And not just examples! The examples are good for demonstrating what is possible / benchmarking / testing purposes on different platforms, but they are not optimal when it comes to readability / documentation! I remeber once I downloaded DirectX SDK and saw their samples/examples. They were more like demos, they were usually *very hard* to read, at least in my opinion.

Of course, all this is my 2 cents only :)

Inertia's picture

Thank you, that's what I assumed too. Articles explicitly demonstrating use of Techniques is probably what 80% of the Documentation will be like. I didn't see how to avoid the topics Vertex and Primitive Type, this is essential to know for beginners.

replicating that information is just a waste of resources
Indeed, but still there must be some kind of documentation showing the differences to the C API. Since the OpenGL bindings come from a generator there's no .

P.S. Sorry if replies are slow, retouching the Articles in the book.

Inertia's picture

objarni: ...the performance-politics against me here
I'm afraid this is inevitable, because when people hear "managed code" they usually start arguing that C(++) assembler is much faster. This was (is?) also a main topic for XNA, I really wish I could find the video again they made about unmanaged vs. managed code.

In that video one programmer from Garage Games showed a port of their game Marble Blast running in XNA. He said that the managed C# XNA version has 98% of the performance of the unmanaged C++ DX version, which was used to port. These 98% were achieved with a straight port, as in no XNA specific optimizations.

If you think you have better luck googling for it, I'm rather sure the video was made 2006 at a Microsoft conference (Gamefest?).

Inertia's picture

Correction:
I've missed a function that could use a Matrix4 overload

GL.MultTransposedMatrix()

also what I said about GL.Get* the Matrix from GL is not the only option. You can get the transposed Matrix directly from GL, see link

http://www.opentk.net/node/172

JTalton's picture

I've been working on Vector, Matrix, and Quaternion structs. I wrote a test program and made sure that the Matrix code was completely compatible with OpenGL. I personally need double precision so I have implemented both single and double point precision. I tested the performance of implementing them as immutable classes vs structs and structs were a lot faster. Immutable does not really give you much when you are working with structs since any time you pass one it creates a copy (unless by ref). I then did performance testing on passing by value vs by ref of structs, and of course the pass by ref was much faster. I also tested operator overloads vs function calls and function calls were MUCH faster since things could be passed by ref and not copied.

While not the most elegant, it is as fast as I can make it.

objarni's picture

Since this is an example of an as-ugly-as-it-gets situation, I think it is the most interesting comparison performancewise:

1) pass-by-ref structs in methods eg.
Vector3.Add(ref v1, ref v2, out result)

2) operator overloaded classes eg.
Vector3 result = v1 + v2;

How many percent slower was 2) compared to 1) ?

JTalton's picture
Timing Tests
 202 : a.Add(ref b);
 236 : Vector4D.Add(ref a, ref b, out c);
 252 : a.Add(b)
1110 : c = Vector4D.Add(ref a, ref b);
1172 : c = a + b;

So by my tests, it is over 4 times as fast, which is significant enough to justify UGLY,
and I do agree that the pass-by-ref structs is a ton uglier then an overload.

I think the performance is related to the size of the struct since much of it caused by the copies.
I performed the same test with Vector4F which is half the size and had much of the same results.

Vector4D Add Functions
    public void Add(ref Vector4D vector);
    public void Add(ref Vector4D vector, out Vector4D result);
    public static void Add(ref Vector4D left, ref Vector4D right, out Vector4D result);

I also have an implementation of Vector4d that is an immutable class,
and it's performance is MUCH worse than the struct implementation.