• Visit: New Solo Project

• Visit: Push Changes To GitHub

First off, be sure to save any work you’ve done in whichever application you’re working from!

⚠ NOTE: If you have your work saved to a location outside of your local git repo you will need to copy or move the saved file(s) into your local repo!

It’s always helpful to perform a cursory git status and/or git log to remind yourself of the current state of your working tree. If you don’t see your changes under “modified files” (if you’ve edited an existing file) or “untracked files” (if you’ve created a new file since your last commit) or you are not checked out to the branch you intended then this is your opportunity to investigate why the contents of your repo are not as you expect. If everything checks out (no pun intended) then proceed with confidence!

⚠ NOTE: You can get a detailed printout of your working tree's commit history including commit messages and branches using `git log`. 
To get a more concise, formatted, visual representation of your commit history you can use an alias such as `git lol` to output the log in a specific, desired format: 
```
# Assign a concise, pretty-formatted commit log command to a short, convenient alias ("git lol"). This only needs to be run once to be able to use "git lol" whenever and wherever.
git config --global alias.lol "log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"
```

After you’ve staged all the files you’d like to include in your commit, you may save their current state to the tip of your current local branch while providing a helpful message to describe the changes by using: git commit -m "Your message here.".

⚠ NOTE: Make sure that you are checked out to the very tip (latest commit) of your current branch! 
You can verify this by using `git lol` (see note at step 3 for instructions on how to set up `git lol`) to check for `(HEAD -> your-branch-name)` where `your-branch-name` refers to the branch you want to make changes to. 
After committing your changes another `git lol` should show 1 new line above the previous latest commit (e.g: the current state of your remote repo at `origin/main` and `origin/HEAD`) containing your new commit alongside your message at the tip of your branch. 
```
# Print out a concise, pretty-formatted commit log so that you can visually verify the state of your working tree.
git lol
```

If everything looks good locally you are free to git push your latest changes to GitHub!

⚠ NOTE: Make sure that your remote branch is now synced to your local branch! 
You can verify this by using `git lol` (see note at step 3 for instructions on how to set up `git lol`) to check for `(HEAD -> your-branch-name)` where `your-branch-name` refers to the branch whose latest changes you just pushed. 
After pushing your changes another `git lol` should show that the current state of your remote repo (e.g.: at `origin/main` and `origin/HEAD`) now corresponds to the latest commit you just created at the tip of your local branch. 
```
# Print out a concise, pretty-formatted commit log so that you can visually verify the state of your working tree.
git lol
```

• Visit: NewForce SOP Index

• Visit: NewForce SOP Index

Well it finally happened! After years of telling myself that I’d learn to use a modern, commercial game engine “eventually” I finally buckled down, found a great Unity beginner’s tutorial which inspired me to keep going after completion!

Anywho, without further ado, I’ll leave you to give the game a spin and perhaps even get enough entertainment out of it to beat my high score (55 as of writing)!

Objective

Fly between as many pairs of pipes as you can without hitting any!

Controls

• Click the left mouse button or press the spacebar (desktop) or tap the screen (mobile) to flap your wings and briefly ascend!
• Click anywhere outside the game widget to pause the game and then click anywhere back on the widget to resume (just beware that the resume click will still register as a “flap” so be careful!).

This was a huge step for me because in the past I’d always inevitably abandon such endeavors before almost immediately going right back to writing everything from scratch (an admittedly laborious, yet comfortably familiar feat). I naturally find the frustration that comes with navigating a complicated UI to be particularly exhausting (which was undoubtedly a contributing factor to the reality that it took me 7 years, as well as an actual job in software development, to finally make the switch from BlueJ to IntelliJ as my daily driver Java IDE). In addition to the brilliant tutorial from GMTK I also found that the process of familiarizing myself with the Unity editor’s UI was exponentially more intuitive this time around given my recent attempt at implementing a Unity-like, composition-based Entity-component system in one of my homebrew game engine projects! Suddenly, it made sense to me just “why” we were “wiring” things up the way we were in the editor and before too long I was able to intuit just “what” to plug in “where” as well as which objects need to communicate with one another in general. Maybe I’ll end up writing a blog post about my entity-component system and composition pattern insights!

I plan to keep developing simple clones and custom copy-cats of popular, minimalist games until I get comfortable enough with Unity to start working on my own original ideas! So, feel free to give me a follow on itch.io!

Thanks for stopping by!

Hi, folks!

Lately I’ve been contending with a bout of emotional strife. My struggle with general anxiety in particular has been exacerbated by the guilt I feel from subjecting the people in my life to the worst of my avoidant tendencies. What’s more is that phases of intermittent apathy amidst a seemingly ever-increasing backlog of obligations have left me yearning for a respite. This has prompted me, for better or worse, to seek refuge in the sanctuary of escapism.

So, without further ado please join me in this babbling stream of consciousness fueled by the onset of hyperfixation! Allow yourself to become entranced by a flame of nostalgia ignited by the spark of an old obsession of mine: raycasting!

What Is Raycasting?

I’m not certain, but over the years I’ve got the impression that there exists some contention or, at the very least, some “fuzziness” as to the exact boundaries of what may formally be considered a raycaster. As a result, I set out to identify some qualities which precisely distinguish raycasting from its derivatives (e.g.: ray marching, ray tracing, etc.) and unambiguously define the relationship between them.

For the purposes of this series I'll clarify some of the relevant terms using a framework that makes sense to me. Thus, we'll proceed with the caveat that this framework is based on my own mental model which may not be consistent with other sources or the broader consensus among industry folks and/or other hobbyists. I invite any feedback to help improve my understanding and, ultimately, this series for the benefit of anyone following along!

My Interpretation

In general, I consider raycasting to be a broad class of computer graphics rendering techniques all characterized by their ability to visualize geometric entities in a scene based on those entities’ interactions with “view rays”. From this perspective, anything which tests objects for intersection with view rays and then renders some representation of those intersections is a raycaster.

What distinguishes various raycasting derivatives from one another, in my estimation, lies within the finer details: how do we arrive at an intersection in the first place and how do we represent the resulting interaction and any subsequent interactions?

My First Raycaster

I have written a raycaster in the past. Granted, it was a certifiable mess, but it served its purpose as a worthwhile learning experience. It featured texture-mapped walls, vertical camera panning via Y-shearing in addition to neat post-processing effects like a reflective “water” floor effect as well as a frame-blending-style motion blur effect.

public class Edges {
    // ...

    public static float[] intersection(
        float xa1, float ya1,
        float xb1, float yb1,
        float xa2, float ya2,
        float xb2, float yb2
    ) {
        float r1=(xb1-xa1);
        float r2=(xb2-xa2);
        float m1=(yb1-ya1)/r1;
        float m2=(yb2-ya2)/r2;
        float y1Int=ya1-xa1*m1;
        float y2Int=ya2-xa2*m2;
        // NOTE: replace "==" & "!=" with threshold
        if(m1!=m2)//slopes are not equal; not parallel
        {
            float x;
            float y;
            if(r1==0)//vertical line 1
            {
                x=xa1;
                y=m2*x+y2Int;
            }
            else if(r2==0)//vertical line 2
            {
                x=xa2;
                y=m1*x+y1Int;
            }
            else
            {
                x=(y2Int-y1Int)/(m1-m2);
                y = m1*x+y1Int;
            }
            //if(Math.signum(x-xa1)==Math.signum(ra) && Math.signum(y-ya1)==Math.signum(yb1-ya1))
            float[] hit={x,y,(xa2-x)*(xa2-x)+(ya2-y)*(ya2-y)};
            if(isInView(hit) && isOnEdge(hit,xa2,ya2,xb2,yb2)) {
                return hit;
            }
        }
        return null;
    }

    private static boolean isOnEdge(float[] hit, float xa, float ya, float xb, float yb)
    {
        //*
        float dotProduct = (hit[0] - xa) * (xb - xa) + (hit[1] - ya)*(yb - ya);
        if (dotProduct < 0) return false;
        float lengthSqrdba = (xb - xa)*(xb - xa) + (yb - ya)*(yb - ya);
        if (dotProduct > lengthSqrdba) return false;
        return true;
    }

    private static boolean isInView(float[] hit)
    {
        return hit[1] > 0;
    }

    // ...
}

By testing the equations of each ray with that of each element of the unorganized list of line segments and then either sorting (painter’s algorithm) or filtering (Z-buffering) the resulting set of intersection points by distance to the camera we are able to solve the visibility problem by brute force ultimately enabling us to render the nearest edge in view if one exists. Because we are essentially solving for the intersection point of a pair of arbitrary, infinite lines, it means that we impose no restrictions on the orientation (position, angle, length or otherwise) of scene elements (“edges” or “walls” if you prefer) relative to one another. This is in contrast to what most of us may be accustomed to observing among titles from the primordial era of 3D games which utilized raycasting. Specifically, consider the likes of Hovertank 3D, Catacomb 3D, Wolfenstein 3D and its derivatives, etc.

⚠ NOTE: if you stopped by to check out this preview I appreciate it!
Soon I'll add the full digest post serving as the overview of a series of posts I intend to create which will include additional narrative entries with code snippets to follow along with in your local project!