Thanks OutRider!!!

If i decided now, trying to make my own software rasterization, what tips could you give me?

I don''t want tips for algebra or related, I just would like to know, for example, how I''m going to post the images on the screen!

For example. Lets say I made a 3D software rasterization... It does all the calculus, and store the images in memory. All that I have to do, then, is to put it in the video-card memory.

So, my question is: How Am''I going to put the pixels in video-card memory?

Will I have to use something like glBitmap or glDrawPixels?

Thanks !

ok, when i said you can do texturing in 8bit mode, i was referring to doing your own software rasterizer. as far as i know openGL does not like 8bit mode for obvius reasons, the very low amount of colors combined with a pallete that must be managed effectivly.

as to me being rude, i think not, but the truth is i am giving him straight info without trying to cushion it so that i make one api look better then another nor make things look easy. the fact is a software rasterizer is difficult to make run fast. even with todays cpus, you can easily kill the bus bandwidth when doing your drawing. also i find it amazing such a powerful cpu has such a crappy video card. dont blame me in the FACT that early hardware vendors did not create good opengl drivers for their hardware if any at all. opengl simply was not as popular as it was back then, and d3d was a bit more cumbersome. i know ppl come to this forum to find out about opengl, but sometiems opengl is NOT the best choice for an application. even if they release it or not. he will not learn much if he can only push 10 polys at 4fps in 400x300 with many of opengls features off. personally i think he should get a better video card so he can learn both d3d AND opengl. i am not trying to bash him so he dont learn, its that there are simply so many newbies that believe all those myths of opengl being vastly better then d3d. and that if you use opengl you cant use dx for anything. simply nonsense. thoug the worst thing is that ppl actually think that doing 2d pixel plotting applications in opengl is simply idea since they are learning to use opengl. sad really, since opengl does not handle 2d pixelplotting too well. especially if you use those read/write pixel functions. heck i was able to write a faster program using the gdi in vb no less then using those horrid read/write pixel functions. now i know you can use sub2dpicture (forgot the exact name) to do faster pixel plotting, but the fact reamins with hardware support it will be slow.

as to d3d, quake2 did not use d3d at all. carmack hated d3d with a passion. though d3d now is a much different beast, i doubt carmack will ever look into doing an engine in d3d, but that dont mean you dont have to. he however did not hate all of dx, otherwise he would not be using directsound in quake2 and quake3. furthermore, i am pretty sure carmack uses directdraw in opengl modes, but only for switching resolutions and primary buffer mangament. in sotfware mode, he merely plotted his pixels to the buffer and flipped. i only mentioned using d3d since it has an 8bit rasterizer which is somewhat usable compared to the slower opengl software implmentations. this is mainly because ms cut many features out, and dropped quality as they should. also do the glide renderer, was done ONLY so quake2 would run on more 3d hardware. opengl is not designed for mulitple vide cards and cannot handle having secondary accelerators on a pc. carmack knew this and did everyone a major favor (including himself since voodoo2s were the big cards back then) by including 3dfx support. opengl was meant for scientific imaging and not for gaming. though it is not a slow library by any means (in fact in certain systems/tasks opengl is fatser then d3d and vice versa making them quite equal in a performance standpoint), it does not give as much control over the hardware that dx does (you cant for instance poll for mulitple video cards nor switch the current screen resolution/color depth). opengl is graphics only, while dx is graphics (directdraw/d3d/directgraphics(which is really just a prettier d3d with no directdraw)), sound (directsound), input (directinput), network (directplay), multimedia video/audio playing (directshow). never forget dx is not just graphics and is why imho dx is better then opengl. though i think d3d (in dx8 anyway) is on par with opengl, especially with todays hardware which is less finicky about opengl support.

as to starting on your own rasterizer. very rewarding. however be prepared to work for it, since in the long run you will have quite an achievment few ppl today can say they have done. if you want to get pixels to the screen, do NOT use opengl. it is simply horrible at 2d operations. i highly suggest either the gdi or directdraw.

using the gdi: (for those who hate dx)
dont expect much control. changing video modes is very problamatic and is best not to be done. accessing pixels however is quite quick. just make sure you use DIBs and blit that to your windows DC. since dibs give you direct memory access to the pixels, it is quite fast. do NOT use SetPixel() or GetPixel(), they are why ppl think the gdi is uber slow. granted directdraw is faster, you can make fast things in the gdi as well. th performance difference between directdraw in window and the gdo (as long as you stay with a colordepth that is the same as the screen) is almost the same. though this is only if you are doing a lot of direct pixel accessing.

using directdraw: (make sure you use directdraw and not dx8)
you get easy methdos to change the display mode. though initilizing can seem daunting at first, once directdraw is inited you simply will be plotting pixels. most likly you will create a double buffer in video memory. and then a third buffer in system memory. the reason for the buffer in system memory is because if you plan on doing any reads from the image buffer (for alpha blending) it is much quicker to read from system memory then from video memory. then you just:

...
do vertex lighting
transform polys
Lock() system buffer
draw polys
Unlock()
blit to back buffer
flip()

alternativly you could do away with the system buffer and just create your own memory buffer and do:
...
transform polys
do vertex lighting
Lock() video back buffer
copy your image buffer
Unlock() video back buffer
flip()

this methd may be better and easiers ince you dont have to worry about locks() except for you copy to video memory. though you will lose the hardware assisted blit from system memory that many agp cards can do. in the long run i doubt you will see a performance difference since the flip is free (the hardware ussually just flips pointer so no memory bandwidth is used).


EDIT: one more thing, iwas not being sarcastic nor witty in that last reply nor this one. i simply am stating opions and facts. i truly thing writing software engines is becoming a lost artform. ppl are too concerned with graphics and forget the gameplay portion. you dont need trilinear filtering or per pixel bump mapping and lighting. look at rez, jet set radio, and other games with stylized graphic. you dont need photo realistic rendering for good art.


Edited by - a person on January 28, 2002 2:28:15 AM

Here''s a though : in 8 bits mode you can "simulate" a R2G3B3 mode just by using an appropriate palette.

I quoted the SGI OpenGL specs above, but here is a similar quote from the redbook (just to be complete): page 246 ''Keep in mind that texture mapping works only in RGBA mode. Texture mapping results in color-index mode are undefined.''

Making your own software rasterizer is a possibility. You will learn quite a few things and gain lots of experience doing that. But it''s not easy.

- AH

quote:

---

Original post by a person
using the gdi: (for those who hate dx)
dont expect much control. changing video modes is very problamatic and is best not to be done. accessing pixels however is quite quick. just make sure you use DIBs and blit that to your windows DC. since dibs give you direct memory access to the pixels, it is quite fast. do NOT use SetPixel() or GetPixel(), they are why ppl think the gdi is uber slow. granted directdraw is faster, you can make fast things in the gdi as well. th performance difference between directdraw in window and the gdo (as long as you stay with a colordepth that is the same as the screen) is almost the same. though this is only if you are doing a lot of direct pixel accessing.

---

I''m being just curious : How do you access directly to the pixels of a DIB? Is there any function of Win32 API that returns a pointer to a given DIB?