• Advertisement

Archived

This topic is now archived and is closed to further replies.

Alot of tutorials but they dont help....

This topic is 6451 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
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 surface

SetPixel(DC, x, y, RGB(r, g, b));

ReleaseDC(/*whatever*/);



remember to lock the surface first though.

Share this post


Link to post
Share on other sites
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~

Share this post


Link to post
Share on other sites
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!"

Share this post


Link to post
Share on other sites
// 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

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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

Share this post


Link to post
Share on other sites
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 <censored> they can make half-<censored>ed work.

Share this post


Link to post
Share on other sites
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?


Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
- Speaking of tutorials that don''t help, , ,
The second example in the MS D3D book (the first to use D3D) returns 385 errors when attempting to compile it, after following the book''s own instructions. Many of the errors are themselves obviously wrong; such as for the line

LPDIRECTDRAW7 m_pDD;

the first eror says ''no ";" before identifier m_pDD''.
?
Book: P 54, file CD3DFramework7. There ain''t supposed to be no ";" there.
The compiler is set to the DX7 search paths. The instructions (on page xxii) say nothing else to do. I yam stumped. - Lubb

Share this post


Link to post
Share on other sites
to Gladiator: If you think % is too slow for you, try to replace %n with &(n-1) -- assuming that the compiler isn''t intelligent enogh to replace the modulo by an and.
Should be faster than the extra shifts Staffan used.

Share this post


Link to post
Share on other sites
I'm speaking of % in general... so you optimization is not going to work at all times (it's gonna work with 2^n only)... and yes, it's going to work in this case, so it'd be pretty fast... I've never debuged on the % operator, so I have no idea what the assembly code looks like, but if VC++ is smart enough to optimize it ..-=[]=-.. that'd be great...

Edited by - Gladiator on June 27, 2000 3:39:40 PM

Share this post


Link to post
Share on other sites
- Okay, some days I be a stupid. I toyed with a DXMedia sample proj and then a D3D sample proj, and even tho'' I changed the dirs, the include and lib dir''s were still on DXmedia when I looked again.
I don''t know why , but anyway.
Some days I''m just special .
I do appreciate the tolerance though. - Lubb

Share this post


Link to post
Share on other sites
quote:
Just a Q...how would you GET the pixel RGB values from a DWORD or whatever it is?


For a 24 bit colordepth (0888) it''d be something like this:

    
// The colorcoding goes according to this:

// 00000000RRRRRRRRGGGGGGGGBBBBBBBB


unsigned long color = 0xFF00FF; // magenta

r = color >> 16; // 0xFF00FF >> 16 -> 0x0000FF (255)
g = (color & 0x00FF00) >> 8; // (0xFF00FF & 0x00FF00) >> 8 -> 0x000000 (0)
b = color & 0x0000FF; // 0xFF00FF & 0x0000FF -> 0x0000FF (255)


"Paranoia is the belief in a hidden order behind the visible." - Anonymous

Share this post


Link to post
Share on other sites

  • Advertisement