Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 14 Jun 2008
Offline Last Active Oct 17 2012 01:56 AM

Posts I've Made

In Topic: Collection of Models question

14 August 2012 - 02:02 AM

If there is some limit on the number of objects, you could allocate a static array, and then loop through it when you need to edit / draw /etc ( just skip any of the objects / pointers that are "null" or otherwise aren't valid at the time.. )

otherwise - creating a dynamic container - vector, list, etc.. and iterate on it.. it sounds like you are getting accessviolation exception trying to go beyond bounds of the original array? or how are you trying to create the array of buffers ( or use it - where is the exception coming from ?? )

In Topic: Spherical gradient

29 July 2012 - 09:17 AM

for the 2nd part of the question - move the center point without affecting the gradient itself... Just move the center point...
example - your new 'center' is (0, .5 , 0) .. so subtract .5 from Y and look up the value there..

Generalized, a function f of vertex P [ f(p) ]can be solved at a new 'center' c using f(p - c) ..
Written out longform this means substituting ( pX - cX ) everywhere you were using just X before, same with Y and Z.

As for the 1st part.. should just be sqrt(x^2 + y^2 + z^2 ) - the gradients would change according to sphere radius.. like layers of an onion..

So ( 0,0,0 ) is black core.. ( 0, 1, 0 ) is white point ( "north pole" )

In Topic: [OOP] Two classes that can acces each other's members

29 July 2012 - 01:12 AM

Oops.. forgot the last bit as well...

So - if any combatant needs info on another combatant, it just accesses the base-class ( or higher class through an interface / virtual function )..

No combatant knows or cares what is "brains" - only if they are "friend" or "foe" or if they're attacking, etc.. etc..

In Topic: [OOP] Two classes that can acces each other's members

29 July 2012 - 01:10 AM

"Player" and "Enemy" don't sound like distinct classes to me - they are "combatant"

"Combatant" has speed, position, possibly weapons, inventory, etc..

Then "Player" is a class derived from "Combatant" - uses input (keyboard,mouse, etc.) to change animations, positions, etc.

And "Enemy" is also class derived from "Combatant" - but this uses AI to drive it...

This would also allow later for AI characters to fight on either side, or possibly have multiple factions...
And networked / LAN players could be derived as well...

In Topic: Super Mario Kart Theory?

27 December 2009 - 07:35 AM

It was a camera "trick" of sorts - the Super NES had "mode 7" to handle the character sprites, scaling and what-not...

The track was just raycast, probably tile-based too. . .

The was a DOS shareware game that had similar look/feel to Super Mario Kart - Wacky Wheels . . you might be able to find source codes and such googling for that..