Jump to content
  • entries
    503
  • comments
    1888
  • views
    335280

yar.

Sign in to follow this  
EDI

84 views

So, I'm on the brink of a lot of good stuff, admitedly I didin't get much done over the weekend (the horror!) partially because sunday got gobbeled up by our 4 hour St. Patrick's day parade.
(the second largest in the country lol.)

but I doubt I would have gotten much done even if I had nothing to do, I just wasn't in the mood this weekend, going through a low phase, but I'll snap out of it soon enough.

it is most important during a low phase of a project to keep sight of the big-picture end goals, and to keep excited about them so as not to abandon the project.

every game project has these points, so to avoid the 'start and quit' cycle that many indies have it is essential to learn to roll with it.

so, as I was saying, on the brink of good stuff, such as:

adding interaction (hit-testing, etc.) to entities.
and the final iteration of the radial menu system.

I developed the Radial Menu System, when I wasn't very familiar with boost pointers, and more importantly easy and efficent uses of shaders and geometry.

so the first result turned out to be really kludged, from an internal standpoint.

the biggest internal kludge was realizing that boost pointers and dealing with tree strctures can get messy.

for instance

node:
smartPtr parent;
list of smartPtr children;
void add(void);


in this case when using add to add a new node to the children list it would require thier parent member be set (to the parent node) however from within the context of the parent node you dont know what it's smart pointer is, and it cannot be gleaned. there are a bunch of kludged ways around this but instead I opted for a different approach

node:
node(smartPtr parent);
smartPtr parent;
list of smartPtr children;

in this case, creation of a node is required to have it's parent passed in (could be null), and children are added by direct modification of the children list, since this only serves as a data-model there is no problem in giving free access to the children container and enhances flexibility by allowing the standard algorithims to act on it instead of writing a few accessors.



from a graphical representation, i chose to use an offset orthographic projection to display my radial menu, while this seemed optimal at the time, it is actually easier to use a standard centerd orthographic matrix, since the items are meant to show in the screen center.

it also makes animating the list via scales and rotations trivial too.


Sign in to follow this  


0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!