Gamedev Like it's 1977: CHIP-8

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Gamedev Like it's 1977: CHIP-8

«‹›8 »

taqueso: Mar 8, 2004

Dr. Stab posted:

I saw this thread was bumped so I had to make a program.

Like all good programs, it's a modified version of the sample person program

http://johnearnest.github.io/Octo/index.html?gist=6a3642baee4a53f8c6b2484eaa0fd3df

WASD - move cursor
V - draw
C - erase
1 2 3 - choose brush
Z X - choose layer

Your sample picture doesn't do this justice. Nice job.

# ? Jun 13, 2016 03:18

Adbot: ADBOT LOVES YOU

# ? Apr 25, 2024 23:46

Internet Janitor: May 17, 2008; "That isn't the appropriate trash receptacle."

Nice, Dr. Stab!

I'm really glad I wrote the new pre-populated sprite movement demo; it's clear from the results of Octojam that providing a starting example with all the elements of a simple game- a movable sprite, framerate control, randomness, some helpful aliases- has a huge impact on usability for beginners. The older demo program didn't provide a good framework for tweaking and experimenting.

# ? Jun 13, 2016 04:37

toiletbrush: May 17, 2010

Was a miserable rainy Sunday yesterday so I wrote yet another Chip-8 intepreter. Was a really fun excercise, although I spent at least 2 hours trying to figure out why the Trip8 demo ran so glitchily, until I looked it up on Youtube and saw that was just how it ran. On the upside tho I wrote quite a nice debugger/trace class!

All the games you folks have made are seriously impressive, as is Octo...

# ? Jun 13, 2016 11:33

taqueso: Mar 8, 2004

proof of concept:

# ? Jun 15, 2016 06:35

taqueso: Mar 8, 2004

Here are some multiply routines I wrote, maybe they will be useful to someone else.

https://johnearnest.github.io/Octo/index.html?gist=3a3020a531951c5964ebc5741a172596
https://github.com/jdeeny/chip8-multiply

# ? Jun 15, 2016 07:39

3D Megadoodoo: Nov 25, 2010

taqueso posted:

proof of concept:

Piss: The game looking good! :mmmhmm:

# ? Jun 15, 2016 13:02

taqueso: Mar 8, 2004

taqueso posted:

Here are some multiply routines I wrote, maybe they will be useful to someone else.

https://johnearnest.github.io/Octo/index.html?gist=3a3020a531951c5964ebc5741a172596
https://github.com/jdeeny/chip8-multiply

Now with 16-bit multiply:

https://johnearnest.github.io/Octo/index.html?gist=ee560a92af35eed00cc74aa5dfca94cd

# ? Jun 16, 2016 04:57

Centripetal Horse: Nov 22, 2009; Fuck money, get GBS

This could have bought you a half a tank of gas, lmfao -
Love, gromdul

taqueso posted:

proof of concept:

Please tell me this is going to be Scorched Earth: CHIP-8 Edition.

# ? Jun 17, 2016 01:42

Quaternion Cat: Feb 19, 2011; Affeline Space

Centripetal Horse posted:

Please tell me this is going to be Scorched Earth: CHIP-8 Edition.

So, uuhhhhh, think I ought to link you to one of the submissions for octojam II: http://octojam.com/octojam-ii/games/t8nks

# ? Jun 17, 2016 02:14

3D Megadoodoo: Nov 25, 2010

Mastigophoran posted:

So, uuhhhhh, think I ought to link you to one of the submissions for octojam II: http://octojam.com/octojam-ii/games/t8nks

This is very nice.

# ? Jun 17, 2016 02:24

Centripetal Horse: Nov 22, 2009; Fuck money, get GBS

This could have bought you a half a tank of gas, lmfao -
Love, gromdul

Mastigophoran posted:

So, uuhhhhh, think I ought to link you to one of the submissions for octojam II: http://octojam.com/octojam-ii/games/t8nks

You were right to do that.

# ? Jun 17, 2016 04:52

taqueso: Mar 8, 2004

Centripetal Horse posted:

Please tell me this is going to be Scorched Earth: CHIP-8 Edition.

Yeah, that was the idea.

Mastigophoran posted:

So, uuhhhhh, think I ought to link you to one of the submissions for octojam II: http://octojam.com/octojam-ii/games/t8nks

That is indeed pretty nice, really polished.

# ? Jun 17, 2016 06:21

Quaternion Cat: Feb 19, 2011; Affeline Space

taqueso posted:

Yeah, that was the idea.

Aw man, hope that I didn't just rain on your parade. IIRC both T8nks and Octopeg (the latter of which I made) only support at most a single pixel of movement per projectile per frame, so, they kinda each have their limitations which could be overcome with a more focussed development.

# ? Jun 17, 2016 22:07

taqueso: Mar 8, 2004

Mastigophoran posted:

Aw man, hope that I didn't just rain on your parade. IIRC both T8nks and Octopeg (the latter of which I made) only support at most a single pixel of movement per projectile per frame, so, they kinda each have their limitations which could be overcome with a more focussed development.

First off, Octopeg is really, really good. The motion of the ball feels 'right'. I want it to have some audio, then it would be pretty much perfect and could have been a hit game in 1982. Way better than Popcorn!.* I need to check out the octopeg source more later.

I hadn't really looked through the jam site before now, there is a lot of cool projects there. I did look at the t8nks source a bit and my trajectory method seems to be more physics based than their what-works-nicely-in-8bit method. I will admit that when I saw their intro graphic I was a bit dejected because it looks drat good and so much better than my programmer art.

No worries about raining on anything, I just thought that a projectile game would be somewhat hard to make and satisfyingly challenging. I still haven't gotten things to work out nicely without overflows and keeping the precision I want (you can see the jitter in the sample gif).

* I just realized I've only played Popcorn! on a black and white TV. I didn't know it had color.

# ? Jun 17, 2016 23:00

Dr. Stab: Sep 12, 2010; 👨🏻‍⚕️🩺🔪🙀😱🙀

The t8nks intro is a photograph of a tank downsampled to 4 colors.

Also, the physics are as physically based as most games. It's adding acceleration to velocity and velocity to position once per tick.

It's not a smooth curve, but it's good enough for games of all sorts, not just 8 bit ones.

What you're doing looks very different and I'm interested to learn how it works.

# ? Jun 17, 2016 23:32

taqueso: Mar 8, 2004

I'm solving equations approximating a projectile's trajectory (like you would use in high-school physics class) for x and y each frame and incrementing a fixed-point time value.

# ? Jun 17, 2016 23:46

Quaternion Cat: Feb 19, 2011; Affeline Space

taqueso posted:

I'm solving equations approximating a projectile's trajectory (like you would use in high-school physics class) for x and y each frame and incrementing a fixed-point time value.

Riiiight, hence the multiplication... that's actually really cool! Using the suvat equations of motion could allow for very specific modelling of a projectile, such as (off of the top of my head) mixed magnification levels, overcoming 1 px per frame maximum movement speed, and rewindability/replayability.

edit: also slow motion

Quaternion Cat fucked around with this message at 02:33 on Jun 18, 2016

# ? Jun 18, 2016 02:26

Centripetal Horse: Nov 22, 2009; Fuck money, get GBS

This could have bought you a half a tank of gas, lmfao -
Love, gromdul

This isn't CHIP-8-related, but I feel like this is the right crowd for it: http://asma.atari.org/asmadb/search.php?q1=2&q2=&q4=1&q3=2

# ? Jun 18, 2016 03:31

ahmeni: May 1, 2005; It's one continuous form where hardware and software function in perfect unison, creating a new generation of iPhone that's better by any measure.; Grimey Drawer

IJ told me to post this here. Been working on an Octo8 headless preview renderer. It's super hacky at the moment but it spins up the compiler/emulator and dumps a ton of PNG frames out which I scoop together with ffmpeg, scale to glorious HD and convert to a gif:

The internals of the emulator are definitely fun to play with and I'd like to scrape ffmpeg out of the picture to a pure JS implementation.

# ? Jul 12, 2016 08:47

taqueso: Mar 8, 2004

I was wondering if anyone had determined the execution time for CHIP-8 instructions on the COSMAC VIP. I couldn't find that, but I realized I could count instructions* in the ROM to find out. I stumbled upon this annotated disassembly of the ROM and figured I should post it:

http://laurencescotford.co.uk/wp-content/uploads/2013/08/CHIP-8-Interpreter-Disassembly.pdf

Could also be used to decide on the 'correct' behavior for instructions with quirks.

* It would require counting cycles, some RCA 1802 operations take longer than others.

taqueso fucked around with this message at 17:37 on Jul 14, 2016

# ? Jul 14, 2016 17:33

Internet Janitor: May 17, 2008; "That isn't the appropriate trash receptacle."

So far when there's been a behavior in question I've used empirical tests with Emma02.

In the near-ish future there may be a new source of insight available for the behavior of the original SCHIP interpreter, but I won't spill the beans on that just yet.

# ? Jul 14, 2016 21:51

Internet Janitor: May 17, 2008; "That isn't the appropriate trash receptacle."

My associates and I have begun doing some reverse engineering and testing with SCHIP, the Chip8 interpreter for the HP-48 series of graphing calculators which gave us SuperChip extended instructions like large sprites and scroll instructions.

As I've already established in a number of my rants, SCHIP introduced some regrettable confusion regarding the behavior of the shift and memory load/store instructions which have plagued emulation compatibility ever since. However, this new research reveals previously unknown divergent behaviors. SCHIP 1.1 is the canonical release of the interpreter, and we have managed to dig up binaries for 1.0 as well as CHIP48, an older basic Chip8 interpreter which was modified to create SCHIP. The older versions also have assembly source available, so we can more easily identify the sources of problems. Time to dig up your HP Saturn 1LT8 datasheets!

Firstly, jump0. This instruction was extremely uncommon before Octo, appearing in virtually none of the ROMs available at the time CHIP48 was written. The implementation:

code:

ib:	; parametric jump to NNN+V0
	call.3	varpd0
	call.3	nnnc
	clr.a	a
	move.b	@d0,a
	add.a	a,c
	move.a	c,r3	; assign to pc
	retclrc

Unfortunately, this doesn't work as intended. Through painful experimentation we determined that jump0 in SCHIP uses the high 4 bits of the target address to determine which register to inspect for the offset. Looking through the code, it appears the author had a typo and called the wrong subroutine:

code:

; varpd0 - get pointer to variable to d0
; 
; In:	d1 points to nibble containing variable number
; Out:	d0 points to variable
; Uses: a,c
varpd0:
	clr.a 	c
	move.p	@d1,c	; get nibble with variable number
cvarpd0:
	add.a	c,c	; convert bytes to nibbles
	move.a	r4,a
	add.a	a,c
	move.a	c,d0
	ret

; var0pd0 -- load d0 with pointer to V0
;
; In:	none
; Out:	d0 points to variable 0
; Uses: a,c
var0pd0:
	clr.a 	c
	move.p1	#0,c
	jump.3	cvarpd0

This evidence suggests this instruction was never tested in CHIP48 and the bug was inherited in subsequent emulators.

On a more straightforward note, sprite drawing. SCHIP does not wrap the pixels of a sprite which partially overlaps the edges of the screen. Rather, these pixels are clipped. On the surface this seems to be an intentional choice rather than a mistake. Perhaps the author was just guessing as to how CHIP8 should behave in this situation, or perhaps wrapping pixels would have been more computationally intensive and slowed down the interpreter.

Octo now includes quirks mode flags to enable both of these behaviors for the purposes of experimentation and interoperability. Stay tuned for more SCHIP details!

# ? Jul 23, 2016 19:32

Fiduciary: Jan 5, 2009

taqueso posted:

Now with 16-bit multiply:

https://johnearnest.github.io/Octo/index.html?gist=ee560a92af35eed00cc74aa5dfca94cd

Very nice, and interesting approach.

I was working on a set of 16 bit operations for Octo some time last year. but I never got so far as any kind of visual demonstration. But who, really, needs a good excuse to write basic math and logic operators in assembly?

Anyway, here it is http://johnearnest.github.io/Octo/index.html?gist=56ab7aa02a1633e095d736d324605a34

Fiduciary fucked around with this message at 05:42 on Jul 25, 2016

# ? Jul 25, 2016 05:34

Tann: Apr 1, 2009

Internet Janitor posted:

Stay tuned for more SCHIP details!

Thanks for writing this interesting post! Octojam is soon!!!

# ? Jul 25, 2016 16:04

Internet Janitor: May 17, 2008; "That isn't the appropriate trash receptacle."

Let's continue our exploration of SCHIP foibles!

Chip8 includes a built-in hexadecimal font, which Octo allows you to access via i := hex vx. SuperChip, with its eye-blistering 128x64 pixel display mode, needed bigger numbers, so it supplied a larger font. Nearly every SuperChip interpreter in the wild today supports this feature, but there's one problem- on the HP it's not a hex font, it's just 0-9:

code:

; 8x10 pixel font patterns (only 10)
hexf810:
	dat.20 #3C7EC3C3C3C3C3C37E3C  ;0
	dat.20 #3C181818181818583818  ;1
	dat.20 #FFFF6030180C06C37F3E  ;2
	dat.20 #3C7EC3030E0E03C37E3C  ;3
	dat.20 #0606FFFFC666361E0E06  ;4
	dat.20 #3C7EC303FEFCC0C0FFFF  ;5
	dat.20 #3C7EC3C3FEFCC0C07C3E  ;6
	dat.20 #60606030180C0603FFFF  ;7
	dat.20 #3C7EC3C37E7EC3C37E3C  ;8
	dat.20 #7C3E03033F7FC3C37E3C  ;9

While we're discussing fonts, let's consider the memory map. On a COSMAC VIP, addresses 0x000-0x200 were occupied by the Chip8 interpreter, and the hex font was stored in high memory as part of the VIP ROM. More modern Chip8 interpreters don't have to cram themselves into that 512 byte space, so they typically store the font(s) there, along with some empty space. SCHIP does the same. One wrinkle worth noting is that unoccupied memory (everything in the 0x000-0xFFF address space except your program and the font data) is uninitialized in SCHIP, and may contain essentially random bytes.

Experimentally, we determined that loading a rom which consumes the full 0x200-0xFFF range would crash the interpreter. Shave a byte off? No problems. Can you see the bug?

code:

	move.a	@d1,a            ; get the object length
	sub.a	5,a              ; subtract length of length
	move.p5	#01c00,c         ; this is #1000 - #0200 bytes in nibbles
	brgt.a	c,a,nottoolong
doerror:
	jump.3	errexit          ; string will not fit in 4 k
nottoolong:
	add.a	5,d1             ; point to the object itself
	call.3	copynibbles

We also noticed that if i is incremented past 0xFFF the interpreter crashes. (On the VIP, the i register had no problem marching off into the full 16-bit address space of the machine- it was just mostly unpopulated and not particularly useful.) The routine responsible for this instruction does check for overflow:

code:

ifx1e: ; increment I by VX
	clr.a	c
	move.b	@d0,c
	move.a	r0,a             ; get old I
	add.x	c,a              ; increment, modifying only 3 low nibbles
	retcs                    ; it wrapped around #1000
	move.a	a,r0             ; save new I
	retclrc

And if we return from an instruction's implementation with the carry flag set, we bail out of the interpreter:

code:

dispatch:
	; dispatch a CHIP-8 instruction
...
	push.a	c                 ; push return address on stack
	jump.a	a                 ; jump to instruction routine
retloc:
	brcs	errexit           ; if carry is set, an error has occurred
	jump.3	nextinstr

errexit:	
	move.w	r3,c              ; get the current CHIP-8 PC value
	move.w	c,r0              ; move to R0
	call.a	push_r0_shortint  ; ROM routine: push short integer from R0
	                          ; (this also restores saved d0, d1, b, d)
	call.a	save_rpl_regs     ; save the registers again (redundant?)
	jump.3	exit

It looks like this behavior was intentional, if not particularly helpful.

In summary, for best compatibility with SCHIP 1.1:

Avoid using bighex characters greater than 9.
Do not produce ROMs which use the last byte of RAM. (Reading and writing it during execution is fine.)
Do not allow i to increment past 0xFFF.

# ? Jul 27, 2016 03:46

Buffis: Apr 29, 2006; I paid for this; Fallen Rib

Instead of polishing my game for awful jams, I golfed down a flappy bird game to 87 bytes.
http://johnearnest.github.io/Octo/index.html?gist=fcd9c1ca2e0365f423b6ad56225377f5 (fl8ppy mouse)
Jump with W

First game using the clipping quirks mode perhaps?

Possible to get it down to 64 bytes and running it with flickering on 7cycles without delay loop and using builtins as sprites:
http://johnearnest.github.io/Octo/index.html?gist=66659f6bf7a8a422043a90f4c3c41cb9

Buffis fucked around with this message at 21:56 on Jul 27, 2016

# ? Jul 27, 2016 20:26

Dr. Stab: Sep 12, 2010; 👨🏻‍⚕️🩺🔪🙀😱🙀

48 bytes

http://johnearnest.github.io/Octo/index.html?gist=ec9f2c2303a1144aafcca587725e06d7

44 bytes, no quirks mode

http://johnearnest.github.io/Octo/index.html?gist=9952e56f1b163bc0ac1b6e739531c76f

40 seems easily doable, but I'll leave that for someone else or another time.

# ? Jul 28, 2016 09:25

taqueso: Mar 8, 2004

Fiduciary posted:

Very nice, and interesting approach.

I was working on a set of 16 bit operations for Octo some time last year. but I never got so far as any kind of visual demonstration. But who, really, needs a good excuse to write basic math and logic operators in assembly?

Anyway, here it is http://johnearnest.github.io/Octo/index.html?gist=56ab7aa02a1633e095d736d324605a34

Very nice job. Your implementation is quite a bit faster than mine (293 cycles vs 568 cycles). I just tried inlining the 4-bit shifts in my version and got it down to 473 cycles. I considered doing shift-add but my intuition was telling me it would be slower.

# ? Jul 28, 2016 15:53

taqueso: Mar 8, 2004

Internet Janitor posted:

interpreter in the wild today supports this feature, but there's one problem- on the HP it's not a hex font, it's just 0-9:

Crazy. I wonder why they would have only included 0-9? Seems impossible for the author to not know the original Chip8 font has 16 entries.

quote:

In summary, for best compatibility with SCHIP 1.1:

Avoid using bighex characters greater than 9.

Do not produce ROMs which use the last byte of RAM. (Reading and writing it during execution is fine.)

Do not allow i to increment past 0xFFF.

Thank you, that is nice to know.

# ? Jul 28, 2016 16:00

Buffis: Apr 29, 2006; I paid for this; Fallen Rib

Dr. Stab posted:

48 bytes

http://johnearnest.github.io/Octo/index.html?gist=ec9f2c2303a1144aafcca587725e06d7

44 bytes, no quirks mode

http://johnearnest.github.io/Octo/index.html?gist=9952e56f1b163bc0ac1b6e739531c76f

40 seems easily doable, but I'll leave that for someone else or another time.

Shaving off 2 bytes from v0 usage was simple, but had to take some sprite liberties to get to 40. The game is now a flappy plane navigating a cavern of letters.
It's like frog fractions but for writing.

http://johnearnest.github.io/Octo/index.html?gist=a82d46b6cbad52bbf1eea89d1cae5e66

Getting it down to 37 bytes is doable if changing the jump button to E and having one of the openings be a bit iffy.
http://johnearnest.github.io/Octo/index.html?gist=1bdbe2e0a7d4df8f44ead0b4ea2198bd

Buffis fucked around with this message at 20:53 on Jul 28, 2016

# ? Jul 28, 2016 17:45

Dr. Stab: Sep 12, 2010; 👨🏻‍⚕️🩺🔪🙀😱🙀

Oh, I missed the v0 incrementing thing. That should have been obvious.

Here's 35 bytes. It's shaving the 4 bytes I was thinking of, plus another one I just found now. press e to fly.

http://johnearnest.github.io/Octo/index.html?gist=20292b2d6200aa515ddf43631605c816

# ? Jul 28, 2016 20:14

Buffis: Apr 29, 2006; I paid for this; Fallen Rib

Dr. Stab posted:

Oh, I missed the v0 incrementing thing. That should have been obvious.

Here's 35 bytes. It's shaving the 4 bytes I was thinking of, plus another one I just found now. press e to fly.

http://johnearnest.github.io/Octo/index.html?gist=20292b2d6200aa515ddf43631605c816

gently caress. I had this page open and was golfing without refreshing it and got it down to 37 (I also figured out the thing with using the 06 from the jump for the button and so on), but you still beat me by 2 bytes

I updated my message above to include my thing.

edit: Haha, using 0x12 for a jump to main due to zero padding is genius.

Buffis fucked around with this message at 21:00 on Jul 28, 2016

# ? Jul 28, 2016 20:55

Internet Janitor: May 17, 2008; "That isn't the appropriate trash receptacle."

taqueso posted:

Thank you, that is nice to know.

I'm working on "A Pedantic Guide to Chip8 Compatibility", which will include this content and more in an easier to reference form. Not sure how long it'll take me to get around to finishing, but I will have it available before this year's Octojam for reasons...

# ? Jul 29, 2016 05:22

Buffis: Apr 29, 2006; I paid for this; Fallen Rib

Dr. Stab posted:

Oh, I missed the v0 incrementing thing. That should have been obvious.

Here's 35 bytes. It's shaving the 4 bytes I was thinking of, plus another one I just found now. press e to fly.

http://johnearnest.github.io/Octo/index.html?gist=20292b2d6200aa515ddf43631605c816

33 bytes (drawing one pipe per cycle)
http://johnearnest.github.io/Octo/index.html?gist=b372df719fecfc82e7f96315078b69a2

Removing v4 += 16 shaves off two more bytes, but then the pipe openings are always the same.

Not seeing any way to golf this further without messing up the gameplay.

# ? Jul 29, 2016 08:11

Lime: Jul 20, 2004

31 bytes based off Buffis's one pipe per iteration
http://johnearnest.github.io/Octo/index.html?gist=449ca18529419160d9bae705bc7d5538

I changed how the physics work: instead of increasing velocity every iteration and then dividing by 4 before adding to position, I overflow a different register roughly once every 4 iterations and then simply add the overflow flag vF to velocity and velocity directly to position. This eliminates one shift-right, saving 2 bytes. The old bounce velocity of -6 doesn't divide by 4 so I had to round up for this new scheme. This makes the bounce roughly the same as using -8 instead of -6 in previous versions. This maybe doesn't feel as good to play and it's harder to break out of the initial death loop, so it's arguable that this qualifies.

EDIT: Here's an especially lovely 30 bytes version. Use X to flap:
http://johnearnest.github.io/Octo/index.html?gist=2536074e89cefada3523bda78a5340c5

By using the first half of the code to initialize all the registers and the second half for graphics, I only have to set i once. I lost a byte from rearranging the loop so I could get a 0x3f in a register.

EDIT: I have to stop. 29 bytes, nigh unplayable: http://johnearnest.github.io/Octo/index.html?gist=3d9790399e1fd973ca4b45ed85f054bb

I got the padding as address trick back by using v3 for pillar sprite y to make the 0x3f I needed.

Lime fucked around with this message at 07:56 on Jul 30, 2016

# ? Jul 30, 2016 00:53

Buffis: Apr 29, 2006; I paid for this; Fallen Rib

Lime posted:

31 bytes based off Buffis's one pipe per iteration
http://johnearnest.github.io/Octo/index.html?gist=449ca18529419160d9bae705bc7d5538

I changed how the physics work: instead of increasing velocity every iteration and then dividing by 4 before adding to position, I overflow a different register roughly once every 4 iterations and then simply add the overflow flag vF to velocity and velocity directly to position. This eliminates one shift-right, saving 2 bytes. The old bounce velocity of -6 doesn't divide by 4 so I had to round up for this new scheme. This makes the bounce roughly the same as using -8 instead of -6 in previous versions. This maybe doesn't feel as good to play and it's harder to break out of the initial death loop, so it's arguable that this qualifies.

I mean, this physics is sortof unplayable, and if that's ok you can just remove one shift from the acceleration of the code I pasted and get this 31 byte one as well.
http://johnearnest.github.io/Octo/index.html?gist=9560fb7e7c4d7c4ca82173121e5cb5ba

Getting below 33 bytes while being able to play this thing seems somewhat hard. The 29 byte one is fun though.

# ? Jul 30, 2016 11:29

Dr. Stab: Sep 12, 2010; 👨🏻‍⚕️🩺🔪🙀😱🙀

26 bytes. x flaps. game doesn't reset on a game over.

This is a pretty bad game. I think I'd rather just type a couple more bytes.

http://johnearnest.github.io/Octo/index.html?gist=2d130a9fd75da183196e3aadbba3f81c

also, unlike the 29 byte version, this one probably won't do so hot on hardware.

# ? Aug 1, 2016 16:43

Buffis: Apr 29, 2006; I paid for this; Fallen Rib

Played around a bit with pseudorandomness and superchip scrolling.

http://johnearnest.github.io/Octo/index.html?gist=11487e18e55d56b08af43b60f871a8d0

Steer with W and S

# ? Aug 6, 2016 22:14

Buffis: Apr 29, 2006; I paid for this; Fallen Rib

Is Octo-ber happening this year?
It's pretty quiet considering it's like a week til October.

# ? Sep 24, 2016 20:08

Adbot: ADBOT LOVES YOU

# ? Apr 25, 2024 23:46

Internet Janitor: May 17, 2008; "That isn't the appropriate trash receptacle."

It sure is!

We're still sprucing things up, improving documentation and adding some new features, but the site is up!

http://www.awfuljams.com/octojam-iii

Please spread the word to your friends, family, coworkers and other contacts.

# ? Sep 25, 2016 15:29

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Gamedev Like it's 1977: CHIP-8

«‹›8 »