Not much for you guys tonight, but lots of progress has been made, trust me[grin]
Before Mark left for a week, he left me with a few good textures for the game, such as the nice tables and floor tiles you see in the screenies. He also left me an animated player sprite, which I just implemented tonight. As you can see below, he has no arms, as their positions will be dependent on the weapon you have equipped. Other than that though, he's quite the improvement from using that medkit to test stuff out....
The room transitions in FoT are pretty simple, the screen simply scrolls in the direction of the new room until it's the main room, whereupon the game continues. The transition isn't slow, nor is it instantaneous, which should deter most people from simply transitioning from room to room, taking a pot shot, and then going back to the old room. Anyways, its not really a good screenshot feature, because you have to see it in motion, but here's a screeny of the game in the middle of a transition:
The Story So Far....
While we haven't quite decided on a background story/reason why you are shooting zombies, but do have this much nailed down:
-It takes place in the same timeframe as Angels 22
-The Laboratory you're in is in Soviet Russia
-Those damn Commies are up to no good.....
I know its not a lot, but at least it rules out space marines and aliens (or does it?[wink])
Well I had my first real mind boggling bug in FoT today (and yesterday I guess), I know most of you don't care what it was or how I solved it, given that no one has ever seen the code for this game, but hopefully you can learn from the moral at the end....
So I finally implemented multiple rooms last night, and everything was going fine, until I plopped my handy little moveable health pack in the level to see how the rooms transition. At first glance, everything seemed ok, until I moved from one room to another, whereupon the collision detection got all screwy, and I started colliding with invisible things that stopped the medkit in his tracks. I had no idea where to start looking for why this was happening, so I started experienting, and discovered that the things I was colliding with were in the same layout as the first room, even if I couldn't see them. That was my first clue that somehow, tiles from previous rooms were somehow "leaking" into the newly transitioned one. I then proceeded to look at the transition code to see if I was updating the old room, but rendering the new one. All this time could have been saved if I had just gone to the source of the problem in the first place, the collision detection code. After exhausting all other options, I remembered how the objects actually know where the tiles are to collide with in the first place. Instead of passing a reference to the level everytime I needed to check for collisions, I had made a static array of tiles in the GameObject baseclass. These tile objects were set equal to the room's tiles at the beginning of the program, which worked fine, until you moved into another room, whereupon the object still used the old room information to check for collisions. A quick line of code to update the tile info when rooms were transitioned quickly fixed the problem, which brings me to the moral of the story. If something doesn't work, look long and hard at the actual function that isn't working, because 9 times out of 10 thats where your problem will be. I spent about 8 hours trying various fixes before I even looked in the collision code..... Arghhh!!
Well, I'm going glider flying tomorrow in a single seat Grob G102, which is pretty damn fun, because you're all by yourself, and the glider isn't weighed down by an extra seat and instrument panel. The weather looks favorable tomorrow, and hopefully I'll get some good flying in, which means kewl piktars foryou guys if I remember to bring my camera.
Well, thats all for now, and as always, comments are welcome. Peace Out!