A while ago i asked some questions about optimizing for a software 3d renderer im writing. One tip was to "keep it 16 bit". I assume he/she meant pixelformat. My Q: Wouldn''t 32bit format be faster? What im going at here is that transfers are in 32 bits (over busses etc...right?) & Todays CPU like 32 bit mode (faster pipe) better than 16 bit. The one reason, i could think of to stay in 16 bit, is the smaller amount of data to be processed. But isn''t 16 bit processed/treated as 32 bit but with 2 "dummy" bytes? Even if this "32/16" might have a smaller impact on performance im still curious what you guys think. (I don''t know that much about CPU arcitechture so please correct my "assumes" in the above Q)

for the data alignment of 32bit..

why not just send always 2 pixels at a time ahah?

but i suggest to use 32bits anyways, because i guess its much more easy to get this fast.. the conversion to 16bit should be done with mmx else it will be much much much much too slow to be fast at all.. for the conversion from for example float to 32bit, you only need to convert to unsigned chars, wich you can do much faster and simpler (by just taking the mantissa, shift by the exponent of the float and use the 8 most important bits.. or so important will be to do clamping..

oh, for the conversion from 0.f <-> 1.f to unsigned char 0 <-> 255, just divide the float by 255, add float(1<<23) to it, and grab the first byte of the float ( unsigned char byte = ((int&)((float_var/255.f+float(1<<23)))>>24)
)

i''m not sure if this code works at all, but the idea is this..
oh, and use mmx anyways

well if you are writing a software rasterizer you should stick to 16bit because bandwidth is the major problem you will have. conversion of floats is completly silly since you should store your color info in how you are using it (ie 16bit). doing it in 32bit is easier, but it will be slower since you are transfering twice the data for the same number of pixels. also keep the res low. bilinear filtering may be too slow though its possible to implement quite fast, its not free like on a 3d video card. plus this should not be in this forum since you wont be using opengl for a software rastirizer, you would use directdraw, sdl, or the gdi.

16bit is NOT nor has ever been treated as 32bits with 2 dummy bytes. and because of this statement along I suggest you learn how to deal with 2d pixel drawing before even delving into do a 3d software renderer. also learn about computers and how they work, its quite esstenial otherwise you will have a hard time programming.

dont use mmx, you dont understand basic 2d concepts yet and using asm will only confuse you even more. first get things working then optimize.

My own suggestion is to use 16 bit over 32 bit in most software renderers (except perhaps those where accuracy is extremely important, and speed doesn''t matter), for the said reasons above. Also, I agree that if you don''t understand this, try 2d programming first, because you will definitely need it if you wish to make a software renderer. Of course, if you could manage your 3d engine in 8 bit mode (Or you could have each texture have its own palette, and have the video mode in 16 bit, so then you''d just have lookups with the textures. Kind of.), you should be able to make it faster yet, but it''s not pretty trying to do lighting if you only have one palette... Finally, before you go off venturing into 3d programming, check out 3d math. Good luck, and happy coding!

Actually i already got a version up & running, but it''s soooo slow, that''s why im asking theese silly questions.

Thanks.