Home of the Open Toolkit library

hi there!
is there a quick and reliable method to find out what functionality is deprecated and what is not? for me, using opentk goes hand in hand with learning opengl. and whenever i go google for some tutorials or code snippets, i find a lot of forum messages that say "dont use this, use that instead, its been introduced in opengl x and deprecated in opengl y". some disagree with each other, some seem to confirm each other, and some seem to be plain wrong.
anyone knows a quick way to verify those?

alright. its easier than i thought it would be^^
now i have a small follow up question. if i generate a random number of variable sized textures per frame, how would i draw them? up to now my text rendering works like that. now that begin/end is deprecated, whats the way to go for one-by-one texture drawing? or is it possible to bind a new texture while rendering a vbo?

now that begin/end is deprecated, whats the way to go for one-by-one texture drawing? or is it possible to bind a new texture while rendering a vbo?

You don't. That's one reason why the immediate mode (begin, ..., end) was abandoned, because it allowed very (VERY) inefficient drawing code such as the one you are using, switching the texture for every character or string you use (if I understood you right and this is how you draw the text). Every texture change costs performance, thus you shouldn't do it. However, with multisampling you would have the possibility to bind several textures and use them arbitrarily in a shader (-> the little program where all non-deprecated drawing will happen), but this is also not the suggested method for text rendering.

If you want to render text efficiently (I think there are a lot of tutorials on the web), you have two general approaches:
1) Create an image file that contains all drawable characters in your desired font in some kind of grid such that you can calculate the position of each character in the image. For example, you could divide the image into 20 x 20 pixel cells and write 'a' in the first one, 'A' in the second, 'b' in the third etc.. The next step is to write a translation function which translates your characters in the application into those cell coordinates and stores them in a texture coordinate buffer, normalized to [0..1]. The third step is the rendering in the shader which should be straightforward then.

2) This is the preferable one in .NET in my opinion, because it is much more flexible. You use the Bitmap class to create an image in the memory. Then you can use the writer method Graphics.DrawString() to write the text you want to this bitmap. The resulting bitmap can be uploaded to the video memory as a texture. The final step is to draw a (fullscreen) quad textured with the bitmap texture. There is a sample code in the OpenTK forum which uses deprecated methods for the drawing step, however, but you should not fail on drawing a forward-compatible fullscreen quad.

thank you for thorough answer.
i pretty much do the second approach, but i draw every string into individual textures, not one full-screen texture. looks like i have to render each of them using a vbo that is filled with a single quad to replace my glbegin/glend thing. no big deal, but somewhat counter-intuitive^^

The most efficient way to do this would be to use one texture for all strings. Is there a reason why you don't do that? Do you post-process (e.g. blur) some of the strings or something? You could just use a static List - or maybe a struct that additionally saves the position, size, color, font etc. to the string - to collect all strings to be drawn, then iterate through all of the entries once per frame and write all strings to a single texture according to their position and font attributes. Finally, draw the texture using a fullscreen quad. There would be an overhead in uploading the image, since it would have to be the screen resolution and not only the size of the string to be drawn, but it would not require using multiple textures, multiple texture uploads etc. and should thus be quite comparable. I'd give it a try :)

the reason is that graphics.drawstring() is made for regular gui usage, not for realtime applications. so i think its rather heavyweight with all measuring, kerning, ligatures and so on. i dont want to use it to draw the whole screen content again and again each frame. i simply hold the textures on the gpu and reuse them. its reasonably fast, nothing to worry about. some overhead for creating new and kicking out unused textures is there, but its few lines.
with its glbegin/glend clauses its not opengl 3.2 compliant, this is what bugs me^^

Well, you don't have to redraw all strings if they are static. Updating only string that you want onto the bitmap and using GL.TexSubImage2D() to upload the updated part of the texture is perfectly fine.

I don't see why you could possibly not be happy about the removal of the immediate mode - OpenGL is so much better now! :)

well, i wouldnt say that i am not happy about it. its necessary to do a cut at some point and remove some of the stuff that has grown into the api, no doubt about it. its just that i am surprised how much effort you have to put into drawing a single quad.