Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / reading rgba-values of an image and input handling

Author
Message
Hierro
16
Years of Service
User Offline
Joined: 22nd Mar 2008
Location:
Posted: 1st Apr 2008 17:03
heyoha,

i'm currently developing a 2d-game using dark gdk and box2d and need two things i wasn't able to find in the documentation:

1) i load an image and want to get its rgba-values on a certain position, but unfortunately wasn't able to find a function handling this?

2) with dbKeyState, dbLeftKey, dbRightKey,... i can find out if a key is currently pressed. that's nice but not exactly what i need: i want to handle only button-down events (when a button is pressed i only want to do certain things once and not all the time when the button is pressed...) and not "button pressed"-events. how can i do this using dark gdk?

greetings and thanks in advance!
ErDa
16
Years of Service
User Offline
Joined: 17th Feb 2008
Location:
Posted: 1st Apr 2008 19:53
Your first question is similar to the one i just posted, so I can't help you with that. For the second however:



This should work nicely i think. What it does is that it executes the commands if 1 is 0, then changes i to 1 until dbRightKey is released.
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 1st Apr 2008 20:15 Edited at: 1st Apr 2008 20:16
I can't address the image question at the moment, though I wish I could. But with regards to the keyboard you might have to do the same thing that I did with the mouse, which behaves the same way. I have to keep a variable (bool mouseIsClicked) and react differently depending on whether the mouse was previously clicked. Below is the code I use.



The downside is that you pretty much have to constantly check the mouse state in order to know when the thing's been released.

Eventually what I'm probably going to have to do is create a Mouse class that tracks the ups and downs of the available mouse buttons. And, I suspect, the same is going to need to be done for the keyboard.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
nodapro
16
Years of Service
User Offline
Joined: 14th Mar 2008
Location:
Posted: 1st Apr 2008 20:34
For the first question:

The function
int dbPoint ( int iX, int iY );
will get the color value from the current bitmap, and
int dbRGBR ( int iRed );
int dbRGBG ( int iGreen );
int dbRGBB ( int iBlue );
can extract the RGB. Don't know how to get the Alpha though.

For the second question:

If you want to do something only ONCE if key/mouse is pressed, see if the following method to avoid repeated reading helps:

http://forum.thegamecreators.com/?m=forum_view&t=126468&b=22
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 1st Apr 2008 23:17
Nice - but the image thing... its not so bad.

MAKE MEMBLOCK from IMAGE

Now you have your image in a memblock.


First 4 bytes are a DWORD - Width of image:
Psuedo - MyImageWidth = Read Memblock DWORD Position 0

Next 4 are Height:
Psuedo - MyImageHeight = Read Memblock DWORD Position 4

Next 4 are Bit depth - usually 32, and frankly - that's all I've seen or used so far - so this post only referes to 32bit depth format.

Psuedo - MyImageBitDepth = Read Memblock DWORD Position 8


From Position 12 on up to memblock size are DWORDS also. Each one represents a Pixel. So each pixel is represented in four bytes. One byte is the RED, the another BLUE, Another Green, and Another the Alpha (Zero=transparent, >ZERO how much it should count when being drawn)

The exact order in mem I forget - meaning ... in a given pixel, I forget what comes first of the RGBA... what I USUALLY do - is something along the lines of:

(Snippets from my oop lib's JGC_PIXELGRID class.)
// To get the Memposition in a memblock that was made from an image:


Here - to access indivudla colors etc using above code for plotting the mem location:


Hope that's helpful.

Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 2nd Apr 2008 00:19
IF I knew what I was doing it might be possible to access the data directly. However, I'm not sure I want to poke around in what may be the DirectX buffers. In the DarkSDKImage.h file there's a prototype for a function that shows the following:

LPDIRECT3DTEXTURE9 dbGetImagePointer ( int iID );

in addition to

void dbGetImageData ( int iID, DWORD* dwWidth, DWORD* dwHeight, DWORD* dwDepth, LPSTR* pData, DWORD* dwDataSize, bool bLockData );
void dbSetImageData ( int iID, DWORD dwWidth, DWORD dwHeight, DWORD dwDepth, LPSTR pData, DWORD dwDataSize );

along with other prototypes that aren't mentioned in the docs. Some look relatively benign while others I wouldn't touch without having a more detailed understanding of DirectX.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
Hierro
16
Years of Service
User Offline
Joined: 22nd Mar 2008
Location:
Posted: 2nd Apr 2008 14:40
thank you for your replies!

got the input and the rbga-reading working (thanks to jason for the memblock-insights! ).

here's a simple solution for my input problem:



and here's my code for calculating the size of an image regarding to its alpha-channel:

nodapro
16
Years of Service
User Offline
Joined: 14th Mar 2008
Location:
Posted: 2nd Apr 2008 16:52
I have a question:

After dbMakeMemblockFromImage, can the reading/writing be done faster than calling the functions such as dbPoint?

I recall a post that says it is very slow to read from bitmaps (the method I used), but I never compared it with memblocks.

Maybe jason has some idea?

Thanks.
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 2nd Apr 2008 17:32
Comparing the two operations might be difficult since benchmarking isn't that easy to do in a multi-tasking environment. I'm not even sure why bitmap operations would be slower. I assume that they're in memory too and just as accessible. But there are quite a number of things I don't know that could explain why bitmaps would be slower. Maybe the best way to test is to see what the maximum FPS rate is using both methods.

Having said that, I will say that I'm a firm believer in pointers and what advantage incrementing a pointer has over recalculating a memory location for each operation. If a large portion of my function requires traversing a row then a pointer is the way to go. And using pointer arithmetic to calculate the beginning of the next row should be a bit faster than recalculating the beginning portion of a row with (row*width + column). dbDot and dbPoint make things easier for me and I'll use them until I get my program well enough along that I can take time to experiment with some lower level functionality of my own.

I've got a few concerns about using memblocks in that they still need to be copied into images to be used. If you take the copy time and the time it takes to be written to the screen is it any better? Naturally that's all tied up in what you're doing with the graphic and how often it needs to be re-displayed. The current portion of the program I'm working on isn't really too dependent on speed since it's only for designing my screen levels. When it comes time to play the game I could do a one-off copy of the bitmap I generate to an image and not have to change the image for most of the level.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
nodapro
16
Years of Service
User Offline
Joined: 14th Mar 2008
Location:
Posted: 2nd Apr 2008 17:42
Thanks for the explanation, Lilith. I think I need to do the same thing when speed becomes important.
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 3rd Apr 2008 04:25
Agreed. Lilith's explaination is true to form for absolute speed. As she mentioned in another post - something I should ask David W about, is that we have a DarkGDK function that returns a pointer to the directx structure an image is REALLY at.

accessing this directly would be faster than the image to memblock back to image technique - not to mention the math to calc each pixel's position versus doing pointer math to get around using incrementing etc.

I think its safe to say we know it depends on what you're doing and whether or not the routine you're working on needs the speed or not.

I do SOMETIMES go for the generally accepted "mainstream best practice" for software design over my "urge to make everything a rocket performer". That "mainstream best practice" that's generally accepted is "Make it work first, then go back and hone the the bottlenecks".

For example - so far, I've only really used my image/memblock manipulations for loading and "pasting" fonts into images.. for text on image sorta stuff. So speed hasn't been a prioirty for this image manipulation thing YET.

I also believe that each task often needs its own optimization - especially with graphics. Plotting a dot? Calc the location, making a BOX Fill? Do the pointer incrementing technique. etc.

I think one of us needs to just eventually dig in and figure out how directx handles this data. My Fear is that the data MIGHT have many different formats depending on bit depth and POSSIBLY the nature of the hardware - (some sort of hardware optimization that requires a bytes to be in a special ... not so intuitive format)

I dunno. I think this is cool stuff though.

Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 3rd Apr 2008 06:28
Having re-read my post I'm thinking I understand why bitmaps are slower than images. This is strictly a guess but I'd say that the image is stored in video memory since it can be used as a texture and much of that is handled by the DirectX functionality. They're closer to the video hardware.

If, as you conjecture, the handling of images is dependent on many circumstances, including hardware brand and color depth, then I'd be inclined to stay away. I might think I'm handling it okay but it might not run under a specific configuration that I can't imagine or anticipate. Getting that close to the hardware scares me spitless unless it's extremely simple, consistent and obvious.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
Sephnroth
21
Years of Service
User Offline
Joined: 10th Oct 2002
Location: United Kingdom
Posted: 28th May 2008 00:56
(uber late reply )
The main reason things like dbPoint() etc are slow are because the commands return a single point, just one and chances are you want many. However to access the surface it must be locked and then unlocked and thats slow - if you are going to do alot of reading from a surface you should try to just lock once, do all your reading in one go then unlock

goto this post: http://forum.thegamecreators.com/?m=forum_view&t=122165&b=22 and scroll down until you see my post in the thread. There are several blocks of code I put in there for image editing. One is GPU accelerated which is very fast but might not be what you want because I never did investigate support for reading pixels that way.

But if you look at the bit I put in "just for interest" then thats my software image editing library which accesses all pixel data by hand through pointers to the directx surfaces. Hopefully you can take something from that and make functions to suit your needs

Remember the biggest optimisation is the one that reduces the surface locks and unlocks to as little as possiable - prefably once per frame at most!

Login to post a reply

Server time is: 2024-09-29 21:31:47
Your offset time is: 2024-09-29 21:31:47