Ikari Warriors (NES)/Fuel drop manipulation - Revision history

Ktwo: /* Part 1 - index of the helicopter */

2020-11-11T22:19:06Z

‎Part 1 - index of the helicopter

Ktwo: /* Some background about object allocation in the RAM */

2020-11-11T22:13:24Z

‎Some background about object allocation in the RAM

Ktwo: /* Part 1 - index of the helicopter */

2017-04-14T10:23:01Z

‎Part 1 - index of the helicopter

Ktwo: /* Part 2 - getting the tank in index 2 */

2017-04-14T10:20:10Z

‎Part 2 - getting the tank in index 2

Ktwo: /* Some background about object allocation in the RAM */

2017-04-14T10:12:20Z

‎Some background about object allocation in the RAM

Ktwo: /* Part 1 - index of the helicopter */

2017-04-11T16:55:23Z

‎Part 1 - index of the helicopter

Ktwo: /* Some background about object allocation in the RAM */

2017-04-11T16:52:46Z

‎Some background about object allocation in the RAM

Ktwo: /* Area 4 fuel drop */

2017-03-30T15:42:49Z

‎Area 4 fuel drop

Ktwo: /* Some background about object allocation in the RAM */

2017-03-30T15:04:04Z

‎Some background about object allocation in the RAM

Ktwo: /* Part 1 - index of the helicopter */

2017-03-30T15:03:18Z

‎Part 1 - index of the helicopter

@@ Line 94: / Line 94: @@
 [[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 />

@@ Line 62: / Line 62: @@
 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] and follows the x-value of the object on screen. The y-values of the different objects are unfortunately harder to visualize and haven't been implemented in the script.<br /><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==

@@ Line 98: / Line 98: @@
 <u>Left side of the barrel section</u><br />
 [[File:Ikari Warriors (U)-3 Heli address fail.zip]]<br />
-Similar to the movies above, a lua and a wch-file have been included to make it easier to follow the objects' index. 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 />
+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 />

@@ Line 75: / Line 75: @@
 [[File:Ikari Warriors (U)-3 fuel manip.zip]]<br />
-The fm2-movie in the file above shows a successful fuel drop. The lua script (in the format [object value, index], while following the x-position of the object on screen) and the wch-file both contain the object addresses to make it easier to follow the address allocations. 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 />
+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 />

← Older revision		Revision as of 10:12, 14 April 2017
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] and follows the x-value of the object on screen. The y-values of the different objects are unfortunately harder to visualize and haven't been implemented in the script.<br /><br />

	==Area 3 fuel drop==		==Area 3 fuel drop==

@@ Line 101: / Line 101: @@
 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 />

@@ Line 2: / Line 2: @@
 ==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 therefore always have the lower 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 />
+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):

@@ Line 134: / Line 134: @@
 <u>Fuel-optimized route</u><br />
 [[File:Ikari Warriors (U)-4 Fuel manip.zip]]<br />
-* At frame 515, the fuel from #1 is collected. This frees up its index with the hope of filling it with blue soldier instead of the turret.
+* 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 a low index.
+* 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 they will both remain.
+* 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 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. Without going into a detailed analysis of how the barrels inherit index, #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 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 #6 gets stuck in the wall and the wall contains a fuel, it has to be collected. If not, it will despawn right before appears, which is almost guaranteed to inherit its index and hence overwrite its drop value.
+* 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%.<br /><br />
-Before ending this section, we'll end with some comments about #2, which hasn't been mentioned above. From emulator testing, it appears to often occupy one of the higher index. However, 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 doesn't appear to make much of a difference for the fuel drop and since it's somewhat hard to get to, #2 hasn't been included in the routes above.
+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.

@@ Line 85: / Line 85: @@
 ===Part 1 - index of the helicopter===
-In the part 2 above, nothing has been 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 />
+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 />
@@ Line 93: / Line 93: @@
 <u>Left side of the barrel section</u><br />
 [[File:Ikari Warriors (U)-3 Heli address fail.zip]]<br />
 Similar to the movies above, a lua and a wch-file have been included to make it easier to follow the objects' index. 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 />
@@ Line 107: / Line 106: @@
 <u>Right side of the barrel section</u><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 />