Difference between revisions of "Ikari Warriors (NES)/Fuel drop manipulation"
From SDA Knowledge Base
(→Area 4 fuel drop) |
m (→Part 1 - index of the helicopter) |
||
(9 intermediate revisions by the same user not shown) | |||
Line 2: | Line 2: | ||
==Some background about object allocation in the RAM== | ==Some background about object allocation in the RAM== | ||
− | All objects that aren't part of the background are allocated to RAM-address $500 and onwards (player 1 is always in $4FE and player 2 is always in $4FF, but they can be disregarded here since they don't interfere with the foreign objects). This includes enemies, destroyable structures, hidden items, mines etc and even bullets. These addresses are referred to as "object addresses". The object address with index 0 corresponds to $500, index 1 corresponds to $501 etc. A new object entering the screen will be allocated to the lowest available index. If two objects enter the screen at the same frame, the object to the left will first be attributed the object address and will | + | All objects that aren't part of the background are allocated to RAM-address $500 and onwards (player 1 is always in $4FE and player 2 is always in $4FF, but they can be disregarded here since they don't interfere with the foreign objects). This includes enemies, destroyable structures, hidden items, mines etc and even bullets. These addresses are referred to as "object addresses". The object address with index 0 corresponds to $500, index 1 corresponds to $501 etc. A new object entering the screen will be allocated to the lowest available index. If two objects enter the screen at the same frame, the object to the left will (usually, but not always,) first be attributed the object address and will then get the lower of the available index. When an object leaves the screen (regardless of how), the corresponding index will be restored to null. Dropped objects will retain the address of the initial object though. Bullets are also an exception as they will be allocated to a high index (without interest for the topics of this page).<br /><br /> |
Different objects provide different values to the object addresses. Some objects share the same value, so there must be additional addresses that determine the exact type of object. However, these values aren't overly important to know, but are helpful when analyzing emulator movie files. Below are some common values (but the list is nowhere near complete): | Different objects provide different values to the object addresses. Some objects share the same value, so there must be additional addresses that determine the exact type of object. However, these values aren't overly important to know, but are helpful when analyzing emulator movie files. Below are some common values (but the list is nowhere near complete): | ||
Line 59: | Line 59: | ||
The type of drop is determined by the value of the object's "drop address". The drop addresses start with $0676. When the object leaves the screen, the drop address isn't reset to null, like the object address. When an object is allocated to an object address, its "drop address" can be overwritten with the object's corresponding drop value. This drop value is overwritten for most objects (including many objects that don't drop anything), but for example blue soldiers don't overwrite the drop values. The only drop value of interest is 20, which means fuel will be dropped.<br /><br /> | The type of drop is determined by the value of the object's "drop address". The drop addresses start with $0676. When the object leaves the screen, the drop address isn't reset to null, like the object address. When an object is allocated to an object address, its "drop address" can be overwritten with the object's corresponding drop value. This drop value is overwritten for most objects (including many objects that don't drop anything), but for example blue soldiers don't overwrite the drop values. The only drop value of interest is 20, which means fuel will be dropped.<br /><br /> | ||
+ | |||
+ | To watch the object allocation and the drop values in an emulator, the following package can be useful:<br /> | ||
+ | [[File:Ikari Warriors (U) - address watch.zip]]<br /> | ||
+ | It contains two RAM-watch files for the object types and drop values, respectively. It also contains a lua script that shows where on the screen the objects are located. It has the format [object value, index].<br /><br /> | ||
==Area 3 fuel drop== | ==Area 3 fuel drop== | ||
Line 71: | Line 75: | ||
[[File:Ikari Warriors (U)-3 fuel manip.zip]]<br /> | [[File:Ikari Warriors (U)-3 fuel manip.zip]]<br /> | ||
− | The fm2-movie in the file above shows a successful fuel drop | + | The fm2-movie in the file above shows a successful fuel drop. Other than illustrating the description above, it's also worth mentioning the role of #8. If the knife gets an index in the range 0 to 2 (which is not feasible to know in real-time) and is not collected, the leftmost gate (#3) will inherit its index, which means the fuel drop will not be possible. If it's collected, one of the enemy soldiers will inherit its index. #8 should therefore always be collected, no matter what.<br /><br /> |
[[File:Ikari Warriors (U)-3 fuel fail.zip]]<br /> | [[File:Ikari Warriors (U)-3 fuel fail.zip]]<br /> | ||
Line 85: | Line 89: | ||
===Part 1 - index of the helicopter=== | ===Part 1 - index of the helicopter=== | ||
− | In the part 2 above, nothing | + | In the part 2 above, nothing was mentioned about the index of the helicopter itself. The helicopter is treated like any other object and will be dealt an object address according to the same rules. This means that if the helicopter has index 0, 1 or 2, it will be virtually impossible to get a fuel drop later on. This section will describe how to manipulate the helicopter into a higher index.<br /><br /> |
Let's start by looking at the map of the section in question with all items shown:<br /> | Let's start by looking at the map of the section in question with all items shown:<br /> | ||
[[File:Ikari1-3 heli area.jpg]]<br /><br /> | [[File:Ikari1-3 heli area.jpg]]<br /><br /> | ||
− | The objects down to the topmost barrel will be on screen when the helicopter appears. So there are 5 non-moving objects that can potentially help keeping the helicopter out of index 0-2. However, there are also blue soldiers creating some randomness by spawning between the barrel section and the helicopter. So the threat comes from either a blue soldier or one of the lower barrels leaving the screen right before the helicopter appears. The helicopter will then inherit a potentially low index. The only realistic variation in terms of routing comes in the barrel section. You can either go to the left, which is faster, or to the right (going straight ahead is not a good option on foot). Let's look at both options.<br /><br /> | + | The objects down to the topmost barrel will be on screen when the helicopter appears. So there are 5 non-moving objects that can potentially help keeping the helicopter out of index 0-2. However, there are also blue soldiers creating some randomness by spawning between the barrel section and the helicopter. So the threat comes from either a blue soldier or one of the lower barrels leaving the screen right before the helicopter appears. The helicopter will then inherit a potentially low index. The only realistic variation in terms of routing comes in the barrel section. You can either go to the left, which is faster, or to the right (going straight ahead is not a good option on foot; '''EDIT (111120)''': Since this page was created, a viable route through the middle has been found. However, it hasn't been analyzed for the fuel drop analysis yet.). Let's look at both options.<br /><br /> |
<u>Left side of the barrel section</u><br /> | <u>Left side of the barrel section</u><br /> | ||
− | |||
[[File:Ikari Warriors (U)-3 Heli address fail.zip]]<br /> | [[File:Ikari Warriors (U)-3 Heli address fail.zip]]<br /> | ||
− | + | As can be seen from the movie name, it shows a case where the helicopter was allocated to an index in the range 0-2, which will prevent the fuel drop later on. To understand why this happens, let's take a look at the map again, but this time with arrows showing how the index are transferred from one object to the next:<br /> | |
[[File:Ikari1-3 heli address fail.jpg]]<br /><br /> | [[File:Ikari1-3 heli address fail.jpg]]<br /><br /> | ||
Line 102: | Line 105: | ||
In phase one (green arrows), we see that #4 and #5 are likely to inherit low index. Depending on when the red soldier leaves the screen, either #6 or the triple shot will inherit its value (the former is to prefer).<br /><br /> | In phase one (green arrows), we see that #4 and #5 are likely to inherit low index. Depending on when the red soldier leaves the screen, either #6 or the triple shot will inherit its value (the former is to prefer).<br /><br /> | ||
− | In phase two (red arrows), it's difficult to imagine a case where the left barrel in #2 will have an index higher than 2. There are a few more barrels that are likely to have a low index, but not to the same extent as #2.<br /><br /> | + | In phase two (red arrows), it's difficult to imagine a case where the left barrel in #2 will have an index higher than 2. There are a few more barrels that are likely to have a low index, but not to the same extent as #2. It's also worth noting that #3 gets the index allocated before the barrel to the left, even though they appear at the same time. It's not known why.<br /><br /> |
In phase three (yellow arrows), we can see the issue with this route. #2 leaves the screen some 24 or so frames before the helicopter appears. If no blue soldier appears in the meantime, it's more or less guaranteed that the helicopter will have an index in the range 0-2, which is what we wanted to avoid in the first place. It can be confirmed in the fm2-movie above that this is indeed what happened.<br /><br /> | In phase three (yellow arrows), we can see the issue with this route. #2 leaves the screen some 24 or so frames before the helicopter appears. If no blue soldier appears in the meantime, it's more or less guaranteed that the helicopter will have an index in the range 0-2, which is what we wanted to avoid in the first place. It can be confirmed in the fm2-movie above that this is indeed what happened.<br /><br /> | ||
<u>Right side of the barrel section</u><br /> | <u>Right side of the barrel section</u><br /> | ||
− | |||
[[File:Ikari Warriors (U)-3 Heli address manip.zip]]<br /> | [[File:Ikari Warriors (U)-3 Heli address manip.zip]]<br /> | ||
The first thing to notice is that this route is bit less straight-forward and a little over a second slower than the left side of the barrel section. With the route in mind, let's take a look at the map with the flow of the index inheritance for this route.<br /> | The first thing to notice is that this route is bit less straight-forward and a little over a second slower than the left side of the barrel section. With the route in mind, let's take a look at the map with the flow of the index inheritance for this route.<br /> | ||
Line 136: | Line 138: | ||
<u>Fuel-optimized route</u><br /> | <u>Fuel-optimized route</u><br /> | ||
[[File:Ikari Warriors (U)-4 Fuel manip.zip]]<br /> | [[File:Ikari Warriors (U)-4 Fuel manip.zip]]<br /> | ||
− | * At frame 515, the fuel from #1 is collected. This frees up its | + | * At frame 515, the fuel from #1 is collected. This frees up its object address with the hope of filling it with blue soldier instead of the turret. |
− | * At frame 603, the index 0 from #1 is taken over by a blue soldier (there should always be one or two random blue soldiers spawning around here). The drop value of index 0 remains 20. Without going into an analysis of how the barrels inherit each other's index, #1 and #3 seem to always end up with | + | * At frame 603, the index 0 from #1 is taken over by a blue soldier (there should always be one or two random blue soldiers spawning around here). The drop value of index 0 remains 20. Without going into an analysis of how the barrels inherit each other's index, #1 and #3 seem to always end up with low index. |
* At frame 650, we're in a similar situation to the speedrun route with two 20 loaded in memory. Still, the situation is quite different, #1 has been taken off screen long ago and its index is now blocked by a blue soldier that will stick around for at least a bit longer. | * At frame 650, we're in a similar situation to the speedrun route with two 20 loaded in memory. Still, the situation is quite different, #1 has been taken off screen long ago and its index is now blocked by a blue soldier that will stick around for at least a bit longer. | ||
− | * At frame 775, the turret in #5 loads. Both index with a drop value of 20 are blocked by objects on screen, which means | + | * At frame 775, the turret in #5 loads. Both index with a drop value of 20 are blocked by objects on screen, which means both 20 will remain. |
* At frame 819, the red soldier in #5 spawns. Same situation as above. It can't access any of the index with drop value 20. | * At frame 819, the red soldier in #5 spawns. Same situation as above. It can't access any of the index with drop value 20. | ||
− | |||
* At frame 987, #3 goes off screen. | * At frame 987, #3 goes off screen. | ||
+ | * At frame 1017, forward progress is halted awaiting blue soldiers/garbage sprites to load. This is a little before #6 is loaded into memory. Blue soldiers tend to spawn on the right side and get stuck on the center wall for a while. Garbage sprites can appear either to the left or to the right and are loaded off-screen. There should be ~1 object/second. If no blue soldiers appear, chances are that garbage sprites have been loaded off screen instead. Either is ok since neither blue soldiers nor garbage sprites have any impact on the drop values. | ||
* At frame 1035, a garbage sprite is loaded off screen. It now occupies index 0, which has the drop value 20. | * At frame 1035, a garbage sprite is loaded off screen. It now occupies index 0, which has the drop value 20. | ||
− | * At frame 1107, a blue soldier is loaded. It also gets a low index and now occupies the other drop value 20. At this point, it might seem a bit too well prepared with the save states to make things fall nicely into place, but the turn of events is actually fairly likely. | + | * At frame 1107, a blue soldier is loaded. It also gets a low index and now occupies the other drop value 20. At this point, it might seem a bit too well prepared with the save states to make things fall nicely into place, but the turn of events is actually fairly likely. As already mentioned above, #1 and #3 always appear to end up with low index. So with #3 recently having gone off screen and with the only objects spawning are blue soldiers and garbage sprites, one of the 20 is very likely to be occupied by these. The other index with drop value 20 should always be occupied by blue soldiers that are now about to go off screen. So again, it's likely that also the other index with drop value 20 will be inherited by random spawns at this point. |
− | * At frame 1167, #6 is loaded, but gets allocated a higher index because of the recent pause. Same goes for #7, which is loaded shortly after. | + | * At frame 1167, #6 is loaded, but gets allocated a higher index because of the objects loaded during the recent pause. Same goes for #7, which is loaded shortly after. |
− | * At frame 1523, a special, but recurring, case is demonstrated. When | + | * At frame 1523, a special, but recurring, case is demonstrated. When garbage sprites are spawned early on, they should be destroyed and the the fuel (if any) should be collected. If fuel is not collected, it will despawn ~40 frames before #10 appears, which adds a considerable risk of overwriting one of the 20 drop values. |
* Between frame 1691 and 1759, four high risk objects are loaded, #8, #9, #10 and the helicopter. All of them are likely to overwrite 20 drop values. Unless advancing slowly, in order to spawn blue soldiers/garbage sprites to fill the low index, there is not much to do other than cross the fingers and hope for the best... | * Between frame 1691 and 1759, four high risk objects are loaded, #8, #9, #10 and the helicopter. All of them are likely to overwrite 20 drop values. Unless advancing slowly, in order to spawn blue soldiers/garbage sprites to fill the low index, there is not much to do other than cross the fingers and hope for the best... | ||
Following this route should increase the fuel drop rate to ~50%.<br /><br /> | Following this route should increase the fuel drop rate to ~50%.<br /><br /> | ||
− | Before ending this section, we'll | + | Before ending this section, we'll briefly talk about #2, which hasn't been mentioned above. From emulator testing, it appears to often occupy one of the higher index. However, the garbage sprites tend to occupy the lower index (partly because of the distribution of objects in that area, but possibly also some underlying and currently unknown mechanics). Since it appears to be hard to get garbage sprites with high index, that objects overwriting drop values are pushed towards high index by the route and since it's somewhat hard to get to #2, it hasn't been included in the routes above. |
Latest revision as of 16:19, 11 November 2020
This page goes more in depth on how to manipulate fuel drops for the helicopters in areas 3 and 4. The RAM-addresses used here are listed in the memory address section.
Contents
Some background about object allocation in the RAM
All objects that aren't part of the background are allocated to RAM-address $500 and onwards (player 1 is always in $4FE and player 2 is always in $4FF, but they can be disregarded here since they don't interfere with the foreign objects). This includes enemies, destroyable structures, hidden items, mines etc and even bullets. These addresses are referred to as "object addresses". The object address with index 0 corresponds to $500, index 1 corresponds to $501 etc. A new object entering the screen will be allocated to the lowest available index. If two objects enter the screen at the same frame, the object to the left will (usually, but not always,) first be attributed the object address and will then get the lower of the available index. When an object leaves the screen (regardless of how), the corresponding index will be restored to null. Dropped objects will retain the address of the initial object though. Bullets are also an exception as they will be allocated to a high index (without interest for the topics of this page).
Different objects provide different values to the object addresses. Some objects share the same value, so there must be additional addresses that determine the exact type of object. However, these values aren't overly important to know, but are helpful when analyzing emulator movie files. Below are some common values (but the list is nowhere near complete):
Object address value | Description |
(128) | Player moving forward |
(120) | Player in tank/heli |
(64) | Rail turret, drops, mine |
(63) | Exploding rail turret |
(62) | Soldier, heli, blinking object |
(61) | Dying soldier, exploding barrel |
(58) | Returning soldier, missile target plate |
(54) | Guardian soldier |
(53) | Dying soldier (alternating with 75) |
(50) | Missile target plate with incoming airstrike |
(45) | Dying kamikaze (alternating with 83) |
2 | Helicopter/tank in use |
64 | Unrevealed mine |
66 | Object not on screen (includes unrevealed hidden items and destroyable structures with drops) |
75 | Dying soldier (alternating with -53) |
83 | Dying kamikaze (alternating with -53) |
The type of drop is determined by the value of the object's "drop address". The drop addresses start with $0676. When the object leaves the screen, the drop address isn't reset to null, like the object address. When an object is allocated to an object address, its "drop address" can be overwritten with the object's corresponding drop value. This drop value is overwritten for most objects (including many objects that don't drop anything), but for example blue soldiers don't overwrite the drop values. The only drop value of interest is 20, which means fuel will be dropped.
To watch the object allocation and the drop values in an emulator, the following package can be useful:
File:Ikari Warriors (U) - address watch.zip
It contains two RAM-watch files for the object types and drop values, respectively. It also contains a lua script that shows where on the screen the objects are located. It has the format [object value, index].
Area 3 fuel drop
This section will explain how to increase the chances of getting a fuel drop from the first tank in the helicopter section.
The tank drops in this game are determined by the index the tank is allocated to. If the tank is in index 0 (= $500), it will drop a tank and if it's in index 2 (= $502), it will drop a fuel. All other index will result in no drop. The goal of this manipulation is therefore to maximize the chances of the tank spawning in index 2. This can be broken down in two parts. One part leading up to the fuel drop and one part ensuring the helicopter isn't blocking the relevant index. It's easiest to understand the route by starting with the fuel drop itself and then retracing the steps while trying to keep the drop conditions.
Part 2 - getting the tank in index 2
With reference to the numbering in the screenshot above, we can see that the tank will be allocated to index 2 if, and only if, index 0 and 1 are unoccupied when #1 and #2 appear on screen. This is only true if #3-#5 get index >2 and the objects occupying index 0-2 at that point disappear before the mines appear. There are 4 enemies (the three in #6 + one underwater enemy not shown in the screenshot) and #7 that are always present and can help achieve this condition. If index 0-2 are occupied among these 5 objects and they despawn between the gates and the mines, the tank will get index 2. #7 will disappear after #3-#5 have spawned, but before #1 and #2, so that's never an issue. Fortunately, the four enemies can also be taken out so they despawn according to this condition.
File:Ikari Warriors (U)-3 fuel manip.zip
The fm2-movie in the file above shows a successful fuel drop. Other than illustrating the description above, it's also worth mentioning the role of #8. If the knife gets an index in the range 0 to 2 (which is not feasible to know in real-time) and is not collected, the leftmost gate (#3) will inherit its index, which means the fuel drop will not be possible. If it's collected, one of the enemy soldiers will inherit its index. #8 should therefore always be collected, no matter what.
File:Ikari Warriors (U)-3 fuel fail.zip
This fm2-movie illustrates some of the things that can go wrong and prevent the fuel drop. Assuming the execution was correct, there are three types of occurrences that will cause problems:
- There is a fifth enemy soldier around #6 in the screenshot above.
- The underwater kamikaze that comes from the left side and starts following you.
- An enemy soldier is running on the right and manages to stay on screen until the group in #6 spawns.
The first case is not possible to work around. All you can do is hope that it didn't get one of the lower index (but they often do since they tend to spawn earlier than the group in #6).
The second case is shown in this movie, but the threat is avoided by barely managing to scroll it off screen before the group at #6 spawned. This enemy doesn't always appear because of sprite limitation, which is an advantage. However, if you collect the heart (like shown in this movie), an index will be released, which increases the chances of spawning this enemy. Avoiding the heart will also result in a more direct route and if this enemy still spawns, it will be scrolled off screen faster. For safety, it's therefore better to leave this heart alone.
It's case 3 that was the root cause in this case. Despite being hit, the enemy's dying animation lasted long enough for it to occupy index 0 when the enemies at #6 spawned. This could have been mitigated by pausing before #6 appeared, but that would also have meant that the underwater enemy probably wouldn't have been pushed off screen. Pausing also increases the risk of more spawns in front of you, which is dangerous in this section. Overall, a difficult situation to deal with.
By following the route and suggestions above, the tank will drop fuel very roughly three times out of four.
Part 1 - index of the helicopter
In the part 2 above, nothing was mentioned about the index of the helicopter itself. The helicopter is treated like any other object and will be dealt an object address according to the same rules. This means that if the helicopter has index 0, 1 or 2, it will be virtually impossible to get a fuel drop later on. This section will describe how to manipulate the helicopter into a higher index.
Let's start by looking at the map of the section in question with all items shown:
The objects down to the topmost barrel will be on screen when the helicopter appears. So there are 5 non-moving objects that can potentially help keeping the helicopter out of index 0-2. However, there are also blue soldiers creating some randomness by spawning between the barrel section and the helicopter. So the threat comes from either a blue soldier or one of the lower barrels leaving the screen right before the helicopter appears. The helicopter will then inherit a potentially low index. The only realistic variation in terms of routing comes in the barrel section. You can either go to the left, which is faster, or to the right (going straight ahead is not a good option on foot; EDIT (111120): Since this page was created, a viable route through the middle has been found. However, it hasn't been analyzed for the fuel drop analysis yet.). Let's look at both options.
Left side of the barrel section
File:Ikari Warriors (U)-3 Heli address fail.zip
As can be seen from the movie name, it shows a case where the helicopter was allocated to an index in the range 0-2, which will prevent the fuel drop later on. To understand why this happens, let's take a look at the map again, but this time with arrows showing how the index are transferred from one object to the next:
As a first step, we can see that there are roughly three transfer phases. The first phase (green arrows), where unknown index are transferred to the objects around the gate. The second phase (red arrows), where the gate object index are transferred to the barrels. The third and final phase (yellow arrows), where the barrel index are transferred into the objects leading up to the helicopter. Numbers in yellow indicate the number of frames between the two connected objects disappear/appear. If a blue soldier is spawned (rng) in the meantime, it will inherit the index instead. As a general rule, the more arrows and the longer chain leading up to an object, the more likely it is to contain a low index.
In phase one (green arrows), we see that #4 and #5 are likely to inherit low index. Depending on when the red soldier leaves the screen, either #6 or the triple shot will inherit its value (the former is to prefer).
In phase two (red arrows), it's difficult to imagine a case where the left barrel in #2 will have an index higher than 2. There are a few more barrels that are likely to have a low index, but not to the same extent as #2. It's also worth noting that #3 gets the index allocated before the barrel to the left, even though they appear at the same time. It's not known why.
In phase three (yellow arrows), we can see the issue with this route. #2 leaves the screen some 24 or so frames before the helicopter appears. If no blue soldier appears in the meantime, it's more or less guaranteed that the helicopter will have an index in the range 0-2, which is what we wanted to avoid in the first place. It can be confirmed in the fm2-movie above that this is indeed what happened.
Right side of the barrel section
File:Ikari Warriors (U)-3 Heli address manip.zip
The first thing to notice is that this route is bit less straight-forward and a little over a second slower than the left side of the barrel section. With the route in mind, let's take a look at the map with the flow of the index inheritance for this route.
The green and red arrows are the same as before, while the yellow arrows have moved a bit. Instead of almost guaranteed giving a low index to the helicopter, the barrels at #2 are now destroyed and will likely feed the triple shot object. With in most cases a steady flow of blue soldiers appearing before the helicopter and a high probability of some of the fixed objects carrying low index, it has now become quite improbable (~10%?) for the helicopter to get an index in the range 0-2. Some final comments:
- By not destroying #1, you'll have another fixed object on screen when the helicopter appears, which increases the chances even more of blocking the index 0-2. However this also introduces some other risks instead as well as a minor time loss from a forced detour when dodging the bullets from #1.
- Leaving or destroying #3 is somewhat a matter of taste. By destroying it, its index will go to #1. By leaving it, there are two chances for the mine getting a low index (and in the ideal case even giving a low index to both mines, although that is pretty unlikely) in case a blue soldier appears right before.
Area 4 fuel drop
The objective here is to get one of the "garbage sprites" around the helicopter to drop fuel. This occurs when the drop value of its index is 20. If you enter this section with at least one drop value of 20, the fuel will usually drop pretty quickly without problems. So the issue is to figure out a way for how to get to that section without all the 20ies having been overwritten. Let's take a look at the map with some relevant objects indicated:
Let's start from the bottom. When a new barrel appears on screen, it overwrites the previous drop value to a random (?) value. When shooting a barrel that contains a fuel, its drop value will always turn to 20. However, it's only the last fuel barrels (#1, #2 and #3) that are potentially of interest, since the drop values from the first barrels will always be overwritten by the last barrels. So the barrel section is about filling the drop value addresses with 20ies. The path from the barrel section to the helicopter is then to keep at least one 20 in memory. It doesn't seem to be possible to get 20 back in memory around the helicopter, so this is where it gets a bit tricky. #5 (both the red soldier and the turret), #6, #7, #8, #9, #10 and the helicopter will all overwrite the drop value of their respective index...
To understand the difference between a good and a bad route, we will look at two examples. One speedrun route that turns out to be counterproductive with respect to the fuel drop and one route that aims to instead optimize the chances of the fuel drop.
Speedrun route
File:Ikari Warriors (U)-4 Fuel fail.zip
- At frame 518, #3 is destroyed to load another 20 into the memory. At this point, there are two 20 among the drop addresses.
- At frame 619, #1 is scrolled off screen. This barrel tends to always have a low index, so the next object appearing is likely to inherit its index.
- At frame 638, the turret (#5) spawns and overwrites the 20 from #1. Now there is only one 20 left.
- At frame 835, #3 is scrolled off screen.
- At frame 879, #6 is loaded, assigned index 2 and therefore overwrites the last 20. From this point, there are no 20 left among the drop values in the memory and it's no longer possible to get a fuel drop with the helicopter.
The issue here is that the first two turrets spawned relatively short after the fuel barrels were scrolled off screen. The only way to avoid losing the 20 already here would be to rely on blue soldiers to spawn in a very timely fashion. And even if you got this far with drop values of 20 in the memory, there are still several objects left that can overwrite drop values. The chances of getting a fuel drop with this route should be <10%.
Fuel-optimized route
File:Ikari Warriors (U)-4 Fuel manip.zip
- At frame 515, the fuel from #1 is collected. This frees up its object address with the hope of filling it with blue soldier instead of the turret.
- At frame 603, the index 0 from #1 is taken over by a blue soldier (there should always be one or two random blue soldiers spawning around here). The drop value of index 0 remains 20. Without going into an analysis of how the barrels inherit each other's index, #1 and #3 seem to always end up with low index.
- At frame 650, we're in a similar situation to the speedrun route with two 20 loaded in memory. Still, the situation is quite different, #1 has been taken off screen long ago and its index is now blocked by a blue soldier that will stick around for at least a bit longer.
- At frame 775, the turret in #5 loads. Both index with a drop value of 20 are blocked by objects on screen, which means both 20 will remain.
- At frame 819, the red soldier in #5 spawns. Same situation as above. It can't access any of the index with drop value 20.
- At frame 987, #3 goes off screen.
- At frame 1017, forward progress is halted awaiting blue soldiers/garbage sprites to load. This is a little before #6 is loaded into memory. Blue soldiers tend to spawn on the right side and get stuck on the center wall for a while. Garbage sprites can appear either to the left or to the right and are loaded off-screen. There should be ~1 object/second. If no blue soldiers appear, chances are that garbage sprites have been loaded off screen instead. Either is ok since neither blue soldiers nor garbage sprites have any impact on the drop values.
- At frame 1035, a garbage sprite is loaded off screen. It now occupies index 0, which has the drop value 20.
- At frame 1107, a blue soldier is loaded. It also gets a low index and now occupies the other drop value 20. At this point, it might seem a bit too well prepared with the save states to make things fall nicely into place, but the turn of events is actually fairly likely. As already mentioned above, #1 and #3 always appear to end up with low index. So with #3 recently having gone off screen and with the only objects spawning are blue soldiers and garbage sprites, one of the 20 is very likely to be occupied by these. The other index with drop value 20 should always be occupied by blue soldiers that are now about to go off screen. So again, it's likely that also the other index with drop value 20 will be inherited by random spawns at this point.
- At frame 1167, #6 is loaded, but gets allocated a higher index because of the objects loaded during the recent pause. Same goes for #7, which is loaded shortly after.
- At frame 1523, a special, but recurring, case is demonstrated. When garbage sprites are spawned early on, they should be destroyed and the the fuel (if any) should be collected. If fuel is not collected, it will despawn ~40 frames before #10 appears, which adds a considerable risk of overwriting one of the 20 drop values.
- Between frame 1691 and 1759, four high risk objects are loaded, #8, #9, #10 and the helicopter. All of them are likely to overwrite 20 drop values. Unless advancing slowly, in order to spawn blue soldiers/garbage sprites to fill the low index, there is not much to do other than cross the fingers and hope for the best...
Following this route should increase the fuel drop rate to ~50%.
Before ending this section, we'll briefly talk about #2, which hasn't been mentioned above. From emulator testing, it appears to often occupy one of the higher index. However, the garbage sprites tend to occupy the lower index (partly because of the distribution of objects in that area, but possibly also some underlying and currently unknown mechanics). Since it appears to be hard to get garbage sprites with high index, that objects overwriting drop values are pushed towards high index by the route and since it's somewhat hard to get to #2, it hasn't been included in the routes above.