8

Draw a shadow sprite like you draw your character before the character (to make it appear behind him). Make sure its X position is updated according to the character, but the Y position stays on the tile. You have got a shadow.


5

In a multiplayer game, every gameplay-relevant decision should be made by only one system. When multiple systems make a decision, like in your case the trajectory of the ball, and they disagree due to timing issues, the game gets out of sync. When each client calculates the angle only after its own collisions and sends the new trajectory of the ball to the ...


4

Your texture is a 32 bit texture. Somewhere between loading it and displaying it, it is getting downsampled to 16-bits (or some other low bit-depth). The loss of precision gets rid of the smooth gradients and gives you bands of colour like that. None of the things you have mentioned (loading it with LoadStream, drawing it with BasicEffect with that vertex ...


4

You could develop your own SOAP or REST API, host it on a website and have your apps connect to that. You'd have full control over it and wouldn't have to pay for anything (other than hosting, of course). There is more of a development cost up front than using some kind of pre-built package, but you have the control to scale as you need to and make the API ...


4

It looks like XNA games are always clamped at a maximum resolution of 800x480; even changing the PreferredBackBufferWidth and PreferredBackBufferHeight parameters doesn't prevent it from using a scaled-up + letterboxed framebuffer.


3

It's something you should look into. There's an article on MSDN about this warning. Essentitally, it's a matter of optimizing you code, but it's important to profile the code so you know what to optimize. These are the steps listed in the article: To investigate high CPU usage on the UI thread To investigate a high CPU usage warning, click the ...


3

Windows Phone is limited to C# 3.0 and .NET 3.5. You have to use the Task Parallel Library to achieve this.


3

You can't. Important parts of their infrastructure are contained within the Game class. (Also, GameComponent's constructor takes a Game.) My advice (as always) is to not use GameComponent. Like the Game class itself, game components are a completely optional part of the framework. And often they're more trouble than they're worth. You're better off just ...


3

Speaking to Android specifically, there is a 2D drawing API available as documented here that is not OpenGL ES based: http://developer.android.com/guide/topics/graphics/2d-graphics.html If you aren't specifically looking to avoid OpenGL ES entirely and are just looking for a convenient abstraction on top of it to prevent you from having to work with it ...


3

By default, in Windows Phone 7 all apps use 16 bits per pixel graphic mode. To switch it to 32 bits, see here: https://stackoverflow.com/a/10313783/126995. This is only available since WP 7.1 Mango, but since every WP7 device can be upgraded to WP 7.1, it's no big deal.


3

Using the information from your previous question, you know what the delta of the drag was. This gives you distance. The only other thing you need to get velocity is a time. So, record the time when the touch even started, and when it finished. The difference in those times is the time it took for the gesture to complete. Now you have distance and time. So ...


2

Yes, you can do this. In the settings for your app you get to set the price and "Free" is one of the options. Some things to consider before doing it: It may be better to have a free and a paid version available to increase visibility. When switching from paid to free, or vice-versa, you won't get put the the top of the new apps list. The new list ...


2

AFAIK it's absolutely OK to sell apps on Windows Phone marketplace. However you need to pay developer membership fee (which is 99$ per year), and submit your app (i.e. game) for certification. I recommend you to check such info before starting working on a product in a future :-)


2

I'm guessing each object has it's own System.Random object initialized with the same seed? Try making it static for now and see if that fixes the problem. Note: System.Random is not thread-safe see Getting random numbers in a thread-safe way for a solution, should you need it.


2

Well as far as I have it, it will probably be easiest for you to create a new Windows Phone 8 MonoGame project from the template and then just copy all the code in. MonoGame uses the exact same namespaces, it just has a lot of behind the scenes changes that make it reference different libraries. Applying these changes whilst also applying all the other ...


2

Mark the starting position of the drag. Then compare against the end position. The difference between them will tell you the direction. With XNA, this is provided for you in the form of GestureSample.delta The delta is a Vector2 that contains the difference for each axis. For example: If you moved up and to the right, your delta vector might look like (10,...


2

The quickest/simplest approach is to get the position and time of the touch and then get the position and time of the release. Then dividing the position difference (which is a vector) by the time difference you have an approximation to the velocity. However, there are more complicated ways to do this which can be desirable in some cases. For example, if ...


1

In XNA, you won't find any direct analog to the Android method you linked. You are also correct that SpriteEffects is not the answer to your problem (it's a very short enumeration). If you want to display an animation, you will have to manually display different sprites sequentially, which is commonly accomplished with a sprite sheet that contains the ...


1

I think the issue is possibly a bug in the older versions of Windows Phone 8. The blend state seems to be borked so you need to create a custom one that you know works. private BlendState alphaBlend = new BlendState() { AlphaBlendFunction = BlendFunction.Add, AlphaDestinationBlend = Blend.InverseSourceAlpha, AlphaSourceBlend = Blend.One, ...


1

The recommended way seems to be scaling the sprites. You can create alternate images to handle differing resolutions and load them depending on the screen's resolution. MSDN Article


1

You're right on that main point: pixel collision is way complicated. Often times, it's going to be far, far more effort than it's worth. You'll likely have to program a form of collision that's not 100% the same as the visuals you draw. A rocket sounds like something that could very easily use rectangle collision detection. However, a random guess suggests ...


1

Going from the emulator to an actual mobile device, keep in mind that the mobile device's performance characteristics will not match. In your particular case, keep in mind that texture-fetch on a mobile GPU is relatively slow. Therefore you want to minimise the amount of texture data that you are accessing for each pixel. Ideally you want the texture to be ...


1

When you want to create 2d games, then no, you won't need it. When you want to do 3d games, you should first consider the available 3d engines and do a cost/benefit analysis of creating your own 3d engine. In most cases, this analysis will tell you that using an existing engine will allow you to bring your game to market in a lot less man-hours. Every ...


1

Once you have handled a touch by firing a bullet you need to record that you have already reacted to that touch and that you shouldn't on subsequent updates. Each touch location has a unique Id field that is maintained for as long as the touch remains active, even across frames. A simple approach would be to maintain a list of all the touch Ids you have ...


1

I have found this issue in my game recently, however I found the way to get over it is to call end before your draw primatives and begin after it: protected override void Draw(GameTime gameTime) { GraphicsDevice.Clear(Color.BlanchedAlmond); basicEffect.CurrentTechnique.Passes[0].Apply(); spriteBatch.Begin(); spriteBatch.Draw(background, new Rectangle {...


1

The spritebatch items don't actually draw onto the back buffer until spritebatch.End() is called. This is so it knows which sprites to 'batch' into 1 call to the GPU. So your code basically: informs the spritbatch that background will be one item in the batch draws Drawcell directly to the back buffer (because you call it explicitly) informs the ...


Only top voted, non community-wiki answers of a minimum length are eligible