I am developing a card game using WPF and since i do not have any knowledge about animations i would like to know if someone could help me in how to write an animation to simulate a Card ( Image ) been played over a table.
At the bottom and top of my game table i have my cards on vertical position.
At the right and left my cards are on horizontal position.
What i really want is give an impression that a human is selecting and throwing the card.
Since your question is pretty open-ended, I'll give you an open-ended start...
Look into Storyboards, and how to use the same to modify the RenderTransform of your Card UserControl.
Your first step should really just be animating your card's position from its initial spot to the center of the table. As an additional hint (which will come in handy after you've learned about Storyboards), your DoubleAnimation.From property does not need to be specified. You just need to specify the DoubleAnimation.To property.
I see questions like this all the time on SO, and it really does give the impression of "I haven't tried, and I have not read anything". You already have your cards on the table (so to speak), and the question is, make it look like a human did it.
There are a variety of ways, some cheap and simple, some more complex and involved. You won't know the answer until you try.
For example, perhaps you want a card to go from one position to another (optionally flipping). You have varying degrees of difficulty here:
Move the card to the position, as is. Cheap and easy. You could even use the distance between the source and the target to determine the speed to have some kind of residual momentum.
Cards are at different angles. How do we rotate? XNA makes this pretty simple, have you looked up on XNA and general rendering? Or do you want to this purely using WPF?
Does the move involve showing the card face-up, or not? Will there be an animation involved? Are you happy with just the face changing or do you want to see an actual "flip"? If it's the latter than some kind of a plane in XNA using 3D might be better, at least then you can have two faces with two different textures.
What I am saying is, and why this is an answer as opposed to a comment, is that you have given no indication of anything that might be considered trying to solve the problem. You seem like you've got halfway there, you've already got cards rendered on the screen. But to ask "Make it look like a human put a card in"...? Well, sorry... it's not that simple. You can make this task as easy or had as you wish.
Related
I have an Unity 3D scene with several cameras looking at the same object (a huge brain mesh ~100k tri) but not necessary with the same point of view.
In the same 3D scene there is a huge number of spheric plots meshes (from 100 to 30000).
In all the cameras i have to display the brain mesh with a part of the plots meshes.
Depending on the camera view, each plot can have a different size (mesh filter and spheric collider), a different material (opaque or transparent) and can be visible or not.
The spheric collider must have the same size than the mesh.
I set up a shared mesh in common for each spheric mesh.
Their material can be one of the several shared materials i have defined.
Before rendering the scene, for each camera view in the OnPreCull function i have to define which plots are visibles and how they look.
This part can be very costly, i tried several things :
setting gameobject inactive : too costly
setting local scale to vector3(0,0,0) : better but i can see that the rendering is still done in the profiler
setting a total transparent material : same result, but the in the profiler the rendering is now transparent instead of opaque
setting a layer not in the cameras layers masks : huge script cost
I don't kwnow if i can make an efficient culling system with all theses cameras looking at the same point...
I welcome any new ideas.
First issue:
Regarding your specific question with the four dots.
Simply set the renderer.enabled = false, that's all there is to it.
Note however that as I mention in a comment, you would never try to "cull yourself" in Unity (unless I have misunderstood your description).
Second issue:
Regarding the small spheres. I suspect you have very many in the scene. You simply can't do that. In video games (the most difficult of all 3D engineering), you just do this with billboarding. It's how say "grass" is done in a scene. You can achieve this nicely with the particle system in Unity, or other techniques. An implementation is beyond the scope of this answer, but you will have to fully investigate billboarding. Simply it's a small flat image which always faces the camera in the render pass.
Issue 2B:
Note however that sphere colliders are wonderful, and you can use as many as you want. I'm sure this is obvious from base mathematical reasons. Side tip: often folks try to "write their own" thinking it will be faster. It's impossible to outwrite the 100? person-years of spatial culling scientific research in PhysX, and moreover they use the metal, the gpu, so you can't beat it.
Issue three:
Is there a chance you're using a mesh collider somewhere in the project? Never use mesh colliders, at all. (It's extremely confusing they are mentioned or used in Unity; they only have one or two very specific limited uses.)
Issue four:
I'm confused about why you are turning things on and off. I have a guess.
I suspect you are not using more than one "stage"!
There's an amazing trick about video games when you have more than one camera. In fact you have "offscreen" scenes! So you may have players in a dungeon or the like. Off "to the side" you may have an entirely duplicate or triplicate setup of the whole thing running (you could "see it if the camera turned the wrong way") for the other cameras. (In the example you would have different qualities on the dopplegangers, coloring, map-style or whatever the case is.) Sometimes you make a whole double just to run physics calculations or address other problems.
Fascinating extreme example of that sort of thing.
In short in your situation,
You likely need one whole 'stage' of a camera and brain for each of the camera views!
Again this can be http://answers.unity3d.com/answers/299823/view.html but it is indeed the everyday thing. In your overall scene you will see eight happy brains sitting in a row, each with their own camera. In each one you would display whatever items/angle etc are relevant. (Obviously, if certain items are "identical, other than the viewing angle" you could use the "same brain with more than one camera": but I would not do that, best to have one-brain-one-camera for each view.)
I believe that could be the fundamental issue you're having!
I've started learning c# and vb.net and have a project related to tracking a moving object on the screen to help me learn some basics.
In essence, I will have a ball on the screen which moves from left to right (only horizontally), and when it reaches a certain point (e.g. 250 pixels from the "mid" point either side) I need to know this, and click an on-screen counter to increase a value (or decrease depending on left or right) and reset the ball to the centre (note that the ball speed will vary from incredible slow to an instant "jump").
I've been asked to look into c# and vb and decide which is best, then use it to create the program. As a complete newbie in both of these, does anyone have a recommendation and a starting point please?
My background is Javascript, HTML and very basic Java.
Thanks!
Not too sure what you define as a "Starting Point" do you mean like different C# libs to use etc. If all you are trying to do is move a ball from left to right basically and count the difference it would be so simple to do in C# XNA.
You can also do it in windows forms too which I really thing shouldn't be too hard at all. Obviously you would create the velocity formulas yourself I don't believe that's what you're asking.
One way to get the screen size in windows forms is:
public Rectangle GetScreen()
{
return Screen.FromControl(this).Bounds;
}
This will return a rectangle with a width and height that you can call, divide both values by 2 and it will give you the center of the screen. Then just add a method that is called every frame to check the balls value from the middle of the screen.
From what I've read I understand what you want to do, but I'm unsure if you just want a windows form or if you'd prefer to use a small game engine like XNA etc.
Either way best of luck and let me know :)
I have actually the following map (isometric projection), and I can move/zoom/rotate without problem with matrix transformations (SpriteBatch): picture.
And I wanted to know if it was possible (if so, how), to get the following result, without referring to 3D: picture.
All suggestions are welcome. Thank you in advance. :)
Its going to be a huge pain in the ass, especially but I think it is at least possible if you don't change the viewing angle.
Some ideas:
Make each tile its own little image unit.
The more far back the tile is from the camera, lower its layer priority when you draw it so that it gets blocked by tiles in front of it. Also you will have to figure out an algorithm that correctly sizes the tiles based on their distance. This algorithm will have to be more and more precise the closer you want to get the tiles, but there should be some mathematical/geometric formula that can do it automatically.
You quite literally CANNOT rotate the camera at all, unless you want to have separate sprites for every single angle for every single tile.
My homework is to write a very simple application (Java or C#, I know both), which can detect water level of a glass of water / coke in a picture (it have to draw a line there). I don't even know how to start it. I have googled all day, but have found no useful results. Are there any good algorithms, which can detect the level of the liquid?
The photo is taken from the side, like this:
(it's also good if it detects both lines). So could you help me out with how to start? Use egde detection (are there any good basic algorythms?), or other method?
It would be best would be if it detected water, coke, and every liqued etc....
You are going to have to do some edge detection and then once you have the edges, try and find the level within the glass. You could use a toolkit like Aforge.NET. Then code to detect the edges is pretty simple, for example:
Bitmap b = new Bitmap(Image.FromFile(#"C:\Temp\water.jpg"));
// create filter
Edges filter = new Edges();
// apply the filter
filter.ApplyInPlace(b);
pictureBox1.Image = b;
Yields an image like this:
Now it should be a little bit easier to find the point of water in the glass. Since all of the background noise has been eliminated, you can focus on determining which edge you should key off of.
Check Hough transformation here
It will help you to get the capacity of the glass in question.
Once you know how much water a glass can hold, you can draw two lines onto the image using functions that you write your self. I would advise one line for the glass size and one line for the water level super imposed over the image, you can then use these lines and the maximum capacity of the glass to form a correlation between the two and calculate the level of fluid contained within the glass.
Remember that your professors aren't interested so much in you getting the assignment 100% correct, they are more interested in preparing you to solve problems using your own initiative. Google searching can't always solve your problems.
I am trying to write a card game, where a player is able to stack cards. E.g. Ace, Two, Three.
I would like to visualize a stack of cards, where the Ace card is partially covered by the Two card, and the Two card is partially covered by the Three card. The Three card is completely visible.
Easy, I thought. I make a user control where I add my cards: Controls.Add(ace); Controls.Add(two); etc.
Then I need something that is able to lay-out my Controls, so I wrote my custom LayoutEngine (derives from LayoutEngine). My first test does nothing more then shift the control 50 pixels.
After running the solution I noticed that the Z-ordering was wrong. Instead of the Three card being on top, the Ace card was on top looking like this:
Ace Card > Two card > Three card where:
Ace Card is on top
Two Card is under the Ace Card
Three Card is under the Two Card.
So I started looking for a way to change the Z order in WinForms and found out that it is simply "not available". Like.. Huh?!
The alternative (provided by MS) is that the Z order can be altered, by setting the ChildIndex for the Controls. Jikes, that means that poking around in a list, change the behaviour of my application. Way to go MS...
Anyway, I tried all kind of things, but it seems impossible to write a layout engine that does the trick.
I've google-d all day, and found nothing useful. I am no GUI expert, so I run stuck on this lame issue. Who can help me out?
Much appreciated!
Bas
Your best bet is to avoid the use of controls entirely. They will A) result in poor(er) performance and B) complicate hit testing/drawing.
Simply create objects to represent the state of the table (I use a CardContainer object) and use Graphics.DrawImage to draw all of the cards where they lie during the paint event. You can use a single control for the entire table if you need to also add other UI elements.
This will also make animating card movement simpler should you decide to add animation.
Updated
I meant to expand this answer but was called away and simply posted what I had. Here are some details you may find useful. I created a "solitaire game engine". The engine hosts one solitaire game at a time (klondike, spider, strategy, etc.). It tracks statistics for each game and allows both playing and editing of the individual games. The games are IronPython scripts which makes adding new games relatively easy.
My CardContainer is an object that holds zero or more cards.
It has a LieDirection (None, Up, Down, Left, Right) which determains how its cards are laid out.
It has a MaximumDepth that clamps the number of cards drawn in the LieDirection. This is handy for games like Klondike where you only want to show the top 3 cards of the waste.
It has properties for spacing the cards. There are separate spacing values for cards that are face up and face down. It can auto-pack cards into an area defined by MaximumLength. And it has an 'extra pad' value, one for each card--whether there is a card at that index or not. The latter is used during a simulated mouse hover to 'uncover' the card pointed to so that the user can clearly see a card that might be obscured by cards on top of it. This is accomplished by setting the 'extra pad' of the card on top of the hover card. This could have been simplified by having a "hover card" and "hover spacing" property, but having extra padding per-card allows for odd kinds of solitaire games that highlight a particular 'row' in the tableau piles with spacing.
It has a HitTest method to return a Card from a given X,Y location.
All of that means that the Card object has no notion of where it is drawn on the table. I have a complex animation system and so a card's location ultimately comes from the animation engine. If a card is not currently animating, the animation system gets its location from its container.
Note that the card's location referred to above is strictly for drawing. All cards are always attached to exactly one CardContainer and are simply moved from one to another. There is one 'special' container called the Deck which initially contains every card. It is positioned off of the table initially. A container has a Visible property. Animations play only if moving a card from a Visible container to another Visible container. This allows you to move cards around without animation when necessary and cards can "fly out" to/from containers positioned off the table.
The engine also has a rudamentary layout system for positioning CardContainers relative to each other. One very handy thing I did was to use a card-size-relative coordinate system. The 'width' of the table is exactly 11 card widths. No matter how big the user sizes the table, the width is always 11 card widths. This means that the card sizes (as viewed by the user) grow and shrink. The height is variable, but is determained by a fixed card-sized ratio (determained from the card bitmaps). If you give a CardContainer an X value of 1.0, that means it will be located one card-width from the left of the table. The values are floating points so you can specify 1/2 a card-width with 0.5. This makes it very easy to position elements in the script without having to worry about screen coordinates. No matter how the user alters the size of the screen, your game will be laid out exactly the same way.
The engine also has unlimited undo and redo. This means that not only do card moves (from one container to another) have to be recorded, but all property changes are recorded as well (both card and container properties). Undo and redo can be difficult to implement if not planned for from the start. The scripts have access to a Game.LogVariableChange method so that they can alter the value of a global variable through the recording mechanism. This is necessary for something like Klondike's "three redeals" feature. The script has to store the number of redeals used, but if the user undid a redeal, that variable's value change has to be undone too.
This works very well for Solitaire, but could work for just about any kind of card game. Obviously you don't have to go and implement all of this your first time out. I present the information just to give you some ideas.