Guinea Pigs Wanted!

Bug:

  • Men Counter wrapping round after Dying. (Lives Checker)

Wow … but it sounds like no one else will be able to do that. How do we fix the level itself?

Now you have something to do code-wise. You get a extra man at the end of each level (up to 10 men but I must have put the code in a spot where it is repeated many times.

Just a Quick question which files use the Queue.h file?

I examined the enemy movement code to try to see if I could find any clues, but it’s hard to keep track of everything.

As far as I could see the gold related stuff itself isn’t causing an issue, but it’s hard to tell how it interacts with other parts.

Could be an issue in the level loading.

Perhaps you should count the gold after the level is fully loaded instead of trying to do it as you unpack the level?

LodeRunner.ino uses it to queue the holes that need to be filled in.
Why, do you want to know how it works or what it does?

(I’m the one who wrote Queue.h by the way. Sometimes I loan data structures to @filmote.)

The main LodeRunner.ino file. It is used to store the ‘burning bricks’ on a ‘first burnt, first to regenerate’ basis.

if (arduboy.everyXFrames(2)) {
      
      for (uint8_t y = 0; y < level.getHeight(); y++) {

        for (uint8_t x = 0; x < level.getWidth() * 2; x++) {

          LevelElement element = (LevelElement)level.getLevelData(x, y);
          
          switch (element) {

            case LevelElement::Brick_1 ... LevelElement::Brick_4:
              element++; //<<<<<<<<<
              level.setLevelData(x, y, element);
              break;

            default:
              break;

          }

        }

      }

    }

This is the one place I could possibly see it occuring within a game without loading being an error.

I rip them from the web initially then when I see they are bloated and poor performers, I ask @pharap for a better one!

1 Like

So what that code is doing is polling the board for any holes that are being dug. Element in this case is a LevelElement item that is at position x / y. If the element is a Brick_1 / 2 / 3 or 4, it increases it to the next image (with Brick_1 being the start of digging and Brick_4 being the hole is almost complete and the next element, Brick_Transition, being fully dug).

This should not relate to the gold or men lives issues. (famous last words, * should *)

A more concise version of @filmote’s explanation:

LevelElement is defined as thus:

enum class LevelElement : uint8_t {

  Blank,       // 0
  Brick,       // 1
  Solid,       // 2
  Ladder,      // 3
  Rail,        // 4
  FallThrough, // 5
  Gold,        // 6
  Brick_1,     // 7
  Brick_2,     // 8
  Brick_3,     // 9
  Brick_4,     // 10
  Brick_Transition,  // 11
  Brick_Close_1,  // 12
  Brick_Close_2,  // 13
  Brick_Close_3,  // 14
  Brick_Close_4,  // 15
  
};

case LevelElement::Brick_1 ... LevelElement::Brick_4: is a compiler extension (i.e. not standard C++, it won’t work on other compilers) that basically means if(element >= LevelElement::Brick_1 && element <= LevelElement::Brick_4).
The next value after Brick_4 is Brick_Transition, so element++; will only cause element to be something from Brick_2 to Brick_Transition.

1 Like

Thanks for expanding … I am on a customer site right now so can quickly thump out messages but probably should look like I am working.

Which Levels use RLE and Grid?

Actually I just realised that technically your prefix ++ implementation should be returning LevelElement & instead of LevelElement, but that’s probably not affecting anything.


It’s a good thing your hobby looks a lot like your job or you’d probably have been sacked by now.
If your hobby was art it would be a lot more obvious that your paintings weren’t what you were supposed to be doing.

Better safe than sorry?

That sums up a good 20-25% of good coding practice and obscure language rules.

Level 3:
When consecutive holes are made with an enemy dropping in both enemys can phase through walls

Edit When Enemys have fallen in a hole under a ladder gold will randomly spawn //Temperamental

The bulk use RLE in either col or row orientation. Where neither of these give good compression, I revert back to the grid compression. Good point though, maybe one of these is giving a false gold count to begin with. I wonder if any levels are producing the problem and not others?

@pharap’s idea of changing the code to count the gold afterwards would definitely ensure the count was correct but (as always) nicer to fix the actual bug.

Its in the enemy code.
(The Gold Bug)

How do you mean ‘randomly’ spawn. The problem with a hole under the ladder is that both the gold piece and ladder element are trying to occupy the same grid location. When an enemy falls into a hole, I check to see if the space above them is ‘blank’ before dropping the gold. Otherwise, they take the gold with them …

I am not sure I understand this one … ‘phase’ (move?) through walls adjacent to the hole they are in? Or do you mean other enemies not in the hole?

Do tell! I suspect you are right … I just cannot locate it.

This Will be your problem

Ill try using the emulator