Super Crate Buino

Nice. You’ll still need a drawPixel that can do INVERT, and can probably re-write the sketch to use Arduboy2’s collide instead of that collideRectRect?

Yes, but I’ll wait until GitHub’s done disagreeing with me before I go messing around with those.

I figured out why GitHub was misbehaving.

Sure enough, it was my own fault, but it was something I did months back, if not over a year ago, so I’m not surprised it took me the best part of a day to realise what it was.

Before I make a proper repo:

  • Did you write those functions yourself?
  • If not, where are the originals, and what licences did they have?

Also I’d like to point out that you’re probably violating the LGPL because you didn’t ‘make the work’:

carry prominent notices stating that you modified it, and giving a relevant date.

But how the licence behaves in this case is a bit hard to tell because the LGPL was intended to be used with libraries, not standalone programs.
(It literally uses the word ‘library’ about half a dozen times in its licence text.
I’m not sure Mr Rodot did his research properly.)

…as mentioned above, got them from:

Which got them from:

and the drawPixel is from:

EDIT: isn’t a GitHub fork by its nature a clear notice of the original source, the modifications made, and the relevant dates?

1 Like

The exact wording of the GPL is:

The work must carry prominent notices stating that you modified it, and giving a relevant date.

What ‘the work’ actually means isn’t actually specified by the licence, but from the usage it can be inferred to mean ‘the program, in source or object form’,
and presumably does not include a GitHub repo because the GitHub repo is merely a mechanism for storing and modifying the program.

I’ve been involved in so many things today that I completely lost track.

LGPL again… bloody thing.

Couldn’t be nice and straightforward like MIT or Apache 2.0 or BSD 3-clause,
has to be some great big goliath full of weasel words and other oddities.

(If the Gamebuino’s documentation is decent I might just read the explanation of the function and write a new one from scratch.)

I haven’t actually modified drawPixel in my version,
so that won’t matter for me.
When I do though, I’ll either duplicate the assembly one from Arduboy2 itself,
or use the one I wrote for the (still unfinished) Pokitto port of Arduboy2.

(At least Adafruit used BSD-3 though. A sensible choice.)

Pharap, you can use tis link:
else you have the github repository:

1 Like

Here’s an approximation (without noise channel, and without volume modulation) of the sound patterns in ArduboyTones format:

const uint16_t player_damage_sound[] PROGMEM = {NOTE_B4, 250, TONES_END};
const uint16_t revolver_sound[] PROGMEM = {NOTE_F5, 50, NOTE_A3, 50, NOTE_GS3, 50, NOTE_G3, 50, NOTE_FS3, 50, TONES_END};
const uint16_t grenade_sound[] PROGMEM = {NOTE_A3, 50, TONES_END};
const uint16_t machinegun_sound[] PROGMEM = {NOTE_D4, 50, NOTE_A3, 100, NOTE_GS3, 100, NOTE_G3, 50, TONES_END};
const uint16_t rocket_sound[] PROGMEM = {NOTE_A4, 3000, TONES_END};
const uint16_t blast_sound[] PROGMEM = {NOTE_GS3, 50, NOTE_G3, 50, NOTE_FS3, 50, NOTE_F3, 50, NOTE_E3, 50, NOTE_DS3, 50, NOTE_D3, 50, NOTE_CS3, 50, NOTE_C3, 50, NOTE_B2, 50, TONES_END};
const uint16_t power_up_sound[] PROGMEM = {NOTE_D4, 50, NOTE_FS4, 50, NOTE_A4, 50, NOTE_D5, 50, NOTE_FS5, 50, NOTE_CS5, 50, NOTE_G4, 50, NOTE_AS4, 50, NOTE_DS5, 50, NOTE_G5, 50, NOTE_F4, 50, NOTE_A4, 50, NOTE_C5, 50, NOTE_F5, 50, NOTE_A5, 50, TONES_END};
const uint16_t enemy_death_sound[] PROGMEM = {NOTE_G5, 50, TONES_END};
const uint16_t jump_sound[] PROGMEM = {NOTE_G4, 50, NOTE_GS4, 50, NOTE_A4, 50, TONES_END};
const uint16_t enemy_felt_sound[] PROGMEM = {NOTE_FS3, 750, TONES_END};
const uint16_t shotgun_sound[] PROGMEM = {NOTE_B3, 150, TONES_END};
const uint16_t laser_sound[] PROGMEM = {NOTE_D5, 50, NOTE_CS5, 50, NOTE_C5, 50, NOTE_B4, 50, NOTE_AS4, 50, NOTE_A4, 50, TONES_END};
const uint16_t club_sound[] PROGMEM = {NOTE_E3, 50, NOTE_DS3, 50, NOTE_D3, 50, TONES_END};

const uint16_t playOK[] PROGMEM = {NOTE_C4, 50, NOTE_C5, 50, TONES_END};
const uint16_t playTick[] PROGMEM = {NOTE_C5, 50, TONES_END};
1 Like

If you just want the whole screen inverted the hardware itself can do that, you don’t need any changes to the software draw functions. Just tell the screen to invert.

also BLACK and WHITE are sometimes opposite in the code because the Gamebuino screen is an LCD not an OLED

This makes sense when you consider B/W is part of the Arduboy brand/experience. Any faithful reproduction on an actual screen should not need inversion… on VGA hardware white should still be white and black should still be black. LCD is hard though. But I think inverting at the DRAW layer is still the wrong bet.

If you can’t invert the whole screen, then invert the paint function.


The reason for a drawPixel that can do INVERT, is for the rectangle that gets drawn for an explosion:

I’d argue that’s more of a filter than a draw. I’d have a separate optimized function to handle that.

Interesting idea for an explosion.

1 Like

OK, have added in the sound now - two channels using Beep1 / Beep2:

Super-Crate-Buino.ino.hex (71.0 KB)


This game seems to have a bug related to the height of the character? I’ll have to take it out of the FX Goldcart for now unless we find a fix.

Do you have a more specific description at all?

The game is completely unplayable. Movement of the character does not relate to where they are actually are within the game code, IE you die from enemies that appear nowhere near you. Bullets come out from a totally different location from where you seem. Platforms are not able to be jumped on.

Try it out for a second and you will see immediately. On a side note, the game runs dramatically faster on my laptop than on my desktop for some reason, both running chrome.

The hex he posted above works perfectly fine on the emulator for me here ( on my phone ).

ArduboyRecording (21)

You can see when I drop down to the lower platform the bullets no longer line up, and then after being respawned I end up clipping through the top platform.

You can also see the bad guys don’t appear to be spawning at the right spot either.

Is it just me?

I can probably have a look at some point if nobody beats me to it.
At the moment though my focus is elsewhere.

I had a quick look… it’s probably not going to be a quick fix.

I can’t imagine it being a long fix, because there’s nothing wrong with
the code… was it recompiled for this ‘FX’ version? if so, was it
recompiled from the correct branch?

Personally speaking I hadn’t actually compiled it, I only had a peek at the code and my estimation was based on how long it would take to read through and understand the code.

After compiling it and running it I can’t reproduce @bateske’s problem,
so there’s probably something else going on.

The Arduboy FX is just a normal Arduboy with an external flash memory chip (the FX chip),
so a normal Arduboy game wouldn’t need any changes to run on an FX.

I didn’t compile it, I’m playing it on the emulator on the hex in the thread here:

Is it a problem with the emulator?