I’ve started placing objects to be picked up and interacted with. Armakuni can now pick up shurikens according to LN2′s way to do that: it is clear where they are found and once he picks them up they are gone from the background
In this update I am showing how to animate the foreground (the flags in this case) and affect the sprite clipping at the same time.
This is all new code inspired by LN3 and now integrated in the LN2 framework. LN2 itself does include background animations (e.g. the torches in level 3), but not foreground animations (those that affect sprite clipping).
This is all good experience that I am documenting as I go along as part of the framework
I have been spending some time today on the framework itself. Most of the time went into an effort to compare the disassembled sources of level 1 and 3 from The Last Ninja 2.
What I observed is that there is a big deal of invariant code shared between these 2. Such code is very likely to be invariant for all levels but it is loaded in different positions in RAM for each level.
As a short term plan, I’d like to simply break down the sources into smaller ones and try to have a baseline that can be reused for all levels. On top of that customizations should find their place. Of course I’d like to give things a logical structure. I doesn’t really matter if the same code is not located at the same RAM locations for all levels.
As a long term plan, I’d like things to change though. In fact, apart from the tune, the disassembled sources I have now are completely relocatable. What I think would make sense for a new game is to try and make tunes relocatable too so that they can be pushed to the top of the RAM together with most of the level specific code and data: the benefit is that the invariant code would only be loaded once in the lower segment of the RAM, thus reducing duplication and file sizes.
As a consequence of having invariant code at the same RAM locations would be, as example, that the POKEs for unlimited lives, unlimited energy, etc. would be the same for all levels.
I decided to change the inventory to use the graphics from LN3. The demo is converging to where it could and at a very fast pace if you think about the fact I don’t spend more than 20 minutes in a day on it and it’s just me working on it
LN3 rewritten using LN2′s engine
Even better, a demo is available here!
I decided to give Armakuni a few weapons at the start of the level in order for him to wander around safely. Don’t get used to that, Armakuni! He’ll soon have to collect these weapons
I also changed the in-game tune. Current look and feel:
At the same time as I work on the generic framework, I have put together a few more bits for the rewrite of LN3. It’s good experience for me and it motivates me to do even more on the framework itself.
Here’s a video of the current status of this exercise:
While trying to collect unused bytes here and there in the LN2 disassembled source, I figured out an optimization that shortens the code and makes one of two lookup tables unnecessary. If I were able to consolidate all the unused fragments before $2000 (where the bitmap starts) I would probably be able to gain a 512 byte slot for some additional code. In there I would move a few routines so that I could extend the sprite clipping routine to work 100% of the times.
The sprite clipping problem is quite complex to explain so I will try to put together a few images of where the tricky bit is and why John Twiddy’s simplification saved him big time.
As I commented before, this problem seems to have been solved properly in LN3 (well done Stan!).