Sign in to follow this  
  • entries
    271
  • comments
    969
  • views
    189080

Update!!

Sign in to follow this  
Sir Sapo

305 views

Hey everyone, long time no see!

Thats right, I'm back with some more Angels 22 development news. Contrary to popular belief, I've been working on Angels 22 the past couple of weeks, but my lack of substantial progress, and a few killer bugs, ruined my work ethic, and the project floundered for awhile. Anyways, I'm back and in my programming groove again, so why don't I bring you all up to speed on what little I did manage to accomplish the past couple of weeks.....

Letterboxing
Mark came up with this one as a way to show the player that a cutscene is rolling (its kinda confusing when the camera shifts to something else without some indication that you're not in control anymore), and a neat way to introduce each level. It's not that complex of an effect, just two black rectangles that move up or down into position during a cutscene, but it adds alot to the experience IMHO. Anyways, here's a screeny of the letterboxing "in action", during a cutscene that introduces the first enemy ship you encounter....

EDIT: I just realized if you are using the black scheme for gamedev this screeny doesn't work too well[grin]



Thrust Vectoring
Thrust vectoring is a design feature in many next generation fighter aircraft that gives the aircraft incredible maneuverability by using articulated nozzles on the engines to "point" where the exhaust goes, which allows for some pretty neat maneuvers, as can be seen in this video of a
">Russian SU-37 at an airshow. (Look at the maneuver at around 1:40 to see how cool this stuff is) Anyways, we're going to give the player the ability to thrust vector in Angels 22 when they obtain the vaunted Partisan MkIII (see Mark's journal for details). It pretty much allows you to do some cool maneuvering of your own, and it looks pretty awesome in motion, but here's a screenshot of me "hovering" over the ocean, with the water spraying behind me....



Enhanced Scripting
I also recently added a whole lot of new scripting triggers and reactions to the A22 scripting language (which I really want to call Angelscript[grin]). They range from toggling letterbox mode, to hurting the player when he flys beyond a certain point. I'm really hoping that the language turns out at least semi-understandable so that other people can create their own scripted levels when we release the final version.

A New Direction
Since we had to drop out of 4E5, we can now get rid of the elements we really didn't like and take the game in the direction we really wanted it to. Since we can ditch emblems and emotion (to some extent), we can focus on the stuff that makes the game fun, not just the stuff that makes it fit the "requirements". Don't worry though, its still going to be the same old Angels 22, just without the crying for your lost wingman[wink]

The Mysterious Initiative Killing Bug
One of the main reasons that I have not been feeling like working on A22 lately is this seemingly random ass crash bug that has been popping up all over the place and with no pattern it seemed. What really had me worried was that sometimes the game would work fine on my compy, but when I put it on Mark's machine it would crash as soon as you unpaused the game (it starts off paused). I was convinced that this had something to do with the way I handle the targeting system in the game, because it involves quite a bit of rather dangerous pointer usage. I was very afraid that the entire system was faulty, and that I might have to refactor the whole underlying entity handling system, which would be a monumental and failure prone task. Since the bug was so random (some days the build that worked yesterday would crash today, but work the next day without any modifications), I was afraid to release a new demo, as it just doesn't bode well for your game if your demo release is buggy as hell. At the same time I was trying to figure out what that random crash bug was, another crash bug appeared, and I knew what was causing it, but I didn't know why: Suddenly, whenever I added a new constant to my "TypeDef.h" file, the game would crash when unpaused, but as soon as I removed the new variable, it worked fine. After trying in vain to get the problem resolved, I finally resorted to the forums, which garnered a post about using extern (as it turns out, not the problem, but I didn;t know what extern was before[grin]). Now that you guys know the backstory, here's what happened today: I started up the game, and I was getting the crash bug, so I decided to open up the compiler and start commenting stuff out until I found what was causing the bug. Now I had noticed earlier that whenever you took out all the enemies from a level, it fixed the problem, so I was able to narrow the search down to all the enemy entities. By removing the types of entities one at a time, I was able to determine that the problem was somewhere within the Update() function of either the Flak, Laser, or SAM Sites. After commenting out line after line to see when the thing would start working, I finally found the troublesome line of code which, much to my suprise, had absolutely nothing to do with the target pointers, thats right, the whole debacle was spawned when I accidently commented out this line:

//float tempangle;

For some reason, my compiler never gave me an error after, even though I use that variable about 5 times in the function. My guess is that sometimes the program magically figured out what tempangle was without it being defined, but randomly, it crashed because it actually didn't exist. Anyways, by simply uncommenting this line, the bug is magically fixed, and I can even declare more constants again without the damn thing crashing, which has certainly boosted my work ethic.

Demo Soon
Now that I fixed that damn crash bug(hopefully), I'm feeling abit more confident about releasing a new demo to you guys soon. I know I've promised that before, but I'm serious this time[wink]

Anyways, thats all I've got for now, expect to see at least a good video in the next couple of days, and perhaps a demo if things go according to plan. Peace Out!
Sign in to follow this  


5 Comments


Recommended Comments

1st: What compiler are you using?!?!?!


2nd: I would suggest searching your WHOLE project for another instance of tempangle because ive NEVER heard of a compiler not catching something like that, not saying its not possable though [lol]

Share this comment


Link to comment
Well, if you're using MSVC, run your project in debug mode and make it crash. Then check the stack trace to see exactly where the crash occurred, then figure out what conditions make it crash using the variable/memory viewers.

The MSVC debugger is absolute sex :3

Share this comment


Link to comment
I would suggest that you continue searching for exactly why the bug was cropping up. Compilers don't implicitly declare variables when you use them (if they do, it's a bug in the compiler).
This sounds like something that could easily crop up later and bite you in the ass. The mysterious bugs have a tendency to do that.
The other possibility is that you just happened to have a global variable tempangle somewhere else, and it was using that, and it's all completely harmless now that you uncommented that declaration.

EDIT: Also, I've seen VC++ do some rather strange things with float variables that are used before being initialized. In my AI routines I used to have a float for holding the distance to the closest enemy, as well as an integer that held the index of the closest enemy, and they were used like this:

closestindex = -1;
for (idx = 0; idx < enemycount; idx++)
{
<calc distance>
if (dist < closestdist || closestindex == -1)
{
<blah>
}
}

It would run flawlessly on Linux, but would crash every time when compiled by VC++ and run on windows. The solution was to just initialize closestdist to some value just before the loop. Odd behaviour, but I guess that's just the way it is.

Share this comment


Link to comment
Quote:
Well, if you're using MSVC, run your project in debug mode and make it crash. Then check the stack trace to see exactly where the crash occurred, then figure out what conditions make it crash using the variable/memory viewers.

The MSVC debugger is absolute sex :3


Quoted for truth.

I don't know how I would live without the MSVC debugger. Actually I do: very painfully.

Share this comment


Link to comment

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