longjoel's picture

2D graphics.

Greetings!

Hello everybody. This is my first post here, but I've been following the project for a while now. Each release is more and more impressive and exciting.

Something I have noticed though is that there isn't any functionality for handling 2D drawing beyond what is available through the core OpenGL implementation. I can understand why this is, because there is no single great way to handle it. For the last few years, I've been working on a drawing system based on OpenGL. It works with pre-OpenGL 1.5 and post-OpenGL 1.5. It handles drawing surfaces of arbitrary sizes in either case. It essentially tries to use a texture rectangle if possible, if it fails it falls back to using a simple tiling method.

The algoritms are sound and tested, I've used it in a few projects of my own, and it's been used in a few shareware games already. This library used to go by the name of hxRender when I was working on the C version. the .net version is much more sophisticated.

In my checked out copy of OpenTK, I have implemented it as Graphics 2D, and I would be more than happy to share what I have. Ultimately, If it meets community standards, I would like to see if it would be possible to contribute it to OpenTK itself. I've started a few open source projects, but haven't contributed to many.


Comments

Comment viewing options

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

Attatched: Source for changes I've added, and a small demo program.

I can also post the API documentation if you want.

This is clearly WIP. I still need to add some handling for doing sprite batching, but I wanted to show you guys what I have done so far.

AttachmentSize
Graphics2DTest.zip7.55 KB
Graphics2D.zip6.43 KB
Hortus Longus's picture

Hi.

longjoel wrote:

I can understand why this is, because there is no single great way to handle it.

Have a look in the Blogs-/Gallery-Sections, there are some helpers for that part. I personally use a mixture from these and sdldotnet, and and I am contently thereby. For 2D anyway, and in many parts even for 3D. Can you list my advantages with your library (when it is finally done)?

longjoel wrote:

In my checked out copy of OpenTK, I have implemented it as Graphics 2D ...

Oouch. "namespace OpenTK.Graphics.Graphics2D". I have executed your Test, and I believe, that is not a good idea. Perhaps in some years. (but I am only a member of the community)

longjoel wrote:

This is clearly WIP.

I think so. :-)
--
a friend of me wanted to become a large writer. I asked him: " which you mean with large". he said: " I would like to have millions readers, and they are to laugh with me and to cry with me.". Now he has his job, he writes error-messages for Microsoft.

longjoel's picture
Hortus Longus wrote:

Hi.

longjoel wrote:

I can understand why this is, because there is no single great way to handle it.

Have a look in the Blogs-/Gallery-Sections, there are some helpers for that part. I personally use a mixture from these and sdldotnet, and and I am contently thereby. For 2D anyway, and in many parts even for 3D. Can you list my advantages with your library (when it is finally done)?

Of course!
The goals:
*A fast, robust 2D graphics component that will scale well on systems that run OpenGL 1.2 to 3.0 and beyond using the same publicly facing API.
*A feature set roughly equivalent to that found in XNA as far as sprite batching, etc, goes.
*Speed matching the drawing routines in SDL, and in some cases, being faster. (Alpha blending, scaling, and rotations).
*Platform independence.

Quote:
longjoel wrote:

In my checked out copy of OpenTK, I have implemented it as Graphics 2D ...

Oouch. "namespace OpenTK.Graphics.Graphics2D". I have executed your Test, and I believe, that is not a good idea. Perhaps in some years. (but I am only a member of the community)

Can you explain what you found lacking? I admit the demo doesn't show off very much, just some rotation and scaling, and transparency, but can you explain a little further some of your concerns? Was it tossing you a runtime error or was there something in one of the methods that rubbed you the wrong way?

Quote:
longjoel wrote:

This is clearly WIP.

I think so. :-)

What features or changes would you like to see added or removed? I could put together a demo with stronger features if you like.
Thanks for the feedback!

Hortus Longus's picture
longjoel wrote:

The goals:
*A fast, robust 2D graphics component that will scale well on systems that run OpenGL 1.2 to 3.0 and beyond using the same publicly facing API.
*A feature set roughly equivalent to that found in XNA as far as sprite batching, etc, goes.
*Speed matching the drawing routines in SDL, and in some cases, being faster. (Alpha blending, scaling, and rotations).
*Platform independence.

Hmm, du you mean, when I use GL.PushMatrix(); than with your tool I should use sb.Push();, what calls GL.PushMatrix(); and goes back, the result will be fast?
I know, a computer is a magic thing, but at all I am not shure about this logic.
Look, when I am searching for a car, and a salesperson tells me, that his car can fly and has no fuel consumption, but he can not show this to me, I will get the car that plain drives. Do you get the point? ;-)
I am was running your program; such a thing was running before times on my Apple][, smoother. I was looking and looking, but where is OpenTK, where is your unique feature? I see a spinning smiley, ok. Tell me: what should I have to see?

longjoel wrote:

Can you explain what you found lacking? I admit the demo doesn't show off very much, just some rotation and scaling, and transparency, but can you explain a little further some of your concerns? Was it tossing you a runtime error or was there something in one of the methods that rubbed you the wrong way?

No, I want not to talk about art of programing, we are to different.
What really floored me mostly was your seizure of a part of namespace. Present to you, theFiddler decides to hang another part to the namespace OpenTK, OpenTK.Graphics.Graphics2D in this case. That will lead practically surely to collisions with your tool. In my opinion the assignment of names takes place via the owner, not via the user. You are not the owner. That, in my eyes, is a question of the courtesy, too. And what is in this case with users which use your tool? They have to restructure all their projects? Think ten times about it. ;-)
Perhaps do you think, OpenTL should no more use the namespace you have captured? I can not follow you by that.

longjoel wrote:

What features or changes would you like to see added or removed? I could put together a demo with stronger features if you like.

A demo? Then that is the wrong question. See it in such a way: I do not want to buy something from you, but you want to sell to me somewhat. I do not want to search what your tool can do, it is up to you to show it to me. I lean back then, looking the fireworks from your tool and say afterwards either what a trash or thumbs up. You understand what I want to say? Good.

Par example, in my projects we need to construct surfaces with more than ten methodes, du you sell me two methods; so what? I have no need to wait for the future. Many forums are full of plans what will come, only a few tools would grow up. First give your kind a face, then show it. Paper != result.

Imho put your tool to the Gallery; if anyone could need it, he will tell it to you sure.
Do not get me wrong, I do not reject your tool; I find your way ... ... let us say not particularly wise so far. ;-)

longjoel wrote:

Thanks for the feedback!

Always yours. ;-)

nythrix's picture

Granted I haven't looked into that project but I hope you don't mind me putting a few, hopefully "objective", lines in here.

First and foremost: every contributed code that aims at making OpenTK a bit easier to use without degrading its expressive power or even better adds new functionality is more than welcome. It sounds boring but those lines carry a close definition of what MAY end up in OpenTK.
Second: Putting together the code is only half the story. Existing OpenTK codebase has Fiddler quite involved. That's why there's no longer Font support (available project, anybody interested?). There just isn't enough free time. So you should be prepared to carry on further development by yourself until the code reaches some sort of stability. And you still may not be done, given the pace at which Khronos updates its specs.
Third: This isn't democracy. The community has its voice but ultimately Fiddler decides when and what. However, if the project is good with people supporting it, you're chances look good.
Fourth: Please keep any criticism constructive. This isn't business wars about loads of cash, for god's sake. Put your heads together and fix it. Cooperation should be open source's strongest weapon. Repeat with me: No, I WON'T put together another linux distro just because I don't like the existing 600 one's.

Side note: Placing code into OpenTK (or any other existing) namespace is not really a good idea. The W3C would tag the situation as "shouldn't". It's not a matter of backward compatibility, after all you don't expect that from a WIP, as much as the confusion it may cause to new users.

longjoel's picture
Hortus Longus wrote:
longjoel wrote:

The goals:
*A fast, robust 2D graphics component that will scale well on systems that run OpenGL 1.2 to 3.0 and beyond using the same publicly facing API.
*A feature set roughly equivalent to that found in XNA as far as sprite batching, etc, goes.
*Speed matching the drawing routines in SDL, and in some cases, being faster. (Alpha blending, scaling, and rotations).
*Platform independence.

Hmm, du you mean, when I use GL.PushMatrix(); than with your tool I should use sb.Push();, what calls GL.PushMatrix(); and goes back, the result will be fast?
I know, a computer is a magic thing, but at all I am not shure about this logic.
Look, when I am searching for a car, and a salesperson tells me, that his car can fly and has no fuel consumption, but he can not show this to me, I will get the car that plain drives. Do you get the point? ;-)
I am was running your program; such a thing was running before times on my Apple][, smoother. I was looking and looking, but where is OpenTK, where is your unique feature? I see a spinning smiley, ok. Tell me: what should I have to see?

You're right, there is no speed advantage to making the call to push matrix from inside my method vs just using the OpenGL method. I accept that. The reason it's there though is just to reduce complexity, make it simpler. You should be able to use this without having any prior knowledge of OpenGL.

Again, you are correct, this little demo doesn't do much at all, atleast, not as far as if you were to duplicate it in OpenGL. But try implementing it in a software only solution, such as what is present with SDL. Rotation, scaling, and blending are all expensive operations, especially with sprites of that size. With SDL, you have to rotate every pixel every frame, which is slow, or generate your rotations ahead of time, which is expensive in memory. With OpenGL, these operations are all offloaded to the GPU and can be executed quite quickly.

There is no standout unique feature. It just simplifies and reduces what is already going on. The big features are things you aren't going to notice which are going on behind the scene, such as determining whether or not to use a texture rectangle, or a tiled texture. You aren't going to notice that it preserves the stacks and attributes and pointers when you start drawing a sprite batch and restores the state when you are done.

Quote:
longjoel wrote:

Can you explain what you found lacking? I admit the demo doesn't show off very much, just some rotation and scaling, and transparency, but can you explain a little further some of your concerns? Was it tossing you a runtime error or was there something in one of the methods that rubbed you the wrong way?

No, I want not to talk about art of programing, we are to different.
What really floored me mostly was your seizure of a part of namespace. Present to you, theFiddler decides to hang another part to the namespace OpenTK, OpenTK.Graphics.Graphics2D in this case. That will lead practically surely to collisions with your tool. In my opinion the assignment of names takes place via the owner, not via the user. You are not the owner. That, in my eyes, is a question of the courtesy, too. And what is in this case with users which use your tool? They have to restructure all their projects? Think ten times about it. ;-)
Perhaps do you think, OpenTL should no more use the namespace you have captured? I can not follow you by that.

You're right, i'm not the project owner, it would be up to the project manager. But I should be allowed to attempt to contribute code, right? I fully accept that it might not get integrated, but I see no harm in trying. All I am doing is offering some code. Again, this is my first project I am attempting to contribute to, but I saw no guidelines for contributions posted.

Quote:

Side note: Placing code into OpenTK (or any other existing) namespace is not really a good idea. The W3C would tag the situation as "shouldn't". It's not a matter of backward compatibility, after all you don't expect that from a WIP, as much as the confusion it may cause to new users.

Future development will be done in a separate namespace. I'll start up a Google code project ASAP. Thanks. Is there a mailing list or an IRC channel as well as the forum?

nythrix's picture
longjoel wrote:

But I should be allowed to attempt to contribute code, right? I fully accept that it might not get integrated, but I see no harm in trying. All I am doing is offering some code. Again, this is my first project I am attempting to contribute to, but I saw no guidelines for contributions posted.

Absolutely. As I said before, everyone is encouraged to contribute. And you don't need to know any coding. Documentation/art and any other contribution is welcome too!

longjoel wrote:

Again, this is my first project I am attempting to contribute to, but I saw no guidelines for contributions posted.

Although marked obsolete these lines are still quite valid IMO.

Hortus Longus's picture
longjoel wrote:

The reason it's there though is just to reduce complexity, make it simpler. You should be able to use this without having any prior knowledge of OpenGL.

Good. Then perhaps it could be better to split that thing in two parts, the first part the SDL-like working-machine and the second part the UI. This would clear the code, too.

longjoel wrote:

But try implementing it in a software only solution, such as what is present with SDL.

Ok, in time I will search a piece of a running code and feed the lion.

longjoel wrote:

Future development will be done in a separate namespace. I'll start up a Google code project ASAP. Thanks.

Ok, your choice. I am not a friend of google, perhaps you have a look at sourceforge and so on.

--
The most fundamental problem in software development is complexity. There is only one basic way of dealing with complexity: Divide and conquer.