Integrated game/music/sprite editor for the bitbox

[ible]

it's been fun working on this small physics engine, which should be a nice stepping stone for the physics engine in the 16 editor...

well, my wife was willing to play a game or two, so here's a video of tetris on the bitbox. bonus points to whoever can figure out the riddle -- what's missing here from a normal tetris game?

 

[TheOldOne]

##
 ##

That is the piece missing!

 

[ible]

yup, i work on two computers, and forgot to do a git pull on that one before building the code...

though apparently i also need to check for some rotation collisions...

[edit] nevermind, easy fix...

 

[___]

haha this is so cool. when you posted in the pico8 thread, that the editor was crappy because it was closed source i was like "ladida, you come up with an open source solution if you want one" and boom there it is. awesome. very nice work indeed!

EDIT: oops, that wasn't even you ible. still awesome.

 

[ible]

haha, thanks for the encouragement! i did indeed think that sentiment, even if i didn't write it...

right now i'm putzing around with some ideas for a 3d-printed bitbox case...

 

[ible]

got around to butchering the tetris theme song (theme A to be precise):

if anyone wants to hack around on making any of the other theme songs, or making the tetris theme A your own style, here's a release:
https://github.com/lowagner/bitbox-tetris/releases/tag/v0.8-beta
if you have ubuntu 16.04, you may be able to run the emulator executable, otherwise you could build from source (if you also get the bitbox SDK at https://github.com/makapuf/bitbox).

 

[ible]

updated the chiptune commands a bit:
https://github.com/makapuf/bitbox/wiki/Palette-16-Tile-Editor#instrument-editor
https://github.com/makapuf/bitbox/wiki/Palette-16-Tile-Editor#track-editor

RANDOMIZE works a bit differently now: instead of specifying which command to randomize, you are forced to randomize the next command in the list. but now, you can use the parameter of the RANDOMIZE command to choose which random values the next command could get. with RANDOMIZE 0, the next command can get any value (0-15), with RANDOMIZE 8, you get some other stuff (like 0-3), etc.

i did this to free up a command for the track mode (verse editor), since the track has 32 command slots, and RANDOMIZE with a slot as its argument needed to be take up two commands (RANDOMIZE0 and RANDOMIZE1) to cover all slots (0-15, 16-31). now, we just need one RANDOMIZE command, and it always affects the next command slot. as a perk, it also allows you more fine control over what random values your commands can take on, so you can fix a rhythm to be a multiple of a beat (0,4,8,12 for example), or control whereabouts a random note will lie.

with a free command, i added in a track JUMP command. but since i only had one free command, i forced the JUMP to go to an even command slot index (0, 2, 4, ..., 30). (this works fine anyways, you can always throw in a useless/duplicate command to align things). i was missing JUMP for repetitive tracks, where it's just a bass line hitting the same note over and over, so it's nice to have it.

adapting the chiptune engine (from the bitbox/LFT stuff) has been fun. a while ago, i was writing a FORTH-like language, and that prepared me for this part of the project. it also feels a bit more useful, to make music instead of a low-level programming language / calculator . but who knows, that's maybe still in the cards for a future project.

 

[ible]

the results of the first poll are in! it was a close race, but it has been decided to name the program 16.

honorable mentions are "nibbles" and "shift4"; the full results are in the spoiler. we had a great turnout, almost.

Spoiler

What is a good name for this program?
https://pyra-handheld.com/boards/th...-sprite-editor-for-the-bitbox.77607/poll/edit

1. 16tiles - (current placeholder name)
   0 vote(s)
2. 16g - (g being 16 in extended "hexadecimal")
   0 vote(s)
3. 16
   1 vote(s)
4. 4shift - (>>4 or <<4 also being common)
   0 vote(s)
5. shift4 - (see above)
   1 vote(s)
6. nibbles - (a half byte)
   1 vote(s)
7. and15 - (&15 being a common operation)
   0 vote(s)

this means that the new repository is located here:
https://github.com/lowagner/bitbox-16

also, got an edit screen for the sprite patterns so you can modify them, though the internal logic isn't implemented yet:

(don't pay any heed to the current commands, they are mostly random, and wouldn't do anything intelligent for a sprite.)

 

[ible]

was working a bit on the case, see here for some variations on a theme:
https://pyra-handheld.com/boards/threads/3d-printers-are-all-the-rage.77819/#post-1391328

here's with the lid, and everything compacted together. interested to see how it turns out, though i'll have to wait for a 3d printer...

buttons i decided to keep vertical, and just stick a long piece of plastic/rubber down a slot to get at them. you can see them either side of the lid (darker).

 

[matej]

Pretty cool! Going to buy BitBox!

 

[ible]

randomly working on real life programs, but also a "16 bit" minecraft. (where your blocks can each have different shapes, and you can freely adjust the colors.)



in the first screenshot you can clearly see that the block in the wire-frame cursor box is less than a full block tall. there are also a few other shapes at the moment.

https://github.com/lowagner/home

the idea is, if it will look nice, to be able to put sloping roofs on houses, so it'd be like a mini architecture program. also trying to keep the CPU usage low, but the GPU is doing most of the heavy lifting .

will get back to the bitbox eventually... but it's also nice to code in "real" 3d sometimes

[edit]
oops, should have tried to get the full gamut of colors (though there are other shades with less saturation, and differing brightness -- i use HSV in a shader to adjust the colors):

 

[ible]

some updates on the 16 front -- now the rudiments of sprite patterns are there, though there is much more to implement:
surely but slowly we'll get there...

 

[ible]

i've added a few more useful commands to the sprite pattern editor, now it accepts player input:

though we don't have projectile firing yet, you can jump and run and walk around... (and you can do one of those things as a "fire" command, if desired.) nice that my first pattern i create does something interesting, but it goes downhill from there

the video is more like a tutorial, let me know if that's a useful format for content, and what you might like to see talked about.

 

[makapuf]

Very cool of course.
Do you think a mouse could be useful to navigate the editors ?
left click on an item to +1/-1 values, right click to copy/left click to paste colors/ tiles.

 

[ible]

it could work that way, but i wanted to make the editor work with just one controller (and not a mouse + keyboard type thing), though one could make the editing much more powerful if adding in more stuff...

i guess the idea is to just quickly iterate editing and playing, so you don't have to plug/unplug controllers.

 

[makapuf]

Well the bitbox should have two usb ports but you're right, identity is more important than functionality here. We could use a raspberry.

 

[ible]

right. i guess i was thinking about 2 player games (which are possible, though i haven't tested it yet), which should also avoid plugging/unplugging. but that's probably a less frequent case... at any rate, i'm finding it fairly simple to use just a controller, so i won't be adding the mouse functionality (though i wouldn't stop anyone who would want to add it), at least not yet.

not sure what you're saying about a raspberry? (pi?)

let me know if you think the sprite drawing algorithm can be improved... i think it's pretty good since we have to consider "invisible" colors, but open to suggestions.
https://github.com/lowagner/bitbox-16/blob/master/sprites.c#L889-L981
[doublepost=1476220037,1476208848][/doublepost]fixed the ghosting control issue (vertical motion) on the last commit:


song is a remake of the continuum intro within the game editor .

 

[makapuf]

for the raspberry, it was kind of (bad) meta : if we want to remove all limitations a raspberry pi was the answer, on that project I think limitations are also what adds character to the projects.

for blit speed, some ideas (but as always, you can't improve what you don't measure : profile first)

- group the readings (readings are done on a 32bit bus. so when you read a u8 you already have 8 source pixels ready in a register)
- on this group of pixels, check if all pixels are opaque (may be the common case ? if not, adjust accordingly ?) -> https://graphics.stanford.edu/~seander/bithacks.html#ZeroInWord to determine if a word - so a group a 8 pixels- has a null nibble ?)
- build a 256 u32 word table - two pixels palette for faster palette lookups if no transparency in those pixels.
- group the writings per words (2 pixels out by two)
- consider the buffer is larger than the screen so blit anyway for smaller values (avoiding a common check for all objects)
or even : blit fast 8 pixels and write back transparent ones if any.
[doublepost=1476272059,1476267887][/doublepost]I had some other ideas :
- blit everything in a u4 buffer (1u32 = 8 u4 pixels)
since everything has the same 16c palette, render all to a 4bpp buffer and render the u4 buffer to 16bit draw buffer once at the end : no more transparency, everything is aligned, can blit , overdraws are 4x cheaper.

 

[ible]

for the raspberry, it was kind of (bad) meta : if we want to remove all limitations a raspberry pi was the answer, on that project I think limitations are also what adds character to the projects.

of course.

- group the readings (readings are done on a 32bit bus. so when you read a u8 you already have 8 source pixels ready in a register)

ok, so you read a u32, which has 32/4 = 8 pixels... the middle part of that sentence didn't make sense to me -- are you saying that when I read a u8, C compiles that automatically as reading a u32, or do i need to code that in?

- on this group of pixels, check if all pixels are opaque (may be the common case ? if not, adjust accordingly ?) -> https://graphics.stanford.edu/~seander/bithacks.html#ZeroInWord to determine if a word - so a group a 8 pixels- has a null nibble ?)

that would be interesting, but i'm afraid since i allow the "null nibble" to be any value (0-16, yes 16 if nothing is invisible...), it can't be checked against automatically. (also i don't know what the nibble version of the 0 case to be.)

- build a 256 u32 word table - two pixels palette for faster palette lookups if no transparency in those pixels.
- group the writings per words (2 pixels out by two)

this could be done together..

- consider the buffer is larger than the screen so blit anyway for smaller values (avoiding a common check for all objects)
or even : blit fast 8 pixels and write back transparent ones if any.

ok, sure, i could try this. i figured by checking i save some work on writing out pixels, but i'm only saving it for edge sprites. also didn't realize the draw_buffer was so large (1024 * 2 bytes), so that i could be a bit lazy... i suppose negative indices get written out into the display_buffer? is that bad for writing to the vga?

- blit everything in a u4 buffer (1u32 = 8 u4 pixels)
since everything has the same 16c palette, render all to a 4bpp buffer and render the u4 buffer to 16bit draw buffer once at the end : no more transparency, everything is aligned, can blit , overdraws are 4x cheaper.

oh, i had to read this a few times to understand, but now it makes a lot of sense. this sounds promising, and could be used in conjunction with the 256 u32 word table...

 

[makapuf]

are you saying that when I read a u8, C compiles that automatically as reading a u32, or do i need to code that in?

Not really, it's the processor which is fetching an u32 from memory/cache, then discarding all but the u8 when loading a byte.
so you need to explicitely tell the compiler you want a word, load it in a register and then work on parts of it.

that would be interesting, but i'm afraid since i allow the "null nibble" to be any value (0-16, yes 16 if nothing is invisible...), it can't be checked against automatically. (also i don't know what the nibble version of the 0 case to be.)

Is the null nibble specific to a sprite ? Cause if it's global, since you can change the palette, why not force it to zero and swap palette values ?

i suppose negative indices get written out into the display_buffer? is that bad for writing to the vga?

you don't know where those buffers will be placed. So I suggest we change in the next kernel that the pointer draw_buffer is buffer1+16 or buffer2+16 when reloaded.