Bitphoria's Release Date Announcement

 I have decided to make my 30th birthday the release date for Bitphoria, which happens to be August 30th 2016. There are several things I'd like to finish, among bug-fixes and networking improvements, before the first release and I thought I'd share that list here. Whatever state Bitphoria is in on that day it will be released.

It is obviously crunch time now (a great motivator for me) so the things on my list that I'd like to have done might be cut short, but I will continue working on it well into the future beyond the release. This will manifest itself in the form of new and updated releases. The initial release itself is meant to serve further development of Bitphoria by allowing other people to finally start messing around, playing games, scripting games, and providing me with bugs and feedback about everything.

I plan on releasing Bitphoria as a sort of public beta, for people to get to know it and see what I've dumped almost two years of my life into. Maybe down the road I will sell it for a few bucks on Steam/ Maybe I should crowdfund polishing it, because I clearly have something that's worth something to someone, somewhere, out there, and I think it has a chance at being a crowdfunding success (after all the hard work is done already).

Hardware contributions/donations are always welcome! ;) I'm currently developing Bitphoria on four different machines: two low-end laptops from a few years ago, a low-end pre-built HP desktop from the same time, and a custom-built desktop - all with integrated graphics. I did manage to borrow an nVidia GTX 680 in the custom-built desktop system that allowed me to record some footage of Bitphoria earlier on, but have since been without and could definitely use a decent GPU just for the sake of tuning Bitphoria's graphics to where high-end systems can be fully taken advantage of for hardcore PC gamers, as well as allowing me to record updated videos of what Bitphoria looks and behaves like. Recording video is actually my primary goal insofar as GPU acquisition is concerned, because without it I will have a harder time demonstrating the game. Worst-case scenario hopefully fans out there will take it upon themselves to youtube videos of Bitphoria. If nobody does that then I've failed at making something that sells itself, obviously, and that's the goal of any project of mine!

If the case is that nobody ever cares about Bitphoria, and it just gathers cobwebs and dust in a dark corner of the web (on this blog, and in a few reddit posts), never amounting to anything more than just a "portfolio piece" for me to acquire a dead-end soul-crushing software engineer job, then at that point I will just release the code in its entirety for everyone to tinker with and learn from. At any rate, the code will ultimately be released eventually. The 'when' of that is still up in the air, and probably will be for at least another year. But if I can earn a living for my family via my lifetime hobby then I'm certainly going to try before giving it all away. Over two decades of programming experience has gone into this project, and there are even things that I learned along the way while developing it that I'd like to invest into a new game engine project, but those are things that I'm just going to hang onto until I feel that this project is 'done', through-and-through, which includes promoting it to a respectable degree that hopefully provides it with enough exposure to ascertain as to whether or not it is something that there is interest in.

As far as my pre-release todo-list is concerned I believe that setting up a master server for people to find each-others' games is imperative, otherwise the whole project is pretty pointless if people can only start a game server, run around by themselves, and then quit out and never play it again. Scripting features and functionality seem less consequential and could be added in along the way at a later time after the initial release, but the existing setup is rather competent. Finishing the scripting documentation also remains a top-priority issue due to the fact that I wish for people to be able to start playing around with the engine itself to see what they can come up with within the creative sandbox that it represents. It has its quirks and nuanced requirements insofar as game performance are concerned (graphically, physics-wise, and networking) which is the case with any game engine out there. However, I would like to point out that it takes no game-development know-how or modding experience to make something out of, or with Bitphoria. Anybody should be able to simply open up the script files that comprise the default games included with Bitphoria and start surfing the documentation to figure out how it all comes together.

Here's my list of things left to do for Bitphoria before releasing it that I'm currently focusing on for the next few weeks:

Master Server: Write and launch a master server to run here from my home to allow players to be able to start and find/join eachothers' games. Along with this I'd prefer to invest in a domain name that points to the master server (my house IP) for the in-game server browser to download the server list from. This would actually kill two birds with one stone. Firstly, it would eliminate the learning curve of PHP and MySQL that I'd need to traverse if I were to create an HTTP master server. I *do* have enough experience with both to make it happen but I'm not competent or well-rehearsed enough to simply knock it out within a day or two - and it would require that I implement HTTP request functionality into Bitphoria, be it by hand or integrating CURL/libCURL. Secondly, running a custom-coded master server from home would allow me to easily implement a NAT-punchthrough handshake protocol to allow anybody to start a game without being required to deal with their router/firewall and port-forward. Conversely, anyone else would also be able to join any game regardless of whether or not they themselves are also behind a router/firewall. This functionality requires that the master server notify game servers when someone is trying to join them, and from what IP/port, allowing the game server to go ahead and send a 'trailblazing' packet to the client player for the sake of tunneling through the NAT and have it route packets from that client player's address to the game server. To have a console application running in the background on my desktop, written in C, using winsock or SDL_net, that would be easy to manage would be much simpler and cheaper than any remote/online option I've come across so far. If at some point there's too much traffic for my home connection I'd then move the master server program to a dedicated virtual host and simply point the domain name at that, and everything will just continue working for everyone without any changes for end-users.

Network Buffering: Implement a network buffering system to, for one, allow for the simulation of latency and its fluctuation for testing/tuning purposes. So far I've only been able to generate repulsive/gross/erratic network behavior when my daughter watches Youtube/Netflix on her machine while I have two machines sharing a Bitphoria game over our wireless LAN. Also, in spite of my efforts to fight network update jitter using extrapolation when an update packet arrives later than intended, it would seem that Gaffer's strategy ( of simply buffering network updates long enough to encompass most network jitter and then subsequently emitting them to the engine internals at the interval they were intended to arrive at would be vastly more effective in its precision and lack of interpolated correction. Buffering network packets as such would also allow me to simulate internet conditions locally without having to track down willing testers (I'm not really a 'people-person', and I have no more computer friends left) and fine-tune everything for what I like to think of as the 'fringe-market' - people who don't have high-end gaming systems (a netbook) or fiber-optic connections. I'm of the mind to release a game that looks prettier the better the setup, but also is completely performant on less ideal setups. Why focus on one area of the market if you can focus on the entire market?

Scripting System Documentation: Finish the scripting system documentation, which would include indications as to where inside of the the sample/default games that are packaged with the initial release that users can find examples of each script command, along with tips/tricks. Also, early on I made it a point to document everything that I script for Bitphoria because I know that people out there should be encouraged to tinker around and pull everything apart.

Artificial Intelligence: Add in simple AI functionality that allows an entity to seek out other entities and designate them as its target, which it can then follow or aim at. This would make it possible for simple zombie-type enemies that just follow players and harass them while they try to carry out other things. I'd like to include some kind of simple navmesh generation that is derived from the distance field of the world but I am thinking I am just going to literally index the distance field and use that for obstacle avoidance while entities try to pursue other ones. If a target is unreachable then it could back out following the distance field outward until the target is visible again, or a new target is found.

World Generation Modes: Add options for the style of the world generation itself. Right now it's a fixed algorithm and starting a game server entails selecting a random seed and then a vertical-scale which is forwarded to clients so they can then generate the same world themselves and play. The world is generated as a 128^3 volume and there's a lot more that could be done with it than just leaving one algorithm in there for people to experience.

Physics Attachment: Entity attachment which allows for an entity to literally attach itself to another entity and inherit its position/motion, with or without an offset that is oriented with the entity being attached to. This could be used for CTF games or power-up modes that want to display some kind of visible effect.

These are more-or-less listed in order of priority. What actually happens by the release date is still completely variable, these are just my intentions and goals, and it's hard to say what exactly will occur as I pursue each bullet point.


Bitphoria Screenshots

 I just felt compelled to post some new screenshots. Not much has changed as I've been working on underlying stuffs and writing the scripting manual, but it sure looks purdy.

Check back soon for more updates. I'm in the midst of designing the master server situation so players can start and find one-anothers' games easily without any port-forwarding nonsense. I'm also hammering out the Bitphoria Scripting Manual as a guide and reference for people who want to make their own games out of Bitphoria and share them with the world via the ingame server-browser. Players do not have to download anything externally to play custom Bitphoria games. It's a thing of beauty.


2D Rectangle Overlap Algorithms

 While working (not so) diligently on the re-write of Holocraft I encountered a situation where the need for an age-old algorithm arose. The algorithm itself, and/or its implementation, has had many minds over the course of time to boil it down to a few bare-necessity lines of code.

Example of the problem and some possible conditions.

 Determining whether or not two rectangles overlap or intersect has been one of those problems that has found application in many a project. It's rather simple to implement, and most novice programmers take pride in discovering a solution to the problem, even including the case where the algorithm is extended into the 3rd dimension in the form of 'axis-aligned bounding-boxes', or 'AABBs'.

3D axis-aligned bounding boxes intersecting.

 There have been many games which utilize either a 2D or 3D variant of this algorithm to determine if two objects in a game world are colliding with one-another. The original Quake game is an example of a game where entities had their collision volume defined by way of an axis-aligned bounding box. This caused players to axially slide off other objects as if they were a flat cubical shape. Personally, I prefer using a cylindrical or capsule collision volume for players and NPCs, because this gives a smoother collision resolution where the player just sort of slips and slides around other players and objects. Most modern games utilize this sort of collision volume for players nowadays for low-fidelity intersection tests, and sometimes as a pre-test to avoid the cost of doing more intricate intersection tests in the case of hitscan weapons and the like.

 At any rate, during my outset to re-write Holocraft it became clear that it was imperative that there be a way to detect where groove optics are overlapping, or otherwise intersecting one-another due to the fact that many of my trial-holograms thus far have been muddied in areas where the density of intersecting groove optics is too many. Too many intersections and too much overlap of grooves can completely annihilate the clarity of their reflectivity. The solution is to prevent the machining process from scribing over the same areas, allowing the fore-front optics of the hologram to take precedence over the background optics, optimizing the overall clarity of the hologram as a whole.

A screenshot of the new Holocraft showing the geometry and optics of a moderately detailed specular hologram. As you can see it is very easy to create many overlapping and intersecting optics (the curved colored lines) which will reflect light to depict the white dots along the edges of the model's geometry. Blue optics will appear nearest, red the furthest, and green will appear with mid-range depth.

 Now, per Matt Brand's whitepaper on Specular Holography, groove optics are hyperbolas that are calculated from the assumed incident light ray altitude angle that will be illuminating the hologram. I have chosen to calculate from the the hyperbola a cubic Bezier curve, which is defined by a starting and ending point, and two control points which dictate the curvature of the line that traverses the space between the endpoints. This curve then serves as the internal representation of the base shape from which all optics for the hologram are then derived, based on the 3D position of the point that is chosen from the source hologram geometry's vertices, edges, or surfaces that will be depicted by this reflective optic.

 These optic curves are segmentized by an occlusion-culling pass, which designates which spans of the curve should reflect light based on whether or not the hologram geometry should be 'blocking' their visibility, on a per-degree of viewing angle (or 'azimuth') basis.

 Once these segments of visibility are determined I then need to determine which ones are intersecting or otherwise overlapping one-another too closely to cause degradation in the final hologram. One way is to brute force compare the distance of every single point of each optic segment against every single point of every other optic segment to determine if the segment needs to be clipped or split/culled, etc..

 To speed this process up I have resorted to the use of a simple bounding rectangle overlap comparison. Effectively, this is a 2D axis-aligned bounding box intersection/overlap test. This is what I call an 'early out', where the core loop that is performing these comparisons and tests can quickly and cheaply pre-determine that there is no possible way for two given optic segments to be intersecting (because they are, for example, on opposite sides of the specular hologram).

 If there *is* an overlap detected between the two rectangles bounding two optic segments, then Holocraft proceeds with a more detailed comparison of the two segments, effectively comparing each point on each segment with each point on the segment in question. This is a simplified explanation of the actual process which determines overlap/intersection, as the actual algorithm uses a heuristic method to dynamically adjust the increment at which it 'steps' along each segment to the next point to compare with all the points of another segment to perform a distance check. This helps to accelerate the process, which is albeit fast enough without the heuristic method being as Holocraft only performs intersection detection when the user is saving the holographic output, currently as either an SVG vector image file or directly to CNC g-code.

 Now, the whole point of this blog post is to share the method by which I devised a rectangle intersection test that serves more utility for Holocraft's purposes. It would seem that with my growing years as a programmer I have been growing a rabid aversion to doing things the tried-and-true way, with a sort of desperation to find a novel way to go about doing things that people have already been doing another way for decades.

 A part of the heuristic method by which Holocraft accelerates optic intersection/overlap detection relies on knowing the rectangle of overlap itself in which two given segments are possibly intersecting. Knowing that their bounding rectangles is overlapping as a mere boolean piece of information is not sufficient for it would require that *every* point on each segment is compared against *every* other point on the opposing segment. To minimize this only the points on each segment that are within the overlapping area of the rectangles is considered.

Here's a copy-pasta of what Holocraft does:

typedef struct
 float x, y;
} vec2;

// 2d rectangle
typedef struct
 vec2 min, max;
} rect2d;

#define MAX(a, b)  ((a) > (b) ? (a) : (b))
#define MIN(a, b)  ((a) < (b) ? (a) : (b))

// returns zero if no overlap, otherwise returns
// area of overlap and optionally the rectangle of overlap via '*o'
float intersect_rects(rect2d a, rect2d b, rect2d *o)
 rect2d c;
 float dx, dy;

 // find horizontal overlap
 c.min.x = MAX(a.min.x, b.min.x);
 c.max.x = MIN(a.max.x, b.max.x);

 // not overlapping horizontally...
 if((dx = c.max.x - c.min.x) < 0)
  return 0;

 // find vertical overlap
 c.min.y = MAX(a.min.y, b.min.y);
 c.max.y = MIN(a.max.y, b.max.y);

 // not overlapping vertically...
 if((dy = c.max.y - c.min.y) < 0)
  return 0;

 // caller requires rectangle of overlap ?
  *o = c;

 // return area..
 return dx * dy;

 This is with the goal of quickly calculating the rectangle of overlap itself, while putting priority over the horizontal check over the vertical check (perhaps in Holocraft's case this should be reversed?) and will bail out if the horizontal overlap fails before bothering with the vertical overlap check.

 This is in contrast to most of the functions you will find on the internet, which perform a few simple greater-than/less-than checks against the min/max of the bounding rectangles/volumes and provide no other useful information.

 In the past, for game physics, I would just make everything a sphere and perform a simple pythagorean distance check against the combined radii of the two entities in question. I almost opted to use circles as early-out bounding volumes for optical segments until I actually sketched on paper how much extra space a circle would typically have over a simple bounding rectangle.

 Incidentally, the rectangle boundary calculated for each segment is derived from the convex hull of each curve, which is defined by both the endpoints of the curve and the control points that define the shape of the curve itself. It is said that the entirety of a cubic Bezier curve is contained within this area, and if there was a fast way to perform intersections against these convex hulls then that is what I would do, but there really isn't. This would require a series of line intersection tests and be quite a bit more complicated than it is worth.

Demonstrating the confinement of a cubic Bezier curve to its convex-hull, as defined by its endpoints and control points.

 One of the advantages of using cubic Bezier curves as an intermediate representation is that outputting a vector image via the SVG file format allows for cubic Bezier curves to be defined as-is, without converting or transforming to any other form.

 This is in contrast with outputting CNC g-code, in which machine toolpaths can only be defined as either linear or circular motions, requiring an intermediate step in Holocraft which deduces a series of circular arcs chained together to form an optic curve. This is done within a user-supplied tolerance value, to give some degree of control over how large/complex the final CNC g-code output is, and the degree to which the machined grooves are faithful to the calculated optic hyperbola.


NewbieTime is Live

 I made a game for my children called NewbieTime. It's an idea I had a few years back but didn't get around to working on until last summer in the middle of Bitphoria development. I had everything pretty much finished and polished and ready to release and somehow decided to move on to other things instead. Well, I stumbled across it and decided it was time that it saw the light of day and now it's live for download/sale at

 Check it out and let me know what you think!

 Working on a re-write of Holocraft that is much cleaner. After much aluminum scoring and grooving I had come to the realization that I needed to mitigate the fact that groove optics were allowed to intersect with abandon. This allowed for spots on holograms that are densely populated with optics to appear 'dirty' and effectively ruin the holographic effect. In order to properly deal with this within the way that Holocraft was slapped together would be just more sloppy work, so I opted to re-write to allow for much better.... well... everything.

 Occlusion culling will be on-point, and the program itself will run much faster, and deal with larger and more complex geometry much better. More on this once it's finished.

 Also on the todo list is documenting Bitphoria's scripting system, which is the final step before an initial public release. I want people to be able to begin playing with the scripting system and see what they come up with. Multiplayer functionality is all there, and entire games can be made out of Bitphoria but I have not been so inclined to actually make a game as of the past year.

 I still need to figure a master-server setup that will allow players to easily start and join one-another's games. This will be included in a later release.