Linux, C# and a way to draw a pixel?
Hi all. I'd like to learn some basic drawing stuff (lines, triangles, towards own 3D stuff maybe). I already got something done with C/C++ and SDL, but I didn't like the speed (it was just horrible) and the most bothering issue was the C language syntax stuff etc (ie. it isn't managed...). I've already used to C# too much :) I have a spare box lying around where I have installed LFS (Linux From Scratch) and it is in its most basic state now. I was thinking that I try to code something with it, but using C#. How/where should I get the DrawPixel() -function? :) All the other drawing I would do myself.
I'm not using X, so should I use framebuffer? DirectFB or something like that? Should I first do a little wrapper in C/C++ then invoke it with C#? Only requirements I have that it is fast... Thanks for your help!
Err.. C was slow? I don't mean to offend you but C has potential to be a lot faster than C#. Yes I know that C# can come quite close to C and sometimes be even faster than C++.
Your "3D stuff" is doomed to be incredibly slow if you use a function (or methdod) to draw a single pixel. Instead you should draw some kind of primitives (such as polygons) and do the pixel drawing inside a method (or a function) with simple operations like memory access through pointer (or equivalent in C#) which don't require a additional calls to functions.
If it has to be fast, look-up for OpenGL (in case you have a 3d-card). I'm not sure if you can use it without X. While there is no tie between X and OpenGL, but there just isn't any drivers that creates OpenGL context for you outside the X.. atleast I presume so. Try freshmeat.net or sourceforge.net to find OpenGL drivers for DirectFB (example Mesa3d) in case i'm wrong.
Your "3D stuff" is doomed to be incredibly slow if you use a function (or methdod) to draw a single pixel. Instead you should draw some kind of primitives (such as polygons) and do the pixel drawing inside a method (or a function) with simple operations like memory access through pointer (or equivalent in C#) which don't require a additional calls to functions.
If it has to be fast, look-up for OpenGL (in case you have a 3d-card). I'm not sure if you can use it without X. While there is no tie between X and OpenGL, but there just isn't any drivers that creates OpenGL context for you outside the X.. atleast I presume so. Try freshmeat.net or sourceforge.net to find OpenGL drivers for DirectFB (example Mesa3d) in case i'm wrong.
Ok, sorry, I was a bit unclear. I meant that SDL was terribly slow when I tested these things (using X of course). I used the SDL methods of drawing a pixel and lines and then flipping things. I did it with C++ and then gave up because I was able to draw few triangles with a fps of about 50. Then I switched to windows for a while and now I'd like to try again with the new faster box and without SDL and X.
I have done things with OpenGL and DirectX, but now I'd like to study how these things really work. Starting from the line drawing algorithm and going to the 3D stuff, you know what I mean now?
Yes, I understand that it would be terribly slow to call a separate function for each pixel draw, but I used it as a metaphor, or something like that ;) All I really would like to know, is that what is the best method of "drawing a pixel to the screen" using linux while not using the X server (and SDL)? And I appreciate if it could be then somehow be used from C# (not necessarily straight, but through a C wrapper maybe?).
I'd like to use C# because of its cleaner syntax and managed nature. I'm not targeting huge performance with my own algorithms, but the pixel drawing should be fast...
I have done things with OpenGL and DirectX, but now I'd like to study how these things really work. Starting from the line drawing algorithm and going to the 3D stuff, you know what I mean now?
Yes, I understand that it would be terribly slow to call a separate function for each pixel draw, but I used it as a metaphor, or something like that ;) All I really would like to know, is that what is the best method of "drawing a pixel to the screen" using linux while not using the X server (and SDL)? And I appreciate if it could be then somehow be used from C# (not necessarily straight, but through a C wrapper maybe?).
I'd like to use C# because of its cleaner syntax and managed nature. I'm not targeting huge performance with my own algorithms, but the pixel drawing should be fast...
Well, atleast DirectFB and SVGAlib allows you to write pixels without X. What is the best way? DirectFB should be hardware accelerated... I can't help you with C#, though. Sorry..
Thanks a lot for your help Winograd, I see you're from Finland too ;) I think I'll manage to figure something out from the DirectFB or SVGAlib. We will see... Luckily I have a spare Matrox G200 to be used (it seems to have very good driver support).
Quote: Original post by Winograd
Well, atleast DirectFB and SVGAlib allows you to write pixels without X. What is the best way? DirectFB should be hardware accelerated... I can't help you with C#, though. Sorry..
SVGAlib is old, obsolete and have been removed from all linux distros due to security issues (it allows direct access to video hardware).
I would recommend using GL for triangles and such. SDL usually is not accelerated under linux.
I'm using C#. For windowing and input I'm using SDL and for graphics I'm using OpenGL. I'm actually making a 2D engine with OpenGL. If I'm happy with the way it turns out I'll probably release it open source.
If SDL and C were too slow for you you were probably doing something wrong; C# won't help that. (I like it better than C, too; speed just isn't the reason to use it.)
If you want to investigate 3D yourself I would recommend working with a surface in system memory then blitting it all at once. That way you won't have to talk to the graphics card for each pixel you want to draw.
I really do think SDL is a good way to do this, unless you want to use C or write your own interface to a framebuffer library. Maybe using SDL was slow the way you used it, but if you code your app right it should be good.
If SDL and C were too slow for you you were probably doing something wrong; C# won't help that. (I like it better than C, too; speed just isn't the reason to use it.)
If you want to investigate 3D yourself I would recommend working with a surface in system memory then blitting it all at once. That way you won't have to talk to the graphics card for each pixel you want to draw.
I really do think SDL is a good way to do this, unless you want to use C or write your own interface to a framebuffer library. Maybe using SDL was slow the way you used it, but if you code your app right it should be good.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement