Jump to content

  • Log In with Google      Sign In   
  • Create Account

Postie

Member Since 28 Nov 2010
Offline Last Active Today, 02:58 PM

#4960796 textures textures textures :)

Posted by Postie on 18 July 2012 - 09:45 PM

The dds format can be uploaded in a compressed state and decompressed by the graphics hardware, whereas .png will need to be decompressed at the cpu/graphics driver end and uploaded as raw bitmap data, which consumes more bandwidth.

That said, I'm currently using .png, as it is easier to manipulate during development. When I'm closer to release I'll convert them all to .dds and see if it makes a difference to performance at all.


#4958616 interpolation of normal on low polygon useless

Posted by Postie on 12 July 2012 - 07:25 PM

If the angle between adjacent faces is more than a certain threshold, you really need to switch to using face normals. If you want a hard edge, use face normals. If you want a smooth edge, use averaged vertex normals.

Also, don't forget to re-normalise the normals after summing them together.


#4942422 C# SQL connector very slow

Posted by Postie on 22 May 2012 - 08:55 PM

Batching the updates together will make a definite improvement. Try something like 100 or 1000 and see how you go. Another thing to look at is how you're building the query string you're executing. If you're concatenating a lot of strings together it will severely impact your performance, as .net has to reallocate the string every time you modify it. The recommended way to build strings is with the StringBuilder class.


#4942141 Broken Game as an Anti-Piracy Measure

Posted by Postie on 22 May 2012 - 03:40 AM

My favourite anti-piracy reaction of all time was from last year by Garry Newman of Garry's Mod fame. He pushed out an update via steam that detected if the game was hacked and threw up an error message when you'd try to run it. The error message included a long error code that was actually the user's steam ID. So when the pirates complained in support forums and posted the error code Garry knew exactly which forum and steam accounts to ban.

Using such a scheme is risky due to the chance of false positives. But it was terribly amusing to read about.

In my personal opinion, there's nothing you can do to make your game completely secure. DRM is good in theory, but when it goes wrong (and they ALWAYS seem to go wrong), you risk pissing off your legitimate customers while the pirates have already found a way around it so they aren't inconvenienced.


#4942133 Textures not rendering

Posted by Postie on 22 May 2012 - 03:00 AM

One idea that springs to mind is that "texture" is null. Direct3D won't complain if you pass null into a SetTexture() call, you just won't get anything displayed.

One thing that seems odd is that you're asking direct3D to return the texture in an unknown format in the FromFile() call. Most likely you'd want to use something like A8R8G8B8?

As Jebbles pointed out, Managed DirectX was discontinued by Microsoft quite some time ago. It was replaced by XNA, which you should look into instead. If the book you're using is the one I think it is, then its from 2004, which explains the obsolete technology it's advocating.


#4930110 direct x9 project

Posted by Postie on 10 April 2012 - 10:40 PM

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.


#4922915 recommended ways of storing game entities and state game structure

Posted by Postie on 17 March 2012 - 05:06 PM

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.


#4922780 WHAAAATT!

Posted by Postie on 17 March 2012 - 03:32 AM

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?


#4922767 WHAAAATT!

Posted by Postie on 17 March 2012 - 01:07 AM

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)


#4922727 recommended ways of storing game entities and state game structure

Posted by Postie on 16 March 2012 - 07:45 PM

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. :)


#4910807 How To Block(Cost)Cells Based on the Terrain ready for A* path finding.

Posted by Postie on 08 February 2012 - 01:21 AM

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.


#4910757 Fast way to calculate 2D signed distance field

Posted by Postie on 07 February 2012 - 09:29 PM

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.


#4910293 What is shining?

Posted by Postie on 06 February 2012 - 03:19 PM

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.


#4910082 A* speed issues (C++)

Posted by Postie on 06 February 2012 - 02:41 AM

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.


#4903405 Constructive Criticism

Posted by Postie on 16 January 2012 - 04:38 PM

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.





PARTNERS