[WIP] Ardunaut (previously Parallax rocket launch)

CatDadJynx · April 30, 2019, 2:24am

Never any need to apologize, I figured you were probably busy elsewhere.

And yeah, that state machine is just cheaper, basically. Initially I wasn’t sure how much space I’d really have so I was just thinking as simple as possible, but now I have a better idea what I have to work with (at least somewhat), and since I wasn’t thinking of anything too terribly complicated I think I would rather do it that way, at least as simplistically as I can. I can do away with the state machine and start on something else tomorrow, just have to sketch out better details beforehand.

Only foreseeable issue I can think of is that in my current program the default ‘gravity’ is already set to 1 which is as low as possible and the only way to circumvent this (that I can think of) would be to set the frame rate lower, which the menu pollbuttons depends on (and I’m hoping to reuse) so can’t be too low. Unless there’s a way to use decimal numbers I don’t know about (which there probably is).

Also I would have to implement some sort of tile wrapping for the background so that it would continuously scroll (within whatever boundaries I set) so I don’t have to read repeatedly use a large tile to cover everything. Couldn’t seem to find anything about how to do this (or or it being done).

And yeah, I’ll keep in mind to take note of actual bytes instead. Will also move some things over to header files ahead of time to declutter a bit. Thanks!

filmote · April 30, 2019, 2:31am

You could use a float (@pharap will point you to a FixedPoint library, later) or you could simply scale the gravity by 10. Every time you want to apply gravity, you would then need to divide by 10.

Pharap · April 30, 2019, 3:02am

Says the person who uses ‘sorry’ multiple times per comment. :P

Keep it until a better way reveals itself.
If you don’t find a better way then at least you won’t have scrapped the way that you had.

One alternative is to use everyXFrames, which would allow you to apply gravity once every few frames instead of once every frame.

The other way…

Yes, there is.
As @filmote has pointed out, there are ‘floating point numbers’.

Floating point numbers are very flexible,
they can represent very large numbers and very small numbers,
but they’re 4 bytes large and (on the Arduboy at least) computationally expensive.
Most CPUs these days (particuarly the kinds used in desktops, laptops and phones) have a built-in floating point unit (FPU) for processing floating point numbers,
but the Arduboy’s CPU doesn’t, so instead it has to simulate them using integer arithmetic and software algorithms.

However, there’s another way of representing ‘decimal’ numbers as well.
‘Fixed point numbers’, which used to be difficult to use,
until a certain talking skeleton invented a very handy library many eons ago.
Fixed point numbers have a much more limited range of numbers that they can represent,
but they’re much faster because their simpler representation means that the algorithms needed to operate on them are much cheaper.
Overall they’re not much more expensive than integers.
(In fact addition and subtraction of fixed points is actually exactly the same as adding and subtracting integers.)

You remember I pointed out my “Physix” demo?
The reason I wrote that in the first place was to test how easy it would be to use Fixed point numbers in a physics simulation.
The reason it has Number and NumberU everywhere is because I wanted to make it easier for myself when I can to switch from using floats to using fixed points.

The kind of floating point format used on Arduboy (and one of the kinds found in most computers) is quite difficult to understand.

But fixed points are realtively easy to understand.
It’s basically just a regular power-of-two integer combined with a power-of-two fraction.
E.g. the format UQ8x8 (unsigned, 8 bits integer, 8 bits fractional) can represent 0 to 255 in the integer part and 0/256 to 255/256 in the fractional part.

Lastly, both floating points and fixed points aren’t capable of accurately representing every number, so there will always be rounding errors, whichever method you choose.

This is actually roughly how fixed points work,
except the factor is always a power of 2 for efficiency reasons.

Ah, I forgot I was going to answer that.

The easiest way is with a diagram, which would have to wait until later when I’m able to use the scanner.

Basically you have to think of the screen as a rectangular ‘window’ or ‘viewport’ into the world, take that rectangle’s in-world coordinates into consideration and think about where to draw the tiles.

There’s some division and modular arithmetic involved and I’d have to think about the maths for a bit because it’s not something I do every day.
(Despite popular theory, not all programmers are good at maths.)

CatDadJynx · April 30, 2019, 3:14am

Hmm, I’ll have to think more on that and decide what route to take from there, then (and probably do some ‘light’ reading :P) and yeah, I always save backups anytime I try anything new just so I don’t ever scrap anything completely til I’m more sure. And as for the background, I was kind of thinking along those lines, that I’d have to have at least twice the screen size so as one half was in view the other could scroll back around (if that sounds viable).

Will do some more planning and homework but already got a decent start just modifying the code I posted most recently so rather than a switch case the gravity is only active within a certain height limit (it’s a start, at least :P), will get back tomorrow.

CatDadJynx · May 1, 2019, 12:10am

So I’ve started getting more into it and decided to go with everyXframe for the gravity… I know it’s a little cheaper and I would honestly rather use floating or fixed points (just to learn them), but if there are rounding errors as you mentioned then I could already forsee this causing issues.

Aside from setting earths gravity to a specified height window (so the player can now leave earths gravity, fly around, and return), all I’ve tried to do so far is the background scrolling, but had no luck. I know its pretty large, but the background tiles are 64x64 so I could fit it once along the screen height, and i tried to tile it twice so it would be 2x the screen height (in two separate draw commands so I could work with them each individually, if needed) and since I had to offset it back because it draws down I had to subtract 64 from one and 128 from the other (during the draw command so the actual values are unchanged), then I tried to set it so when the background Y point reached 64 it would set it back to 0. This did nothing.

I’m sure it’s harder to visualize what I mean without the code, sorry, just spent the better part of my night playing my Arduboy (naturally :P), but I’m going to move most of my game code to separate header files now so i won’t be spamming the forum, then I’ll post it when it’s cleaned up a bit.

EDIT: can’t upload over the game that’s already on there and don’t feel like having to fight with it for however long (again) so I’m just gonna have to do the cleanup later.

Here is my current code, with my last attempt to offset the background when it reached a certain point (with no luck) in the drawGame() function. Next im just going to print the value to the screen and see what it is, in case its a simple oversight on my part.

EDIT 2: A couple things worth noting… it seems that my background scrolling is offsetting by 1 each time (so as the player takes off and lands repeatedly it becomes 1, then 2, then 3, etc.) so ill have to address this before moving on. Judging by the similar issue with the player sprite i would think its likely something similar to that. Also, when i printed the value to the screen it showed the number decreasing in value rather than increasing, so changing the 64 to negative got it to do what i wanted (although now i will have to figure out how to make it work in the opposite direction, but will worry about implementing this after i fix the other issue). Have since removed the statement to shift the background at a certain value, but have added a counter for testing.

EDIT 3 (last one, promise): Got the bug fixed, just had to set the height increment for gravity to the beginning, rather than the end (not sure why this worked when its opposite the input, but doesnt seem to affect the player sprite any) so I posted over top the code that was there. Now moving on to the background looping…

#include <Arduboy2.h>
Arduboy2 arduboy;

uint16_t heightCounter = 0;

struct Timer {
  unsigned long currentMillis;
  unsigned long previousMillis = 0;
};

struct PointXY {
  int x = 0;
  int y = 0;
};

struct Launchpad {
  int x1;
  int y1;
  int x2;
  int y2;
};

struct FuelBar {
  uint16_t x;
  uint16_t y;
  uint8_t height;
  uint8_t width;
  uint16_t rate;
};

struct Arrow {
  uint16_t x1;
  uint16_t x2;
  uint16_t x3;
  uint16_t y1;
  uint16_t y2;
  uint16_t y3;


};

Timer timer;
PointXY playerXY;
PointXY background1;
PointXY background2;
PointXY background3;
FuelBar fuelBar { 0, 20, 30, 5, 2000 };
constexpr Launchpad launchpad { 61, 58, 73, 58 };
constexpr Arrow arrow { 61, 73, 67, 58, 58, 64 };
constexpr int worldWidth = 128;
constexpr int worldHeight = 128;
constexpr int tileSize = 64;
uint8_t const *playerSprite = nullptr;

PROGMEM const unsigned char playerUp[] = {
  // Bitmap Image. No transparency
  // Width: 9 Height: 9
  9, 9,
  0x00, 0x00, 0xE0, 0x7C, 0x47, 0x7C, 0xE0, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

  0x00, 0x00, 0xE0, 0x7C, 0xC7, 0x7C, 0xE0, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

  0x00, 0x00, 0xE0, 0x7C, 0xC7, 0x7C, 0xE0, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00,

  0x00, 0x00, 0xE0, 0x7C, 0xC7, 0x7C, 0xE0, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
};

PROGMEM const unsigned char playerDown[] = {
  9, 9,
  0x00, 0x00, 0x0E, 0x7C, 0xC4, 0x7C, 0x0E, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00,

  0x00, 0x00, 0x0E, 0x7C, 0xC6, 0x7C, 0x0E, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00,

  0x00, 0x00, 0x0E, 0x7C, 0xC7, 0x7C, 0x0E, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00,

  0x00, 0x00, 0x0E, 0x7C, 0xC6, 0x7C, 0x0E, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00,
};

PROGMEM const unsigned char playerLeft[] = {
  // Bitmap Image. No transparency
  // Width: 9 Height: 16
  9, 9,
  0x01, 0x06, 0x2A, 0x74, 0xA8, 0x1C, 0x08, 0x10, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

  0x01, 0x06, 0x2A, 0x74, 0xA8, 0x3C, 0x48, 0x10, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

  0x01, 0x06, 0x2A, 0x74, 0xA8, 0x3C, 0x48, 0x90, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

  0x01, 0x06, 0x2A, 0x74, 0xA8, 0x3C, 0x48, 0x10, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
};

PROGMEM const unsigned char playerRight[] = {
  // Bitmap Image. No transparency
  // Width: 9 Height: 16
  9, 9,
  0x00, 0x10, 0x08, 0x1C, 0xA8, 0x74, 0x2A, 0x06, 0x01,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

  0x00, 0x10, 0x48, 0x3C, 0xA8, 0x74, 0x2A, 0x06, 0x01,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

  0x00, 0x90, 0x48, 0x3C, 0xA8, 0x74, 0x2A, 0x06, 0x01,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

  0x00, 0x10, 0x48, 0x3C, 0xA8, 0x74, 0x2A, 0x06, 0x01,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
};

PROGMEM const unsigned char backgroundTile1[] = {
  // Bitmap Image. No transparency
  // Width: 64 Height: 64
  64, 64,
  0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
};

PROGMEM const unsigned char backgroundTile2[] = {
  // Bitmap Image. No transparency
  // Width: 64 Height: 64
  64, 64,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
};

PROGMEM const unsigned char backgroundTile3[] = {
  // Bitmap Image. No transparency
  // Width: 64 Height: 64
  64, 64,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
};

void setup() {
  arduboy.boot();
  arduboy.setFrameRate(10);
  playerSprite = playerUp;
  arduboy.clear();
}

uint8_t playerFrame = 0;

void loop() {

  if (!arduboy.nextFrame()) {
    return;
  }
  timer.currentMillis = millis();
  arduboy.clear();
  testing();
  AtLaunch();
  arduboy.display();
}

void gravity(){
  if (!arduboy.pressed(UP_BUTTON) && heightCounter >= 1 && heightCounter <= 150) {
    //if  height counter is less than 20 move player, if greater scroll background
    --heightCounter;
    if (heightCounter <= 20) {
      movePlayerDown();
    }
    if (heightCounter >= 20) {
      backgroundScrollUp();
    }
  }
}


void handleInput(){
  //movement
  //if up button pressed
  if (arduboy.pressed(UP_BUTTON)) {
    //if height counter is less than 20 move player, if greater scroll background
    //change player sprite and frame
    playerSprite = playerUp;
    playerAnimate();
    if (heightCounter <= 20) {
      movePlayerUp();
    }
    if (heightCounter >= 20) {
      backgroundScrollDown();
    }
    //if time elapsed is greater than fuel rate, lower bar
    if ((timer.currentMillis - timer.previousMillis >= fuelBar.rate && fuelBar.height >= 1)) {
      ++fuelBar.y;
      --fuelBar.height;
      timer.previousMillis = timer.currentMillis;
    }
    //raise height counter
    ++heightCounter;
  }
  if (arduboy.pressed(DOWN_BUTTON)) {
    //change player sprite and frame
    playerSprite = playerDown;
    playerAnimate();
    //if height counter is less than 20 move player, if greater scroll background
    if (heightCounter <= 20) {
      movePlayerDown();
    }
    if (heightCounter >= 20) {
      backgroundScrollUp();
    }
    //if time elapsed is greater than fuel rate, lower bar
    if ((timer.currentMillis - timer.previousMillis >= fuelBar.rate && fuelBar.height >= 1)) {
      ++fuelBar.y;
      --fuelBar.height;
      timer.previousMillis = timer.currentMillis;
    }
    //lower height counter
    --heightCounter;
  }
  //if left button is pressed and background is less than 75, scroll background and animate sprite
  if (arduboy.pressed(LEFT_BUTTON)) {
    backgroundScrollRight();
    playerSprite = playerLeft;
    playerAnimate();
  }
  //and right
  if (arduboy.pressed(RIGHT_BUTTON)) {
    backgroundScrollLeft();
    playerSprite = playerRight;
    playerAnimate();

  }
  //if no buttons are pressed, frame for player animation is 0
  if (!arduboy.pressed(UP_BUTTON) && !arduboy.pressed(DOWN_BUTTON) && !arduboy.pressed(LEFT_BUTTON) && !arduboy.pressed(RIGHT_BUTTON)) {
    playerFrame = 0;
  }
}

void movePlayerUp() {
  --playerXY.y;
}

void movePlayerDown() {
  ++playerXY.y;
}

void playerAnimate() {
  if (playerFrame < 3) {
    ++playerFrame;
  }
  else
    playerFrame = 0;
}

void drawBackground() {
  //For each row in the column, draw background
  for (int x = 0; x < worldWidth; x += tileSize ) {
    for (int y = 0; y < worldHeight; y += tileSize) {
      Sprites::drawSelfMasked(x + background1.x, y - background1.y - 64, backgroundTile1, 0 );
      Sprites::drawSelfMasked(x + background2.x, y - background2.y - 64, backgroundTile2, 0 );
      Sprites::drawSelfMasked(x + background3.x, y - background3.y - 64, backgroundTile3, 0 );
    }
  }
}

void backgroundScrollLeft(){
  if (background1.x > -75) {
    background1.x -= 1;
    background2.x -= 2;
    background3.x -= 3;
  }
}

void backgroundScrollRight(){
  if (background1.x < 75) {
    background1.x += 1;
    background2.x += 2;
    background3.x += 3;
  }
}

void backgroundScrollUp(){
  background1.y += 1;
  background2.y += 2;
  background3.y += 3;
}

void backgroundScrollDown(){
  background1.y -= 1;
  background2.y -= 2;
  background3.y -= 3;
}

void drawLaunchpad() {
  arduboy.drawLine(launchpad.x1 + background1.x, launchpad.y1 - background1.y, launchpad.x2 + background1.x, launchpad.y2 - background1.y);
}

void drawPlayer() {
  Sprites::drawSelfMasked(playerXY.x + 63, playerXY.y + 50, playerSprite, playerFrame);
}

void drawArrow() {
  if (heightCounter >= 30 && heightCounter <=150) {
    arduboy.fillTriangle(arrow.x1 + background1.x, arrow.y1, arrow.x2 + background1.x, arrow.y2, arrow.x3 + background1.x, arrow.y3);
  }
}

void drawHUD() {
  arduboy.setCursor(0,0);
  arduboy.print("alt.");
  arduboy.print('\n');
  arduboy.print(heightCounter);
  arduboy.print("00");
  arduboy.fillRect(fuelBar.x, fuelBar.y, fuelBar.width, fuelBar.height);
}

void drawGame() {
  drawBackground();
  drawPlayer();
  drawHUD();
}

void AtLaunch() {
  drawGame();
  drawLaunchpad();
  gravity();
  handleInput();
  drawArrow();
}

void testing(){
  arduboy.setCursor(40,7);
  arduboy.print(background1.y);
}

CatDadJynx · May 1, 2019, 5:57am

Okay! Ive gotten the scrolling to work (along the Y axis), but had to change the launchpad from constant so i could keep the position updated. I also had to add two additional sets of backgrounds to make sure the scrolling was continuous when going up or down, but im hoping i can just use two, just wanted to try to iron that out a bit more then ill post it.

CatDadJynx · May 1, 2019, 2:06pm

Sorry to be spamming talking to myself again, just excited with the progress I’ve been making and made a few noteworthy additions/improvements.

First, I got the background scrolling to work now with only two backgrounds in each axis (not sure why I used three initially, just tired and brain was a little jelly, I guess), using the initial background plus one more in x, and one more in y, then a fourth background at the intersection of those two (basically a square with four 128x64, the player starting in the one to the bottom left), so now the scrolling for each tile and layer seamlessly repeats along the x and y axes.

Also, since I had to reset the y position of the background to do this, I update the position of the landing pad before doing so in order to keep track of it (so you can fly out as long as you want and still fly back and it will be where it should be). I didn’t update the position in x though, so it repeats every every other 128 px (I liked this in order to keep the game space reasonable).

And, I reintegrated the menu I used in the gamestates version, and as such did redo the gamestates part I did before, but this time only for the menu and gameplay area.

And last (but certainly not least :P) shortly before finishing all this I was able to upload it onto my Arduboy, so I can finally organize its all into header files to cut down on the mess it’s turned into. Just wanted to do that real quick before posting (to spare everyone the headache).

Pharap · May 1, 2019, 6:08pm

I’m going to advise against it.

I’ve recently been helping out/advising someone else with a game project that has a bit of overlap with this project (in terms of physics and using tile-based rendering) and something I found with the everyXFrame trick is that it can cause problems because of the timing.

What the everyXFrame trick is supposed to do is to simulate decimal numbers/fractions, but instead of accumulating the fractional part of the distance you’re just delaying until you can add a whole part.

I.e. if you had a ship travelling at 4 pixels per second (1 pixel every 1/4 of a second) then your movement is going to look like this:

Method \ Frames	1	2	…	14	15
Using `float`	0.0666	0.1333	…	0.9333	1.0
Using `everyXFrames`	0	0	…	0	1

I’m doubtful that it will be a problem, and I’ll explain why…

The error depends on the format.
Whether it’s going to affect you or not depends on what the smallest fraction speed you’ll have to represent is.

The smallest fractional value that a floating or fixed point type can repsresent is called its ‘epsilon’.
(The epsilon is also the smallest value larger than zero that the type can represent.)

float's epsilon on the Arduboy is:
0.000000000000000000000000000000000000011754944324493408203125

Which I think it’s safe to say is pretty tiny.

UQ8x8 and SQ7x8 have an epsilon of 0.00390625 (1 / pow(2, 8)).
It’s significantly larger than float's (more specifically ‘orders of magnitude’ larger),
but it might not be that much of an issue.

UQ16x16 and SQ15x16 have an epsilon of 0.000015258878 (1 / pow(2, 16)).
That’s still comfortably small.

What you have to ask is what sorts of values are you going to be handling.
If you wanted to move 1 pixel per second at 60 fps then you need to move 0.01666… pixels per second.
0.01666… is still over 4 times UQ8x8's epsilon and over 1092 times UQ16x16's epsilon.
With UQ8x8, theoretically you could go as slow as 1 pixel every 4 seconds before you’d encounter problems.

I’m not sure what you’ve done so far.
That was all a bit too much for me to process.
I’ll wait until I know that your GitHub is up to date and then I’ll have a peek.

Before I sink too much time into it, I think I need to know a bit more about what you want.

What’s your intention for the background?

Are you going to have the same 64x64 block repeated infinitely?
Are you just going to have stars in the background?
Stars and planets?
How much variation do you want in the star patterns?

While thinking about it I’ve had an idea that I think you might like, but I need a bit of time to test it.

Whne I have a better idea of what your intention is and how the background is going to be drawn, I’ll start discussing the movement of the background with you.

When it comes to tile games there are two approaches:

Move the camera and keep the world static
Keep the camera static and move the world

I think you might be better off with a static world and a moving camera, but we’ll see.

CatDadJynx · May 1, 2019, 6:46pm

Sorry about that, thats understandable. At first I found a bug, then fixed it, then got the background scrolling working so you could take off and scroll infinitely up, left, or right (or at least until the value became too large).

Im still kicking around ideas where to go next, though… Id like to make something bigger than may be possible so I might end up just using the different ideas for their own separate games, but im still hoping to make something that captures the adventurous spirit i was kind of shooting for when i started… I know i couldnt, but id like to make something you could take off and land on the moon and walk around (from a top down perspective), even if it was just in the same looping tile space (like I have set up for launch/space), but even making the most minimal player sprite and background i could takes up 6717 bytes of ROM and 1221 bytes of RAM (and i hadnt even tiled it yet), and this game takes up 14098 ROM and 1336 RAM (leaving me at 99% RAM), so ill probably take it a more simplistic route (maybe so you can get out but keep in the environment as is) or just remove the parallax.

Pharap · May 1, 2019, 6:48pm

While I think of it, here’s an example of a game that uses fixed points for its movement calculations:

(In fact I think it’s the first game that ever made use of my fixed points library.)

In theory the movement should be smoother than games that don’t use fixed points or floating points,
but I don’t really play enough Arduboy games to know if that’s the case.

Pharap · May 1, 2019, 8:55pm

Actually, that’s kind of what my idea is about.

I was going to write a demo to make sure it would work before telling you because I didn’t want to get your hopes up, but I’ll tell you anyway.

Basically I remembered all that discussion we had about procedurally generated worlds and it suddenly occurred to me that if you generated the background tiles using a hash function then you should be able to achieve very large worlds (not infinite, but large).

When you were looking at the idea of a top-down world the hash function was a bit of a problem because it only generates noise rather than cohesive structures, which is why all the extra steps were needed.
But with a space setting, all you really need is patterns of stars,
so noise should be perfectly adequate for that.

So what I’m thinking of doing is basically:

const auto value = hash(tileX, tileY);
const uint8_t index = (value % 8);
Sprites::drawOverwrite(drawX, drawY, stars, index);

For each tile to be drawn.

Cheap. Cheerful. Incredibly large.

Is your GitHub code up to date?
I’m sure it’s possible to reduce that.

CatDadJynx · May 1, 2019, 9:14pm

My github code is up to date, although it isn’t organized into header files yet (doing that now) so it’s still a bit of a mess.

And I meant the program as it is on github plus a new program I wrote (for the top down perspective part as minimally as possible) equals 99% RAM, although I was hoping there might be a way to reduce that (like chunking) because I had to draw so many backgrounds in order for it to loop (which is why I was also thinking of doing away with the parallax, potentially), wasn’t sure if there might be a better way to do it.

And as for the hash function, I can somewhat follow (just generating noise for star placement), but how does it actually work? Also, what would the output look like (does it just populate the screen, does it populate a larger area outside, how large, etc), and what size tiles were you thinking? Sorry, just asking so I follow. Thanks!

MLXXXp · May 1, 2019, 9:19pm

I modified Flappy Ball (one of the earliest games ported to the Arduboy) to use fixed point math for the gravity calculations. The fixed point code was done by myself, before @Pharap’s fixed point library existed.

Pharap · May 1, 2019, 9:54pm

I’ll have a read of it tomorrow.

I won’t look right now because it’s late and I want a spin on Oblivion before the night is over.

There almost always is.

Ah, when I heard this I had to have a peek.

I’m not exactly sure what you’re doing with all the different backgrounds, but I’m almost certain there’s a better/easier way.

Which part? The hash function or the tiling?

Imagine 8-16 black rectangles.
Imagine those rectangles filled with a pattern of white dots.
Imagine those white-dotted rectangles tiled across the screen in a random order.

That’s what it will look like.

Probably 8x8, 16x16 or 32x32.

The world size limit will be determined by what type you use for coordinates because your ship’s coordinates will always be in pixels.

CatDadJynx · May 1, 2019, 10:27pm

No worries, like I said it’s a bit of a mess, hopefully I’ll have it more cleaned up by the time you can get back to it.

And yeah, basically what I did was tile the background three more times, once more in x, once more in y, and once more diagonally (like quadrants of a rectangle) and when each respective background traveled the specified distance (so that it was offscreen) I moved it to wrap back around.

But since the parallax scrolling uses 3 layers I ended up with 12 backgrounds overall, hadn’t really planned ahead and didn’t realize til it was getting a little out of hand, just kinda went with the first method that came to mind

Occurred to me after the fact that I probably could have even tried chunking, but I don’t mind burning rubber on this kind of stuff, helps me to sharpen my skills better using the information I learned more recently (so it’ll be less of a blunt force trauma :P), if anything.

And that definitely helps to clarify a bit, thanks! I’m just not so sure how it works under the hood yet but I’ll just sit with it a bit and digest and I should get a better idea. Thanks again!

Pharap · May 2, 2019, 2:41pm

I started the day intending to write an example of the stars demo but I’ve been sidetracked half a dozen times.

I saw your thread about memory usage (and made a few comments).

People are right that in general it does depend on the game and the context,
general tips are only useful if you know when and where to apply them.

I think that a large chunk of your RAM usage has been chewed up by the background drawing,
but I’m struggling to see a way to reduce it because I’m struggling to track what all the backgrounds are doing.

My instinct says that you could possibly just generate all the background coordinates on the fly using a single pair of x and y offsets as a base.

One thing I’d like to point out.
Instead of doing -= 1, -= 2, -= 3,
you could just store one set of coordinates,
and then when it comes time to draw it:

Sprites::drawSelfMasked(x + (background.x * 1), y - (background.y * 1) - 64, backgroundTile1, 0);
Sprites::drawSelfMasked(x + (background.x * 2), y - (background.y * 2) - 64, backgroundTile2, 0);
Sprites::drawSelfMasked(x + (background.x * 3), y - (background.y * 3) - 64, backgroundTile3, 0);

And if you were to pack your backgroundTiles into a single array with multiple frames, you could further reduce that to:

for(uint8_t index = 0; index < 3; ++index)
{
	const uint8_t scale = (index + 1);
	Sprites::drawSelfMasked(x + (background.x * scale), y - (background.y * scale) - 64, backgroundTiles, index);
}

I’m not sure that would help here.
It depends how you were thinking of using it.

Chunking is primarily for generating terrain dynamically (in bite-size chunks, so to speak).

Pharap · May 2, 2019, 6:51pm

I finally found time to do it.
This is what I was talking about:

StarTerrain.hex (22.3 KB)

And here’s the code:

Basically the world is static and the camera moves around the world.
The rendering code decides which tiles are on screen and renders only those tiles.
The rendering loop takes the coordinates of the tiles,
feeds them into a hash function,
and then limits the output of that hash function to an index of one of following 4 images:

If that doesn’t make sense,
I’ll write a clearer explanation later.

I’m sure there’s a way to add parallax,
but it’s going to involve some maths so I’ll have to mull it over.
I know it will involve scaling coordinates at least, it’s just a question of how.

CatDadJynx · May 2, 2019, 7:18pm

Ah, thank you! Ill be away from the computer a bit but ill take a look as soon as I’m able

CatDadJynx · May 4, 2019, 12:34am

Sorry, just to try to keep things from jumping around too much, back to this thread…

I can understand things up to the hash fuctions, then im lost, just because there are too many operators I dont know about or understand yet (more specifically the different bitwise operators). I looked into them each individually and have an idea of what each does on its own, just seeing it all together i get a bit lost as to whats going on. But Im just going to keep reading about what i dont get yet (to try and spare you too long an explaination) and hopefully things will make more sense.

Pharap · May 4, 2019, 1:10am

Oh, you should have said so sooner.
I didn’t realise it was the operators you were having problems with.

^= is the compound form of ^, which is the xor operator.
<< and >> are the bit shifting operators.

To understand them you first need to understand binary.
https://www.mathsisfun.com/binary-number-system.html

Personally I find that thinking of binary numbers like this helps a lot with understanding them:
powers-of-2

(This way of looking at them is also fundamental to certain types of calculations where binary numbers are treated as polynomials. Polynomials still scare me slightly.)

<< shifts the binary digits left.
So for a single shift 0110 becomes 1100, and 0101 becomes 1010.

>> shifts the binary digits right.
So for a single shift 0110 becomes 0011, and 0101 becomes 0010.

(Note: ‘bit’ is actually short for ‘binary digit’.)

^ is a bit different, it takes two numbers and applies the outcome of a ‘truth table’ over every bit:

left	right	output
0	0	0
1	0	1
0	1	1
1	1	0

Or to put it another way, the output is 1 if only one of the two bits is 1.

So 0110 ^ 0101 would become 0011 because:
0 ^ 0 becomes 0
1 ^ 1 becomes 0
1 ^ 0 becomes 1
0 ^ 1 becomes 1

To help you understand what’s going on, here’s a version that only introduces new variables rather than modifying old ones:

uint32_t hash(uint32_t value)
{
	const uint32_t v0 = value;
	const uint32_t t0 = (v0 << 13);
	const uint32_t v1 = (v0 ^ t0);
	const uint32_t t1 = (v1 >> 17);
	const uint32_t v2 = (v1 ^ t1);
	const uint32_t t2 = (v2 << 5);
	const uint32_t v3 = (v2 ^ t2);
	return v3;
}

So basically I’m just mixing up all the bits and making a real hash of them.

But frankly, the hash function could have just used arithmetic operators.
Some hash functions do.

Ultimately unless you’re a particularly good mathematician, all you can do with hash functions is either borrow someone else’s function or do trial and error until you get some nice output.

In the cases of generating backgrounds/terrain you don’t need to worry too much about the quality of the function because of the way it’s being used.

This page has some examples of some hash functions (all operating on arrays of characters, but don’t worry too much about that, the point is the mish-mash of operations being used):
http://www.partow.net/programming/hashfunctions/#AvailableHashFunctions

Usually I end up getting sidetracked because I end up clicking on many different links or doing something else part way through an explanation.
(Or just getting lost in thought.)

Secret 20% off Arduboy Coupon!

Use coupon code "ERRORCOUPON" at checkout!

Buy Arduboy Now!

[WIP] Ardunaut (previously Parallax rocket launch)