• Create Account

Banner advertising on our site currently available from just \$5!

rakketh

Member Since 07 Nov 2007
Offline Last Active Sep 11 2013 09:59 AM

Efficient backface culling

01 March 2009 - 12:50 AM

I'm quite new to 3D programming, so stop me if you've heard this one before! Standard backface culling iterates through a set of polygons, calculates the view vector, and calculates the dot product of the the view and normal vectors. I am looking for a way to remove the requirement of iterating through all of the polygons and returning all front-facing vertices in a single operation. I have come up with the following incomplete solution: Each vertex object has a pointer to the polygons it is a member of. The vertices are stored in a sorted map (angle->vertices). If we take a 2D view, you can see that if you are looking from 0deg, you can get all of the visible vertices by returning a sub-map of angles between 270-90deg. For large objects, the view vector may vary too much accross the object, so some level of error, and/or multiple vector maps, would be required depending on view distance. The problem I am having is in finding a data structure to store the map in 3D. Standard polar coordinates have a problem of being able to see back facing normals when you look over the top if they are only just backfacing, so you can't use a simple 2 pass check. I need an efficient way of determining the sub-map. Any ideas?

Separation of data model and visual output

01 March 2009 - 12:07 AM

I am creating my first game, which is a simple puzzle game (you may have seen it before, it's not original). You have a grid of squares, red or green, and you have to get them all to green. When you select a square, it flips the colours of all squares in a 3x3 block centred on itself. I have been going off several tutorials for different aspects, but am trying to code it so that it is modular and reusable. I currently have the following parts: Model: Stores the state of the game world. For this game this is a vector of vectors of Square objects, which know state information. Performs game logic when actions are given. I have 2 child classes - PlayingModel and SelectingModel. On a move input, SelectingModel changes size, while PlayingModel changes the selected square. On an action input, SelectingModel returns GAME_WON, while PlayingModel iterates through the squares checking for a win condition and returns either GAME_WON or VALID_MOVE. Input: Polls the controller states, currently only keyboard, and sets up an array of current actions. Output: Knows how to draw the model. Currently each frame it takes the model, creates a vertex buffer, calculates the triangles to draw, and draws the scene in an orthogonal view. Controller: *Creates the main window. Creates Model, Input and Output objects. Initialises the game. Each frame gets input, updates model, calls for output. On win condition, switches between PlayingModel and SelectingModel (not elegant but I'm not polishing here) (Please comment on this design if any parts feel wrong, eg * the main window function may need to move elsewhere) I now want to move to a 3D view rather than orthogonal and am not sure where to store the graphics data. I want to be able to change between DirectX and OpenGL in the future without having to change all of the game model objects. I was thinking of Creating a GraphicsObject class in the Output module that takes a Square object in the constructor (will be generalised) and builds extra information around it such as the vertex buffer and index buffer, texturing, etc. These new objects would be held by the drawing class. Is this the best way to do it? How do I maintain the mapping between the graphics objects and the data objects? Also, if I keep a vertex buffer in the graphics object instead of recreating it each frame, do I have to manage it? Such as recreating it if the device is lost.

Avoiding the MMO end-game with generational advancement

30 January 2009 - 02:19 AM

Most MMOs I've played seem to be a race to get to the max level so that you can play the "real game". My idea is that instead of having this maximum level to strive for, you can create a new character that carries on some traits of the parent. For example, if you want a fire mage you can train in fire spells. The current character will only be able to reach a certain level of spell. To progress further, you would have to start a new offspring character. In this case, the parent has been training with fire, so the offspring would start with a certain level of fire affinity. This would allow him to train his fire spells a bit faster and to a higher level. The new character could also be given traits, depending on certain circumstances. If the parent character died while retreating, the offspring might hate his father for being cowardly. In this case he would get a resolve trait which would give him a burst of health/stamina if he was nearly dead. Other traits could include hatred of a certain type of creature. I haven't fully thought out what traits could be included, so any help in this area would be appreciated. I don't want them all to revolve around the manner of the parent's death, which these two do. Because everyone would be creating offspring at different times there wouldn't be huge "n00b" areas of the game world completely abandoned and all the high level areas full of max level players. I have some ideas of what to do with the ancestor characters, such as continuing to be able to use them but with a penalty of perma-death, but would like to discuss the mechanic of constantly creating new characters here. Is this a good way to spread out characters throughout the game world? Does it put too much burden on the player to keep restarting from a lower level? Do you think it's an awesome idea :D? Are there any games that do this already? I'd like to take a look to make sure I'm not just copying an existing idea and to make sure my way has a unique angle.

const return problem

15 January 2009 - 10:15 AM

I'm having some trouble working out how to return consts correctly to stop the returned value from being modifyable, specifically when using pointers. I have a GameState class that contains a dynamically allocated 2d grid. I want to be able to return a non-modifyable version of the grid to classes such as the graphics renderer. Here is what I have:
```#pragma once

struct GameSize {
int x, y;
};

class GameState
{
GameState(int x, int y);
~GameState();

const GameSize * getGameSize() { return &gameSize; }
const bool ** getGrid() { return grid; }
void changeSquare(int x, int y);

private:
GameSize gameSize;
bool **grid;
};

```
The first return works fine, returning a pointer to the GameState's GameSize object which cannot be modified (please correct me if that is wrong). The second return gives the following error: 3>c:\documents and settings\administrator\my documents\visual studio 2008\projects\testgame\testgame\gamestate.h(13) : error C2440: 'return' : cannot convert from 'bool **' to 'const bool **' I've returned grid instead of &grid since it's already a pointer so passing it by value isn't an overhead.

Audio input

13 January 2009 - 09:36 AM

I'm interested in trying to make a game similar to guitar hero, but using an electric violin connected to line-in. The stave would scroll along the screen and you play the notes as you normally would. The game would rate your pitch and timing. I'm currently learning to play (2 weeks in) and think this would be a great learning tool, as it would indicate whether you had your fingers in the right place for pitch and train tempo awareness. I don't know anything about audio programming at the moment, so I'm looking for pointers to tutorials and general information. I'll start off small, making a tuner for a specific string, then expand so that it identifies any note you are playing. I've done a quick search for capturing audio, and there are a few apis that handle audio input. I'm going to want a GUI, so was going to go with DirectX. Is DirectX's audio library up to the job, or would you recommend using another api? http://www.codeproject.com/KB/audio-video/Asio_Net.aspx has information on ASIO, but my sound card doesn't support it. There is a link to a driver which is supposedly compatible with most sound cards to provide ASIO support. Is it worth doing this for the lower latency, or is DirectInput (or another of your suggestion) good enough to do this task? I've also read up a little on Fast Fourier Transforms, which I understand I would need to use to obtain the frequencies being played. Can anyone recommend an FFT algorithm that is fast enough and accurate enough to do what I want? What difficulties am I likely to face in the first parts of development? Are FFT algorithms fast enough to do this real time? Will I have difficulty analysing the frequency curve? Anything else. Thanks for any help.

PARTNERS