Tobias V. Langhoff
Recent community posts
This is great! And super hard!
It was completely unplayable for me with the default cursor speed, as it was impossible for me to move the cursor only one step at a time, but when I turned it down to 1 or 2 it worked great.
I wonder if it'd be possible to add mouse control, or if that'd make it too easy (navigating the cursor around with the keyboard does add its own challenge). But with mouse support and potentially a browser version for a lower barrier of entry, I think this could be a hit.
What build pipeline did you end up with? I also lost some work to the dreaded "loading..." message the other day (although I had backed it up manually in a gist a few days before, so it wasn't so bad). I'm mostly using VSCode, and the Octo extension seems outdated and non-functional.
You are correct in that `i ` pointed to real memory locations, and that programs start at 0x200 because the CHIP-8 interpreter was using that RAM on the COSMAC VIP. However, on the VIP, the font characters weren't located in the interpreter, but in the VIP's own OS or monitor program (CHIP-8 simply reused the VIP's font). The original CHIP-8 specification didn't specify where the font was (or should be) located, so in a way it was "abstracted" away. The value of `i` after using the font opcode was, in a sense, undefined.
Modern interpreters do it differently. Somewhere along the line, people decided to put the font in the now unpopulated memory region that used to be occupied by the interpreter. After all, why not, if the spec doesn't say where it should be?
Not quite; the screen memory was not located in the first 512 bytes. (Neither was the font, which was in the VIP OS.) That only contained the interpreter code itself, but no variables. On the COSMAC VIP, the 256 bytes of screen/frame buffer were located in the last 352 of the addressable memory, along with variables for the V and I "registers" and other data. This location changed depending on how much memory the VIP had, which is probably one reason it wasn't included in the spec.
There were in fact even some "hires" CHIP-8 interpreters for the COSMAC VIP, such as "CHIP-10". That was unproblematic, as long as the VIP had enough memory. Although, the way the "Pixie" video chip worked, the resolution was 64x128 instead of 128x64 (because each pixel was fewer scanlines tall).
It simply wasn't part of the original interpreter spec.
Other implementations (including CHIP-48 and SCHIP) didn't put the screen memory (and other stuff) at the same locations. Any program that relies on the screen memory location would only work in that specific interpreter. (Some early CHIP-8 games for the VIP might rely on this.)
In fact, the location of the screen memory changed in the original COSMAC VIP interpreter based on how much memory the computer had, since the interpreter's variables (including the screen memory) was always lcoated at the end of the addressable memory space.
Well, there's nothing stopping you from putting code beyond the "regular" 4K of CHIP-8 memory, but XO-CHIP doesn't provide a way to jump or call code there. You can set the `i` index register to anywhere in the 64K memory space, however, so it's easy to use for graphics or audio.
Cool! Usually CHIP-8 games have the scope of a single micrograme, hehe. But it's definitely possible to cram a bunch of stuff into one game, especially if they don't need a lot of graphical assets. Even then, XO-CHIP gives you a lot of space for assets (just not code, easily at least).
Cool! I made two games last year that targeted the original COSMAC VIP CHIP-8 implementation, and I'm working on another now. Historical accuracy is definitely one of the things I enjoy most in Octojam.
"Sprite drawing trigger vblank" means that when Octo encounters a `sprite` instruction, it will then halt and wait for the next frame is drawn before continuing execution, so drawing sprites will be a bottleneck for speed.
I think 7 or 15 cycles per frame is reasonable. It's all an approximation, of course, since in Octo all instructions take one "cycle" (AFAIK) while it varies between instructions on COSMAC VIP. Here's a table of real-world timing for each instruction.
The best approach is probably to test your game in the Emma02 emulator, which emulates the COSMAC VIP faithfully. As far as I remember it's a little hard to understand how to use it though.
The jam has started! Has anyone started? Do you have any ideas?
I have a few ideas. This year my goal is to make on CHIP-8 game targeted at the COSMAC VIP, one SUPER-CHIP game targeted at the HP48 calculators, and one XO-CHIP game. I made two CHIP-8 games that ran on original COSMAC VIP hardware last year, and that was great fun. (I also like turn-based stuff and puzzle games anyway, which is well suited for that.)
I'm so stoked for Octojam, I put together a little keypad, inspired by the COSMAC VIP's keypad, to play this year's games with:
It's a BM-16A PCB and case, purchased from KPRepublic. I had to solder in switches myself (I put in some Zealios Zilent switches I had lying around for a tactile feel). The keycaps are a DSA Mono-Color keyset for an ortholinear layout from Pimp My Keyboard (Signature Plastics); the DSA profile means the keycaps are all the same height, and the ortholinear set comes without sublegends on the numeric keys.
I then programmed the keypad using the open source QMK firmware, and mapped the keys to the Octo layout (ie. 1234qwerasdfzxcv).
Time to play some CHIP-8 games!
Really fun idea!
I'm playing on PC. The instructions say that left click clears a tile and right click flags, but it seems like both left and right click flags? I have to double click to clear.
Thank you! I definitely think I can do more interesting things with the concept, but sadly I didn't have time for much level design or to develop the concept further.
In retrospect I agree on the red+green color choice – those tiles are actually from a classic (now public domain) puzzle game called Laser Tank, which I've played a lot, so I guess I've just gotten used to the colors over the years, haha.
Thank you! Yeah, I totally agree. I made them controllable on the title screen as a tutorial, but individual levels would be better. I got a lot of ideas while making the prototype, but I should have set aside waaaay more time for making levels. Puzzle levels are hard to design!
Amazing game! And amazing artwork. I haven't played a lot of text adventures before, but this game really made me interested in the genre.
I'm still not done, missing two mushrooms (I have tall, indigo, striped, russet, inky, skinny, broad and golden) and probably a lot of easter eggs, judging by the ending text.
A small bug: "EXAMINE TREE" works in all (?) rooms and says "The skinny sycamore tree has taken root is not here".
Yeah, it's not impossible, but certainly tricky. I feel like the three sentences in the introduction aren't really "story", but "setting". Maybe I'm thinking too much in terms of "plot" though. We'll see what I manage to squeeze out.