The new input class is working beautifully. I've returned to what I was doing when I hit the rut with the last input class and this time the wrinkles were quickly smoothed over and I've had no problems. The problem with my old class was that I couldn't easily switch from wsad (up/down/left/right on the keyboard) to a joystick or a mouse because buttons and axises were treated differently. My new system has the capability of treating a button as an axis and vice-versa. It also has the ability to combine axises. This feature comes in handy when creating an up/down axis for the keyboard. I created two buttons, W and S, wrapped them individually with an axis converter, W == -1 when pressed and S == 1, and combined them.
Anyway, I can now move the camera around and zoom in and out. All entities are now displayed (nodes, people, and routes). However, I've been progressing slowly because I'm allowing my mind a little time to mull over how I'll do the next step. In the last rendition, I would run through every node and section in the collision detection. However, I've realized that in a long game, the playing board may have hundreds of routes and nodes, slowing the collision detection down significantly. Therefore, I've been thinking of ways to filter the tests. I'm thinking of creating a grid of classes, each representing a square of the playing board. Each class would contain any node or section within it or passing through it. This way, when I'm building a route, only the grid squares it passes through will be tested. I imagine this would improve the performance considerably.
I could also use that method to determine what entities are within the camera's range. I wouldn't have to test every single entity, only those in the squares that the camera overlaps. The next question would pertain to the size of these boxes. However, I can set an arbitrary value now and test the performance later when I have a functioning game.
Comments? Thoughts?
clevceo
No comments:
Post a Comment