Postie

It depends on what you're trying to achieve. If your goal was to draw a triangle, you're done. If not, tell us where you want to go, and we can offer suggestions.

I would definitely cache your textures. Creating and destroying Texture objects all the time is a great way to kill your frame rate. I like the idea of having a centralised Texture Cache that's responsible for creating and destroying Texture objects because I use an "on-demand" resource allocation strategy. Ie, on render, I'm checking if the resource is allocated or not, and creating it as required, rather than allocating everything on load. This also allows texture re-use if objects are using the same texture.

You can then get a bit more advanced with reference counts to deallocate textures that you haven't used in a while to manage your video memory a bit better.

I think it has to do with the fact that to represent a point or vector in 3d space, you need 3 coordinates, and to transform those coordinates using rotations, etc you multiply it against an appropriate matrix. A 3x1 Vector multiplied by a 3x3 Matrix will give you another 3x1 vector, representing the transformed point.

The issue is that a 3x3 Matrix can represent rotation and scaling, but can't include translation. To do that we need to use a 4x4 matrix. But in order for that to work, our original 3x1 point needs to be expanded to 4x1, since you can't multiply a 3x1 vector by a 4x4 matrix. The new coordinate, w, controls if the translation part of the 4x4 matrix is added to the result, so under most circumstances you want it to have a value of 1.0. However, if you're transforming a vector instead of a point, you don't want the translation applied, since a vector is an offset from 0,0,0 and the translation will change the vector's direction and magnitude, so you can use the same transformation matrix as before, but set the w coordinate of the vector to be 0.

I think that ordinarily, Direct3D takes care of adding that w=1.0f term automatically when it expands from a float3 to a float4, so when you use input.Pos, the value would be correct.

I don't fully understand the thing myself, but my explanation makes sense to me. Doesn't mean it's correct though. Maybe someone more knowledgeable like MJP can chime in and correct me if I'm wrong?

The w-coordinate of the position is used to indicate if the position should be treated as a position or a vector and should be either 1 or 0 respectively.

Your position value is incorrect. It most likely should be float4(5.0f, 5.0f, 5.0f, 1.0f)

Oh, I should have probably been more specific about this but the keyHandler and mouseHandler classes just hold a hashmap of which keys were pressed (for the keyHandler) and which location on the screen was clicked (for the mouseHandler). They don't handle the events (the JPanel uses key bindings and a mouse listener to do this), more so just store what event was triggered. Every game state would need access to these since I have to be able to processEvents in each game state. Same with each component of the screen (inventory, etc).

Ah ok, that makes more sense.

One of the things I've learnt in the last 15 months working on my current project is that I only ever come up with the "right" design for something at first attempt about 1% of the time. Sometimes it's not bad but needs tweaks. Other times it's awful. My current game engine has evolved a lot as I've added new functionality and decided some part of the design was flawed. I've actually spent a fair bit of time rewriting existing code, but each iteration the system becomes better and more logical in my opinion. So I've learnt to not stress too much about having a perfect design from day one.

Generally speaking though, one of the metrics I use to tell if something isn't "right" in my code is that there are ALOT of interdependencies going on, ie many references to other classes that are passed through into other classes. There's not always an obvious elegant solution however. Sometimes you just have to live with it.

Calculate the slope between adjacent cells and then construct a formula to convert that slope into a movement cost. If the slope exceeds a certain value, the terrain is too steep and you can simply treat that cell as inaccessible.

In my current project I actually use the height difference, since the slope is deltaHeight/deltaX and deltaX is always 1 in my case.  If it exceeds 1m, which corresponds to a 45 degree angle, I consider the cell to be inaccessible. Otherwise I multiply the current movement cost (calculated from factors such as the terrain underfoot) by 1 + deltaHeight. So at maximum it increases the movement cost of that tile by about 2x. That might not be realistic, but in testing its behaviour looks ok to me at the moment.

I should mention this is for creatures walking around. Slope affects vehicles much more severely I believe.

The brute force way is slow, but accurate. As far as I can tell, all of the faster algorithms sacrifice varying degrees of accuracy to achieve their speed. While researching systems for rendering text for my current project I came across the following papers:

http://infoscience.e...ch/record/86623  (This link proposes a few corrections to Danielsson's technique)

http://citeseerx.ist...p=rep1&type=pdf (The "dead reckoning" signed distance transform)

I ended up implementing the transform outlined in the second paper, which is pretty quick, but has a few flaws.

I've always found it hilarious that people find it necessary to implement lens flares in games, particularly FPS's. The implication being that in first person mode the eye of the player as represented in the game is an actual camera. 3rd person perspective or cut-scenes are a different matter though.

There's a surprising amount of heavy lifting that occurs in the open and closed lists. If you profile your code you'll soon see where the real culprit is.

That said, you may not need to go to the extent of implementing a binary heap if you can reduce the number of members in the closed list. I had some speed issues in my first attempt at an A* implementation and refactored my code to make better use of the spatial partitioning my engine was already using and the performance was good enough without needing the complexity of a binary heap.

My game world is broken down into zones which are 32x32 tiles, so instead of storing tiles in the closed list, I stored Zones and a 1024bit array representing the traversal of each tile for the zone. To check the closed list I simply find the zone through a list scan then do some simple bit twiddling to find the tile itself, thus reducing the size of the closed list by a factor of between 100 to 1000.

Basically I was too lazy to learn how to implement a binary heap.

Another option is to do the pathfinding on a much coarser grid first, then pathfind between adjacent grids.

I quite like the notion of "buying your freedom". Most games by beginners don't really have a well defined end goal.

A few quick thoughts:

• On the face of it your entity class seems ok, but since your Weapons class inherits from Entity, you end up with weapons having properties like boughtFreedom and isAlive.
• Since the hero is the only one who'd be buying their freedom, it would make more sense as an external variable.
• The way you've implemented the different weapons is a little odd. You'd be better off creating a weapon class with the properties Identity/Name, Strength and Price, and then instantiating one of those for each of the 3 weapons you want to support. Then you'd assign the appropriate weapon to the entity.

On my current project, pre-production ran for a couple of years (on and off) before I thought the idea was solid enough to begin work on it. In the year of development I've put into the project since I've run into plenty of issues I didn't foresee in my planning, as well as come up with countless new ideas that I only thought of due to implementing my ideas and make them concrete. What I mean by that last line is that when an idea is just an idea it doesn't have to pass strict tests for correctness, its given some leeway for the details to be "fleshed out later". But when you come to implement the idea, you can't hide from the details, they have to be done. I find this is a good test for how good the idea is, and you have to be prepared to throw away ideas that you love but can't get to work.

To sum up, unless you're writing something simple that's a clone of another game I would argue that you can't possibly think of everything before you start. I've read design documents for some of the big games that clearly took months to write, and though they do cover the vast majority of the final game's mechanics, there are always differences, where the original idea simply didn't work in practise.

Finding a good name is very difficult, but talking to others about your "untitled <insert genre> project" is a pain. I tackle this by assigning a codename until I have a proper name. This also gives me a lot of time to come up with a proper name I like. A friend of mine had a favourite saying that amounted to: "If you design the packaging before the project has started, the project will never be completed."

Whenever this has happened to me, it's been because I've forgotten to free all resources before calling Device.Reset().

Try commenting out the creation of resources until the problem goes away, and then you've found the culprit.

Based on my experience, the Pow() function can be slow for squaring. I find it's better to simply multiply the numbers together much like you've done in the first line of the formula.

In addition, Math.Sqrt(2*Math.PI) is a constant value, so you could get rid of the expensive square root by pre-calculating that somewhere else and passing in the value.

To address the issue of whether to have the calculation be done on the GPU or CPU, in general the GPU is going to have much faster, since its heavily optimised for crunching numbers, but it will depend on how utilised your CPU is. If you GPU is already grinding away on other shaders, but the CPU is mostly idle, it may be better to have the CPU do it instead.

The only way to know for sure is to try both approaches and see if there's a difference in frame rate. In short, benchmark!

I've been working with SlimDX now for about 10 months, and I've noticed that there are few resources on SlimDX out there. That said, I've also noticed that despite not knowing a thing about DirectX before I started, I can now read and understand DirectX examples and translate them to SlimDX in a matter of minutes. I credit the designers of SlimDX for that. They've followed the DirectX API very closely.

I'm actually using directx 9 and shaders, so I bought a book on that topic, and despite all the code examples being written in c++, its very easy to translate directly to SlimDX.