Love the result! It runs super smooth, really gives you a feeling of control over your ship. I don't mind the hexadecimal score keeping :)
Recent community posts
A bit late to the party, but this explains the general concepts well if you want to take the calculating road:
But I too think Internet Janitor's idea of storing each digit in its own byte is probably easier to do with less code. Especially if you're just keeping score in a game and you only need to increase your large (0-9999) value by one at a time.
Something like this:
: bump-score i := score load v3 v3 += 1 if v3 == 10 begin v3 := 0 v2 += 1 if v2 == 10 begin v2 := 0 v1 += 1 if v1 == 10 begin v1 := 0 v0 += 1 end end end i := score save v3 return : show-score v5 := 0 # Coordinates to draw to v6 := 0 i := score load v3 i := bcd-buffer bcd v0 i := bcd-digit load v0 i := hex v0 sprite v5 v6 5 v5 += 5 i := bcd-buffer bcd v1 i := bcd-digit load v0 i := hex v0 sprite v5 v6 5 v5 += 5 i := bcd-buffer bcd v2 i := bcd-digit load v0 i := hex v0 sprite v5 v6 5 v5 += 5 i := bcd-buffer bcd v3 i := bcd-digit load v0 i := hex v0 sprite v5 v6 5 return : score 0 0 0 0 : bcd-buffer 0 0 : bcd-digit 0
Hahahaha what are the odds? ^_^ Love how clear your version is, I guess I traded resolution and framerate for noise? Is your source or a write-up online somewhere? Would be curious what the differences in our approach are :)
Cool! I was thinking about writing a chess game for this Octojam, but when I looked into the AI part I quickly realised that that's a bit too much for me to do in a couple of days or so. So no chess game for me this year.
I did however design these four colour hires chess pieces. Board is 64x64 pixels, squares are 8x8. So yeah, same here, if anyone feels like using these, go ahead :) An acknowledgement of my work would be appreciated, but otherwise feel free to do as you please.
IIRC it was mainly that it would be hard to implement in a sane way on systems that don't have a (full) colour display. Having four static colours allows for manual intervention, whereas having unlimited dynamic colours does not.
For example, when going to four level grayscale: if the program selects red and green with equal luminosity, how would the interpreter know how to map the colours without losing legibility? For four static predefined colours a human can intervene and configure the program to use colours that make sense.
Sounds like an interesting idea! I'm sure there are already quite a few useful snippets of code out there, maybe a fun community project could be to collect and index those somewhere. I have some in-memory masked sprite drawing routines in my entry from last year, to contribute.
Concerning graphics primitives: most people try to target the older systems, or something "spiritually compatible" with those clock speeds. As such, when you need a circle, you pre-draw a circle and store that as sprites, because computationally drawing a circle is just way too slow :D But nevertheless, having line/circle/square drawing routines is probably useful for someone targeting XO-CHIP.
Heheh, no bending the rules for me this year! ;)
But yeah, the 16 colours in Silicon8 don't require any new opcodes or changes to the spec or the interpreter. They are just a "creative interpretation" of the existing XO-CHIP opcode that selects the planes, and as such backwards compatible. I think it's a good rule of thumb to say that it should (be able to) run in Octo.
We've had some discussion about adding the ability to swap colours at runtime to the XO-CHIP spec, but IJ voted against it with some compelling reasons.
I made a thing! 😄👌🏻 With the upcoming Octojam, I thought this was the perfect moment to try to explain how to write CHIP-8 games a bit. It's probably way too long and either too basic or too advanced for most people but I thought I'd give it a try 🙈 I hope it helps some of you to get started with your project!
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!
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!
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
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 :/
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.
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! :)
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 ;)
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 loop again
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.
: main jump 0x0202 :org 0x1000 # Data here :org 0x0202 # Code here loop again
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..?