itch.io

Did you find the easter egg? :-)

If one split a 2-bit sprite into 3 different sprites and just drew them at different opacities you’d have essentially Gameboy 2 bit color… This isn’t that, but if this was ok I’d think that would be also.

Feels like a bit like letter of the law vs spirit of the law to me - hence the ask.

Like this but without the red and orange obviously…

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?

Any idea how much space a nice track would typically use in a jam like this? I presume we can’t store it in the cart but would need to store it encoded in the code and then extract it to the music/sfx RAM on first boot?

…So one person could work on the game and another on music/graphics? I realize there isn’t as much “room” for that (with only 1k), but to the extent it’s possible - any objections?

I saw this:

Shrinko8 can compress better than Pico-8 itself, so you’re recommended to download the file instead of copy/pasting)

Can we take advantage of this? I haven’t yet tried what happens if you download the cart and then reopen it in Pico-8 editor… are the additional savings still there?

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.

So eerily quiet this year - are people just working on their games heads down or?

Are :struct and :include and with part of Octo8? I’ve never seen them documented anywhere…

Have you decided which “hardware” you’ll be targeting, ie original CHIP-8, XO-Chip, how many operations per cycle, etc?

Would love to see some links to your work once you have it online somewhere.

Thanks. :-). I’m glad you’re enjoying it.

Are we doing an Octojam 10 this year?

Don’t see anything in the rules saying you couldn’t.

I would imagine tilesets one buys are licensed but ALSO still copyrighted (by the original author), does this mean one can’t purchased a tileset and must used all their own artwork? The intention here could likely be started more clearly.

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.

That chess mockup is awesome.

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.

Do jumps outside the first 4k work as long PROVIDED they are jumps back into the first 4k? IE, could one locate a jump table at 0xFFF?

but IJ voted against it with some compelling reasons.

Is that discussion online somewhere? I’d love to read it.

OMG, so much nicer! I thought it’d be here somewhere!

I dunno how to find the address before I get there, and I don’t think I can use a label because I’m inside a macro and that would generate duplicates?

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
}

Makes sense, thanks!

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…

In a prior year I specifically asked about a variant with hardware registers to allow swapping the 4 colors (still 4 colors, but swappable by writing RGB values into RAM - I’d have modified the JS Octo build to allow this to work) and IIRC you vetoed it. Yet this year I see you specifically mention silicon8, which has a 16 color mode - quite a bit beyond your “official” XO-Chip spec.

So I’d like to again ask for clarification in this regard.

Also, is there a winner or prizes? (I don’t recall such from prior years)… if this is all just for fun isn’t the spirit of the law here a lot more applicable than the letter of the law?

I’m specifically imagining things that would seem possible given the Octo ‘hardware’… ie, in keeping with:

The additions are sparing and try to retain some degree of historical plausibility and the flavor of Chip8’s creative limitations.

• palette swaps - if the ‘hardware’ can show 4 colors (from 16 million) per cartridge it seems there ought to be some way a cartridge could change those 4 colors are runtime (this presumes the underlying LCD ‘hardware’ is 16/24-bit, etc)
• video RAM - in original implementations the video RAM had to be stored somewhere on the actual hardware - so making it accessible somewhere in the XO-Chip address space for direct reads/writes seems realistic and also very similar to how many other retro systems worked.

Thoughts?

Any interest in utilities/library code for more ambitious XO-Chip projects? I was imagining perhaps a graphics library (circles, lines, etc) or a really nice credits scroller. If anyone is interested in such “support” items I might have some time to help out. Often what I do for this jam is get super excited about a new idea and then build the idea instead of a game anyways. So perhaps I should just realize that that but then help out someone else’s project.

Thoughts?

For my own game (if I have time) I’m thinking of like a scrolling shooter Star Trek game or story based platformer. I’m (mostly) interested in XO-Chip turned way up (ludicrous) to try and build something but if I thought of something slower I could imagine trying more “realistic” speeds (probably still XO though for the RAM).

Remind us again what cycles per frame setting is more/most “realistic” to best emulate older devices?

Oh yikes. Oops. Thanks for letting me know. The earring isn’t really important to the story, so nothing to worry about.

The game itself is not downloadable as many of it’s assets (images, music, etc) are hosted online.

It’s also shiny, another good reason to put it on. :)

Did you wear it when you found it? The hint when you put it on connects to the hint you get if you try to swim without it…

I added in/out. :). Thanks again.