Thursday, November 1, 2012

ASCII Errors

So, the last couple weeks, I have been distracted by the annual IF Competition. No Hugo games this year, but I decided it was a good year to make an honest effort at playing and reviewing the games. I got through them, but I tell you, playing other people's games is nowhere near as satisfying as making progress in one's own game or coding ability.

I tried to jump back into the Hugo swing of things yesterday. It went about as well as could be expected. There was a moment where I tried to remember why I thought my PrintStatusLine redesign the other week was a good idea (I mean, I still think it is, but it sure looks kind of a monstrosity at first glance). I moved on to my WIP, where I spent an ungodly amount of time trying to come up with a good, unused name for a bowling alley. I made some progress but I'm not sure I'm there yet.

I switched my attention to another part of the code where I had a random ASCII-key-printing thing. In fixing some problems, I learned a couple things. One, my ASCII "clip text" file that I made for EditPlus had some issues. For one thing, I made no notation for when it skipped numbers, which made it possible for me to forget that in such cases like my randomizer, I couldn't use every value between a and b (like my code was doing). When the official Hugo interpreter gets a non-valid number, it doesn't really print anything. Hugor, on the other hand, does one of those "hey-we-couldn't-print-this-character" characters.

So, I went back over my EditPlus clip text file and fixed the misleading entries (and added a BAD token for unaccounted values). On one hand, the lower range of ASCII values, where all of the normal letters are, have none of those troublesome gaps. Still, some fun ASCII symbols, like yen symbols and what not, are in the higher ranges. I also updated the Hugo by Example ASCII page so it now links to the best ASCII value chart I found in my limited searches.

Part of the reason I was attacking this ASCII thing was because Hugor had an unexpected gap at the end of a line that should have printed to the end. Eventually, I figured it out that just calling system(61) (which checks if the interpreter is a simple port) makes Hugor think we have progressed a character position, so commands like 'print to display.linelength;' always come up short.

Anyhow, I'm pretty happy to have found this one, as I think there's a good chance it's responsible for the weird behavior I wrote about in this post.

So, don't know if I'm entirely in Hugo mode yet, but that can't be a bad start. Anyhow, the HugoComp officially starts tomorrow (I'll make a post to, so it'd be really nice to wrap up one of these projects real soon like. Fingers crossed.

No comments:

Post a Comment