Card Game && Player Hand

Jotomicron

New member
Joined
Sep 18, 2006
Messages
2
Hi.

Im trying to design a card game and need to show the user its own hand. I first tried using PictureBoxes, but the problem is with transperency (see image at the end). Then I used this.CreateGraphics() to draw the image directly into the form, but besides being much more dificult to handle, I need to have some events so that I know when the mouse is over the Image, when the user has Clicked the image and so on.
[Broken External Image]:http://www.geocities.com/jotomicron/Cards.PNG

What do you advise?
 
This is just my take on the situation, although there are probably others with more experience on the topic than I.

I personally would recommend the latter option if you are serious about making the game look good. This involves much more work, though. Essentially, you must maintain a list of the visible objects on the screen that might interact with the mouse, and along with each object in the list you need a z-order value (z-order being an integer that specifies where, from top to bottom, an object is. An object that is drawn on top of a second object would have a higher [or lower?] z-order than that second object).

Then, detecting which object the mouse is over can be done more than one way. The simpler would be to store a rectangle to represent the location of each card, and on a mouse click you can search through the rectangles, top to bottom (sorting rectangles by z-order) and find the first rectangle that contains the position where the mouse is.

The more complex method would be for each object that can be represented on the screen to have a HitTest() method. HitTest() can examine the objects image and identify whether the pixel clicked is transparent or opaque. If it is opaque, return a true value, if transparent, return a false value. Call hit test on each object, from top to bottom (again, sorting by z-order) until you find an object that returns true for HitTest(). This latter method will be much more precise.
 
Thanks for the quick reply. That seems a good suggestion, and Im already thinking on the correct way to implement some drag-and-drop operations.

I think one problem remains, though. When I used this solution, the redrawing of the form was somehow ugly, because I was able to see, for microsends, the cards with a lower z-order (which is to say, the ones below). Is there a way to avoid this flickering?
 
Double-buffering. If you are using .Net 1.x you must implement this yourself, usually by doing all of your drawing to a Bitmap (this will be your backbuffer) and then when you are done drawing the bitmap to the screen. I often contain my graphics in a picturebox whose image is set to my back buffer. After I have drawn my image I invalidate the picturebox. (A good optimization is to invalidate only the region that has changed.) I recommend this method, simply because it is easy.


.Net 2.0 has double-buffering functionality built in, but it is less flexible than using your own back buffer because you must use the standard painting mechanism for controls. This sort of double-buffering has to be implemented as follows:

Set the DoubleBuffered property to true, or inherit from your desired control class and, in the constructor, use the SetStyles method to set DoubleBuffered and AllPaintingInWmPaint to true. Now your control is double-buffered.

When using this method, as the AllPaintingInWmPaint style indicates, all drawing must be done in the Paint event or within the overridden OnPaint method. This means that when anything happens that effects what the graphical output should be, you must determine the region that is effected and pass that region to the Invalidate method of the control (or you can invalidate the entire control, but this will slow down the process). This is kind of a round-about way of doing things, but it is the Windows way. Calling Invalidate tells Windows that your control or part of the control needs to be redrawn, and then Windows tells your control that it needs to be re-drawn, which calls the OnPaint method and raises the Paint event, at which point you finally do your drawing.

The logic of this second method tends to be more complex.
 
Back
Top