Wednesday, September 25, 2013

bitbox updates

The Jump game has made progress : coins to collect (and lure you into places where you shouldn't go >:-D ), sounds (not very happy with some of them but it's working) and extra score handling. Game begins to be interesting. Now, level design !

I've also found that the USB port I've used is not the one that is used by the bootloader (duh). So, no upload by dfu for this one unless some fine soldering is done ...

I started to think about bitbox rev2 : getting rid of the bulky minidin to replace it with USB OTG (I've still to figure out if a kernel can work with it sufficiently reliably), getting stereo sound, 15bits colors(?), a proper GPU.

OTG would be huge for using normal keyboards, mice, controllers, (maybe even MIDI) but also less standard controllers.

I'm also preparing a tutorial on making a simple game and, of course thinking about many games that could be done ...

Saturday, September 21, 2013

Bitbox repository available.

Just a quick note to say that a Bitbox github repository has been created. Not much in it now, apart from the SDL emulator (very simple), makefiles, preliminary kernel & test kernel demo. Also some articles as wiki pages. Github repo is in the links on the blog front page.

Friday, September 20, 2013

Tutorial : developing for Bitbox (the basics)


We're going over the course of this tutorial to program and build a simple program for the bitbox console on ubuntu. I'm trying it on a 13.04 Ubuntu, so adapt accordingly.

For windows, there is a small guide on the blog, you can use is in parallel with this page.

Tuesday, September 17, 2013

First bitbox simple game preview : Jump ! (video)



I programmed a simple, very bare tile/sprite engine+game to test everything : JUMP !

Screenshots from the emulator



The game is a very simple vertical scrolling platformer where you only control left/right and die if you touch the base of the screen. Different platforms types make you jump higher, ... and there are other types :)

Debugging using gdb on the board itself is possible through SWD (the kernel giving you some perf data stats), but for game devel, I also developed a simple SDL-based emulator of the kernel for on-computer tests. Of course it's certainly not accurate but it can be useful for graphics and gameplay-related tuning.

Now, the game is playable - although still very rough - level needs a bit of work, there is no sound (edit : yes there is now !) , imperfect collisions, need to add some bonus, maybe particles, ...- but stays enjoyable nonetheless.

 Sample screenshots from the game, and a video (no sound).





bitbox first game prototype ! from mak apuf on Vimeo.

Bitbox news

I finally advanced a little bit on my sample game, while reworking the kernel for better image & needing to rewire a bit of the prototype (hence, the prototype qualification).

The kernel upgrade involved getting hardware sync (as did the new waha demo, jupiter and beyond - credit where it is due), which is much more reliable timing-wise that software, because even a few instructions from flash can behave very differently depending on the concurrent memory access : since the bus is used both by the DMA to transfer the current line and the CPU to prepare the next one, the availability of cached flash data instructions can vary quite a lot, and with 7 cycles latency from flash at the used speeds, it means that one cache miss implies one pixel off !

Of course, the pins I was using couldn't be driven directly by hardware, however I found a combination of Timers, DMA channels, pins ... (I'll try to explain the kernel in a future blog post) that implied only one pin change, h-sync.

So I went away and soldered a tiny wire directly on the new pin of the

LQFP64 chip to the vsync VGA output (I'm quite proud to have managed that with my firestick iron), and cut the original pcb trace.

Having done that, the VGA is now much more stable, and can achieve 640x480x60fps @ 4096 colors now without distortion.

Again, the controller is a snes compatible gamepad with the replaced with a ps2 mini din plug (useful to connect a keyboard).

The kernel exposes the following main elements for the graphics (as a C library) :
  • a game_init call back : initialize everything on your game
  • a game_frame callback : do what is needed every frame, like getting user input, moving sprites x/y/frame , .... , using the global integer "frame".
  • the gamepad is simply a global variable "gamepad1", read as a uint16 with 1 bit for each button.
  • a draw_buffer of 640 uint16 pixels and a "line" int to know which line it is (from 0 to 479)
  • a game_line callback : in this callback, you should draw each line (every frame) by blitting your screen line. So given a line number (from 0 to 479 and a ptr to a bunch of 16bit unsigned data, you have ~5k cycles to blit your graphics.


You can blit however you want, do what you want in 5k cycles per line : from aligned memsets (2 pixels at a time, word by word transfers, very quick) to full antialiased, rotozoomed, alpha blurred sprites (very expensive - tiny sprites !) : you do it & tune it (that's part of the fun) !

Of course, building a library / engine that you can reuse & tune from game to game is useful, but sometimes, the ad-hoc just blit it (tm) engine is simpler !

I then made a sample game, which I'll talk about in a next entry.

Wednesday, September 11, 2013

Bitbox early prototype schematics

By popular request (or not), I'm posting this schematics of the console, as CC by-sa license.

There is already quite a list of errata, so expect a rev2 of the board corresponding better to what I have now, after having pcb traces cut, Boot0/1 resistors added (still learning !),  tiny wires soldered directly on lqfp pins ... But, that is the basis I have been working on. I will make another, better revision for sure (yeah, right, promises).