Show HN: I'm building a game for the Nintendo GameBoy

IANAL, and yes, you can not copyright game mechanics or ideas. This is why so many clones of every game exists. Because no one owns the rights to "a tower defense".

Yes, it's all written in z80 assembly, although the GameBoy CPU really uses a mix of i8080 and z80 instructions, the mnemonics are all z80. I've also written my own assembler just recently, to have more control over the output and more easily generate debugging information: https://github.com/BonsaiDen/gbasm

Holy carp - he is writing it in assembly.

https://github.com/BonsaiDen/Tuff.gb/blob/master/src/core/co...

Nice.

Cool, came here to report the exact same bug. Twitching, and doing the down smash eventually caused me to warp through the floor and initiate an endless fall into white nothingness. [Edit] After exploring some more, the extents of completeness are more obvious. I like the design style, and the art is very evocative. In terms of gameplay, there's a lot of blind jumps that basically end in death (spike and lava rooms to lower right). While I like the quick save mechanic with the light pillars, telegraphing those rapidly changing hazards might be less frustrating. Also, is it currently possible to get to the stuff up to the left?

I got there too.

Atari Archives also has quite a good selection of old programming books for the later models.

http://www.atariarchives.org/

You got me! I enjoyed Knytt so much, and it was the game that first inspired me to make the first version of Tuff way back in 2010 :) https://github.com/BonsaiDen/Tuff/commits/master

Yeah, I wanted to mention that too. The save mechanic is very similar.

I'm a full stack Web Developer at daytime and I'd argue that I probably do speak JavaScript more fluently than I do English. So for me it really was a no brainer. The custom conversion tools needed for the graphics / map / sounds are also written in JS, so it's a bonus to have good interop with those too.

In addition to that, getting the compiler up to speed (takes < 90ms on my old core i5) was a nice exercise in getting more familiar with v8's performance analysis tools :)

Some options include: He is familiar with it, the Z80 is so simple it doesn't really matter, and someone else already wrote one in JavaScript. Lastly does it matter?

You'll probably need to do a little work to make it work. The Gameboy used a Sharp LR35902, which is kinda 8080-ish and kinda z80-ish and has some of it's own stuff as well.

It's a 16x16 screen world which wraps around, if you move to the left or right you should eventually land on a non-empty screen. The "world" is anything but finished, to be honest, it's more of a debug / feature test world than anything else at the moment :)

Here's a picture of the whole world for reference: https://dl.dropboxusercontent.com/u/2332843/tuff.map.png

Sure!

I'll start with the graphics part, since that's the easier part of the two.

Since the original GameBoy has only 4 shades of gray, all "bitmaps" are 2 bits per pixel so you can squeeze a total of 4 pixels into 1 byte, the graphics are converted from PNG files via some JavaScript routines which can be found in the convert.js file in the repository.

The GameBoy uses 8x8 pixel hardware tiles on a scrollable "background" and supports up to 40 sprites which can be either 8x8 or 8x16 pixels in size.

There are 2 tile buffers in VRAM which partly overlap and only the lower one can be used for sprites, which gives you 128, 8x8 tiles for use with sprites and 256 for use with backgrounds.

Sprites can be mirrored, so this somewhat reduces the amount of graphics needed for the player character.

In order to reduce the map data, each room uses 80 16x16 blocks which are served from a meta table in memory, where each index maps to 4 8x8 tile definitions of the block. When drawing the screen the code resolves the individual 8x8 tiles and sets their value into the current VRAM buffer for the screen (there are two, which are swapped, to minimize draw artefacts).

Since the meta table is limited to 256 16x16 blocks too (due to the fact that the map format only uses 1 byte per block tile) there is some additional pre-computation magic going on when creating the map data. Basically, the block tiles are split into 4 x 8 rows, each screen then maps onto 4 of these "rows". By then packing often uses block tiles together, you can have more details for certain rooms since they don't need to use all of the different rows available and can basically swap some of them out.

Also, all graphics and map data are additionally compressed with a custom LT Type compression routing and are decompressed on the fly. Except for player graphics, which are stored into a RAM buffer at start in order to avoid graphic glichtes when switching out the sprite tile reference indexes and the graphics at the same time.

Overall, the timing is really important since you don't have too much time during the VBlank period (yes, it emulates a vblank!)

Now as for the sound, right now I'm really just setting the sound channel register values pretty much "Per hand", meaning, that I pick some decent values (tested in some GBA sound test ROM for gameboy sound channels I found somehwere - yes the GBA still has the original GameBoys 4 channels, since it's backwards compatible).

The sound data is stored in some kind of JSON format for easier editing, all the bit field stuff is than generated at compile time and baked into the ROM.

I've also gotten a prototype of a music engine running (not yet in the repository) where you'd play pre-defined sound "patterns" on virtual channels and "mix" them down. The sound / music stuff really is a whole story of its own, especially since there are nearly no references to find, except for some old, undocumented ASM sources of some Rare Ware GameBoy ports of Banjo / Jet Force Gemini which apparently got uploaded by one of the Sound Engineers at Rare.

There are quite a few resources you can find after searching for a bit e.g http://problemkaputt.de/pandocs.htm or http://students.washington.edu/fidelp/galp/megaguides/GameBo... (the latter one being the original manual for licensed developers)

You would have to first port the ruby interpreter to the Zilog Z80 which could be a challenge because it is only an 8bit CPU!

The GBA actually has a 32 bit ARM CPU, although a very slow one (16 Mhz) so perhaps it would be possible to build a very minimal Ruby VM for that. I wonder if it would be possible to optimize by building a JIT compiler and JITing on an emulator before installing on the cartridge?

You can't :)

The people who might be able to and the people who would want to do so are mutually exclusive groups.

mruby can be compiled to embedded bytecode in a C file [1]. It might be possible to do something with that on the GBA, but the original GB is out of the question -- even the options for C are limited.

[1]: https://github.com/mruby/mruby

Which part of the process are you interested in- -executing in z80? -using the sounds? -using the graphics? -etc?

if the latter three, why not write in those languages and use an API to interface to the drivers for those peripherals?

So did I.

It's a bit hard to find, but it's all there :)

- http://gameboy.mongenel.com/dmg/gbspec.txt (html version http://problemkaputt.de/pandocs.htm#soundcontroller ) - http://www.otakunozoku.com/nintendo-gameboy-cribsheet/ - http://realboyemulator.files.wordpress.com/2013/01/gbcpuman.... - http://students.washington.edu/fidelp/galp/megaguides/GameBo... (The original Manual)

There are more, but I can't seem to find the links right now :O

You can do a wall jump or a double jump, at the moment all powerups are enable from the start since I'm missing out on the animation for collecting them an all other sorts of things. I tend to deviate from the gameplay aspects of programming and spend a lot of time doing optimizations and tooling, just recently I wrote my own assembler to cook the whole thing into the final ROM image https://github.com/BonsaiDen/gbasm

It's not only Spotify. I've had the same issue with Adium notification sounds while the game was running in Safari on OS X 10.9.

Funny, the sound became all 8-bit like, so it fitted the game quite nicely. :)

It's known issue, I've to the exact same issue here on Linux, seems to be related with their Web Audio implementation.

I had the same problem though I was playing music with Radiant Player. However, I switched my sound output from HDMI (a Vizio TV) to my MBP speakers and it went away.

I'll also submit the above as a comment on the bug report.

Works fine for me.

I ended up falling endlessly through a blank void :-\