Low-level stuff.
Author
Ok, I want to develop my own graphics system, mostly from scratch.
I just want to learn doing this (pointers, memory management, low-level stuff, just doing things on my own without knowing that this little function will load my file and etc.).... I just need fullscreen, so no window and other stuff is needed....
I was wondering, is there anything like a tutorial on what is needed, and how to go about this?
Once I did a few programs in DOS (yes, with a DOS compiler) and VGA memory (0xA0000000) and other stuff, but it wasn't compatible with Code::Blocks and GCC because GCC isn't a does compiler and Code::Blocks won't work with djgpp...
Well, I don't exactly NEED to start from scratch, but I mean having some kind of access to video memory and then just doing things on my own from there (creating classes for images, etc.)....
It'll be fun that way... Preferebly C++, although I guess C won't be ALL that bad...
Any tips?
I'm ok if you suggest some API or something, but atleast something that let's me manage the graphics manually rather than the API itself, unlike SDL/Allegro... Oh, and this is all simple 2D, ok? No fancy effects either.
I'm soooo excited to do something but I think I'm stuck with (no offence Watcom) ugly old command line compilers and Watcom C for DOS....
THANKS!
So to just say it in a few words, I am looking for a way to:
1) Set up fullscreen with dimensions (something like 640x480, nothing fancy).
2) Get access to video memory...
3) Do stuff myself.
You can't get direct access to video memory. However, that's not really important. Using GDI you can access a nice block of memory that you can consider a framebuffer and then use BitBlt to copy it to a window.
If you are thinking about 3D graphics *eventually*, books you might want to check out are "The Geometry Toolbox" and "Essential Mathematics for Games and Interactive Applications." They cover a lot of fundamental stuff very well -- online tutorials are usually not very good at this. The first book and even good parts of the second will also be relevant to 2D graphics, as well.
I don't know of any good resources offhand for regular 2D stuff such as drawing lines (Bresenham's Line!) and geometric shapes like circles and triangles, images, et cetera. However most of it is relatively straightforward stuff. Well I take that back, triangles and arbitrary polygons can be pretty fun. You'll want to look into one of scan-line rasterization, half-space rasterization, or edge-tables (best for polygons) for information about those topics.
I don't recommend you write *loaders* for a bunch of image types, however, as that's usually not worth it. I wrong a PNG loader once and I'll never do it again. Ick. Use existing libraries (like GDI+) to load your image data, get a raw pointer to it and copy it into your internal image class.
If you are thinking about 3D graphics *eventually*, books you might want to check out are "The Geometry Toolbox" and "Essential Mathematics for Games and Interactive Applications." They cover a lot of fundamental stuff very well -- online tutorials are usually not very good at this. The first book and even good parts of the second will also be relevant to 2D graphics, as well.
I don't know of any good resources offhand for regular 2D stuff such as drawing lines (Bresenham's Line!) and geometric shapes like circles and triangles, images, et cetera. However most of it is relatively straightforward stuff. Well I take that back, triangles and arbitrary polygons can be pretty fun. You'll want to look into one of scan-line rasterization, half-space rasterization, or edge-tables (best for polygons) for information about those topics.
I don't recommend you write *loaders* for a bunch of image types, however, as that's usually not worth it. I wrong a PNG loader once and I'll never do it again. Ick. Use existing libraries (like GDI+) to load your image data, get a raw pointer to it and copy it into your internal image class.
Essential Math for Games Programmers is the companion website to the book "Essential Mathematics for Games and Interactive Applications".
All you need to do is create a Device independent bitmap in windows using CreateDIB and you can write to the bytes directly. It is easy to blit or serialize from there.
GLUT - window API
I suggest you use GLUT to create the fullscreen window since the API is very easy to learn and use and does not require as much code as other alternatives (e.g. Win32). You can download the necessary library and header files from Nate Robin's site.
Note that setting up the fullscreen mode is slightly more complicated (a bit buggy too) than the windowed mode but is certainly worth the additional effort. Have a look at the lighthouse for tutorials on GLUT and specifically on GLUT's game mode.
OPENGL - graphics' API
You can use Direct3D or GDI but why not stick with good'ol OpenGL that is cross-platform? It'd be a shame not to since you've already selected GLUT. As jpetrie said, you can't access the video memory directly but why should you anyway. Work on a colour buffer and when you are done, just pass it on to OpenGL for rendering via glDrawPixels (or you could make a texture out of the buffer and paste it on a fullscreen quad...blah blah... ;)
Just make sure that the format of your colour buffer is the same as what OpenGL expects from you (e.g. don't tell OpenGL that you are using unsigned integers and then pass it an array of floats!)
As soon as you've got the whole system ready, then you can start experimenting with the buffer and the various 2-D rendering techniques.
I suggest you use GLUT to create the fullscreen window since the API is very easy to learn and use and does not require as much code as other alternatives (e.g. Win32). You can download the necessary library and header files from Nate Robin's site.
Note that setting up the fullscreen mode is slightly more complicated (a bit buggy too) than the windowed mode but is certainly worth the additional effort. Have a look at the lighthouse for tutorials on GLUT and specifically on GLUT's game mode.
OPENGL - graphics' API
You can use Direct3D or GDI but why not stick with good'ol OpenGL that is cross-platform? It'd be a shame not to since you've already selected GLUT. As jpetrie said, you can't access the video memory directly but why should you anyway. Work on a colour buffer and when you are done, just pass it on to OpenGL for rendering via glDrawPixels (or you could make a texture out of the buffer and paste it on a fullscreen quad...blah blah... ;)
Just make sure that the format of your colour buffer is the same as what OpenGL expects from you (e.g. don't tell OpenGL that you are using unsigned integers and then pass it an array of floats!)
As soon as you've got the whole system ready, then you can start experimenting with the buffer and the various 2-D rendering techniques.
Author
Thanks guys!
One more question: If I can't get direct access to video memory, then how are opengl, directx, gdi, gdi+, and others implemented? They must surely have access themselves, because how would they draw if they didn't?
One more question: If I can't get direct access to video memory, then how are opengl, directx, gdi, gdi+, and others implemented? They must surely have access themselves, because how would they draw if they didn't?
Quote:Original post by agi_shiWhy do you think you have to install a video driver?
One more question: If I can't get direct access to video memory, then how are opengl, directx, gdi, gdi+, and others implemented? They must surely have access themselves, because how would they draw if they didn't?
Quote:Original post by PromitQuote:Original post by agi_shiWhy do you think you have to install a video driver?
One more question: If I can't get direct access to video memory, then how are opengl, directx, gdi, gdi+, and others implemented? They must surely have access themselves, because how would they draw if they didn't?
To expand here a little.
DirectX and OpenGL are 'intefaces' that stand between video hardware and the games you are playing day by day. They can stand there because video card manufactures write their drivers DirectX and/or OpenGL friendly. 'The others' are just layers build on top of OpenGL or DirectX. You should really focus on building something that uses OpenGL or DirectX. You can go other way too but I would at least think twice before doing so
[Edited by - Calin on March 16, 2006 4:57:54 PM]
You can do your own stuff, write all your graphics routines and the like with DirectDraw7. You can create a primary buffer with one or two back buffers and then you would typically lock the last back buffer surface and write directly to the frame buffer (It gives you an address you can write to). Then when your game loop cycles through the flipping chain your graphics data will be displayed.
Hope this helps.
Hope this helps.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
