Hi All,

First post - some simple questions for you. But first a bit of background...

I have a rough plan in mind of where I want to be in a year or so's time, and have decided to do some extra-curricular learning in around the subject area of creating a 3d engine. I've used several engines in the past (Ogre, Powerrender, Irrlicht) and have pretty much been shielded from the 'complexities' of DirectX and OpenGL. This time I want to know what is going on from the ground up, so have gone out and bought a shedload of books/bookmarked lots of sites.

I'm quite experienced with several languages (C#, C++, Java) but my journey has taken me onto a slight detour and have decided it is time to learn some Assembly. I have toyed with MIPS assembly and x86 and have a rough handle on how it all works with regards to registers, memory, operations, binary notation, hex and all that.

When I used the Ogre Engine, it has 3 outputs (or at least used to) - Software rendering, DirectX and OpenGL. I am interested in creating a pure software rendering engine as well as DirectX and OpenGL at a later date.

I have bought a book that was recommended - Zen of Graphics Programming by Michael Abrash. It is quite old. In it, it refers in great detail of how to squeeze the most out of the VGA. I have flicked through it, and at the moment, a lot of it goes straight over my head, but I'm sure with a little hard work it can be understood.

My questions are these - putting DirectX and OpenGL to one side for the moment, and concentrating purely on the Windows platform, how would one go about creating a software renderer today? Is the VGA still relevant? Is there a way of opening a screen and draw to it without relying on any additional components being installed?

I ask this because I have crossed paths with the Demo Scene and am interested in the 4k demos that they put out. Is it possible to write a renderer (2D at this point, for example a plasma effect) using for example the Windows API?

I understand that there are OOP libraries such as ObjASM and graphics libraries such as SDL that I can use but I want to keep it as simple as possible.

I have read source code for old demo effects that ran in DOS and I can test them using DOSBox. Is there a way of writing similar/equivalent code and having it run in windows without referring to DirectX?

Thanks in advance.
Posted on 2010-10-03 12:54:19 by steviedisco
You create a DIBsection, write directly to it and then display it on a window.

OR

You can create a DirectDraw7's surface and write directly to it.

OR

... many other options, actually ^^
Posted on 2010-10-03 14:41:28 by ti_mo_n

I'm quite experienced with several languages (C#, C++, Java) but my journey has taken me onto a slight detour and have decided it is time to learn some Assembly. I have toyed with MIPS assembly and x86 and have a rough handle on how it all works with regards to registers, memory, operations, binary notation, hex and all that.

When I used the Ogre Engine, it has 3 outputs (or at least used to) - Software rendering, DirectX and OpenGL. I am interested in creating a pure software rendering engine as well as DirectX and OpenGL at a later date.


This probably goes without saying, but - software rendering, whether using C/C++ or assembly is going to be dog slow.  No amount of register/opcode optimization is going to help you create a speedy little demo compared to using DirectX or OpenGL. Nor do you really want to get into the business of writing card specific drivers.  That's the main purpose of DirectX/OpenGL - to shield you from the hardware complexities and allow you to write software capable of running on a myriad of cards and output devices.  All 3D engines written today make use of those.


I have bought a book that was recommended - Zen of Graphics Programming by Michael Abrash. It is quite old. In it, it refers in great detail of how to squeeze the most out of the VGA. I have flicked through it, and at the moment, a lot of it goes straight over my head, but I'm sure with a little hard work it can be understood.


That book was great - for its day.  Michael did a bang-up job describing things such as Mode-X, swap buffers, register and memory optimization, etc..  However, while the concept of optimizing your code will always apply, many of the specific tricks he describes needs to be modified in order to successfully execute in today's environments.  Specifically, forget about writing directly to the graphic memory.  No modern operating system is going to allow you to do this.  Understand swap buffers though as they still heavily apply.


My questions are these - putting DirectX and OpenGL to one side for the moment, and concentrating purely on the Windows platform, how would one go about creating a software renderer today? Is the VGA still relevant? Is there a way of opening a screen and draw to it without relying on any additional components being installed?

I ask this because I have crossed paths with the Demo Scene and am interested in the 4k demos that they put out. Is it possible to write a renderer (2D at this point, for example a plasma effect) using for example the Windows API?


There is always WinGDI where you are basically blitting bitmaps here and there from within your 2d engine.


I understand that there are OOP libraries such as ObjASM and graphics libraries such as SDL that I can use but I want to keep it as simple as possible.


Even those use DirectX/OpenGL internally.


I have read source code for old demo effects that ran in DOS and I can test them using DOSBox. Is there a way of writing similar/equivalent code and having it run in windows without referring to DirectX?

Thanks in advance.


My personal advice - save yourself some time, forget about DOS, and learn to code with either DirectX or OpenGL.  Writing a small 2d engine can be done very easily using either.  You'll thank me ;)
Posted on 2010-10-03 18:54:22 by p1ranha

Specifically, forget about writing directly to the graphic memory.  No modern operating system is going to allow you to do this.


Actually, DirectDraw on Windows allows you to do exactly that. You can lock the frontbuffer (or backbuffer), and then obtain a pointer directly to the memory.
I believe on linux and similar OSes, DirectFB allows you to do pretty much the same thing.
My first steps in Windows graphics were basically to set up a DirectDraw environment which was very similar to mode 13h in DOS, so I could port over my DOS graphics stuff.
Posted on 2010-10-04 02:09:33 by Scali
Thanks a lot chaps. I know what I am trying to do is slightly masochistic, and I certainly don't expect to throw around the kind of polygons possible in a DirectX or OpenGL engine, just a little 3d cube and 2d effects.

You've given me a few keywords to go on there though, and some interesting ideas which I will investigate further.

I doubt I'll do much in assembler, but you never know where it might be useful, and it will enhance my understanding of what is going on under the hood.

Thanks again, and if anyone else has any further pointers, I'm all ears.

:)
Posted on 2010-10-04 06:00:42 by steviedisco


Specifically, forget about writing directly to the graphic memory.  No modern operating system is going to allow you to do this.


Actually, DirectDraw on Windows allows you to do exactly that. You can lock the frontbuffer (or backbuffer), and then obtain a pointer directly to the memory.
I believe on linux and similar OSes, DirectFB allows you to do pretty much the same thing.
My first steps in Windows graphics were basically to set up a DirectDraw environment which was very similar to mode 13h in DOS, so I could port over my DOS graphics stuff.


Yes, That is basically what I did as well to get my DOS graphics programs ported years ago.  It involved using DirectX to obtain the buffer pointer and lock -something that the OP was trying to avoid.  Thus, for the benefit of the OP - again I re-assert that, excluding DOS, you don't get direct memory access without using DirectX or OpenGL either directly or via some 3rd party graphics library (which will make those acquisition/lock calls internally anyways). 
Posted on 2010-10-04 07:10:42 by p1ranha
So, can I assume that every computer has directx installed and by extension, creating a directdraw surface and writing to that would count as software rendering?
Posted on 2010-10-04 08:51:25 by steviedisco
Yes, pretty much. DirectDraw has been part of DirectX since the first version. It was removed in DirectX 8, but all current Windows are still backwards compatible, so even DirectX 1 code will work in Windows 7.
And yes, that would be software rendering (there are a few hardware-accelerated things in DirectDraw though, such as page flipping and bitblting).
Posted on 2010-10-04 11:41:04 by Scali

Yes, That is basically what I did as well to get my DOS graphics programs ported years ago.  It involved using DirectX to obtain the buffer pointer and lock -something that the OP was trying to avoid.


Was he? I think I missed that part.
Or perhaps the confusion is about whether or not DirectX/DirectDraw/OpenGL require extra components to be installed?
Well, Windows comes with DirectX/DirectDraw out of the box.
As for OpenGL, this comes with the videocard driver, so in practice every Windows machine will also have OpenGL (the version may vary though). But I wouldn't recommend OpenGL for software rendering. Even if you want to make something that is multiplatform, I would not recommend OpenGL, but rather build a simple wrapper to set up a framebuffer to draw in, and implement a wrapper for each OS (pretty much what SDL does).
Posted on 2010-10-04 11:43:25 by Scali