I’m kind of surprised at that because I just realised I meant to grab suicide = 0 but put playerDies() instead. Oops :P
Like I said earlier, it’s sort of random. The few times I tried it in your fork it didn’t have the issue, so maybe I was just lucky.
I’ve updated now to set suicide to 0 instead.
Try it now:
https://github.com/Pharap/LodeRunner/tree/light-fix
The light not going off on the main game happens when you start the suicide sequence but don’t finish it (because there was nothing to switch it off when you let go of the buttons).
If more than one person confirms this works, I’ll make it into a PR.
Likewise if someone wants to test my earlier branch to make sure it still works:
https://github.com/Pharap/LodeRunner/tree/size-reduction
If it works then a few saved bytes are better than nothing.
Boy @Pharap, you have been busy. I am a little scared about your first set of changes simply because every time I touch movements I tend to make new issues - GitHub makes it really hard to see the actual changes you made. I suspect the bulk of the memory savings are in the ‘hasMoved = true;’ change to ‘return true;’. If the testing checks out, then lets merge them!
Technically it’s the diff system, not Github itself.
I think most of my changes are functionally equivalent.
If I changed any functionality it will be related to the order or a condition.
I was going to try to add the AI thing but stopped because I wasn’t sure how level offset worked in conjunction with player and enemy position.
Actually I think the compiler might have already figured that one out. I can’t remember exactly, I’ve been staring at data structures for hours since I committed that.
Originally I was trying to stick to your brace & space style, but even if I stuck to the brace style, all my editors are geared towards tabs (even the Arduino IDE) and I find the gaps between the statements and the braces just makes it harder to see the bigger picture.
You might want to drop things in a bit at a time to decide what to keep.
Some things didn’t impact space, I just did them out of habit or in an attempt to decrease the size and didn’t bother to change them back.
The light fix can probably be merged right off the bat or with a bit of tweaking. Let me know when you’ve checked and you can either add it yourself or I’ll make a PR.
For the more substantial change you’ll probably need longer to pick through it and you might want to leave bits out so again I’ll leave it to you to say whether you want me to make a PR or whether you want to merge it in a bit at a time on your own accord.
Lol how so fast? I’m only on 18 XD. The game is really hard.
Its not hard, its a challenge.
3 Likes
I merged all of your code by hand … after all the braces were all wrong 
Thanks for this, it freed up another 80 or so bytes and fixed the LED issue.
I must be getting close??
1 Like
-80 sounds about right, the -92 from the savings and then the +whatever from the light fix.
So, how are the coordinates actually represented.
Are player coords relative or absolute?
Ard enemy coords relative or absolute?
As I mentioned before, manhattan distance is:
uint16_t distance = absT(x2 - x1) + absT(y2 - y1);
Which you could then use as a metric to decide whether enemies should chase the player.
Alternatively (or even in addition to that), put a cooldown timer on player that ticks (either up or down) when the player isn’t moving and have the enemies look at that to decide whether they should go after the player. E.g. if the player has been stood still for 120 ticks then start making the enemies travel in the opposite direction (i.e. they’re either bored with the player or can only sense movement because they’re weird robotic bat things).
Enemy coords are absolute.
Players coords are screen coords - the Level offset describes how far the screen is scrolled left / right or up / down. Player absolute coords can be calculated using:
int16_t x = (player.getX() - level.getXOffset());
int16_t y = (player.getY() - level.getYOffset());
Those ideas could work. The enemies do not stand still and if a player is not moving they will start moving in other directions if they cannot move towards the player. So depending on how long you force the enemy to move away from the player, you may not see much difference to what is implemented now.
What needs fixing now, Ive been offline for a few days so Im kinda outa the loop
There is an issue with the saving / restoring of games. Apparently, the number of men gets screwed up. Fingers crossed, that is the last of the bugs …
I did come across this bug whilst playing
Point me to the appropriate code and I’ll skim it to see if I can spot any possible problems.
To be honest, I haven’t had a chance to even look at it and are not really sure what the exact issue is. The save / restore code is all in EEPROM_Utils.h file.
What circumstances cause the ‘men’ bug to occur?
Player dying?
This was the original report:
Another weird thing happened, after getting a Gameover screen when i resumed, where it shows how many MEN i have left, it’s now showing things like MEN: ¡!7 . And it seems i don’t get a GameOver screen anymore… After i turned the Arduboy OFF and ON again, that small bug disappeared, maybe i triggered a super secret infinite lives cheat :wink:
I wonder if I have disrupted it through other fixes and have managed to fix it ?
I must admit I haven’t noticed that one.
I thought the bug was that it wasn’t saving and restoring properly.
I can see what would have caused if the ‘men’ count had hit the hundreds, but I’m guessing that doesn’t happen anymore.
That bug never happened again in the later versions, you probably fixed it without knowing.
That being said over the weekend i managed to play more and got to level 28, but on some levels i saw more gold then what was needed to complete the stage. maybe i should try @Pharap’s fork of the game to see if it fixes it?
Bugger … and you were playing V0.99C?