Or tap-tap, tap-tap-tap… long hold, short hold, etc… I can think of quite a few “combos” (all with one button) that would work - depending on the type of game…
Josh Goebel
Creator of
Recent community posts
I was specifically talking about AI for coding (not art or music). In my head I imagine game jams where judging is centered around:
- story
- play-ability
- creativity
- game mechanics
- artwork
- rules (is your game truly 1-bit, etc)
- theme
NOT code.. And none of that has anything at all to do with AI code assistance. Maybe some jams are more about code but the few I’ve entered so far no one was even looking at the code.
I’ll keep looking for jams less restrictive in this area.
We must not let the “it knows X so I don’t have to ever learn X” mindset limit humans.
I can agree with this, completely. That’s very short sighted thinking (for now)… though we’ve already done this with so many other things (take Google or Stack Overflow for just one example). Which does make me wonder when AI is allowed if it’s for learning use rather than doing use (and who decides that line)… but we don’t have to go there necessarily. :-)
Worth noting: you’re locking out another group of people as well. I’ve been doing this stuff (programming) professionally for over 2.5 decades - I use AI not to avoid learning - but to accelerate productivity. For these kind of things I often (but not always) enjoy the creativity and UI design parts more than the raw programming, so if AI is there to help with the dry parts, great.
Just some food for thought.
Not “fully”… but perhaps partially vibe coded?
Just curious, what’s the thinking against vibe coding? I feel like (from the reading I’ve done) a lot of jams would suggest that an artist/designer (who perhaps has a game in their head) to go out and find a [human] coder to pair with… but why should it matter if the artist paired up with a human or with an AI?
Is the idea that it’s somehow cheating?
So if someone wanted a greyscale effect at the tile level… say a tile/icon is 8x8… could they just render some tiles 25% opaque, some 50%, etc… to achieve effective grey-scale? Ie all the background/wall tiles might be 50% opaque whie the players/enemies are 100%… would this be within the confines of the rules?
You can use ALL the editors, you just can’t include ANY of the sfx/gfx data in the cart directly - it all has to be part of your source code - which you’d have to decode and put back in the sfx data area at startup.
Yes, you can use the function - once you’ve put some data there - or else I assume the function would do nothing but be silent.
Impressive and very interesting! Have you talked to John to see if he’d be interested in any of these extensions in Octo itself? I particularly like the struct stuff (and include)… I’m interested myself, but not in a whole new IDE… I might build some of this myself, just as a pre-processor… so that the output of the pre-processor would be 100% valid Octo-8 code.
I need to just put all the code on GitHub… I haven’t had a chance to finish it yet or clean it up… but I should find the time to post what I have for anyone who wants to play with it. Personally I don’t consider it super useful without a paired compiler, but perhaps that’s just me.
Therefore, would you extend your VM to support 32-bit arithmetics?
That would require some thought… the stack is currently all 16-bit values… the opcodes that process data all 16-bit, etc… To go all in on 32-bit you’d really need a dedicated series of 32-bit push/pop/math opcodes… I’m using 7 bits to store the opcode though, so that does allow 128 instructions (of which I’m only using 36 or so) - so we would have plenty of space in the instruction set for 8 and 32-bit ops.
Perhaps one could add 32-bit math just by making the stack (largely) agnostic about what it’s storing… if you call push32 push32 mul32… then you are pushed 8 bytes unto the stack and multiplying them as two 32-bit numbers…
I’ll see if I can get what I have so far published by Sun/Mon… it’s at home on my other system though or I’d work on it right now.
If you’re referring to my thread Jack (as defined by the course) doesn’t support floats, only int16/bool/array objects that contain those things. You could of course write a floating point library in Jack, but it doesn’t have operator overloading and such niceties… or you could add it to the language/compiler itself and write it in Jack VM opcodes (or even Chip8 instructions). I haven’t gotten that far - I’m still finishing the VM.
Fixed floats would be easily compatible with 16-bit math, right? The fastest code to run natively would be code that just treated it as one big 16 bit number with a virtual decimal. If so then all the 16-bit math in the Jack VM (and the OS multiply/divide routines) would “just work” out of the box…
The only trick would come at the edges when you needed strings or just the integer or fractional components. You could potentially even use a lookup table for converting the fractional remainder to a base10 number, then feed it into the existing BCD to font stuff.
Where were people imagining the fixed point being?
And if you’ve never heard of Jack it’s a simple high-level language syntactically similar to C or Java:
class Main {
function void main(){
var Fraction a, b, c;
let a = Fraction.new(2,3);
let b = Fraction.new(1,5);
let c = a.plus(b); // compute c=a+b
do c.print(); // should print the text: “13/15”
return;
}
}
It has has classes, objects, arrays, booleans, looping constructs, pointers, etc…
For anyone interested I’ve been working on a Jack VM (16-bit) to run into Octo. When reading the stack source linked from this years jam I got the idea of building my own automated testing suite as well… and this is working out MUCH better than I ever thought… you just add tests cases and they are auto-magically registered with the test runner…
Ref: https://www.nand2tetris.org/
Here is an example of the kind of thing I have working so far:
test "simple add"
vm_start
o_push_constant 1 # 0x80 0x00 0x01
o_push_constant 2 # 0x80 0x00 0x02
o_add # 0x04
vm_stop
pop_into_reg vC # returns a 16 bit value in vC-vD
assert_equal vC 0
assert_equal vD 3
success
;
Note, that vm_start and stop wire up the VM runner… so o_* instructions are NOT generating CHIP-8 code, they are generating the binary shown - Jack VM bytecode. The course itself never gets into defining bytecode for the Jack VM - but it wasn’t too hard to conceptualize. And of course we’re adding our own opcodes as well so that we still have low-level access to things like clear, etc… The Jack VM is stack based, so our opcodes vary from 1-4 bytes (mostly 1 or 2). With things like function dispatch being the most complex and ops like add being a single byte.
vm_start preserves the address, pushes the org forward 2 bytes (to save room to a jump we’ll insert later to skip over the VM code and jump past vm_stop… then vm_stop inserts a o_halt opcode (that instructs the VM to stop and return) and then sets the VM’s PC to the start of the mini-program and then boots it. Oh, it also quickly goes back and adds the jump now that we know where we need to jump TO.
So now each time a test hits a VM block the VM fires up, runs the code, and then we test the results to verify correctness. And of course there will be a tiny little UI for this as well.
The overall idea is we fit the VM engine into the first 4.25kb of RAM (we have a jump opcode table at the end of 4k for opcode dispatch) and then that leaves 60kb or so for program code (since it’s now abstracted by the VM). Right now I have most of the Jack “basic” opcodes implemented (other than flow control) along-side my test suite and I’m sitting at 2.6kb of low RAM used - so I think this doable.
I still need to figure out:
- delay
- sound
- inputs (memory mapped?)
- sprites
Step two would be writing (or repurposing) a Jack compiler in JavaScript to generate Octo flavored Jack bytecode… even better would be pairing it with an editor so all this was available on a simple web page where you could write a Jack program, compile it, paste it into Octo and run it. :-) A “compiled” program would just be a blob of binary/data + the VM runtime.
If anyone is interested (or wants to help) I’d be happy to share more or answer questions.
I might make a PR, I personally don’t find that wording clear. It seems jump (and likely call) ARE allowed, so long as the targets are in the first 4kb… I just tested jump and it works just fine.
Not sure how useful this is - except for a jump table where the entries were pretty spaced out (think VM opcode decoding from high bits of instructions)… Feels like a nice place to stuff an opcode jump table, to save the low 4k for the VM and opcodes.
Here is what I have now:
:macro assert_equal_16 REGPAIR VALUE {
:calc hi { ( VALUE & 0xFF00 ) >> 8 }
:calc low { VALUE & 0xFF }
if REGPAIR != hi begin
test-fail
return
end
# rewrite REGPAIR to REGPAIR + 1
:calc here { HERE + 8 }
i := here
load vF - vF
vF += 0x01
save vF - vF
if REGPAIR != low begin
test-fail
return
end
}

http://johnearnest.github.io/Octo/index.html?key=KHC68WVt
For anyone using Octo and wanting to brag about it. Uses Chip-XO instructions and multi-color, low-res mode. The progress bar is just for show now but if someone wanted to actually do real work inbetween it could be modified to be a callback that advanced the progress.
Thoughts? Ideas for improvements?
Victor or not I’m also not seeking any kind of “advantage” here… I’d OSS whatever changes I made to the runtime (happy to submit them back upstream as well if we agreed on a spec)… so anyone who wanted to have a game with say palette swaps could just compile/build with my modified version of Octo and then upload…



