This week I created a bug/feature list to better keep track of issues and what I wanted to do. And the list says that this week missile rate of fire was limited, explosion rendering was fixed, the player’s physics body was updated, jumping was converted jumpjets rather than legs, the player can now be controlled using an x-box controller, and work was started on a HUD. That sounds like progress to me! w00t!
This week’s accomplishments are mostly of the bug crushing variety. I reduced the likelihood that the ‘no more jumping for you error’ occurs. I’m not convinced it’s completely resolved. What exactly is this error you ask, well let’s start with a screen shot (finally) of physics body debug render. The player is represented by the small square on top of the circle on the bottom about 1/3 of the way in from the left side.
Since jumping is conditional on having something to jump off of at present, the circle fixture checks to see if it has contact points near it’s bottom. if yes then jumping is allowed if not no jumping for you. At various times during testing the player stopped responding to jump commands while appearing to be grounded visibly and with in a few thousandths when the numbers were reported. The cause of this phenomenon is it seems that when Box2D contacts are reported to a libgdx box2d contact listener only the most recent contact point is retained. So if the player is contacted from the side, by let’s say a box propelled by an explosion, the circle would record a side contact and decide it was hovering making jumping impossible. The solution I used was to shrink the size of the circle ever so slightly, so that the box now projects out past the sides of the circle slightly. This has eliminated current instances of this issue, but I’m not convinced all cases have been eliminated.
In other news Rho_Bot stopped by long enough to find a problem with the explosion system. Basically too many explosions (to put a number to “too many” somewhere 3-4 range) in rapid succession caused the program to hang while the physics calculations were completed. This was solved by limiting rocket ROF which was planned anyway.
I’m beginning to remember why I didn’t want to do a status update post every week when we started this website.
It’s that what gets accomplished in one week tends to be easily summarized in a few words. For example this week I got projectiles working completely and explosions working partially (unless being able to walk on compressed air waves is a feature in which case explosions are done), and while someone who does game development would think that’s a reasonably productive week when combined with bug crushing. Those of you who are not developers are likely thinking, ‘that doesn’t sound like much. Why didn’t he do more? And where are the screenshots.’
Well the screenshots are coming … eventually. I could post some box2D debug renders, but that’s just a bunch of rectangles outlined with different colors. Ahh the days when someone around here did artwork.
Speaking of Box2D I’ve got more things to say about it. Some good some bad.
I used Box2D to implement the explosion. I think it is fantastic and reasonably straight forward now that I’ve done it once.
Things get stuck at the seams of butted objects; not always but often enough to be annoying. This is a known issue and is supposedly being worked on. Currently suggested is don’t place objects contiguously. This means that loading a world tile by tile is a no go.
On first implementations of things I frequently pass bad data or make inappropriate calls to the Box2D world. This is a normal part of the development process however since I’m developing on java and Box2D runs in native libraries I get lovely unhelpful error messages like.
Process finished with exit code 255 (Box2D, java, libgdx)
Which I got when I tried to add a new object while the world was stepping.
EXCEPTION_ACCESS_VIOLATION (0xc0000005), AL lib: (EE) alc_cleanup: 1 device not closed – (Box2D, java, libgdx)
[Update] which was caused by attempting to address(dispose of) a body that had been disposed of.
I also had an equally unhelpful error when I disposed of a shape before instantiating a fixture based on that shape. I’m too lazy to reproduce this error so no console capture for that one.
Since these crashes happen in native code that means that lost objects aren’t cleaned by the java garbage collector, and it’s entirely possible they sit around causing a memory leak. yay. Oh wait that other thing, booo.
Last week I mentioned screenshots for the platformer, and everyone here to see those will be disappointed, because instead of spending time adding content and updating graphics I decided to reorganize how level data is organized. Why exactly did I do this?
Because I could.
Also levels were defined in a combination of *.xml and *.json and I wanted to standardize it a bit. Now all level data is stored in a single *.json file. I also wanted to move level loading instructions into their own class. Previously level’s loaded themselves; however, the level class was getting long and moving the loading functionality seemed to be a logical way to split up the class.
So not a very exciting week when viewed from the easily demonstrated progress dimension, but streamlining level files and improving class compartmentalization should make things smoother going forward.