Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Timendus

50
Posts
3
Topics
9
Followers
A member registered Sep 27, 2020 · View creator page →

Creator of

Recent community posts

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 :)

Heh, you're absolutely right :) Silly me.

(2 edits)

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

I was just working on my submission and being busy with life  ;)

Oh, I just replied here :P https://itch.io/jam/octojam-9/rate/1772352 I am at least equally surprised right now! It feels like we would probably have gotten even further by working together :')

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 :)

Hey, you managed to get an Octojam entry out after all! Super cool 😄 Two musical internet memes in one Octojam?!

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.

Well, technically, the jam is about making CHIP-8, SCHIP or XO-CHIP games. The tooling is unrestricted, but the end result should conform to one of those three (and thus run in Octo) ;)

I'll be working on a cool collaboration with Kouzeru! Hope I manage to pull off my part. No spoilers though 😄

Yes, I had the same idea. CHIP-8 could probably do with a good fixed-point math library more than it could do with graphics primitives :)

Nope.

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!

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 :)

https://github.com/Timendus/3d-viper-maze#readme

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

https://timendus.itch.io/3d-viper-maze

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
  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.

This works:

: 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..?