Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics


A member registered Sep 27, 2020 · View creator page →

Creator of

Recent community posts

Nedap BrowserJam community · Created a new topic Welkom!

Welkom bij deze eerste Nedap Game Jam!

Voel je vrij om van dit community board gebruik te maken, maar realiseer je wel dat het een openbare website is ;)

Wie ben je, en wat denk je te gaan maken? 

Hey Kouzeru, thanks for the invite!

It's not really an extension to XO-chip, it's already in the spec, it's just not been implemented by interpreters :) The only thing that isn't defined is the colour palette. I've been thinking about drafting a separate proposal for the palette, but I have yet to finish that.

I've joined the Discord server, but I don't normally use Discord much so I need a few pointers ;) I'm Timendus on Discord too. Hit me up!

Hello Darzington!

Really enjoyed your stream last year and I'd love your feedback on my submissions. I expect you'll find my reduced version of 3D Viper maze very boring in comparison to last year's jump scares ;)

Looks like I will probably not be able to see the stream live though, so looking forward to watching it later. Good luck!

Very entertaining!

This is a very cool game. Totally weird, and I never managed to get 70 orbs, but I like it ^_^

Really cool! An adventure game like this is also still on my todo list  :) I was sad to have finished it so quickly!

This is really quite addictive! Cool game, great execution!

Hey thanks man! Those look waaay more optimized than my routines. The main difference being that I was thinking my sprite drawing routine should do the heavy lifting of masking out the buffer and putting the sprites in place, instead of actually using multiple buffers. Seems a waste of cycles and memory otherwise, but maybe I'm not seeing something ;) I'll give it another spin, see if I can't get it sped up a bit with these ideas.

I also wrote a second implementation that doesn't use a buffer in memory, but that has some logic in the background drawing routine to mask out the foreground sprite. So the background just leaves a "hole" for the foreground to render into. Much less slow, but I'm a bit scared to go down that path because it requires a lot more bookkeeping in the background drawing routine, which may get hard to work with as the game gets more complicated...

I was thinking about writing a game with a couple of "layers"  (in colour, so I can't use the "each plane is sort of a layer" trick). Only having XOR for sprite drawing is a little limited for my purpose, so this evening I wrote a few rendering algorithms that operate on a buffer in memory (clear buffer, AND/OR sprite to buffer, render buffer to the screen, that sort of thing).

Now here's the thing: it's working just fine, but it's freakishly slow. Even on "ludicrous speed" :P Especially the sprite rendering to the buffer seems to be way too slow to fill the screen in a reasonable time (in hires mode especially).

Hence my question: Has anyone here ever tried to do buffered rendering? And if so, was that a success? Is my code just really silly and unoptimized, or is it just kinda outside of the reach of the platform?

I guess I've already made a "demake" of my game from last year :P

My "demake" of 3D Viper Maze can run on the original VIP CHIP-8 interpreter as a watered down infinite-random-mazes game. I've called this version 3D VIP'r Maze ^_^

I really don't know what to make for this year's Octojam though... I had a few ideas but those are all quite ambitious. And I have a lot less spare time this October than I had last year :/

Thanks Thavelick, that's great to hear! :)

As some of you have already discovered, my "post mortem" is here :)

Hey there! I'll try to at least watch, but I have some other engagements that may kinda overlap. We'll see! Thanks for reviewing my game and have fun with the stream :)

Yes, I could. I thought about adding another "Press any key" to the first screen (that doesn't have any sound, and currently just transitions after a given time). But then I'd have to redesign that screen to make room for the extra text. Ah well, you have to know when to stop sometimes ;) This is not an issue with Octo or my program, it's just a little annoyance because of the fact that we run it in a browser. That's okay with me.

Haha! Thanks a lot :)

Too bad, it ruins the atmosphere of the dramatic entrance to the game ;P But let me add to that: Octo is an amazing platform, and the XO-Chip extensions are a great addition to Chip-8. Thanks a lot for both! :)

Thanks man! Your game is pretty impressive as well! :)

Another Octo related question: In the generated HTML file, the music doesn't start playing until I press a key. I assume that's one of those browser limitations, where you need a certain amount of "user engagement" before you're allowed to play music?  Or is it a bug in the Javascript?

Wow, I actually managed to release (a version of) this before the deadline! ;P

I don't think I'll have time for the pure Chip-8 version in the next four days. Maybe next year?

(2 edits)

As far as I understand it, which is probably not that far ;), random takes a bitmask as an argument. The bitmask is a value that gets ANDed with a random number from 0 to 255. So:

v0 := random 0xFF   # v0 is a random number from 0 to 255
v0 := random 0x01   # v0 is randomly 0 or 1
v0 := random 0x07   # v0 is a random number from 0 to 7
v0 := random 0x08   # Careful: v0 is randomly 0 or 8 ;)

Cool! Impressive animation on the chicken! I'm guessing we're looking at quite a few cycles per frame here?

This is the most addictive submission so far! Very nice! :)

Making good progress imho! Just a few more gameplay elements, some pixel art and much level & music design to go...

Oh no, you didn't just fix this issue in a matter of hours, just because I complained about it, did you? :) I hope I didn't inconvenience you too much... 

It works like a charm now, thanks for saving my two bytes ;P

Alright, I need to be able to do an "unpack-long" type of thing. Seeing as my file was ~3000 lines anyway, I decided to split it up into smaller files and recombine it in a build stage. This also allows me more flexibility in moving data and code around without getting annoyed by it.

So I'm trying do this:

:org 0x1000
  # Data here
:org 0x0200
: main
  # Code here

But if you try this in Octo it will give you an error: "Data overlap. Address 0x0200 has already been defined". I guess there's an implicit ":org 0x0200" at the top of the file.

This works:

: main
    jump 0x0202
:org 0x1000
  # Data here
:org 0x0202
  # Code here

But I mean, that's just plain annoying ;P Especially since an "unpack-long" is pretty much the first thing I want to do in my ": main". Do you have any suggestions on how to clean this up..?

That's interesting! The behaviour is a bit different though: I can :unpack a label that occurs later in my code, but with this macro I can only use labels that are placed before it in my code.

The reason I want to have a 16-bit unpack is to be able to dynamically point to data in the lower 61.5k from the code in the top 3.5k. I guess the advice would then still be to restructure the code with the whole :org to-data to-code trick..? :/

Why is it that :unpack only does 12 bits? Is it also from before the 65k expansion?

Another beginner question about the Octo assembler... Is there such a thing as

:unpack long <address>

Because I need the full 16 bit address in v0 and v1, without prefix nibble. Am I missing something, or should this be a feature request? ;)

Impressive endeavour! :O

I don't hope to be able to achieve more than faux 3D. Especially if it needs to be finished in two weeks ;P

Ah, I'm not as original as I hoped after all  :D

Can't find that game anywhere other than YouTube yet.

Thanks Tom :)

Hey there!

I'm pretty new to Chip-8. I only discovered it about a year ago and had a lot of fun last winter writing an interpreter, an assembler and finally a compiled higher level language that I didn't finish. All in Javascript, and running in the browser. At some point I discovered that Octo is a thing that exists, and that Octojam exists, and because implementing the Chip-8 tools gave me so much joy decided to join the jam and see if writing software for the platform is equally enjoyable :)

I've been able to put a couple of evenings' time into my idea, and it's starting to look like something, so I thought I'd share what I'm working on.

The concept is loosely based on the 1981 game "3D Monster Maze". I really enjoy playing with retro 3D and pseudo 3D stuff, and as far as I could find there are no games or demos that do anything related to the third dimension for Chip-8. (Did I miss anything..?) Also, I like that the original game is almost as old as Chip-8 is, so that makes it a great match, I think. Probably no dinosaurs in my version though, I have some other ideas ;)

I can currently walk around the map in "3D" and I can also bring up a top-down mini-map to see where I am. I'm not sure if the mini-map is going to stay, or if it will mess with the gameplay. This screen capture is running at 30 cycles per frame:

These flat, boring images are just for testing the "engine". The intention is to get it to look more like this:

As you can see I'm still playing with shading the stones, making them dirty in some places? Maybe the ceiling needs some love too..? This project is going to be a lot of work, even in pixel art alone... ^_^'

As you can see I chose to use Octo's XO-Chip extension for drawing four colours and SCHIP's extension for drawing 16x16 sprites. That's all though, so another idea I'm playing with is to make a very bare-bones black-and-white version of this game that is actually Chip-8 only, and should run on the hardware from the period. It'll be slow, but it should just be playable, I guess..? We'll see! One step at a time.

If you're interested, my code is on Github, under a GPL license.

Thanks for the ideas! And the crazily quick replies! :)

(1 edit)

Ahh, so that's what's going wrong. That's pretty annoying :/ I have a shit-ton of data that I need to reference in this way. I guess the data is going to the top of the file, cluttering up the place, if there is no other way.

I was just getting used to the jump0 trick, until I realised that I have 48 entries in the table and 47 * 6 = 282, which is more than v0 can hold... So v0 is overflowing and giving me errors... o_0'

If I want to have the data before my code, can I do something like this?

:org end-of-code
:org 200
: main
: end-of-code

This particular code gives me an "Undefined name 'end-of-code'".

Edit: Never mind! I don't have to move all the code under the data, I just have to move the look-up table under the data. Problem solved! Thanks guys :)

Ah, that's a neat trick! But does that only work with constants? Or can I use it with labels too? :)

Hey there,

I have a question regarding labels in Octo. I want to have a look-up table of labels that point to data:

: my-data
: image-1
  0xFF 0x00 0xFF # Et cetera

I use this table to look up the address of the right image and load that in "i" with some self-modifying code that adds a 0xA0 (load i) prefix. And it seemed to be working quite well so far.

However, now that my program has passed the 3,5k mark I'm getting an error "Value '<much>' for label 'image-1' cannot not fit in 12 bits!" (there's a small spelling mistake in that error, by the way). This has lead me to realise that my table of labels doesn't really compile to a table of addresses, but to a table of call statements. And the fact that I AND those statements with the right nibble in my self-modifying code has kept that fact hidden from me.

So the question is... does Octo have a way to just put the address of a given label in the output binary? I looked through the manual, but didn't really find anything.

This example shows a table like this:

: table
  i := 0x123 ;
  i := 0x456 ;
  i := 0x789 ;
  i := 0xABC ;
  i := 0xDEF ;

Which would work with "i := long <label>;" too, I guess. But that would be six bytes per entry, instead of two. Seems like a waste :)