Quote:"A real game programmer can write a 3D engine from scratch with blood pouring out of his eyes, on fire, and with needles in his eardrums, as well as use 3D hardware.."So I gave myself a mental task, if i had a standard x86 machine, with no APIs etc (except a c++ dev environment, and maybe windows headers/dlls) , how can I plot a pixel on screen. So my first though was ok, im gonna write a struct POINT and will give it two memebers x,y positions. And thats where I came to a halt. I have a point in memory, now what. As I thought about it, I couldn't even picture the place I could start drawing that point out to screen. I've been reliant on the outside APIs/Libs for so long that all I know in my 2 years of programming is how to call a function. So I decided to embark on this huge, massive, discouraging quest, of plotting a single point to screen all by myself, i mean completely, completely independent. So as the title suggest i decided to write a software render, a word that almost everyone scorns these days. So Im here in the Beginners forum, not precisely for the exact code references of how I would go about doing it, but simply how do I start. This is my approach as what I managed to think out by myself 1. Somehow "aquire" the memory in video ram of my graphics card (up to now all I know about this is saying Lock(...) to pass in the buffer that comes back with that mem) 2. Input my point into that buffer, in some sort of format or something. 3. Allow the buffer to return to card so the card can draw it. This post is getting exteremly long so my first question is how can I bypass all the windows layers and talk to my graphics card directly. Thanks, Tim. [Edited by - VanillaSnake21 on May 6, 2007 11:38:07 PM]
software renderer?
Author
I just realized that I don't know anything about game programming. A quote that caught my attention is from Andre Lamothe's book on 3D Rasterization,
Author
Quote:Original post by Jimmy Valavanis
Ask the programmers who work in DirectX Development!
As I said, I'm not planning on using any API but rather building the whole renderer from scratch, so I don't think they can help me :D
This sort of thing isn't really feasible on modern operating system. Direct access to the hardware is a bad thing generally speaking - it's way too easy to make a mistake and cause serious damage or completely crash the computer (blue screen style or worse). If you want to write to video memory directly without using an API you need to be running in kernel mode. This means either writing a skeleton operating system that will run your software renderer or writing a custom driver that will write to video memory for you. Neither of these things is especially easy and if you make a mistake kernel mode debugging is not exactly fun.
You might be able to ask windows to emulate some sort of old DOS video mode for you, but this would mean writing 16bit DOS style code and that's not much fun either.
Honestly the best thing to do would be to make a buffer in system memory. Pretend that buffer is video memory and build the software renderer based on that. Then display that buffer to the screen in whatever manner you like. You could dump it to a window or display it using direct3d. Heck you could just lock a primary surface in direct3d and memcpy your buffer onto the surface.
You might be able to ask windows to emulate some sort of old DOS video mode for you, but this would mean writing 16bit DOS style code and that's not much fun either.
Honestly the best thing to do would be to make a buffer in system memory. Pretend that buffer is video memory and build the software renderer based on that. Then display that buffer to the screen in whatever manner you like. You could dump it to a window or display it using direct3d. Heck you could just lock a primary surface in direct3d and memcpy your buffer onto the surface.
This reminds me the old days when
the games were running in DOS and
the programmer accessed the Video-ram in x800000 memory address (or
something like that). I don't know if that can happen under Windows,
or if you 're able to bypass all layers and get a pointer to
the video ram.
Idea: Use a directdraw surface and transfer pure(software rendered) data
to that surface. Does this help?????
the games were running in DOS and
the programmer accessed the Video-ram in x800000 memory address (or
something like that). I don't know if that can happen under Windows,
or if you 're able to bypass all layers and get a pointer to
the video ram.
Idea: Use a directdraw surface and transfer pure(software rendered) data
to that surface. Does this help?????
Quote:Original post by VanillaSnake21
...So I decided to embark on this huge, massive, discouraging quest, of plotting a single point to screen all by myself, i mean completely, completely independent.
It can't be done, at some point you've got to interface with the graphics card driver, which would count as using an API :P
I guess you could download the one of the open-source gfx-card drivers for linux, and see how they interface with the hardware, but then you'd be limited to that one card, and your code wouldnt work anywhere else...
If I were to write a SW renderer, I'd just use GL to open a window, and limit myself to the GL functions that let you write directly to pixels.
Just use an API for actually drawing the pixels. I've written two 3D software rasterizers for school, one that used OpenGL and made a vertex at each pixel, then drew point lists, and another that used GDI to draw points (both approaches were pretty slow, so I'm sure you could do better). The point to doing this yourself is to learn all the math and such involved in a renderer, not the machine code to interface with your graphics card.
Author
The thing is - it's not the pixel plotting that I need, I currently have a semi-working game in development that does much more than pixel plotting. What I want is to actually work with the hardware without the APIs. Some suggestions were to use a surface to get the mem, but that defeats the whole purpose of what im trying to do. I think that by calling one of the APIs functions to fetch the mem for me, behind the scenes a couple of million lines of code is executed that I have no conception of. The graphic card calls are not like MatrixMultiply or other functions where users can guess what kinda of implementation the makers used, mem calls are some mysteryous portals that no one goes beyond, and that no one challanges =D.
cshowe mentioned that i need to get into kernel mode, or write a driver, both of these I am willing to attempt. At least now I have some lead as where to begin. Ok, kernel mode. How do I get in? As for the driver - that sounds like a very interesting idea - ive been dying to try out driver dev for a while, can someone elaborate on what the custom vid driver has to do. Thanks for the replies :)
P.S If there is any area that is physically impossible for one person to do please tell me, so if something that im asking about requires enourmous amount of code etc, that for one person would take months or years to even type, please gimme a heads up, thanks =)
cshowe mentioned that i need to get into kernel mode, or write a driver, both of these I am willing to attempt. At least now I have some lead as where to begin. Ok, kernel mode. How do I get in? As for the driver - that sounds like a very interesting idea - ive been dying to try out driver dev for a while, can someone elaborate on what the custom vid driver has to do. Thanks for the replies :)
P.S If there is any area that is physically impossible for one person to do please tell me, so if something that im asking about requires enourmous amount of code etc, that for one person would take months or years to even type, please gimme a heads up, thanks =)
Yes, you can (easily) talk to your graphics card directly, without an API: like Jimmy Valavanis said, you just need to write to the appropriate address.
It is definately feasible for one person to do it (how do you think people made games back in the DOS days?).
I started learning graphics coding from denthors tutorials, they are still around: (now in C!)
http://www.cprogramming.com/tutorial/tut1.html
That will give you an introduction to what to do.
If you want to go further and use "modern" resolutions and color spaces (32 bit color, 1024x768) you will have to learn about VESA modes (a lot more work), and probably there is something now that has superseeded that - I don't know what though : if your really that dedicated you could probably take a look at the linux drivers source code.
Good luck!
It is definately feasible for one person to do it (how do you think people made games back in the DOS days?).
I started learning graphics coding from denthors tutorials, they are still around: (now in C!)
http://www.cprogramming.com/tutorial/tut1.html
That will give you an introduction to what to do.
If you want to go further and use "modern" resolutions and color spaces (32 bit color, 1024x768) you will have to learn about VESA modes (a lot more work), and probably there is something now that has superseeded that - I don't know what though : if your really that dedicated you could probably take a look at the linux drivers source code.
Good luck!
Author
Quote:Original post by e64
I started learning graphics coding from denthors tutorials, they are still around: (now in C!)
http://www.cprogramming.com/tutorial/tut1.html
Thanks!!, thats some amazing stuff, I;m currently experimenting with assembly and I've been looking for ways to implemnt it in games, that site addresses my current issue as well as uses assembly :)
Quote:if your really that dedicated you could probably take a look at the linux drivers source code.
Is there anything for windwows? I just googled the topic and some intresing results came up for display drivers on windows, im trying to get the WDK (wndws driver kit) from MS Conneect righ now.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement