Advertisement

Alot of tutorials but they dont help....

Started by June 25, 2000 06:46 AM
15 comments, last by Macke 24 years, 5 months ago
I struggling with probably the most common problem with DirctDraw. The 16bit plot pixel problem. I use this code to figure out if its 15 or 16 bit. CODE: ddsd.dwSize = sizeof (ddsd); ddsd.dwFlags = DDSD_PIXELFORMAT; lpddsprimary->GetSurfaceDesc (&ddsd) int g = ddsd.ddpfPixelFormat.dwGBitMask>>5; if(g == 0x1F) colormode = 7; //RGB = 5-5-5 else if(g == 0x3F) colormode = 8; //RGB = 5-6-5 else {error = "Wrong colormode"; return FALSE;} CODE ENDS! But the problem is that I havent got a macro that works to convert RGB values to an integer. I have tried dozens of macros but they only work on some colors. Is there a macro that actually works? Or is it wrong with my code above?
id you dont mind losing a bit of speed, you could use GDI functions to plot the pixel for you.

GetDC(/*whatever*/); //get DC of destination surfaceSetPixel(DC, x, y, RGB(r, g, b));ReleaseDC(/*whatever*/); 



remember to lock the surface first though.
Advertisement
First, POINT, I think you didn''t read his post exactly, because he is searching for the RGB macro you are even using in your snippet.
Second, I would recommend to NEVER use GDI functions in the way POINT did. Trust me, Windows GDI is REALLY slow, and for direct pixel manipulation and such stuff, it''s even multiple times as slow! Only use GDI functions if REALLY, REALLY necessary, or to load Bitmaps to Memory before you draw anything, but only in moments when it''s not too bad if something steals all your cpu''s power, for example on level-loading and such.
For the Macro, look at the GameDev Tutorial section under DirectDraw, somewhere there were some examples on it, even on your topic, blits in every resolution. Just have a look.

hope it helps

pi~
Jan PieczkowskiBrainwave Studios
GDI may be slow, but if you''re making an adventure game and the target platform is for 486''s and Pentium I (100 mhz), then GDI works fine. Exile is proof of this! Don''t underestimate GDI.

- DarkMage139
"Real game developers don't change the rules. Real game developers don't break the rules. Real game developers make the rules!"
"Originality (in games) is the spice of life!"
- DarkMage139
// gbits should be 5 or 6 depending on the color coding (555/565)
// Takes three values ranging from 0-255
RGB16(r,g,b) (((r >> 3) << (gbits + 5)) + ((g >> (8 - gbits)) << 5) + (b >> 3))

That _should_ work if i typed it in correctly. That was what you were looking for, right?

Edited by - Staffan on June 25, 2000 10:00:42 AM
quote: GDI may be slow, but if you''re making an adventure game and the target platform is for 486''s and Pentium I (100 mhz), then GDI works fine. Exile is proof of this! Don''t underestimate GDI. - DarkMage139

- - - Not to appear arrogant, but (since you''re in the same country as I am) the last time I looked at the local electronics specialty store, the cheapest generic PC''s they had ($500) were 300 Mhz PII''s. Considering that rolling your own is usually a bit cheaper than buying a complete system off the shelf, anyone who would build one themselves isn''t likely to build one with a processor slower than that. - There are many countries where people can''t buy new PC''s, but those are the same places where bootlegging software is rife anyway, because they can''t afford that either. So who gives a **** if a game won''t run on a 100 Mhz machine? You might as well code for DOS. - Lubb
Advertisement
I don''t believe it is possible to underestimate the GDI ;P
Stop the madness.

And building a machine (or anything for that matter) usually cost more; generally because you don''t buy crap in the aftermarket - unlike OEM equipment.

PC, auto, homes, whatever... OEM''s buy the cheapest piece of flaming &ltcensored> they can make half-&ltcensored&gted work.
- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara
Thanks Staffan. That was exactly what I wanted. I shall see if your code works.

I have already looked on gamedevs tutorials and used their code but it didn''t give the correct colors. Some gave a magenta instead of white for rgb(255,255,255) and another gave green.

Anyone else who got their own macro?


RGB16BIT(r,g,b) ((b%32) + ((g%64) << 6) + ((r%32) << 11))

That's what I use, and it must work since my whole engine is based on it...

That's for 565 btw

Edited by - Rappler on June 26, 2000 5:03:00 PM
"The Gates of Pearl have turned to gold, it seems you've lost your way."
It does but it''s DOG SLOW... Staffan''s macro would work a lot faster... 3 modulus operators for every single pixel... wow.. doesn''t seem so efficient...

-Viktor

This topic is closed to new replies.

Advertisement