32, 24, 16, or 8 bit?
masterbooda	I am currently working on DaBooda Console(or OldSchool) and the resolution is going to be 320x240...DirectX7(yes I am going through backward evolution here) Well here is the problem... I need some input here on this.. I was going to use 8bit to have palette support, but I am using a method to actually access memory of the backbuffer.. seeing this I can now emulate palette support which is better. Also I know some people(my bro) who cannot even run 8-bit at this resolution. I do not want the same problems that DaBooda Turbo has, and this is of course lack of support. I need to know if 16bit(which is a pain when it comes to color conversion... like 555 or 565 issue), 24 bit which is good but some computers switch the green and blue which is a pain. 32 bit which is fantastic, but I am worried about support again. The question I suppose(after endless rambling) is: Do you think everyone can support 32bit color at 320x240? DaBooda Out... P.S. Any input would be appreciated on this point. For anyone interested, this emulator is using strict byte manipulation(bit shifting and such), there will not be a single Blt statement in the entire thing. If I pull this off, expect a tutorial on this... thats a promise Eric.
Walrus	Well, 320x240 32-bit works for me. But here's sth else: my card supports 32-bit, but not 24-bit. Is that wierd?
Eric Coleman	Also, voodoo cards support 16bit only. Most video cards will be either 16bit or 32bit. The best solution is to detect what the video card can support and use whatever is available. I would simply limit it to 16 or 32 bits since those are the most common.
Crysstaafur	With the issue of alpha support, 24 and 32 modes are striaightforward, I don't think it will be a problem with 16-bit either if we simply convert the needed alpha value into a decimal composite(0.0->0.1->...0.9->1.0) and use it in the alpha module(rightshifting each composite) we talked about earlier. I suspect this mainly has to do with the way color is actually managed on the cards. Some in some modes flip a g for a b. sans rbg instead of rgb. Would there be a way to rearrange hardware color returns back into a normal set of composites?
masterbooda	Here is a problem I am now encountering with 16bit resolution... My card deciphers the two bytes as gggbbbbbrrrrrggg... this is very strange and I can create a conversion for it.. But I also know that some cards arrange the two bytes like bbbbbgggggrrrrrn... the n being null which again I can convert... but I need a method of finding out which cards use which method and using the proper color conversion.. Again universal support would have been lovely here, but we all know how this goes... but I believe 16bit is the way to go, for it seems to be the most supported, just a pain in the rump to convert colors.. As for the method... I simply just have the user entering values of 0 to 31 for color levels... because 11111 is 31 for red and blue in method 1 and 111111 is 63 for the green value wich is really just 32 x 2... its the splitting of the green to compensate, which is going to be the fun part... and a sorely wish vb would let you do straight bit manipulation like 1000 + 0001 = 1001... this would be simple but I will have to do it with bytes... Any ideas or tutorials on color conversion in 16bit would be greatly appreciated... DaBooda out...
2dcoder	Hello,
2dcoder	"P.S. Any input would be appreciated on this point. For anyone interested, this emulator is using strict byte manipulation(bit shifting and such), there will not be a single Blt statement in the entire thing. If I pull this off, expect a tutorial on this... thats a promise Eric." Wow, I've seen some BlitzBasic type routines that do stuff like this. Sounds like a fun retro project, good luck!
masterbooda	I am going to use 16 bit color... I figured out a way to convert the color into two bytes and the reason I was reading it wierd was because in memory the bytes are flipped... so after figuring this out it was pretty easy.. and dx7 has some handy built in features for reading color bit masks(slapping head and saying duh)... and the only thing that changes is sometimes the green is 6 bits and others its only 5 bits, so very easy to convert the difference... This method is truly great, I have run this thing on a cheap computer with a nil integrated video card and it ran just fine... the only problem I see is it is pretty processor intensive but with a little optimization we should get the fps up there... it doesn't really tax the video at all... I have it running about 45 to 50 fps on my 400mhz celeron with a good card, and about 70 on a 1.2 with crap card, so its pretty even tempered on video. Of course this is compiled, at uncompiled its 7 fps... crazy, but true... of course this engine will be compiled into a dll so this won't be an issue.. Thanks for the comments and I will keep progress posted, maybe I will even post a demo to see if compatibility is going to be an issue at all.. and yes DaBooda Turbo is going to be on the back burner awhile sorry guys... but this is too interesting to put down... DaBooda out... P.S. I know I sound excited about this, and I am, and this has most likely been done before in vb. But this method opens up all kinds of possibilitys... imagine palette animation, zooming, rotation, even alpha blending in directx7 with no loss of performance and total compatibility... this is why I am excited.. but I will try to tone it down.. lol.