|
So, this week has mainly been presenting the game in it's current state to other team members and those who attended the Game Developer Forum meeting on Tuesday as well as ongoing assessment of where to take things. I got some of my tax money back on Tuesday as well and yesterday, along with paying some bills and taking care of a few other necessities, I picked up an Xbox 360 controller and a wireless 360 peripheral receiver for Windows. So, today and for however long it takes me over the weekend, I'm starting to implement DirectInput(for non 360 gamepads and devices) and XInput functionality into the engine. I'm also going to fix a few things that I thought of at the game developer forum meeting and that was suggested to me by some of the group participants as well, but those fixes shouldn't take very long. Away I go.
I took a few days off last week from focusing on the code. Mainly the weekend as I spent time with my son and nephew. After having that time away and then coming back to work on the game again, I began sifting through the code for the demo and thought to myself that it's now time to start refactoring code.
The demo , in it's current state, is an ugly mesh of global functions, the physics code for the block management and bullets are stuck inside places that don't really make sense and use math functionality that can easily be stuck into a component class for reuse, and it's all large enough where it's hard to manage and can take anywhere from 30 secs to 2 minutes for me to find a certain section of code at times. These are all bad signs.
I was planning on waiting to refactor until I was finished with the proto-type, but the code is getting in the way of productivity now and the addition of a vector class and a generic physics class to the engine in general will be a definite benefit. I'm also going to take this time to go a head and begin implementing the support for game pad functionality into the engine.
Doing all this stuff also has a second function. It's going to allow me to do some more experimenting with the wide area collision management system as well as allow some time to do additional research as I've yet to finish that part of the game. Also the addition of the physics class for the engine will allow me to handle multiple types of physics calculations for a single function that I can switch between in certain instances which will add for some interesting play mechanics.
This means that a public demo has the possibility of being delayed a little, but hopefully not, as once these items are done it should actually speed up things nicely, it'll also make for a more complete demo and hopefully save time in the overall development of the game once we start production of that.
So, after really getting down and dirty, replacing code with previously tested code in different sections and completely substituting the entire current structure of the prototype with the old one to make sure that the problem was in that code I finally figured it out.
IT WAS ShowCursor(true);
Don't ask me how the hell this was making everything corrupt, but it was, I don't get it?? Who'd a thought. I use that call in other places and have never had that problem before.
So, I found the error that was causing the release build to throw an exception. It was an instance of a class that was created for testing and referenced in a small local part of the code and for some reason alt tab-ing out of the app was causing some sort of corruption, so I got rid of it. Now something else weird is happening. Frame rates are dropping drastically in areas that contain hit test for mouse detection. I've never had problems with this before, and it only happens if I load the Barricade prototype first. If I load another of the demo's that are accessible in the engine, even those that use hit testing, it doesn't produce the same result. I spent a long time looking over the code. I even compared it to previous versions but couldn't find anything. I'll find out what it is or go blind trying.
This weekend is kind of crunch time, but I've got my son this weekend, so I probably won't get that much done code wise. Which means I need to concentrate a lot tomorrow and Sunday night and Monday night. The manager at the place I was supposed to start working this week also hasn't returned any of my calls. It's got me a little worried, but I suppose as Bob Marley says, "Lord I've got keep on moving, Lord I've got get on Down!" so I'll just keep my spirits high and hope for the best, prepare for the worst. I really want to start working though, but I guess I just have to things as they come, is all anyone can do.
So, I got burned out on working on the block dropping management system on Sunday after I fixed the issues previously stated and there was still errors happening. The system is going to need a complete overhaul. I've got the right ideas, but I'm missing some functionality that I had initially tried to put in(mainly keeping track of the blocks that surround every block), but for some reason didn't work like it was supposed too. So, I need to fix that and then go ahead and redo the entire system.
Instead of working on that, I've been getting the bullet class up to par. I've got bullets firing now, got the bullet chamber up and cycling through bullets, and have the bullets following the correct vectors to where the aiming reticule is currently located. I also got a good speed for the bullets to travel at. One where they are just a blur, but you can still see them, because well, it's a game you need to see the bullets flying through the air. I've next got to get the damage inflicted on the aimed at blocks, which will require a little bit of ingenuity as conventional intersect testing isn't the solution.
Here's a screen shot.
Click For Bigger
I've also ran into an interesting problem with release builds that I can't put my finger on. It just started happening with this last build. And I can't reproduce it with a debug build. When I alt tab out of the app or minimize it a few times, it triggers an unhandled exception. As far as I can trace what's happening on the stack is that for some reason, the application is calling the destructor for a sprite when alt tabing back into the application. This doesn't make since because it shouldn't be being called. It'll definitely require some research. I think I may just try rebuilding though and see if it still happens, a bad build possibly? Who knows.
Only a week left from today until next weeks game developer forum meeting in Ankeny, and while I'm close to where I want to have the game by that time, there is still a lot to do. I'm kind of burned out on it too and have been wanting to take a day off from working on it, but I just can't seem to keep away. Especially because the weather is horrible, it's cold and snowing, and because the company I'm supposed to start working for this week hasn't called me to get started yet. And plus it's too much damn fun to work on. I think I will take tomorrow off though.
I was up very early today and began setting back to work on the second phase of the wide area collision. There were three problems that I came across during that time and after resolving them I figured I was done. I tested it a few times and after a while I began to notice the blocks were doing some interesting things. Interesting meaning doing things that they shouldn't have been doing.
Things being that they were falling in the correct spots, but for some reason certain blocks were only partially falling to the point they were supposed to before being marked as at rest, so they were being suspended in mid air, which meant a collision was happening and they were hitting the blocks directly below them, as the system is designed to check for, but I was a little confused on why. So, I took a break from the collision for a while searched for some new fonts, did a little bit of texture mapping, had lunch, and then came back to try and tackle the problem.
I've found that from time to time when I do get stuck, it's a good approach to move onto something else, and then I can come back later and look at the problem without as much stress and a fresh set of eyes. In this case I was actually going to finish implementing the bullet class so I could shoot multiple blocks to help figure out what was going on, but as I sat down to do that it dawned on me that my design for a two phase wide area collision system was flawed.
In the current system there are 2 phases, phases in this instance can also be translated to 2 large code blocks.
The first phase consists of looking to see if a block is marked as no longer being collide-able. If it is marked it's then marked to be destroyed. It then cycles through every block checking to see if it is in the same y cell column and that no other blocks would stop that block from falling. If those criteria are met then the block is marked to fall, grid location is updated depending upon the size of the block being destroyed, (the size of the block being destroyed tells us how many cells our other blocks should fall), and that's it for the first phase.
The second phase is where actual collision tests take place based on sector locations as well as actual updating of the blocks positions. Designing these two parts separately was a mistake however because of the way in which the blocks are placed on the grid to begin with. It's done somewhat randomly, placing blocks where there is no block and where there is room to place them. Meaning that having the second phase executed outside of the first phase causes the wrong blocks to fall first. This results in premature collisions, which results in the suspended blocks.
For example :
|_2_|
|_3_|
|_1X_|
Block one is the one being destroyed and blocks 2 and 3 are marked to fall.Because the blocks are out of order, when we reach the second phase, block 2 is checked for collision first and moved first, meaning, that since block 3 hasn't moved yet a premature collision happens. This may not happen every time, it depends on where the block is that is being destroyed and where the blocks that are falling are located, but it's an obvious design flaw.
So, the solution then, which I'll begin working on after this post is to combine the two phases together. Even though the blocks are iterated through in the first phase, we start with the one directly above the destroyed block, so, if I start moving these blocks as soon as they are found, then the premature collisions should no longer happen. At least that's what I'm thinking right now. I guess I'll find out soon enough.
Well, I've been pretty busy with other things today. But I spent a few hours fixing another problem. If you look at the screen shots below, ever since I started working on the collision and block placement, the blocks seemed to have a lot of space in between them. I was a little confused about this because I had used my editor to map the textures to the size that they were supposed to be. It turns out however that somewhere a long the lines I had lost five pixels in length and width on my small blocks. Using math to multiply the bounding volumes was how I got a visual stencil to map my other sized blocks, so the loss of five pixels translated over to 10 in width of the narrow blocks and 10 in width and height for the bigger blocks. This of course is what caused all that space. After figuring that out this morning, I set about fixing it over the last couple of hours. That's done now. Here's a screen shot.
__Click for bigger view__
Ironically all that space actually helped me to develop my collision system though, so it worked out pretty well having that error happen.
Ah.. now that's much better. I still haven't finished the wide spectrum collision, but as I stated I've been busy with other stuff today. I may finish it tonight, but definitely will get it done by tomorrow. I'll be going back to work at a day job next week, so I want to get as much finished over the weekend as possible. More later.
Ok, so I'm still hard at work and making decent amounts of progress.
Yesterday, I took the time to fix proper scaling of the bots in proportion to their game display size in accordance with their actual size on the sprite sheets. I also remapped the textures so that they are now more precise and there are only some minor fluctuations now that your average person probably won't notice, just very slight dither blurring at certain translation locations of the sprites. I was thinking that it's due to floating point error, but I'm satisfied with it for the demo. That actually took most of yesterday to complete and I think I did some more things as well, but I can't really remember so they must not have been to vital.
Today I set back to work on the wide spectrum collision detection for the blocks. What exactly does the wide spectrum collision detection entail you may ask. Well it simply keeps track of the blocks that aren't resting(as in falling), what sector(s) of the block placement area that the block is in. It then looks at other blocks in the same sector and determines which one is underneath a falling block. From there a narrow collision is checked against that specific item. If a collision happens, the falling item is then marked as resting. It works out pretty good.
The second phase of the wide area collision has to deal with updating blocks when blocks below them are destroyed testing if other blocks prevent certain blocks from falling and then entering into the first phase. I guess you could really reverse the numbers for the phases or just call one the top phase which is what I have to finish yet. I got some testing and tweaking to do to it yet. Hopefully that'll be finished tomorrow with minimal effort.
In the meantime, here's a screen of the first phase in action. After the blocks are initially placed on the grid, the collision system now kicks in and the blocks land on top of each other. If you scroll down and look at the picture of the post where I finished the initial block placement, you'll be able to notice the difference.
Click it for a bigger pic. More Later.
Damn it feels good to be a gangsta. I finally, after about a week of doing research into using Separating Axis Method for collision detection, and working on the collision systems for the engine and for Barricade on a whole for about three weeks, finished the narrow pass collision detection. I want to do some cartwheels right now because the whole process was kind of starting to get under my skin. Reason being, I'm no mathematician by any means and the only resources available out there are written from a math theorem perspective. But anyways, I've complained about the process too much as I did it, which if I didn't complain as much I probably would have been finished faster, but it's done.
So.. I can finally go back to concentrating on building a wider spectrum collision management system for the game barricade. They systems already about 75% done at this point, I just have to continue to tweak a few more things. I was worried I wasn't going to make my goal of having a playable proto-type for next months game development forum meeting, but it looks like things should be a go. There's still a lot that I want to get done before an official public release however, but that will hopefully be ready by the first of March or round abouts.
Things that still need to be finished at this point include, but probably aren't limited too..
Finishing the Wide area collision management system.
Remapping some key textures for sprites and animations.
Getting the texture fonts mapped and loaded.(Currently using bitmap fonts for the game.)
Getting some temp sound effects for the demo and getting those inserted into the correct places in classes and adding the proper audio updates.
Replacing the temp graphics made by me with actual graphics made by Dwayne for the game.
Implement the bullets class and resolve bullet to block collision.
Add the ability of blocks to drop powerups and other items upon being destroyed.
Implement chain effects for blocks(Not sure if this one will make it into any of the demos because of lack of information on how this is supposed to work regarding how damage effects different block sizes and Mike Pool is no where to be found for comment.)
Implement powerup effects.(Not sure if this will make it into the demos for the same reason mentioned above.)
Implement gamepads.
Implement general scoring system for the demo.
Create a general level manager in charge of dynamically selecting play arenas and calling the functions related to generating blocks upon the start of new rounds.
There's a lot more stuff to do from there, but once those things are taken care of, a public release of the proto-type will be done. Then we'll have to see how things go from there.
I know after that I need to get back to working on the editor scribe and really start focusing on having the engine be more dynamic and taking care of all the design elements that I made sure to put in place last year. I'll post some screen shots later in the week once I start getting more things up on the screen.
Seeing as this is the first game I've ever programmed using the game engine I've been building over the last two years, I knew I would have a lot of problems to solve. I've gotten over a lot of hurdles that I've come across, and I'm learning more everyday, plugging away everyday, but some days, I just want to have it done.
A lot of the stuff are design patterns not common to me. Essentially what I'm finding is that designing systems for large numbers of objects that require constant updates and such seems to become more and more complicated. The more problems I solve, the more I seem to come across as well. Once again, I'm still making progress, but it's requiring a lot of testing, a lot of small tests for implementing new systems and unfortunately, because I'm learning as I go along, a lot of re-writing things as well.
The most important thing that I'm learning I think, is that sometimes it's important to take the time and think about a problem from many different angles. If you don't you can find yourself designing an entire system that can later get tossed out, and then you end up losing a lot of time that you can't get back.
Things slowed down a little bit on the development front this last week. I didn't make as much progress as I had wanted because of the problems mentioned above. This simply means I'm either going to have to learn to more efficient, or have to end up putting in more time so that I can try and make up for lost time, or both. At any rate, I'll have some screen shots and more meaningful posts later in the week, maybe even a video, but we'll have to see how far I make it. Also, I've been aiming for an end of the month completion, but it may end up being a few weeks beyond that, but I should have some game play by the end of the month for sure, I just want to take the time to polish things up, but I do plan on having a play session at next months Game Developer Forum here in Ankeny Iowa. Back to coding.
Ok, I ended up spending the weekend hanging out with my son and my nephew so I didn't do any coding. Today , aside from a couple hours this morning that are my daily exercise, eat, and shower routine and a few minutes to make this post, I'm pretty tied up.
Yesterday however, I finished writing the block management class and finished writing the block generation and placement for the game Barricade. Here's a screen shot.
Clicky For Bigger
It felt great to finally get this finished. Tomorrow I'll be starting on something new for the game. More later.
Ok, so I ended up scrapping the entire collision based block placement idea after a few more iterations of merking with it. Instead I decided to go with a basic grid placement system, that I will hopefully have finished by the end of the weekend. I just keep track of the space available, how many blocks of various sizes I have to place and update that information after each block placement. It's more of a simple system and actually makes sense, unlike my mad scientist ideas previously ventured. More later.
I was doing some more reading and I had a side thought about the last suggested block placement logic. The way it is currently set up the loop exits upon first collision, meaning that if the block were to intersect on the x axis while it was being placed, it would simply be projected away from the object it was colliding with and then the loop would exit leaving it possibly suspended in mid air, if the block was now no longer colliding with an object.
OOps, not what we want to happen. This is an easy fix though, we just have to continue to move the object through the main do loop until both an x and y collision has happened, so that the Object is at rest. So, this will change the logic structure too..
int collide=0 //Change collide to an integer value
do
{
if(collide==0)
{
Move block along negative x and y axises by -0.005
}
else
{
Move block along negative y axis by -0.005
}
if( collision with block placement area)
{
determine the projection by seeing which axis is the shortest distant to
non collision
move block to new position.
collide +=1; //ADD ONE TO COLLIDE
if(collide==2)
{
break; //(SIMPLE IF ENCLOSER OF BREAK STATEMENT)
}
}
else
{
do
{
subtract a number from the current block to work down the list of previously
generated blocks
if(the current block to check is out of bounds)
{
subtract one from the current row of blocks to check and make the last
block in the row the first to check
}
if(the row is out of bounds)
{
no collision happened, so break this loop
}
if(collision with current block to check)
{
determine the projection by seeing which axis is the shortest distant to
non collision
move block to new position.
collide +=2
break;
}
}
while(there's still blocks to check)
}
}while( collide<2)>
This seems to fix our problem, but upon closer inspection we run across one more. Using the current structure of logic the blocks at some point will begin to leave spaces due to the inability of the blocks to know about spaces between each other. This problem occurs no matter what point of origin is used for placing the blocks into the Block Placement area. This is due to the different sizes of the blocks and the random nature of their creation.
So.. Now what?? Well one solution is that through the use of reference counting, the blocks keeping track of the order in which they are created, that they should be able to share information with a management system. It will be the job of this management system to keep track of available space that needs to be filled as the blocks are generated. For example : The first row of blocks can be generated by keeping track of the translations of the blocks before them without running into the space problem. By simply knowing the boundaries of the block before it and knowing it's own boundaries the right origin for placing the block can be determined. Once the first row is filled, if we continued to rely on this system alone, the same problem would occur so an added element is needed. Because of the nature of the growing complexity of placing these blocks, this is where a quad tree does indeed come in handy. By Subdividing the space we can know which blocks the next block placed in the new row can come into contact with, without having to cycle through all of the blocks. It will be up to blocks to keep track of what sectors or branches of the subdivided space they are in so that when an initial collision occurs on the new row, by comparing sizes of the blocks, and knowing the dimensions of the each sizes bounding blocks, we can determine where the new block will fit without wasting space.  This sounds well and dandy in theory, and I'm glad that I took the time really analyze the problem before attempting to really code the solution again, even though this analysis took me a couple of hours, it probably ended up saving me a couple of days time. Following this model I will be structuring a new system for block placement. I will post screenshots of this implementation, even if it ends up that it doesn't work out. That will be available sometime later today. Further analysis will be required as well if this implementation fails.
I'm trying to get into a habit of continuously blogging with good content. Hopefully I make that become a reality. It has been a somewhat progressive week.
With the addition to the implementation of the bounding boxes for objects in the game engine, I also managed to add some simple AABB type collision to the system.
I'm still struggling with how I'm going to actually handle the collisions for the initial block placement in the game barricade however. So, because of this, tonight, I'm taking some time dedicated solely to research in that area.
Yesterday, I experimented with writing some simple functionality that took a block and moved it from the center of the world origin down the negative y axis and the negative x axis until it either came into contact with the block placement volume or another block. Once a collision happened, a test would take place to make sure that the block was not outside of the block placement area, if it was, we iterated small movements until it no longer was testing both the X and Y half-vectors of the bounding volumes. ( I realized that this wasn't the best approach as it eats up some time, but seeing as how there are only a maximum of 60 blocks currently being created, I figured it was at least worth experimenting with.) If it was intersecting with another block we did the same thing. Now feasibly this should work, except that you either A) have to at least divide areas into sub regions and check every block in that region, or B) check every single block in that has already been generated and placed. Seeing as how the game works with such a small number of objects, for simple block placement it didn't seem to make much sense to write a system to check for subdivision organization. My opinion on this may eventually change as I do some additional research this evening.
My problem with the sample implementation yesterday simply was a lack of accurate checking on the x axis for all boxes. I was simply trying to write something fast and was some what disoriented as I've been sick for the last week or so, again.. damn winter, At any rate, I only checked for a collision on the previously generated and placed block instead of with all
blocks. Essentially what I was supposed to have written was two separate main bodies of code for collision, one that checked for block 2 block collision and one that checked for block
to placement bounds collision. Inside each one I was supposed to have checks to see what the shortest path of projection for the objects to no longer be intersecting was and then move the objects appropriately to their resting places. But as I said I didn't check for every block on the x axis, and I didn't get the new translation position from projection, instead, I did small moving increments, which looking back caused extra checks to be made afterwards.
Writing this out has really allowed me to see where I went wrong with things yesterday. I had the right idea, but my actual implementation was wrong. My new structure should look something like the following.
bool collide=false
do
{
Move block along negative x and y axises by -0.005
if( collision with block placement area)
{
determine the projection by seeing which axis is the shortest distant to
non collision
move block to new position.
break;
}
else
{
do
{
subtract a number from the current block to work down the list of previously
generated blocks
if(the current block to check is out of bounds)
{
subtract one from the current row of blocks to check and make the last
block in the row the first to check
}
if(the row is out of bounds)
{
no collision happened, so break this loop
}
if(collision with current block to check)
{
determine the projection by seeing which axis is the shortest distant to
non collision
move block to new position.
collide = true
break;
}
}
while(there's still blocks to check)
}
}while( collide == false)
That should be all the code I need for proper placement of the blocks, at least that's what I'm thinking right now. Yesterdays implementation was something like 273 lines of code, so, if this works, it should speed the block placement up drastically. I'm still going to do some additional reading before trying to implement this in the actual game and make sure that there isn't a better approach to take that I haven't thought of yet. Hopefully, my next entry will include some screen shots of some neatly placed blocks.
Well, I spent the last few hours working on implementing bounding box collision detection. I would have gotten farther today, but I spent a lot of time looking for a simple bug in the wrong places, which sometimes happens. Essentially for the game barricade, I have it setup so that I can see the bounding boxes in debug mode for the game. Or, at least that was what I was trying to do. All I could get it to do was draw three boxes in the center of the screen though, one for each of the different sizes of blocks in the game. So, I went hunting to see if I could find the problem. I thought maybe I wasn't drawing it right, and tried different variations of using offsets from the quads the sprites are drawn on. It didn't work.
I then realized, after setting some break points, that the data stored in the structures for the sprites bounding boxes was still set to zero. You see, I had placed setting the bounding boxes translations in the same function that generated the sizes of the blocks. This wouldn't have been a problem, except that the bounding boxes are determined by an offset based on the dimensions of the textures and the translations of the quads for the sprites themselves. So, of course the size of the blocks would need to be generated before the placement of the blocks, so the data wasn't getting set correctly. I finally figured this out after looking around for a while. Simple, simple things can cause such chaos in a system.
So, I ended up re-building the system within it's own function and had it updated after the placement of every block. This worked out great. Here's a picture of it in action.
Clicky for bigger View
Next up tomorrow will be writing the actual collision detection for block to block collision. Then it will be on to finishing the bullets class, followed by bullet to block collision. Then bot to powerup collision.
After that the only things left to do will be to code the powerup effects, the scoring system, add sound effects, and the demo will be finished. I'm aiming to get this done by the end of the month.
It's been a while since I have blogged oh blog of interest oh mine. As a new year starts I am reminded of my own mortality, of the short time that I know I have to get things going, of the relationships that I have to remember to cherish and of all the good things that are to come.
Game development wise, things have still been moving forward, slowly but surely. I was even gracious enough to help start a local game development meeting that meets the second Tuesday of every month, which is very cool. It's good to find some kindred spirits in the area. Unfortunately life has been heck tick due to some bad decision making on my part, so I haven't really had the time to build those relationships as much as I would like, but that should change with time.
Engine progress is going well, editor is coming a long too. I'm entering a design phase again currently, making sure that things are going where I need them too and deciding on the functionality that I really need to concentrate on. Also, I'm shooting to have a playable Barricade demo complete by the end of this month. Short of adding collision detection to the game demo, it's pretty much complete.
I'll be shooting to journal more once again, as I gain some stability to my interest once more. I'll need to structure up some actual interesting things to write about for a change though. :P
Building an editor takes time. It has been taking me a while up until recently. I guess I really haven't spent that much time on it up to this point either, but it's becoming more pressing as the engine moves along. Design has been rather slow, but things will be picking up this week. I took some time off from game development, about a week, after having to drop out of said competition mentioned in the previous post.
It did give me some interesting ideas to continue to move things along however, so it was not all in waste. I think I'm going to continue to make the game I started developing resources for during the competition as I develop the editor as well. This way I can hopefully find any bugs that may come along and have something to keep me busy as I work on back end python scripting for the engine. I hope to have that and the editors GUI and menu's finished by the end of next weekend.
I haven't been working on Wrath of The Scarecrow the last week either and one of the books I ordered from amazon was canceled so I'm still waiting on some material. I'll start back to work designing WOTSC tomorrow as well.
It's been a little bit of time since I wrote anything in this blog, which is something that I should put an end to this week. I don't really have a lot of time though, and as such I've been blogging over at my GameDev.net Journal
a lot. In regards to the issue with the sprites, I fixed the issue the same week as my entry. Essentially it came down to texture filtering. So graphics look great now. For anyone who may not know. The game that I was working on, Barricade, with Phyersoft has essentially been indefinitely postponed due to the designer not having follow through with the project. So, I've been working on a little project that I like to call Wrath of the Scarecrow. Check out my other journal if intrigued I'll be posting some stuff in here about work on the engine soon as well.
I'll have to update this blog later in the week. In the meantime check out the Taming the Beast link to the right over there. You'll find information about the project I'm currently working on, if you're interested. Which if you're here reading this, you might just be. Barricade is on hold indefinitely as far as I know, but an equally, if not more exciting project is underway. More later.
Well, I was hoping to have already been working on the demo for the comic book convention by this point for Barricade, but time flows a lot faster then I would like in a day, or at least it'd be nice to
A. Have enough wealth so I wouldn't have to work to earn a pay check for the rest of my life, I could dedicate my time to that which I wanted(I'm working towards this one.)
B.Had more hours in a day.
C. Could manipulate time with my mind so that I could get more accomplished.(I'm working on this one also)
So, I'm not really that far behind schedule all things considered. Only a couple of weeks of what I was shooting for to get done in the month of march, but now I'm running into some other issues, that I recently had to solve, and are in the process of now being resolved.
The main issue, had to do with animations for my sprite class. I have no idea how other people handle this in their code. I haven't bothered to ask or do research, but the way I've been handling it is simply loading a sprite sheet into memory as one texture and then mapping the sections with the individual frames to be shown at the appropriate time.
Some pseudo code might look like
----------------------------------------------------------------------------------
LoadTexture
Sprite->Animate
Call to Animate Looks like
advance function hit count
get active frame
if enough hits have taken place advance the active frame number
MapTexture
for frame one show these texture coordinates
for frame two show these coordinates
ect..
---------------------------------------------------------------------------------
My actual codes a lot better structured and is organized object orientedly and works great. The problem is that when I go to manually map my textures in my current editor
(I'm concurrently building a new editor as these issues and the demo are being built)
I have to go in and manually manipulate the textures for the frames to show up correctly on the quads. This is where I'm sure it isn't the best approach, but I don't really know another one, (Aside from having the graphics artist create the sprite sheets very precisely, which seems to be as much trouble as I'm having on my end anyways.)There are slight shifts in the textures do to slight shifts in the textures when I'm going in to map them, and while the anomalies are small and would even possibly be unnoticeable to someone playing the game, they are pretty damn obvious to me.
The solution I've come up with thus far is to increase the precision of movement for mapping the textures and also come up with a more precise grid for aligning the texture on the quad. I'll be trying this out in the next couple of days when I have a little bit of time this weekend.
If anyone out there can make some suggestions or offer any similar experiences up, I would be thankful, although I'm not sure if anyone ever reads this anyways, but if you do thanks in advance for the comments.
|
|
