[EarlyRelease] RogueBoy

Here is a small Rouge-lite Game I have been working on Hope you enjoy it


There’s no need for #include <Sprites.h> in your sketch. #include <Arduboy2.h> will do that for you.

1 Like

Github repository has been updated thank you for the input


Hmmmmm. Very nice! Very nice indeed👏

1 Like

Thank you! Im reworking the map loader at the moment so that I can use interactive elements.

Running into a bit of a snag since progmem cant be rewriten

1 Like

Hmmmm. I have never tried anything with progmem

You can use RAM, but it depends how much you need and/or what you need it for.

The max map size is 10x10 atm as a test i have it stored in a 100 byte long, unsigned array

EDIT: I’m actually quite surprised that there have been less graphical bugs altogether since I don’t actually have an emulator nor an actual arduboy.

Do you need to alter your map during the game?

If you don’t then you can just keep it in progmem, but if you do, you might want to have a map buffer in RAM but initialise it from progmem using memcpy_P.

I have the updated code however i have no clue how to delete an entire file from git

EDIT: I am incompetent with github but I managed it.

1 Like

Two test maps have been Added

I haven’t looked it all over but I had a quick peek at the last commit and I can see some issues.

Firstly setCursor is per-pixel so all these prints are going to overlap each other:

ard.print(Level); sinx++;
ard.print(padd); sinx++;
ard.print(kadd); sinx++;
ard.print(kadd+padd); sinx++;

Secondly you’d be better off displaying like this:

ard.print("Level: ");
// etc

And thirdly (this is more of a tip than an issue) you can save RAM by wrapping printed strings in the F macro which stores them in progmem.


Three tips about github:

  1. You can overwrite an existing file with a file of the same name by using ‘upload files’, you don’t have to explicitly delete the old one first.
  2. You can rename files if need be by using the edit tool (the pencil icon) and then changing the file name at the top.
  3. You can move files like this.

I’ve got some time so I’ll have a quick run of it to see if it’s running alright.

1 Like

Seems the player isn’t moving for some reason.

I think Walkable is the problem.
Commented Walkable out and it sort of worked.
I’m not sure if the player’s position is the problem, if it’s the map loading or if it’s some other issue.

1 Like

To sort it out id have to have something to work with to see what is wrong
Images would be apriciated

GetBlock is definitely always turning up 0

I edited the code to print values out:

bool Walkable(int x, int y) {
  bool Walk = false;
  auto block = GetBlock(x / 16, y / 16);
  switch (block) {
    case OPEN_DOOR: Walk = true; break;
    case DOWN_STAIRS: Walk = true; break;
    case EMPTY: Walk = true; break;
    case OPEN_CHEST: Walk = true; break;
    default: break;
  return Walk;

And the first value is 0 for every direction.
Because the player is at 0,0 it makes sense that it would be returning 0 when x or y is -1, but for some reason it’s returning 0 when x and y are 1 too.

I’ll try to see if I can spot some other reason.
The map does seem to be loading because editing the player’s position moves the character.

I see that MAP_2 is the map that’s being loaded first, most likely because of

void NextLevelLoad(){
  gameState = GameState::Game;

Changing the code to this loads MAP_1 instead:

void NextLevelLoad(){
  gameState = GameState::Game;
1 Like

I think this is the classic Face palm moment XD

It might have something to do with the map indexing
Map[(x + (y * MAP_WIDTH))] = bl;
it might have to be
Map[(x + (y *( MAP_WIDTH+1)))] = bl;

Nope that code’s fine.

I found your problem, look very carefully:

for (int i=0; i<(MAP_WIDTH*MAP_HEIGHT), i++;){
    Map[i] = pgm_read_byte(&CLevel[(OFFSET+i)]);

Here’s the fix:

for (int i=0; i<(MAP_WIDTH*MAP_HEIGHT); i++){
    Map[i] = pgm_read_byte(&CLevel[(OFFSET+i)]);

Afterward you’ve got a few tiles that aren’t drawing properly but the player can move freely.

1 Like

Huh It came up with an error last time i did it like that

If that is the case about 90% of my for loops would be incorrect

I’ve put the updated code on git

1 Like

You had probably written:

for (int i=0; i<(MAP_WIDTH*MAP_HEIGHT), i++){
    Map[i] = pgm_read_byte(&CLevel[(OFFSET+i)]);

Which would be an error, ; and , are not interchangeable.

* looks back at the code *

Oh… ok… yeah, you’ve got some rewriting to do :P

Disection of the problem:

A for loop has three parts in the brackets, the initialiser, the expression and the increment.

for (initialiser; expression; increment)
// body

Which effectively translates to:

// body

The comma operator (which is what the comma is being in the case you’ve used it), discards the result of the first expression and uses the result of the second.
So effectively your code becomes:

int i=0;
while(i++) {
  Map[i] = pgm_read_byte(&CLevel[(OFFSET+i)]);
  // Do nothing else

Which only runs once, because in the second loop i is one which gets implicitly cast to true.

This was fine how it was before:

uint8_t Block = Map[(x + (y * (MAP_WIDTH+1)))];

It’s supposed to be zero indexed. 0 is the first element, 1 is the second, 2 is the third etc.

1 Like