Day 69: Shoot To Rotate and Scroll

Today was a pretty spooky day today. Not because it's Halloween, but because the work space was a Scooby Doo ghost town. That aside, I fixed up the prototype of the accelerometer shooter to have Metal Gear shoot towards the far plane when rotating towards a point. To further explain, when the player holds down a finger, it shoots not only in the forward vector of Metal Gear, but rotates Metal Gear towards that point, using a far plane from the camera as a reference. This ensures a more reliable control for shooting static bullets:

For something particularly unrelated to the prototype, I also stuck in the ability to pinch and zoom, which changes the field of view based on the difference between the previous positions and current positions of two exact fingers being held down on the screen. This can also be applied to an orthographic camera by way of changing orthographic size:

(not shown: fingers pinching to zoom inwards)

And as for the next prototype, I'll be looking into a simple infinite runner that incorporates swipes somehow:

Isn't there so much more atmosphere with a background? I'll have something running on it soon.

Day 68: Metal Gear Launches Static

Today was where the challenge started in mobile device input. The way that the accelerometer reads input in Unity is similar to that of a gyroscope, except with magnitude. Since I needed to work with a variable speed, I figured I'd normalize the values and work with that as a rate to apply acceleration to the model in question I'm working on (a shameless copy of Metal Gear Rex).

The idea is to take a scrolling shooter and vary its controls by way of the accelerometer, rather than by specific touch controlled input. This is a bit of a step back from the precise control people are looking for, but may provide a unique experience. The model is viewed from a tipped angle, and accelerates up, down, left, and right.

There was a bit of an issue, however; the way that this acceleration input works, the values were only zero at a completely flat-laying phone; this required a relative initial offset, which also had to be normalized and applied against the current acceleration. That way, an initial position could be wherever the phone is when the application begins.

Afterwards, I applied the static sprite as a billboard for firing bullets. The problem? Oddly enough, Transform.LookAt applied to these sprites cause them to look backwards. I found no other solution than had them look the other way via the transform.position - Camera.main.transform.position switcheroo for a target. And behold! An accelerometer controlled Metal Gear that launches balls of static!

Hopefully I won't run out of prototyping ideas until the big day on Tuesday.

Day 67: Keep Your Eye (And Fingernail) On the Ball

Today was a day to dip into using the accelerometer. The way that Unity handles accelerometer input is accessing its acceleration (positive x is right, positive y is up, etc), so one can apply this to an object in the scene, say a ball bouncing around.

The small issue with this is keeping the ball relative; if the ball accelerates purely based off of a initial position where the device is laid flat on a surface, it would severely limit its use. Solution? Relative acceleration. Save the starting accleration and use it as an offset.

I was also worried during remote debugging on my iPhone device; when setting the screen orientation, the screen would rotate no matter what. Thankfully, after testing an Android build, no problems occurred.

What next? Try something like attaching a shmup player with accelerometer input. I like the idea.

Day 66: A Healing Touch

Today was another day of nothing-to-do, so I got back into prototyping touch control work in Unity.

When doing the tracing experiment yesterday, the line renderers were surprisingly stiff and limited, especially in the case of multiple line segments. I looked into spawning a circular sprite whenever the targeted touch moved, which worked for slow movements. However, when the finger zipped fast enough, there was a noticeable space between the previous and current touch points. This would not do for a free form line.

What to do? By taking the distance between the touches and a direction, I could fill it in with a series of dots per frame. Suddenly a grouping of dots becomes a free flowing line.

Afterwards, I looked into a tracing guide for certain shapes, and put in a placeholder tracker that would turn red upon tracing. Thus, something like the Healing Touch from Trauma Center is now an iPhone reality:

What next? Well, in order to make interesting and more exact shapes, one could use a tool to actively make these shapes for tracing. I'll be working on an application that can take in clicks as an input and write them to a file for use in the program.

Day 65: Connect The Dots

Good news! Our presentation for our project went over very well, without a complaint in sight.

Bad news: Due to a miscommunication regarding the programming project, I had to redo a small bit of the project. Thankfully it was only a small bit; the average calculation ran untouched. The main change was how the data was stored; the actual binary data had to be stored in one single file, reading guide included. By using the numbers of values as a header for each section, I managed to read those values first, then skip and check averages. So far, I'm all prepared once more.

What to do next? I'm still experimenting with various prototypes involving touch controls in Unity - so far, I relearned the particularly tricky parts of how touch structures are stored.

Touches in Unity are stored as structs; not only that, but the actual touches are retaken every frame. This means that Touch.GetIndex(0) will not always yield the same touch each frame. Luckily, there's a fingerID, which means that by iterating through the various touches and checking for that, one can spot the same touch between frames. Combine that with the previous touch collision I implemented yesterday and line tracing, I can connect the dots below:

What next? When tracing something in a game, one can use these "Trace Points" as a means of recognizing a shape. However, I'll have to come up with something a bit more free form than line renderers. That, and line renderers fail to produce the same width for multi-line segments, so I had to attach a line renderer for each trace point. I'll definitely get to work on the free-form drawing from the success of this one.

Day 64: Good Touch, Noisy Touch

Today was another day of a whole bunch of nothing (excepting a restart button as per request of reeeaaallly late playtesting) so I dipped my fingers yet again into Unity mobile development.

Thankfully, Unity is good with mobile debugging. So good, that one can hook up a device like an iPhone or Android and actively use it for touch control debugging.

What to do for a demo? For what I had time for, I experimented with how Cg represents noise in shaders. Unfortunately, Cg kinda lacks a good random function, so I used a rough approximation and used the location of a fragment to produce the result. Afterwards, I just set a tiny minigame where one has to touch to take out continuously growing TV static squares:

What next? Since I'm experimenting for now, I might as well go for something a little more interesting and see if I can trace objects together by way of a set of circle targets and the touch screen.

Day 62-63: A Blur of Zeal Then..Nothing?

Phew! Apologies on the missed post; I was intently busy once more on fixing up that data reading/writing assignment.

Turns out the problem lay on two fronts:

The first front was an easy mistake - turns out I specified "w" instead of "wb" on the write mode of my binary files. The frustrating part is, it works most of the time, but on some sections writes an extra byte where it shouldn't. The madness!

The second front dealt with a much larger problem - the numbers got too high when I used a fixed point conversion by way of multiplying by 100 then dividing. In the case that the number (30 bytes, shorts, etc for example) was too small, the division wouldn't work due to the quotient being larger than a word. The solution? Divide by the value number AND the fixed point number multiplied together, then convert the remainder to the hundreths place and redivide to get a rounding value.

What next? After doing some work with the UI and finding out more emergent solutions, our project is more than ready to go:

Heck, even our heavy pumpkins can be stacked like platforms when they're small enough and in the exact same horizontal spawn spot.

What next? Not much, really. I figured it'd be time to tackle mobile development, and I know for a fact most of FIEA deals in Android devices, so I'm setting up SDK use for Android devices. So far Android Works with Unreal has thrown me some issues involving user permissions for installations, but I'm currently downloading the SDK for Unity and have fingers crossed for the best!

Day 61: Do it Again, But With More Pain

Phew! Today was one rough day for homework. 8 hours of it, to be exact. That assignment involving writing binary data was managed pretty well in C, along with swapping the words and longs in little endian form beforehand to give the assembly code a fighting chance, but it did not prepare me for the tough nature of the assembly assignment.

Luckily enough, I had also prepared a set of data that contained the size of bytes, shorts, and longs in each section, so I could use that as reference to skip forward to a certain section and read it. However! I had to keep other things in account, such as odd numbers of bytes that demanded data padding when writing to the binary data, and knowing to skip that padding as necessary.

Once I got that rolling, the computing averages to two decimal points was ferocious. This time I needed exactly 100 as a fixed point denominator value, along with proper rounding; however, when summing and averaging a group of shorts and longs multiplied by 100 for that fixed point value, the division instruction kept overflowing. I had to divide it by 100 * the number of values, then use that remainder and calculate a rounding value from it. It was certainly tough work.

What next? The night is young; I still need to print an extra zero if the fixed point values in question are below 10.

Day 60: Short n' Sweet

To have time to enjoy my evening, I'll keep the blog post short for now.

Managed the reswapping of meshes and textures so we finally got that visual bouncy/ghostly appeal:

And, after discovery and request, I also increased the mass on the heavy versions of objects to create an emergent ball pit:

What next? The actual struggles today are in programming yet to come. I must write random bytes, shorts, and longs to a binary file using C and then access and calculate averages in 68K once more. Is it overkill? You betcha. How will I know what to access if the values are random? Reading guide binary file; thankfully, the file shouldn't be longer than 301 bytes.

Day 59: More Emergence, Spider-Style

Today was a nice polishing day, so we went to work in discovering more emergent aspects and improving what was already there.

We managed to use the UI Event Systems to change properties by selecting buttons (the more intuitive route) but it was a bit tricky dealing with the ScreenFade. The OnMouse events unfortunately don't work if there's an object in front of it (namely, the ScreenFade object), but deactivating the object allowed this to work just fine.

The spider also carried a bit of a surprise of its own; after attaching a line renderer as a web to the spider to make it blend in with a new web mesh, I found out the spider could effectively be weighed down by objects and cleaned up some of its programming to reflect that property:

What next? The spring meshes and ghost textures just came in! Time for a visual overhaul...

Day 58: Cast-Iron Candy

Woot! Today was a successful interim; the forces from above have decreed that our game definitely fits the requirement for emergent gameplay. That said, we still need to follow up with polish to make the game complete.

First off? The kid; he needs to be a little bigger and animated. This, unfortunately, is one of my weaknesses with Unity; I have no idea how animations work. I'm not sure, but think animation files actually go separately from the actual model I've been using. I'll have to contact the artists for details:

I also had to cut some code thin; it seems that a complex function that restrained the kid to the Z axis actually stopped the kid from moving in the x direction when colliding with bouncy bars. By switching it to a constant update of the position to be 0, I thankfully held the kid in place.

What next? The main suggestion for our work was to properly represent the visuals of the objects. Colors are not enough! Seems like we must add various visuals to represent the bouncy, floaty, and heavy aspects. I got to a start by employing the bump mapping technique with a cast-iron cauldron texture and the original object as a normal map. Solution? Indeed, the cast iron objects are now set. We're also planning to put in a *thunk* sound for heavy collisions so it properly communicates the idea:

Day 57: Emergently Discovering Emergent Elements

Today was a successful day in terms of emergent programming! Previously the team was worried about the lack of use of the bouncy effect of the pumpkins and candy bars, so I whipped up a risky but successful solution; apply a fake impact kickback to the player from bouncy objects. This is to be added along with the movement controls and dampened over time.

I also implemented a more obvious extension of the steam vents - covering them up with pumpkins. This required another raycast, similarly to the spider's tracking, but works fairly well as a workaround for people who are vertically challenged with pumpkins:

We're well on our way to a mildly successful prototype; playtesting reveals emergent elements and new ways to overcome these problems. Hopefully Week 2 brings more from a mix of these properties.

Day 56: Making Emergent Elements Work Together

Today is finally a day where things are looking as if they are coming together. So far we've got the latest implementation of the level and things like spiders and ghost radii in the mix; this ensures that the ghosts only start stalking when the player is near.

I'm also finding that the elements are starting to work together nicely. I had to change the player a bit so that the character wouldn't go up steep slopes and slide down slopes based on the normal of the ground. Thankfully the character controller provides a hit function that gives me the normal of the plane, so I can take the cosine of a specified steepness value and test that with the ground. 

What next? Tweaking; we've put things together, but it'll be up to the play testers whether they'll find these things or find them enjoyable. I can hope that people will experiment and not assume that the ridiculous strategy like this below is not valid:

Day 55: Oh Hey, a Level

Today was quite the busy day. In creating environmental aspects to interact with the player and the drawable objects, we managed to create spikes which objects would stick in and ghosts that would move and rotate toward the player.

However, there was a bit of an issue with the rotation. With rotation, I figured using spherical interpolation of the current forward vector and a look rotation would be the answer, but there was this unexplained jerky movement, as if it was clashing with something else. Lo and behold, the Rigidbody of the character and the character controller were clashing, and the Rigidbody was unnecessary and had to be removed.

We also ran into some hefty issues involving Perforce; looks like we have to have the exact same version control settings or serializing assets won't work across our builds.

Other than that, the level looks beautiful and spooky. Next up is making an exit window and further populating the level for something more complete-looking.

Day 54: Floating Hijinks and Spiders

Today was a pretty long day, but due to some C program homework, my brain's slightly fried for today, so I'll be short.

Floating objects were managed today by way of applying a constant upward force and disabling gravity for a rigidbody. This results in some very interesting emergent effects involving vertical scaling via floating pumpkins and candy bars:

I also managed some effects to interfere with the drawn objects, including spiders and heated vents that eat and melt candy bars. Note: the spider is indeed, that horrendous cylinder. Luckily enough, the player can sacrifice themselves to protect the candy bar:

What next? Sleep. That, and spikes to stop pumpkins in their tracks.

Day 53: Now With More Robust

Phew! The tools are finally starting to show themselves in the game. The pumpkins now have a full look, and definitely fit the feel of what we're looking to show. I did have to fnangle the radius a bit, as the original pumpkin radius is rather small:

As for the candy bars, managing their creation was a bit tricky; I used the line renderer and got the normalized vector difference between the two positions. Afterwards, I calculated the angle with the horizontal, keeping mind to reverse the angle for things above 180 degrees. Afterwards it was connecting the bars based on their width and the scale of the plank (which scales all bars at once) and rotating and moving them based on that normalized vector. And thus...

Candy bars! We're also working on physic materials to add to them; the bouncy material is currently being displayed above.

What next? Differing between materials and managing their properties and colorization based on tweaking the current standard shader.

Day 52: Robust Pumpkin and Candy Bar Maker

This recent prototype involves creating pumpkins and candy bars on the fly. When drawing a line renderer on the scene, the line can be a radius or also specify a length in which to spawn objects. The result? Pumpkins are currently spheres for now, but have the possibility of carrying various properties like bounciness, drag, and floatiness (through physics materials).

Candy bars? Candy bars are a bit different, resulting in specific width boxes connected in a single rigidbody. This gets a bit tricky when destroying a link in that chain, forcing two separate entities to hold the rest:

Next up? Actually drawing the candy bars.

Day 51: Interim to New Prototype and Midterm Craze

Phew! Today had a particularly tough midterm. I won't go into the details due to its test-like nature, but I will say it involves finding elements of thousands of bytes of data (mean, mode) that require a lot more than a single loop to manage.

As for today, I also went through the latter parts of the the Unity shading tutorials, managing plane shadows and nonlinear deformations. The specifics of nonlinear deformations weighted the average between the two vertices to bend objects toward the vertices of another object. This can be applied to, say, a corset on a character figure, or a cube jankily trying to bend toward a sphere. Both examples of the nonlinear deformation and plane shadows are shown below:

What next? Plenty. The next prototype is upon us and I have plenty to learn from mouse controls.

Day 50: Emergency Implementation Switch

My goodness, today was stressful. Due to a misunderstanding about the nature of displaying score in our assembly project, I was forced to ditch the hardware window and quickly come up with a way to actually draw score to the screen.

Solution? It may cover a bit of the screen, but I managed to draw a score rectangle (that would continuously re-draw itself) along with drawing lines for each of the bits present in the 7 segment display.

Downside? You bet. Table-accessing values really sped up my implementation in score display, but now the implementation has to take that number and test it 7 times with seven bits, due to the multiple of lines with separate x1, y1, x2, y2 coordinates involved. It's become a bit wayward, but with prototypes shuffling over the horizon I'll stick with the mess.

And now...a completed game!

I also added a quick "quit" key that halts the simulator and stops sounds, so it vaguely functions as a quit and allows me to take screenshots of the action.

Day 49: Psychedelic Ball and Billboards

Today was yet another optimizing and slight addition day; with the luck of the DirectX player sounds I managed yesterday, I added a couple of other sounds in a similar manner. I also pulled in a neat effect where I took the random block colors I applied to the blocks and applied it every time the ball hits something; this ensures the ball changes color in a psychedelic and mildly confusing manner.

What next? Honestly, what next? I'm running out of time before the project turn-in, especially with two gigantic tests over the next couple of days and the prototype on the horizon:

I also went back to working with Cg in Unity and learned how billboarding works. When applying the point, I apply the projection matrix, but also multiply it with the world-view matrix times an origin point in object space (0, 0, 0, 1). This ensures the textured area in space always rotates toward the camera, used with things like grass or in this case, world maps:

Time for sleep, as exams await tomorrow and Tuesday.

Day 48: Double the Paddle, Double the Pain

Finally! An actual visual update of the assembly project! The second paddle has been added, with a generic function now controlling the collision of a paddle and drawing a paddle, instead of drawing and colliding the paddle.

The tricky part, I discovered, was the increased slowness and extended cycle count of adding an extra paddle. Turns out that when drawing a rectangle moving from left to right, you can draw the non-overlapping portion of the bitmap over the previously drawn rectangle. The frame-rate has improved immensely, and may even allow three or four paddles. The possibilities!

I also had to make another input register for player 2's controls. It's a bit bothersome for two players to fight over the same input, so two sets of player inputs are tested per frame. Fortunately the second paddle does not detach the ball, so it only needs two inputs.

After that, sounds! The part that truly brings a little project like this to life. The standard player can only play one sound at a time, but if one loads in multiple sounds to the DirectX player, one can play music and other related sounds at the same time.

Very soon, this project nears completion. That, or anything else I can add onto the top.

Day 47: Optimizing and a Chance for Something More

Today unfortunately will not be featuring any screenshots, as nothing has particularly changed visually about the product. What has changed, however, is a full refactoring of code (making sure all them data registers are named nicely) and a neat optimization involving global variable access.

When accessing my group of variables, I established an address and put the variables after it as defined offsets of that address (i.e. putting every name with an EQU *-GameVariables, for example). I found that I strictly used a4 for the address register, so I removed about seven load effective address functions that were thankfully unnecessary.

After that, I managed to include an acceleration that switched between acceleration and deceleration of the y velocity to keep things interesting, and clamped my bitmap drawing to 0 for a bug fix on the ball passing too far above the death collision point and drawing a unnecessary strip of bitmap along that x location.

What's next? The game is actually completed! So we can add more! I'm currently planning on adding a second paddle, so I've just made the DrawPaddle function a more generic one that can take arguments.

Day 46: Polishing Up

After finishing with the perils of collision detection, I saw that there were a couple of things that needed fixed up and optimized before putting in the concept of acceleration for the ball.

The collision impulse worked nicely for accelerating the ball in the x position, but not so necessarily in the y position. Strategically, one could smash the ball using the paddle to increase the velocity, but it never quite balanced out in the y direction. I'll be planning to ease acceleration in and out in the y direction to make sure things don't get too fast or slow.

The outline issue from yesterday gave me a bit of trouble, but I managed; the function had to redraw the line on not only the left boundary, but the upper boundary when destroying a block. When accessing the left boundary, it's as easy as going one byte back in the destroyed states array, but as for the upper boundary... oddly enough, the array goes from bottom to top, so I had to add the amount of blocks in a row instead of subtract backwards in bytes.

The last part today was a neat optimization on my lengthy branching of values when determining which value to place in each section of the address in the score display. Luckily enough, the numbers I was using to represent the display could be indexes in an array of numbers. Lo and behold, the numbers can be used to offset from the beginning of the array address to access the necessary hexadecimal value. This is a small optimization, seeing that a block isn't destroyed and score added every frame, but it's MUCH quicker than the previous implementation.

What next? There's still some polish to be done. Once the acceleration's in, the assignment will be presentable, but I'd be silly to stop there.

Day 45: On a Collision Course With Progress

Phew! Today was a tough meandering through collision detection and handling responses. After getting fixed point and time-based velocity values, I decided to go through with making that collision detection I worked on the other day. In this one, a rectangle (The ball) in this instance has four conditions with each of the target rectangle's boundaries in which a collision is formed.

With that, one would assume to be finished and just negate velocity? Nope; the question remains as to what direction. This required two more checks, which determined if the ball was approaching from the left or right and thus negated x velocity, whereas the false condition just brought on the y velocity negation.

However! It was not that simple. Negating velocity but not pushing the ball out of the block led to some very strange bits of passing through objects, so I went so far as to apply an impulse to the ball to use its velocity to force itself out of the object, which resulted in an interesting way to speed or slow down a ball's velocity by ramming it with the paddle on the sides.

Once that was through, I kept a byte-sized array of blocks to hold destroyed states, and put in a function to draw the bitmap over them and only check collision if they were not destroyed. All of this worked out nicely, especially with the generic CheckRectCollision function that operated with both the paddle and blocks, leading to this wonder:

But wait! What is wrong with those blocks? The right boundaries are eaten off! I'll have to put in a method to redraw that line soon. Score is also ready to connect with block destruction, and I'll have plenty of refactoring and possible optimizations to make this assembly breakout presentable.

Day 44: Master of Time and Fixed-Point Space

I've got good news and bad news for today. The bad news is that nothing has changed visually about my project today, so there'll be no need for a screenshot for progress.

The good news?

Underneath the surface, movement has improved immensely; the problem I had with the frame-based movement had a simple (looking) solution of time-based movement. However, time came in a decimal sense, the hundredths of a second sense. How to fix this? Fixed point math. By assigning certain bits to a register (8 bits, to be exact), we can manage up to 2^-8 of decimal points, allowing much more control over range of movement and variance by deltaTime.

Phew! Now she moves like she should. The most difficult challenge (collision) is yet to come, but I'm prepared to make it happen...

Day 43: Random Color Eater

As the second prototype draws to a close, I found more time to focus on the assembly assignment. I had figured out the distortion bug that was plaguing my ball drawing - seems as if I had forgotten to present the scene once it had drawn as a double buffer. Afterwards, I also realized every draw called could add up to a single scene present command, which saved a few lines.

Next up was block population and collision. Since the project called for a bit of randomness, I decided to make every block a random color. The actual creation of a random number generator is slightly horrific to think of in an assembly perspective, so I opted for the approach used in class, or combining the get-time command (gets time in hundredths of a second since midnight) and the number of clock cycles at that time. Do some multiplications and additions with a seed value and one ends up with random colors.

Another thing that I managed was collision detection and ball movement, which led to a particularly strange bug (well, the blocks are a completely different type of collision detection than the walls, so they still need done) in which the ball moved much more slowly when the paddle was moving at the same time. This led to a horrific discovery; the bitmap chunks determine the flow of time in this game, so that in order for a constant speed throughout the bitmaps needed to be constantly drawn, instead of only drawing while moving. This led to a more complete looking scene here:

As one can see, the collision with blocks and the paddle is most certainly next on the list.

Day 41-42: Space Rescue Complete

So far the prototype is going smoothly; the dialogue tree is almost complete and is fully integrated with (90 lines of dialogue?!) and events through the game. We've also setup a link to a url that traces choices that the player makes through the game (save drifter? Escape?) so people can keep track of their overall choices.

As for that, not too much. There was a bit of an issue with the drifter reaching VERY high speeds on collision, but I just disabled the collider of the station while moving the drifter to prevent this issue. Debris was also textured, but required loading from prefabs instead of meshes and ensuring the local position of all children was 0, requiring a recursive fix.

Phew! Time to go back to assembly tomorrow.

Day 40: Broken Bitmaps and Binary Coded Score

Phew! Today was definitely a busy day in terms of assembly work. Leading off from the hardware problems yesterday, I actually got a wonderful piece of advice on what functions 68K supports: binary coded decimal arithmetic.

Binary coded decimals, or BCD, is a way to encode decimal values as hexadecimals, but still have them read as such from memory. For example, $999 could still be read as a decimal number (not in the regular way, as it's still 9 * 256 + 9 * 16 + 9 * 1). Also, the processor allows abcd and sbcd instructions, which only work with byte sized spaces (logical shifting, anyone?) but do proper BCD arithmetic and even carries the extension from addition that overflows the byte size into another addition, so 50 + 50 could indeed be 100.

What next? Optimizing the bitmap was a slight nightmare, as I had to work from scratch, 16x16 pixel scratch (Augh my eyes). Luckily enough, I found the error of my ways to be in the dbra instructions I was using; instead of checking at 0, it actually checked at -1. Just like that, my problems were solved relatively quickly and I have a pink paddle moving with proper input on my screen, with unfortunate flickering from redrawing the bitmap:

What's next? Double-buffering may be the key to my issue, but that may still lead to some flickering. The ball also needs to be implemented, as I will soon need it for collision testing and possible floating point shenaniganery.

Day 39: Rope Fix and The Terror of Hardware

Today was quite the busy day again, as I juggled both prototype tasks and the next upcoming assembly project. Fresh off from our bitmap project (which I just managed to optimize after finding out a bug that had me skip progressively less and less pixels per row), we are now tasked with creating a simple game in an utterly non-simple way. We went over setting up a loop and getting keyboard input at a proper pace, but I was unfortunately focusing on bitmap optimization, so I may have to wait until that code is released.

On the flipside, the rope finally works! It seems as if transporting the object in question (drifter + rope) and then attaching actually produces a much softer transition. Now we are no longer in need of fancy rope (Whew).

Back to assembly. Right now I am working on a part we haven't covered in class just yet, but will require a great deal of attention. The hardware simulator in Easy68K will be responsible for displaying our score (seen below):

Seems simple, right? Just set the display based on the number, right? Nah, it's never that simple. Each of the red lines on each digit requires a special bit value, with very specific hex values for the simple 0-9 set. That, and numbers are stored as hex in memory. Thinking of accessing decimal ones, tens, and hundreds places? Get ready to do some fancy footwork in converting to those places from hex.