So, ah, looks like my "trusty" old MacBook Pro may have gone to the big Apple Store in the sky.
As I was browsing a twitter feed during lunch, the video glitched out and froze the machine. Hard-resetting resulted in a glitchy-looking Apple boot screen, then the "Kernel Panic" message. Several hours of research and debugging steps later, I may have to call it: my GPU is fried.
I decided to stress test my normal-mapped OpenGL project today, to get an idea for how feasible it would be. For reference, my early estimates on ship complexity are about 200 sprites. That's a ship larger than the screen, about the scale of the Millenium Falcon for crew of 32-pixel diameter. And that ship has skeletal beam sprites underneath floor and wall sprites.
Hey Folks! Hope everyone had a good weekend. I kept meaning to sit down and work on an RPG design presentation for a possible developer's talk, but I barely would get into it when baby stuff came up. Such is parent life :)
Just a quick update today as I need to head out in a few minutes.
A chunk of today was lost to an errand. But the time when I did work I was focused on memory optimization. Steve pointed out that NEO Scavenger was starting to consume 200+MB of memory when all the data was loaded, and that'd cause problems on some mobile hardware. We needed to look into trimming that fat.
I think I'm making progress on the OpenFL+GLSL shaders. It was a close call, but by the end of the day, I finally wrote my own normal map vertex and fragment shaders, and they seem to be displaying like they should.
If nothing else, I'm learning OpenGL, GLSL, and a lot about 3D display math. For example, one thing my previous attempts did wrong was to use deprecated OpenGL uniforms. Namely, things like gl_Normal, gl_NormalMatrix, gl_ModelViewMatrix, etc. Silly me thought, "The shader already has those values? That's really handy!"
Hey Folks! Today started off with a bit more tablet parsing work. And later, more shader investigation.
I think I've finished putting all the data type and parser code together, and Steve is going to plug those into his encounter processing to see if things run normally. Depending on how that goes, there may be more stuff I can do to help shoulder the burden of the mobile port. 4 years of code is a lot to convert!
NEO Scavenger is now officially updated to v1.13! Since the test builds have been relatively stable, I've just finished updating the default builds to 1.13 on all sites. The "test" links are no longer necessary, and have been removed for now.
Head down and shoulder to the wheel again. More data parser code.
It's pretty mechanical work so far, but not mechanical enough to be automated. There are little exceptions to each data type, which require special handling. For example, the way headlines are defined in the data, they all share a common base item 7.0, and have their description and subgroup IDs updated based on the headlines.xml. And a similar thing is done for datafiles.
Most of the day was spent writing xml-parsing code for the mobile version. I added data types and parsers for items, hexes, factions, and treasures, and I'm getting started on creatures now. Just pure data parsing right now, so it rips all the values from the xml, converts to basic data types, and stores them in classes to match the data type. Nothing fancy, no logic, etc. Once all this is done, these data classes can be read by game objects to get the info they need to execute.
Hey Folks! Not too much to report today, as most of the day was spent researching shaders on OpenFL and HaxeFlixel.
First, why are shaders important? Basically, shaders are what allow games to do things like lighting, bump maps, and other interesting graphics tricks. Traditionally, they're used on 3D geometry like meshes and full-screen effects. However, they can also be applied to plain old bitmaps, which is what most 2D engines like HaxeFlixel use. Getting shader support in HaxeFlixel can provide the ability to make sprites look more interesting/attractive.
Hey Folks! Hope everyone had a good weekend. I tried not to stress out too much about the dev issues over the weekend, so as to come back refreshed. I couldn't help it though, and some dev thinking snuck in :)
The good news is that I was able to get some performance gains this morning. It turns out that the bottleneck wasn't the item state updates or line of sight checks. It was actually the sprite rendering.
I've got the prefab-based tilemap working again. Looks like my problems were due to some bad calculations in the trimming/padding functions. Things like sign and rounding errors causing null pointers in some cases. As of this morning, I was able to build ships from prefab items and then watch my crew walk around them. And lighting could be toggled on and off.
That's the good news.
The bad news is is that it has lots of problems. Namely, the lighting looks bad on diagonal walls, and performance is pretty poor.
I spent today doing a lot of clean-up on the old tilemap code. As mentioned yesterday, the old code made a lot of assumptions about the tilemap data. Most notably, it didn't care about synchronizing additional tile data arrays such as those used for lighting and sockets.
So, I replaced the old code that manipulated tilemap sizes to be more friendly to this meta data. This meant rewriting the tilemap trimming and padding functions.
Hey Folks! With the NEO Scavenger v1.13 test build live, I'm going to give it a couple days to see if it has any critical issues before promoting it to the default build. So with that, it's back to prototyping!
Today's work continued efforts to build the ship from arbitrary items (prefabs) instead of square tiles. These items still get placed on the tilemap grid, but the tilemap itself is invisible and only used for things like pathfinding, light/collision tests, and socket info for placing items.