Jump to content
  • Advertisement
  • entries
  • comments
  • views

Udo updates

Sign in to follow this  


After the depths to which we quickly sank in the comments to my last post, I shall just briefly say that my Sky+ TV service is now all installed. I now have over 200 channels of crap to choose from, the only real net effect being that it will now take me far longer to figure out there is nothing on I want to watch.

Having taken the day off to await the engineer, I've made some good progress on Udo today.

I drew the above forward-facing sprite with its feet up and twice the size of the normal Udo sprite and now, when you die, it sort of leaps up and out of the screen at you by starting off drawing it at half-size then gradually increasing the sprite size as the horizontal movement plays out. Looks quite nice. Looks alright as a static image above as well, actually, IMHO.

The particle system is working and you can also now collect the stars. The star collecting is not very interesting in itself, but it is based on the new collision-response system.

Objects all derive from class Actor, which has two virtual methods of interest - CollidesWidth(CollisionInfo &Info) and CollidesWithUdo(Udo &U).

When anything runs through the functions in the collide module, first I gather CollisionInfo's into a vector from various places, depending on what the object collides with. These can be either from Actors or from MapCells. Each CollisionInfo stores a pointer to Actor which, if NULL, means it is a cell and the MapCell member is valid. Bit icky, but no need to go overboard.

When you call a collide method, you pass in a pointer to the Actor being tested. This in turn then calls Actor->CollideWidth(Info) on each CollisionInfo structure that the actor is found to be intersecting with.

Within just Udo's implementation of CollideWith(), if the CollisionInfo points to an Actor, that actor's CollideWithUdo() method is then called, passing through the reference to Udo.

Each Actor can then respond how it wants, including calling back methods on the Udo instance, since through some forward declaration and including nonsense, all Actors in the hierachy can be aware of the Udo interface.

Thusly the Actor interface avoids getting polluted with "do nothing" methods that only apply to the player, and new Actors can be snapped into the existing system fairly easily.

I really need to dust off some old sound code and get sound working at some point soon since that always seems to bring things to life.

Nicked the tar from Pod as well and turned it into water. Looks okay.
Sign in to follow this  


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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!