Isometric & Alpha-Blending
I''m working on an isometric engine in Delphi, non-DirectX.
I would like to know how to go about casting shadows and other light-related effects using alpha-blending. I think it has something to do with bitshifts, but I''m not too sure (hence this post).
Any ideas?
Merrick
"NPCs will be inherited from the basic Entity class. They will be fully independent, and carry out their own lives oblivious to the world around them ... that is, until you set them on fire ..." -- Merrick
Well your not using DirectX eh? Well what *are* you using?
First off if your going to do everything in software your going to have to know how to access each pixel directly? Can you do that?
Cause then you can get a pixel from the source bitmap and it''s corresponding pixel from the destination bitmap, mix them, darken them or whatever mathematically, then place it back in the destination.
Does that make sense? Once you can access all the pixels individually your set to make your alpha blending routine, so start by getting a simply blitter basically that will blit any rect to anyother rect from two different memory locations and jut blit an image, once you got all the addressing a basic pixel accessing code down, post back here and we can help you with alpha blending.
Take note I''m not sure how many people here use Delphi for games as it''s not really the industry standard, I mean I''ve seen WAY more games in VB than delphi, but heh maybe I''m just not looking hard enough for Delphi stuff.
Anyhow I don''t know Delphi but I can explain the concepts and most everything is also in the reference section here on GameDev so look there two, you''ll just have to convert C++ stuff to Delphi.
See ya,
Ben
First off if your going to do everything in software your going to have to know how to access each pixel directly? Can you do that?
Cause then you can get a pixel from the source bitmap and it''s corresponding pixel from the destination bitmap, mix them, darken them or whatever mathematically, then place it back in the destination.
Does that make sense? Once you can access all the pixels individually your set to make your alpha blending routine, so start by getting a simply blitter basically that will blit any rect to anyother rect from two different memory locations and jut blit an image, once you got all the addressing a basic pixel accessing code down, post back here and we can help you with alpha blending.
Take note I''m not sure how many people here use Delphi for games as it''s not really the industry standard, I mean I''ve seen WAY more games in VB than delphi, but heh maybe I''m just not looking hard enough for Delphi stuff.
Anyhow I don''t know Delphi but I can explain the concepts and most everything is also in the reference section here on GameDev so look there two, you''ll just have to convert C++ stuff to Delphi.
See ya,
Ben
__________________________Mencken's Law:"For every human problem, there is a neat, simple solution; and it's always wrong."
"Computers in the future may weigh no more than 1.5 tons."- Popular Mechanics, forecasting the relentless march of science in 1949
"Computers in the future may weigh no more than 1.5 tons."- Popular Mechanics, forecasting the relentless march of science in 1949
How much non Directx ?
My rts game only uses directx for accesing the screen, sound and network. The drawing routines are all my own. I use borland cbuilder for the editor (no directx at all) & msvc for the game
(most source code common to both)
I have some asm/c routines for drawing compressed sprites in my gfx lib, but I know nothing about Delphi.
Regards
Bill
http://serpentsoftware.com
My rts game only uses directx for accesing the screen, sound and network. The drawing routines are all my own. I use borland cbuilder for the editor (no directx at all) & msvc for the game
(most source code common to both)
I have some asm/c routines for drawing compressed sprites in my gfx lib, but I know nothing about Delphi.
Regards
Bill
http://serpentsoftware.com
I''m using a combination of API calls and inline assembler. I can access individual pixels easy : either pixels[x,y] := color or putpixel(x,y,color). Getting colors is not a problem : color := Getpixel[x,y]. As well as these I also use BitBlt, PglBlt & MaskBlt (all standard Windows calls).
I have a basic finished isometric engine. I''m working on deformable terrain as well. But I really want to get shadows & light out of the way to make it look REALLY good.
I know how to use both DirectX & OpenGL, but the whole exercise to me is NOT using them...
So, blitting & pixels I have sussed. Lead on...
Merrick
I have a basic finished isometric engine. I''m working on deformable terrain as well. But I really want to get shadows & light out of the way to make it look REALLY good.
I know how to use both DirectX & OpenGL, but the whole exercise to me is NOT using them...
So, blitting & pixels I have sussed. Lead on...
Merrick
"NPCs will be inherited from the basic Entity class. They will be fully independent, and carry out their own lives oblivious to the world around them ... that is, until you set them on fire ..." -- Merrick
Ok so now instead of just copying the byte(s) in your blitting loop you need to insert some new code.
Alpha blending equation:
result = ( ALPHA * ( srcPixel - destPixel ) ) / 256 + destPixel
Where: ALPHA ranges from 0 to 256
So in pseudo code:
Load srcPixel
Load destPixel
Subtract destPixel from the srcPixel
Multiply by AlphaValue (0-255)
Divide by 256
Add destPixel
Place this value into destPixel
No of course you''ve gotta do this on each colour compenent, so 24 or 32 bpp is REALLY easy. Oh wait when you "GetPixel(x,y)" it always returns a DWORD right? Or 4 bytes? or RGB? Cause you just gotta get out you red, green, and blue colour components then do that pseudo code on each colour component and place the pixel.
Now there are many ways to speed this up. But just get this one working, then I''ll see if I can find some good links on Alpha Blending using Windows API. I think I know where there are some good ones. (It was done in VB only, so it uses no assembler, or dll''s or anything, good for your goal of learning how to do it without LowLevel dependencies and such)
I''ll be back with that link in a while, in the meantime try to get this going!
See ya,
Ben
P.S. I guess I assumed you knew a fair bit about alpha blending, well this routine will blend the source over the dest picture with a varying transparency level, so if Alpha=128, you''d get a half/half look. I believe the lower the the alpha value the more it looks like the dest picture, the higher the alpha value the more it looks like the source picture.
Alpha blending equation:
result = ( ALPHA * ( srcPixel - destPixel ) ) / 256 + destPixel
Where: ALPHA ranges from 0 to 256
So in pseudo code:
Load srcPixel
Load destPixel
Subtract destPixel from the srcPixel
Multiply by AlphaValue (0-255)
Divide by 256
Add destPixel
Place this value into destPixel
No of course you''ve gotta do this on each colour compenent, so 24 or 32 bpp is REALLY easy. Oh wait when you "GetPixel(x,y)" it always returns a DWORD right? Or 4 bytes? or RGB? Cause you just gotta get out you red, green, and blue colour components then do that pseudo code on each colour component and place the pixel.
Now there are many ways to speed this up. But just get this one working, then I''ll see if I can find some good links on Alpha Blending using Windows API. I think I know where there are some good ones. (It was done in VB only, so it uses no assembler, or dll''s or anything, good for your goal of learning how to do it without LowLevel dependencies and such)
I''ll be back with that link in a while, in the meantime try to get this going!
See ya,
Ben
P.S. I guess I assumed you knew a fair bit about alpha blending, well this routine will blend the source over the dest picture with a varying transparency level, so if Alpha=128, you''d get a half/half look. I believe the lower the the alpha value the more it looks like the dest picture, the higher the alpha value the more it looks like the source picture.
__________________________Mencken's Law:"For every human problem, there is a neat, simple solution; and it's always wrong."
"Computers in the future may weigh no more than 1.5 tons."- Popular Mechanics, forecasting the relentless march of science in 1949
"Computers in the future may weigh no more than 1.5 tons."- Popular Mechanics, forecasting the relentless march of science in 1949
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement