Archives for posts with tag: javascript

Blackjack is the longest game that I have converted thus far, and has several complex issues. The converted code spends most of the time in an unrunnable state until most everything is taken care of. Fortunately the systems and techniques built up over the previous conversions should hold me in good stead. Read the rest of this entry »

After converting the Awari game, I got cocky and went ahead with converting a maze generator called Amazing, even though it had been converted before. That one knocked the stuffing out of me, and after messing with it for half the week, I learned that the original code had the same bugs I was trying to squash. Read the rest of this entry »

This is the big one. The original author of BASIC Games to JavaScript seems to have stopped at Awari, and I’m curious as to why and what the challenges will be. Read the rest of this entry »

Converting 3D Plot is the last of my preparation before tackling Awari. The main challenges with 3D Plot was how to properly handle the tab statements, and how to handle the animation of what used run on a tractor-feed printer. Read the rest of this entry »

Before to converting the BASIC Computer Game of Awari, I figured that the person that had converted three games from BASIC to JavaScript might have stopped there because it got more difficult. As such, it would make sense for me to do a few others first before jumping in to that one.

Since he started converting games from A, and I have already downloaded the BASIC source code from all of the games at Vintage BASIC Games, there are a couple of other games before A called 23 Matches and 3D Plot. These look to be good material for me to start learning about the conversion process. Read the rest of this entry »

While playing around with Blanket.js, an annoying ANSI color code in Chrome’s console has prompted me to fix the color display issues once and for all.

Read the rest of this entry »

The food coop kicks back in to gear after being postponed from the day before, and a lot of simplification occurs to some code making it much easier to understand.

Food co-op creative maths

What with yesterday’s delay, the food co-op got back in to the swing of things today on Thursday. Apparently it wasn’t the weather that stopped the truck from arriving yesterday, but was instead a genuine break-down of the vehicle for other reasons.

Des seems to like putting me on to food items that need weighing, which has something to do with the running tally that I keep in my head during the course of things. Normally we would take the 29 10kg crates of tomatoes and needing 356 packs, and figure out that:

\frac{290}{356} = 0.81

resulting in us wanting 800g of tomatoes in each pack. But I found a much easier solution. While weighing up 800 grams at a time and tracking that we were under by 150 on this pack, over by 100 on another leaving us 50 to play with, and over by 50 on the next bring us back to an even balance of things, I also did some rough division in my head for the number of packs divided by the crates we had, which gives us:

\frac{356}{290} = 12.3

So we’ll be wanting 13 packs from each crate of tomatoes, which is much easier to achieve without such detailed weighing. Since the crates invariably contained 14 sets of tomatoes still on their vines, it was a simple case of throwing the occasional extra tomato in with each pack and job’s done.

Sure, math can solve problems and can be quite useful, but taking things a bit further can help us to be lazier more efficient. Sometimes a bit of creative thinking can go a long way too.

Simplifying code

It all started off last year as the following spaghetti code from FORTRAN for working out information about an aircraft at different speeds:

   20 V=V+DELV
      IF(V.LT.VS1) GO TO 20
   21 RC1=RC
      IF(RC.LE.0.) GO TO 23
  103 FORMAT(4X,F6.1,7X,F6.1,7X,F6.4,7X,F6.1,6X,E10.3)
      IF(ISTAL.EQ.1) GO TO 22
      IF(IMAX.EQ.1) GO TO 24
      GO TO 20
      GO TO 20
      GO TO 21

which is horrible code, but that’s the best that could be expected several decades ago.

Making improvements to it when translating it to JavaScript can help to highlight structure of the code, and moving some parts out to separate functions helps to make things easier to understand:

do {
    rc_prev = stats.rc || rc;
    stats = calculateStats(v, data);
    if (stats.rc > 0) {
        if (!imax) {
            v = nextDeltaAirspeed_alt(v, vel_step, data.vs1);
    } else {
        v = finalAirspeed(v, vel_step, stats.rc, rc_prev);
        imax = true;
} while (imax === false || stats.rc <= 0);

and even though we can more clearly see what’s happening, it’s still difficult to understand what is going on and why.

Effectively the imax value is used to figure out if we’ve reached the maximum achievable velocity, so that we can loop through one more time to find a final airspeed.

I ended up pulling things apart by removing the else clause, and realised that three main things are happening in the loop. First an initial airspeed is being calculated, then the airspeed is being gradually increased until no more lift is available, and lastly the final airspeed is being worked out.

Because the loop has only one main purpose, the other parts dealing with the initial and final airspeeds can and should be extracted out. By separating these from each other we can achieve a greater understanding of the code.

So by tweezing things apart we now end up with the following:

stats = calculateStats(v, data);

do {
    v = nextDeltaAirspeed_alt(v, vel_step, data.vs1);
    stats = calculateStats(v, data);
} while (stats.rc > 0);

v = finalAirspeed(calculated[calculated.length - 1], stats);
stats = calculateStats(v, data);

which is a lot easier to understand than anything we had before.