It always amuses me that the code for calculating velocity is perfectly reasonable by modern game standards, it's only awful because *this is a NES and there's no multiply instruction*
The original dos version of XCOM UFO Defense shipped with pre-computed sine/cosine values in game files, due to hardware limitations on lower end systems
I have played Ikari Warriors 2 on the nes (which I assume has similar code) and always wondered why the control was so bad, the character so slow, why the digitized voice line sounded completely awful and utterly incomprehensable, and why any time you paused the screen would go blank for 2 to 5 seconds before going from game to menu or vice versa. Why does it take longer than any other pause menu in existence? I'd really like to know what nonsense it's doing in the pause function, or if Ikari Warriors 1 does the same thing an explanation for that would suffice. A "this is fine" meme would go well with 15 fps for Ikari Warriors 1. 😂
Oh I’ve on many occasion developed things that were slow to run but easy to change because the designers were annoying and designed it that way and tossed them the keys. That’s the other plausible scenario, no idea how to make the game fun let’s just code the math in correct and make it easy to change. Ie they had way more brains than time
Its actually kind of impressive they took what could be considered a modern solution and used it on underpowered hardware. They just could have maybe tested this and seen the results and put that little trick in their back pocket for later.
One of my proudest achievements in software development was an easy to read (and maintain) function that used deterministic finite automaton graphs to decide which placeholder image to render inside a shopping cart based on the titles of the items (dumb design beyond my control made that a necessity). Of course I could have used just a dirty, fast to process, and long regular expression, even use a tool to automatically generate them each time it needed modification (a total of one time in three years btw), but WHERE'S THE FUN IN THAT, I just wanted to flex my useless knowledge on theoretical computer science.
To me it feels like they implememted it that way for making it more flexible and would be intended to be optimised later but they probably ran out of time and just kept it like that to release the game in time.
The funny thing is that, as a programming layman, I'd always put the shoddy performance of these old Micronics games down to basic laziness. I had no idea that they were actually overengineered in counterproductive ways.
If you want your facility to not function in a way that is conducive to human use, get an engineer to design it for a year and tell him. "we're optimizing use of machines with minimal space." You'll get this outcome. Why do you think it's impossible to disassemble certain things directly on something, because a screw is at a place a screw driver simply cannot reach at all without taking apart half the device?
follow up: If you want it properly built, tell the same engineer you have two weeks to design it, and it must be modular, with everything built in a way that can be removed without removing other components (like how old business computers of the 90's were with removable CD rom drives and hard drives.. with removable slots, like PMCI that could be used for modular upgrades or if redesigned, could be used for HDs or ram expansions) When have you, past the 2000's, seen a laptop with modular PCMIC slot components or modular components in general, for that matter?
@@PhysicsGamer yes my computer can be opened and the HDs and RAM be removed/replaced. But it isn't modular. It isn't accessible in anyway other than disassembly.
That's a marvelous example of a well-designed algorithm (fixed point multiplication) applied in the worst way possible. And a reminder that being a programmer was not a walk in the park, in a time where no internet and scarce literature were available. Thanks for the video, much appreciated as always!
Reminds me of feedback on why a professor picked me up for an Arduino project, because I came from another uni with a notorious "bit scrubber" professor and their average student was too busy using design patterns on a machine that had 2KB of RAM, just because you could use the heap doesn't mean you should. My first time refactoring the code I turned the lot of it in lookup tables, removed or drastically reduced code that wrote in the limited write EEPROM complete with checks to avoid burn-in, and now the old code that couldn't be expanded because it maxed out RAM and was unstable now used like 5% of the resources, rock solid stability and could be greatly expanded if new functions used the same methodology. "Why don't you use double precision floating point?" "Remember binary arithmetic? Multiply these two numbers with 8 bit sized registers. I need to run this code at least 2000 times per second when this routine is called. Go."
Good explanation! I can see how the developer thought that this implementation is reasonable, from a mathematical point of view, but it's terrible from a gameplay standpoint. Sometimes it's better to be fast and accurate enough, than slow and accurate.
What they really should have done is reither emove the ammo count, have the character firing continously (or the option to turn on and off with select) and have the A, B buttons rotate the character. Hold select for grenades. That or go for a two controller setup, like the NES version of Smash TV had.
My thought is the designers were trying to reduce the bullet hell shooter frustration of having enemies in areas you can't reach. If 8 directions leaves too many gaps and 16 directions wasn't practical. If you allow for a bullets in between the 8 directions while rotating, they believed it would be less frustrating to players.
Better solution would be to increase movement speed to shift over to move your shots in line. One button could be a "lock on" which converts the dpad to movement only, locking your direction. The other button shoots.
It's crazy that they chose to attempt to band-aid the problem by changing the number of directions instead of fixing the actual problem by simply using the Control Pad as intended. And if that wasn't good enough, they could've also slowed down the enemies so they don't dodge the bullets as often. It looks like they move at twice the player's speed...
It gets far weirder than assembly. Contrary to what Google search AI regurgitates, they weren't all assembly language. A surprising number of early console games had script interpreters in them. Probably not BASIC running under the hood, but still very sophisticated with conditional branching, math, variables and extensive script functions hooked into everything. (graphics, animation, sound and processor intensive stuff was in assembly, but governed by scripts that weren't assembly language) My experience is mostly limited to SNES game hacking. In Shadowrun, everything is done in scripts, to the nth degree. Hired shadowrunners are entirely controlled by scripts, even following the player around when not fighting, their movement/position is set by a script. That's also why the game gets so laggy when more than three enemies are on screen. That secret debug room that was revealed a few years back was never found, because it was a script, buried in a bottomless pit of scripts that nobody ever decyphered. It's also very extensive in Ultima 6 The False Prophet. A noteworthy example is that leveling up is done inside a dialog script that's shared between the shrines. It checks exp and current level against constants and increments the level, or those checks fail and it reports that more experience is required ... all done in some really clunky interpreted code.
The 6502 actually does have decimel correction but the Ricoh 2A03 used in the NES disabled it on the die so they could "legally" bootleg it. Before 1990 CPU designs were only covered by patents and removing that feature broke the patent even though the transistors for it were still on the stolen shadow mask (actually stolen, they used an actual MOS Technology 6502 shadow mask that had been smuggled out of a foundry). Basically Ricoh and Nintendo did the equivalent of stealing a blueprint and then blacking out a few wires with a sharpie and claiming it was an original design. And when MOS got suspicious and decapped an 2A03 and found it was just a crudely edited 6502 and connected it to the missing shadow mask Nintendo and Ricoh pointed at each other and said that the other guy did it and they had no idea.
Nintendo wanted to use the actual MOS 6502 but wanted to source it through another Japanese company, hence why Ricoh came up with its own 6502 clone the 2A03.
@@ClassicTVMan1981XThey didn't come up with it though they just stole it. As in they straight up literally stole a 6502 mask from a MOS authorized foundry and then made a few changes to it so they could try and claim it wasn't a 6502. Which "legally" it wasn't under pre 1990 patent laws covering ICs, but realistically it was a very, very skeezy 6502 bootleg. And I don't believe for a second Nintendo's cockamamie story that they dindu nuffin and Ricoh did it all behind their backs. All makes sense when you understand that the entirety of the Japanese video game industry has close ties with the Yakuza.
To be fair I can see why decimal flag was removed, it is not used much in general, it has few quirks of its own, and converting hex to dec values to be displayed on screen is pretty easy anyway. Cost reductions being the main reason for all the other stripped 6502 variants.
The NES port of Smash TV using two controllers was pretty smart, although that meant coop was difficult to achieve since most people didn't have the ability to get four controllers hooked up.
If you play the arcade version of Ikari Warriors on the fbneo emulator, I believe by default it maps the right analog stick to direction and fire. Essentially it turns it into a twin stick shooter.
wait what the heck, why did they store the entire 360 degrees of sin/cos like that. they know that it's the same values out of phase with each other and could have calculated accordingly.. and that they're symmetrical and everything.. these are all properties we knew long long ago!!!
How much memory do the extra instructions require? And they must be executed on every cycle, with multiple jumps. (And no I'm not defending Ikari Warriors. I bought the game back in the day, hated it, and we called every bad game after that "so Ikari.")
Creating a "cheat sheet" of lookup values means that the processor doesn't have to spend extra time calculating any variations. The longer the cheat sheet, the more space is used in the ROM, but the less taxing the lookup process is on the CPU. The theory is solid and the trade-off can be justifiable in other contexts, but Micronics' decision to implement this as part of a complicated and taxing custom multiplication routine in the first place sort of undercuts the whole idea.
The fact that there is a whole lot of ROM filled with $FF makes me wonder why they didn't just have a sine/cosine table for each velocity. That would have saved them the trouble of all that multiplication. Then again, it's hard to know how much space a game will need while you're making it.
Plus they didn't even use symmetry to cut down the number of entries to a fraction necessary. They shouldn't have used 16 angles in the first place. A more reasonable 8 angles is pretty easily calculated by just using 1 / sqrt(2) magnitudes (instead of unit) when multiple axes are active.
@espfusion The issue with symmetry is that you need extra code to handle the symmetry. Handling symmetry is usually slower than a simple lookup. And if the table is small enough, then the size of the symmetry code can exceed the size of the memory saved from the lookup table.
congrats on finally getting 100k subscribers! seeing that number hover at like 98.7 for the past several months has been killing me, like "these videos are incredible, where the hell is everybody??"
Twin stick controls are obviously the best (especially analog), but the hold-fire-to-maintain-aiming-direction method used in Shock Troopers on the Neo-Geo works pretty good too. So many of these old top-down run&guns would have held up so much better if they had it too.
As mentioned by someone else, the NES port of Smash TV used the rare idea of using two controllers for one player, one D-pad for movement, and one for firing direction. I always felt that worked well for the NES, although admittedly it limited coop since most people couldn't get four controllers hooked up to their system.
Ikari Warriors was never designed to be a twin-stick shooter, and the pace of the game isn't balanced for that. Of course, it also wasn't balanced for this monstrosity of a control scheme...
if the game were to be rebuilt from the ground up I think the best control solution would be to have two movement "modes" switched between by pressing select: a "default" mode that lets you snap freely to eight directions and fire the way you're facing, and a "strafe" mode that locks your firing direction to the last direction pushed and lets you move around freely while facing that direction
that, or make the movement instantly snap regardless of direction while still maintaining the rotation calculations so you sort of get to choose which direction you would've faced. definitely needs to rotate faster than 15 fps for this to work though lmao
I have a feeling the dev was a clever mathematician but less clever bare metal programmer. Or perhaps more likely the programmer was caught between a strong headed designer and whoever held the money bags
I imagine they said "there's a fairly well known arcade game that we can translate to the NES so there's free advertising built in." There was probably a programmer and artist. They said "the arcade has a special rotating controller, so should we--" At that point they got cut off. "I don't know or care what you're talking about. You have 2 weeks."
On top of that, its entirely possible Micronics had zero access to any source code or assets, and had to remake the game entirely off the final arcade version... and probably just pictures and video at that.
When you look at Micronics' entire catalog, it seems more like they were just looking to do quick and cheap turnarounds. Look at their port of 1942. It's still 15 FPS and is roughly as bad as Ikari Warriors. Whether you believe the "it was just one guy trying to make a buck while in college" rumor or not, Micronics never really demonstrated much in terms of competent design.
An easy enough optimization one could do (at least from a memory standpoint, might also save cycles) is that you don't need a full-sized lookup table for sine/cosine-you could go as low as 90° (maybe even 45°!) and just use some phase shift properties to switch from one area of the unit circle to another.
One way to implement a custom controller with rotation capability would be to just...use the Super NES gamepad. Obviously the connector wouldn't fit so you would have to either rig up a hardware adapter or rewire a new plug, but other than the physical shape of the connectors, the interface is essentially identical: NES and SNES use the same serial protocol for data, with the SNES pad just sending more bits corresponding to the added buttons. Then you could code it to use the L and R buttons for counterclockwise and clockwise rotation.
Of course it would still be way cooler to have a joystick with rotary switch to input quadrature and direction, just like the arcade. Who knows... maybe they would have inspired other games to make use of that controller too.
I don't know 6502 assembly, and this is the first time since my Data Structures class 25 years ago that I've encountered fixed-point decimals, but even just looking at the horrific mess that is the velocity calculation that Micronics was certainly Doing It Wrong. Not that there was any doubt there after they decided arbitrarily to introduce an entirely new rotation-splitting mechanic to movement that was NOT in the original arcade port. Or, y'know, after only getting the game to run at 15fps. Scary stuff.... appropriate for spooky season. Great video as always.
The rotation is like the arcade, they've simply changed it from 30 degrees to 45/22.5. They only have character positions at 45. It's generally easier to deal with 45 degree angles than 30 degree angles. This tank As for the multiplication, the 6502 does not have a multiplication instruction (or division). You can easily perform multiplication by looping. This is a very "correct" way to multiply a fixed decimal by a whole number. The problem is that it is extremely slow, with a cost of, essentially O(n), where n is the whole number. It's probably just like you would see it in a "how to program the 6502" book. (A quick scan looks like the standard examples). In fact, I think this whole thing is an example of a young programmer trying to be too "correct". As he says "The math is solid, but CPU cycles are sacrificed". It could have been done better by "doing it wrong", not because it was "doing it wrong". All of that said, I think you have to remember that 15 FPS wasn't actually such a crazy thing back in those days. I just put on Ikari Warriors on the NES, and it's pretty sluggish and was never great, but it was far from terrible. The semi-tank momentum wasn't a great idea, but Ikari Warriors in the arcade was a sluggish game almost certainly on purpose, as those quarter munchers were. If they had fixed it, it would play much faster than the arcade. In retrospect, most arcade conversions that didn't play like the arcade were better. That's one reason Commando is the better game. But that's more obvious now than in the 1980's.
I work in microcontrollers for industrial applications, and there are still many instances where use a fixed or implied decimal place. Lots of 16-bit math. If you ever want to see what general computing was like 30 years ago, find a PLC programming gig. It's actually steady work and pays pretty well - you don't get laid off after one project fails to sell well.
@@eightcoins4401 With Ghost n' Goblins I also think they literally interpreted the wrong elements due to lack of experience/wisdom/time/skill. I think this game also gets an incorrect modern rep as being terrible because it is judged on the NES as a whole. This is a 1986 release. It was a massive hit then for a reason despite the performance. It's similar to looking at early 3D games; they do not hold up graphically. Also, there's a believable claim that Micronics was primarily one college kid at the time. This isn't unrealistic. For example, many years before he ruined the Xbox's market position with bad decisions, Don Mattrick was a 17 year old wunderkind porting games in record pace for Accolade.
@@kyleolson8977funny thing is, 30 degree angles would probably work better here, since sin(30) = 1/2, and sin(60) is approximated well by 7/8 (giving an angle of 61.04 degrees). Both are trivial to multiply by (shift right for 1/2, shift right by 3, subtract original and negate for 7/8).
Jeremy Parrish has talked about this but hasn't really elaborated on it any more. This leads me to believe that there isn't any more substantive info. Until someone who worked there (possibly THE person who worked there) comes forward with the tea, we'll have to keep guessing.
These games have credits, lads, the answer is burned in the ROMs. I suggest looking up Micronics on GDRI and diving into their credits list if you're interested in the details. The short answer is that no, Micronics was a team of programmers and artists like any other developer, BUT they're a small enough team that the Micronics "house style" is likely the work of the same handful of programmers.
It's very interesting to see how game programming changed. Now you compute trigonometric functions in code without even thinking about performance, here they had to implement a huge subroutine just to multiply speed by a value.
To be fair, even for its time the 6502 was a bare bones implementation. MOS traded capability for cost, and it was a good move because their customers preferred to build their own functionality than to pay more for features, especially ones they didn't need. By comparison, trigonometric functions were for all intents and purposes always supported on the x86 platform. The 8087 FPU coprocessor was released a year or so after the original 8086 and was available for about a year before the original IBM 5150 PC. That said, FPUs were pretty rare in PCs until the 80486 and game developers would have used simplified implementations anyway.
Even if you're thinking about performance, you want to compute it because reading memory (unless you're certain it's cached) is *so much slower* nowadays that you would be better off doing the math than using a lookup table. Back in those days, CPUs were so slow that reading a byte was just as fast as any CPU math operation.
Interestingly, while trig functions are still slow on the CPU, they're quite fast on the GPU. So, while you still have to avoid them in your CPU code, you can freely use them in your shaders, as the GPU hardware does a better job than most attempts to approximate them.
Wild that even as a grade-schooler who knew absolutely nothing about coding or frame rates, I could still tell when a game like Ikari Warriors or Super Pitfall (yes, we owned both at one time or another) just *felt* wrong. They simply didn't play like other games, and this deep dive into why is fascinating for now-grown-up me. P.S. Runner up for "jankiest, most frustrating mess of a game" goes to Spelunker, an Irem/Broderbund collaboration straight from NES Hell.
I find I understand more and more as I watch these, it's super cool. There is an hour long documentary on here somewhere about the development of Elite for the BBC Micro where the guy takes a 20 minute aside into the 6502 and how it works pin for pin, greatly increased my understanding of the instruction set we see in videos like this. I wish I could remember who posted that...
I have to assume this control scheme was built by pasting together some existing trig libraries and, when the original control idea didn't work, going "oh well", and shipping it anyway, like every other 80's game rushed for a deadline. You could store a lookup table for the velocities at "speed 1", add it three times to get "speed 3", include an additional table for larger values, and get the answers needed for the game in fewer total instructions while still having variable speed. If it were restricted to 8-way this would be even more true.
A lookup table for sines for any given scalar speed world be 32 bytes. Getting both a sine and cosine would be roughly 40 cycles, assuming a relatively generic retrieval code. Enough to bump the game to 20 fps? Probably not, but maybe it would get close enough that the devs would think that it's worth it to look for more optimizations.
For a custom replica of the arcade joystick, instead of mounting the entire joystick on a 12-way rotary switch, you could use a normal arcade-style joystick and put a rotary encoder on top, under the... the top part. Between the shaft and the knob. Yeah. Point is, you don't really need to know what orientation it's in when the game boots. You can just assume it's "up".
I've programmed for many processors that didn't have a divide instruction - and that's in the much more recent past. I understand their pain and have often used bitfields with shifts and rotates (usually 1 cycle execution op codes) to process fractions. Often this has to be done with the frequently accessed part of RAM in the first 256 bytes of memory (sometimes less) or an 8bit processor has to page which is a slow operation for frequently used data. In short, if you cannot normalize the values in a way that allows you to multiply and divide by bitshifts you are probably effed and need to find a more novel approach. Slowing down the framerate is one approach I suppose... But limiting directions to 8 and using a lookup table, balancing the game around movement speeds of x2 steps would be better. Vehicles move at speed 1, you walk at speed 2, planes at speed 4, bullets at speed 8 etc. Bit shift multiply/divide heaven!
Well, they had two more arcade games first. (Victory Road and Ikari 3) Lots of SNK characters became tournament fighters after SNK became "the fighting game company". The fighting game boom did a number on their creative output. I COULDA HAD CRYSTALIS 2!
I wonder which is more surprising, the fact that the Ikari Warriors were later able to redeem themselves in the King of Fighters tournament, or the fact that standalone rotary dials are somehow not affordable...
Well the original arcade game was a pretty big hit. I wouldn't say they redeemed themselves as much as they had a cringe moment when they hung out with a bad crew (Micronics).
@@CptJistuce I'm talking about modern standalone rotary dials. I've been wanting to emulate stuff like Forgotten Worlds, but I ain't gonna pay $70 for a USB rotary dial.
I've been WAITING for someone to tackle this. Okay, now that I watched the video. Here's my two cents. I would eliminate the turn/rotation entirely, and integrate a more traditional directional control. If I tap that direction, I want the character to face that direction immediately, rather than have to cycle between turning animations. That alone would improve the overall experience of the console version of Ikari warriors.
You probably will. Someone who has watched all of Chris' videos who tries to make a game is going to be starting from a better place than someone who watches random tutorials and tries to make a game.
Fascinating that this code does have a lot of thought behind it, it's not stupid and hap-hazard, but still very suboptimal. As if they started programming, had the ideas and when they realized the NES's limitations, it was too late to change course.
This episode made me think of the jump in technology between the NES and the SNES, with the prime example, to me, of a rotational shoot'em'up being Desert Strike by EA. It's wild to think about.
I once had the pleasure of helping reverse-engineer the code on an industrial machine that had to execute its control code 100 times every second, so there was a hard limit of 10ms to execute all code. But the timing always got thrown off when the machine was run by particularly skilled operators. Over the course of about a week (because I was still green and working with a programmer who's not trained in physics) we determined that a previous developer had written in a check for whether the joystick was moving along the x or y axis in which case it would skip doing the trig and return 1, -1, or 0. But if the operator strayed outside the generous deadbands on the joystick, it'd revert back to calling full-precision trigonometry functions. This would blow the execution time up from ~5 ms to 20 ms or more. Since we couldn't simply stop execution when the timer was up (it would cause undefined behavior) then anybody who developed the skill to operate the equipment with some finesse caused the program's timer to suddenly run at roughly half the intended speed, ruining all the physical calculations. 😅 I only wish my lexicon included "this meeting could have been a lookup table" at the time...
No no no no, YOU hold MY tacos mister. That's what I pay you for. Also, seeing Tiger Heli gives me a warm, nostalgic feeling of nine year old me with a couple of friends returning from Blockbuster, game in hand and a solemn vow to not rest until the game is beaten.
lol “This meeting could’ve been a look up table” got me. I love every video you put out. I hope you keep making content like this and I appreciate the hard work!
Micronics! Oh my god it looks like I played all of these Micronics games, besides Ikari Warriors the most famous one... I'll admit, 2 looked really interesting though. Bless the mess that is 15fps, but I still love when crappy developers punch above their weight (for example Color Dreams, I love these guys). I can't believe they actually coded 16 directions into this thing! It may be result of thoughtless yes, but I find it really interesting nonetheless. You did a great job, I bet this wasn't easy! I'd love to learn to code how you do, for real
Did you know this game has a player speed increase powerup? It doesn't first appear until well into the 1st stage, and of course it's hidden and easy to miss. It really make the game so much more playable and should have been the default speed in my opinion. Great video, as always!
The Atari 7800 version of Ikari Warriors has blaster master controls, so you just hold down one button to strafe, and fire with the other button. The 7800 version is better.
Interesting revelation regarding the arcade controls. I never mapped out the angles, but I always intuitively knew, and enjoyed, that the character turned faster per joystick click than the actual angle. It feels good and not at all incongruous. It just works in your brain. Also revealed in this video, a lot of problems with game controls stem from developers favoring some sense of artificial evenness or easy implementation over what feels good to the player and what's appropriate for the level of action in the game, even if it doesn't exactly jive with a programmer's or mathematician's mindset. Another good, recent video on this concept is Kosmic's "The Misunderstood Genius of Super Mario Bros." There it is discussed that the vast majority of storage in SMB is code rather than something like music or stage data. Most of the game is handling game logic in all sorts of cases with the clear goal of benefiting the player. Comparisons are drawn to other platformers with much harder and harsher game logic.
I am starting to see that most of these videos have suggestions to make these games better, and then I get disappointed that they are not getting the love they deserve. :(
Thank you. You have single handedly corrected all the rage I had for games I rented from mom and pop shops, and felt like I was scammed out of $2, over the weekend. For those of you too young to know, but mom and pop shops were the Steam version of the 80's and 90's games. You only had those games to play, and you would play the crap out of games you didn't own, because you never knew when they were going to be taken away.
I love these calculations. For whatever reason, the sine lookup tables remind me of how oscillator phase is handled on FM chips. For the envelope generator, they used a different trick to avoid multiplication there (logarithmic addition with exponent lookup tables). I can't imagine what hardware limitations prompted them to sacrifice precious CPU cycles to save ROM space, other than maybe they were contracted to use the bare minimum. Weird choices indeed, maybe clever in the wrong places...
The method of multiplying Speed with unit angular directional X/Y lookups is actually used in the first-generation Command and Conquer (they support 256 directions with support for 8 (infantry, some vehicles) and 32 (most vehicles, turrets) visual facings). It is used not only in velocity calculations, but also turret offsets when the turret is not centered on a unit and the unit rotates. Of course, that game targeted (16-bit DOS / 32-bit) PC, while this game targeted a very early console.
This feels like a two man project - one was a game designer getting resources together based on the arcade, and the other was a business / science programmer who was used to writing math software on 6502. The problem is that Nintendo (as always) cheaped out. It was noted in the Pachi Com rant, it’s noted elsewhere, but the way Ninty abused the 6502 was utter madness. So, it’s my theory that whoever designed the movement here in Ikari Warriors was expecting a lot more than Nintendo gave them.
The blame does not fall on Nintendo. Whether they "cheaped out" or not aside, there were many many high quality games made on the NES. It is a poor craftsman who blames their tools.
@@pvanukoff I don’t entirely disagree with you. But the problem is, if you were accustomed to the 6502 in a scientific setting or nearly any other machine with a full implementation of the chip, you need to shift your paradigm to really grasp the NES. Some people could do that. Some couldn’t. Micronics, certainly, couldn’t. Hence my thought that the lead programmer was trained in math and/or science.
@@endymallorn Oh yeah, I forgot. I do remember spending a whole rainy Sunday at my friend's house to beat this game. That, and going to see "42nd Street" when someone gave my mom free tickets (and my dad didn't want to go) were the two worst days of my life.
There are not much resources about it, but Heavy Barrel on NES also attempted to emulate the rotary joystick (It contains the early graphics data matching the Arcade version) before they decided to stick with the standard current direction+aim route, just like Guerrilla War.
Interesting that they allow 6 bits of integer part for the speed. I wonder if anything moves at a higher speed than, say, 15/4? Otherwise they could have cut the multiplication time in half by halving the loop count. A classic trick before CPUs had fast multipliers was to create a fixed multiplication with one or a few bit shifts, say if you want to multiply x by 5 then you calculate x + 4*x, where 4*x can be done with a bit shift. Since the speeds seem to be pretty hard coded (at least the player seems to only have a few cases), I wonder if they could have gotten away with that kind of trick instead. Should have saved a lot more execution time.
As a kid, I remember finding a few arcade cabinets that had rotating joysticks for the purpose of aiming your character. Sadly, I didn't get to play them at all. As an adult in a math class who just reviewed trigonometry, I'm a little bothered by the positive angle increases going in a clockwise direction. Regardless, this was an interesting video to watch as I folded my laundry. I find the decision making during these kinds of things fascinating.
Heavy Barrel and Time Soldiers were two other awesome arcade games with a rotary joystick. It took some getting used to, but when you did it offered some great control.
It depends on what the code is whether you're gonna get 60FPS out of it. This code is, unfortunately, far more complex than it needs to be. Also, Ikari Warriors is a 1986 game with a 128K ROM and the most minimal of bankswitching hardware. Super Mario 3 is two years later, three times larger, and has the then-new MMC3 providing much more complex bankswitching and an interrupt generator. It isn't a fair comparison even if all other things were equal.
@@CptJistuce Yeah but it's the same console. It's not like I'm comparing 1986 to 2006. It's just baffling how poorly some older games (on this channel especially) were programmed.
While we traditionally associate 2D games with 60 FPS as a bare minimum in the modern day, you'd be surprised how many games back then would target lower. I can't speak for the NES (aside for the example of Dr. Jekyll and Mr. Hide, which targets something like 12-15 FPS), but the IBM PC and compatibles in the early days often had games run slower than 60. Even Fallout 1 and 2; which came out in the era of Windows targeted 30 IIRC.
@@LonelySpaceDetective Doom's framerate was hard-capped at an ambitious-for-the-time 35, which it never reached and mostly serves to confuse people today who don't know that low-res VGA was 70Hz.
@@CptJistuce DOOM is a weird title for what we're talking about (I choose this phrasing because I do not want to get into 2D/3D discourse rn), being an FPS. While I can see someone being surprised it's capped at 35, I can also easily see them being like "well, Super FX games ran super-slow so I can see why", or something like that. Hence, why I used Fallout 1/2 as the example, since those are games just about anyone would expect to target 60.
The limited ability to perform multiplication within 6502-derived processors is a factor that persisted into the 16-bit generation. Some staff from Treasure have gone into detail on how this influenced their decision to develop games on the Genesis over the SNES. Better and more complete native support for multiplication on the 68000 made their complex movement patterns for multi-jointed multi-sprite characters much more streamlined and efficient than they ever could have been on hardware without that capability. It's a good example of how developers of the time had to play to the hardware's strengths and how that ultimately helped define the libraries and image of the console platforms themselves.
Dude, i´m not an expert but i know the SNES Ricoh 5A22 cpu (a variant from the 65c816) has hardware multiplication and division. Not only that, but the SNES PPU also can do multiplication and division in hadware too.
@@jsr734 It's not that the SNES didn't have "any" native support for multiplication, but that the extent that it did wasn't as great as contemporary hardware, sometimes even older hardware. It's an interesting facet of the realities of video game programming of the time, and it filters into how developers sometimes self-selected for their platforms.
@@jsr734 The 65816's MUL was rather slow, leading to it often being outsourced to S-PPU or the SPC700. The Genesis was generally just faster to do anything than the Super Nintendo though, despite its more limited AV chipset.
@@CptJistuce Interesting i have been researching and it seems multiplication and division is also very slow on the 68000. On the SNES cpu multiplication takes 8 cpu clock cycles, multiplication on the Genesis 68000 cpu can take between 38 and 70 cycles. Divisions on the Genesis cpu take around 140 cycles while division on the SNES cpu takes 16 cpu cycles. Also it seems the SNES ppu can do faster multiplication than the main cpu with no need to wait for the result.
7:59 Yeah I remember making practical use of trig when I was programming an enemy to follow me around. Spare time during recess. I remember always having to make special exceptions for strong nauticals like due up/down/left/right because the calculations would divide by zero or use impossibly large numbers. Always wondered at the time if there was some standardized way of dealing with those cases.
An NES rotary controller would be awesome, as long as all three Ikari Warriors and Iron Tank were reprogrammed to use it. I would buy into that stuff for sure.
awesome video! I think though you didn't hammer home how jank this whole experience is, this game is pure pain, it needs to played just for 5 minutes to experience the horror. I beat it using save states one time and even that hurt my brain. after watching this though, somehow the issue wasn't that the programmers sucked, it seems that this was an issue of the programmer being too good (or just someone with a deep love of 6502 and over engineering things) and the hardware not being enough (from a certain point of view). I do wonder how this got ok'd. how did jackal get it right and this just became a torture sim. I do hope that someday Ikari warriors nes gets a redemption arc
You know that someone at Micronics was just trying to impress Becky in QA with all of their trigonometry and algebra and MANUAL MULTIPLICATION code. Thanks a lot, Becky. You ruined Ikari Warriors on the NES, all because Steve wanted to go out with you.
I got the idea that Micronics were attempting to reproduce the rotary joystick experience in such a manner that a custom controller, had it come out for the NES system, could be deployed optionally. That never happened, making most of the work done here pointless. It's like night and day, seeing the technical wreck of this game, but also the great implementation of Guerrilla War. Both of these games were SNK-created, and both used a rotary joystick originally. But whoever worked on the home version of Guerrilla War basically did everything right, unlike here.
A little off-topic, but maybe an idea for a short section of a future video: any explanation for the code behind the flying glitch in this game? If you get in a helicopter then press A, B, and Up simultaneously, but keep holding down A or B, the result is that the character dismounts but continues sailing forward at helicopter speed while also being invincible. Presumably some failed transition out of helicopter state and into walking around state...
Removing the game's signature feature is a bold approach to adaptation, to be sure. I've played some versions of Robotron where you just shoot the direction you move. They kinda suck.
It's conceptually not really that different from twin-stick shooters, just, achieved with a single stick instead. Hell, that's typically how modern ports handle games such as Ikari Warriors. Unless you just meant in terms of porting to a console like the NES where there's only one d-pad or stick. In which case, fair, though you should understand that just as the other person said, removing a prominent gameplay mechanic is not something to be done lightly.
It always amuses me that the code for calculating velocity is perfectly reasonable by modern game standards, it's only awful because *this is a NES and there's no multiply instruction*
lol
I definitely use sin and cos for my 2D (and limited 3D) game development all the time. It's awesome to see them used back then too.
The original dos version of XCOM UFO Defense shipped with pre-computed sine/cosine values in game files, due to hardware limitations on lower end systems
I have played Ikari Warriors 2 on the nes (which I assume has similar code) and always wondered why the control was so bad, the character so slow, why the digitized voice line sounded completely awful and utterly incomprehensable, and why any time you paused the screen would go blank for 2 to 5 seconds before going from game to menu or vice versa. Why does it take longer than any other pause menu in existence? I'd really like to know what nonsense it's doing in the pause function, or if Ikari Warriors 1 does the same thing an explanation for that would suffice. A "this is fine" meme would go well with 15 fps for Ikari Warriors 1. 😂
@@joestaff89 Even then for this use case it'd be a lookup table made from those functions. There's just no point to calculate these few angles.
You'd think this game was made as a programming challenge.
"I bet I can get this thing to calculate trigonometric functions"
That's amusingly plausible. XD
It's not calculating any trig functions, just looking up the precomputed values.
Oh I’ve on many occasion developed things that were slow to run but easy to change because the designers were annoying and designed it that way and tossed them the keys.
That’s the other plausible scenario, no idea how to make the game fun let’s just code the math in correct and make it easy to change. Ie they had way more brains than time
Good God, trigonometry on the 6502.
It almost feels like someone on the dev team was just very proud of their math knowledge and wanted to implement it, performance be damned.
Honestly, I'd probably do that. (I _have_ done that to the OoT decomp. 🙃)
Pretty much this. Just because they COULD didn't mean they SHOULD.
Its actually kind of impressive they took what could be considered a modern solution and used it on underpowered hardware.
They just could have maybe tested this and seen the results and put that little trick in their back pocket for later.
One of my proudest achievements in software development was an easy to read (and maintain) function that used deterministic finite automaton graphs to decide which placeholder image to render inside a shopping cart based on the titles of the items (dumb design beyond my control made that a necessity). Of course I could have used just a dirty, fast to process, and long regular expression, even use a tool to automatically generate them each time it needed modification (a total of one time in three years btw), but WHERE'S THE FUN IN THAT, I just wanted to flex my useless knowledge on theoretical computer science.
To me it feels like they implememted it that way for making it more flexible and would be intended to be optimised later but they probably ran out of time and just kept it like that to release the game in time.
The funny thing is that, as a programming layman, I'd always put the shoddy performance of these old Micronics games down to basic laziness. I had no idea that they were actually overengineered in counterproductive ways.
If you want your facility to not function in a way that is conducive to human use, get an engineer to design it for a year and tell him. "we're optimizing use of machines with minimal space."
You'll get this outcome. Why do you think it's impossible to disassemble certain things directly on something, because a screw is at a place a screw driver simply cannot reach at all without taking apart half the device?
follow up:
If you want it properly built, tell the same engineer you have two weeks to design it, and it must be modular, with everything built in a way that can be removed without removing other components (like how old business computers of the 90's were with removable CD rom drives and hard drives.. with removable slots, like PMCI that could be used for modular upgrades or if redesigned, could be used for HDs or ram expansions)
When have you, past the 2000's, seen a laptop with modular PCMIC slot components or modular components in general, for that matter?
@@xenxander That's Framework's whole business model. And even then, most non-notebook laptops do still have swappable RAM and hard drives...
@@PhysicsGamer yes my computer can be opened and the HDs and RAM be removed/replaced. But it isn't modular. It isn't accessible in anyway other than disassembly.
@@xenxander Yeah, in that case I think the closest to what you want is Framework
"This meeting could have been a lookup table" is gonna be my new email signature at work 😂
It needs do be on a t shirt
That's a marvelous example of a well-designed algorithm (fixed point multiplication) applied in the worst way possible. And a reminder that being a programmer was not a walk in the park, in a time where no internet and scarce literature were available. Thanks for the video, much appreciated as always!
Reminds me of feedback on why a professor picked me up for an Arduino project, because I came from another uni with a notorious "bit scrubber" professor and their average student was too busy using design patterns on a machine that had 2KB of RAM, just because you could use the heap doesn't mean you should.
My first time refactoring the code I turned the lot of it in lookup tables, removed or drastically reduced code that wrote in the limited write EEPROM complete with checks to avoid burn-in, and now the old code that couldn't be expanded because it maxed out RAM and was unstable now used like 5% of the resources, rock solid stability and could be greatly expanded if new functions used the same methodology.
"Why don't you use double precision floating point?"
"Remember binary arithmetic? Multiply these two numbers with 8 bit sized registers. I need to run this code at least 2000 times per second when this routine is called. Go."
Good explanation! I can see how the developer thought that this implementation is reasonable, from a mathematical point of view, but it's terrible from a gameplay standpoint. Sometimes it's better to be fast and accurate enough, than slow and accurate.
A huge part of game development is balancing accuracy and speed.
I think you're right. However, wider hit boxes would have done this, too. But they probably were committed to far to see that.
"A little janky overall" is being very generous to Super Pitfall.
You can't see it, but I am wincing and nodding at your comment right now.
@@DisplacedGamers Just the way you say Super Pitfall in the video says it all!
“A little jank” the walls literally stop working at random moments if any moving object is on screen
What they really should have done is reither emove the ammo count, have the character firing continously (or the option to turn on and off with select) and have the A, B buttons rotate the character. Hold select for grenades.
That or go for a two controller setup, like the NES version of Smash TV had.
Or package the game with a custom rotary controller! I would have begged my parents for it.
whoa larry. where ya been, mate?
Or have aim follow movement by default and have one button lock your aim so you can move freely
@@SHKEVE I've been sick :(
Hello you!
My thought is the designers were trying to reduce the bullet hell shooter frustration of having enemies in areas you can't reach. If 8 directions leaves too many gaps and 16 directions wasn't practical. If you allow for a bullets in between the 8 directions while rotating, they believed it would be less frustrating to players.
Better solution would be to increase movement speed to shift over to move your shots in line. One button could be a "lock on" which converts the dpad to movement only, locking your direction. The other button shoots.
It's crazy that they chose to attempt to band-aid the problem by changing the number of directions instead of fixing the actual problem by simply using the Control Pad as intended. And if that wasn't good enough, they could've also slowed down the enemies so they don't dodge the bullets as often. It looks like they move at twice the player's speed...
@@Treblaine Since it's a port, they needed two buttons already for bombs and interactions.
Congrats on 100k 🙂 I appreciate your work
Thanks! I appreciate your work as well.
YAY! More Assembly code that I dont understand but love to hear about it.
It gets far weirder than assembly. Contrary to what Google search AI regurgitates, they weren't all assembly language. A surprising number of early console games had script interpreters in them. Probably not BASIC running under the hood, but still very sophisticated with conditional branching, math, variables and extensive script functions hooked into everything. (graphics, animation, sound and processor intensive stuff was in assembly, but governed by scripts that weren't assembly language)
My experience is mostly limited to SNES game hacking. In Shadowrun, everything is done in scripts, to the nth degree. Hired shadowrunners are entirely controlled by scripts, even following the player around when not fighting, their movement/position is set by a script. That's also why the game gets so laggy when more than three enemies are on screen. That secret debug room that was revealed a few years back was never found, because it was a script, buried in a bottomless pit of scripts that nobody ever decyphered. It's also very extensive in Ultima 6 The False Prophet. A noteworthy example is that leveling up is done inside a dialog script that's shared between the shrines. It checks exp and current level against constants and increments the level, or those checks fail and it reports that more experience is required ... all done in some really clunky interpreted code.
The 6502 actually does have decimel correction but the Ricoh 2A03 used in the NES disabled it on the die so they could "legally" bootleg it. Before 1990 CPU designs were only covered by patents and removing that feature broke the patent even though the transistors for it were still on the stolen shadow mask (actually stolen, they used an actual MOS Technology 6502 shadow mask that had been smuggled out of a foundry). Basically Ricoh and Nintendo did the equivalent of stealing a blueprint and then blacking out a few wires with a sharpie and claiming it was an original design. And when MOS got suspicious and decapped an 2A03 and found it was just a crudely edited 6502 and connected it to the missing shadow mask Nintendo and Ricoh pointed at each other and said that the other guy did it and they had no idea.
Nintendo wanted to use the actual MOS 6502 but wanted to source it through another Japanese company, hence why Ricoh came up with its own 6502 clone the 2A03.
@@ClassicTVMan1981XThey didn't come up with it though they just stole it. As in they straight up literally stole a 6502 mask from a MOS authorized foundry and then made a few changes to it so they could try and claim it wasn't a 6502. Which "legally" it wasn't under pre 1990 patent laws covering ICs, but realistically it was a very, very skeezy 6502 bootleg. And I don't believe for a second Nintendo's cockamamie story that they dindu nuffin and Ricoh did it all behind their backs.
All makes sense when you understand that the entirety of the Japanese video game industry has close ties with the Yakuza.
To be fair I can see why decimal flag was removed, it is not used much in general, it has few quirks of its own, and converting hex to dec values to be displayed on screen is pretty easy anyway.
Cost reductions being the main reason for all the other stripped 6502 variants.
@@VinsCoolI thought it was also to make room for the audio engine.
@@Desmaad that too.
The alternate path could be taking a page out of Smash TV and using 2 controllers for 1 player, each controller splitting firing and movement duties.
I regularly play the SNES version and I can say it's a bit weird but it at least *works*
Smash TV wasn't out yet, so they couldn't have found that example.
@@DesmaadYeah, but Robotron had been out for a while, same control scheme.
The NES port of Smash TV using two controllers was pretty smart, although that meant coop was difficult to achieve since most people didn't have the ability to get four controllers hooked up.
If you play the arcade version of Ikari Warriors on the fbneo emulator, I believe by default it maps the right analog stick to direction and fire. Essentially it turns it into a twin stick shooter.
Good thing the NES version of Guerilla War was developed by SNK themselves.
That game was awesome
wait what the heck, why did they store the entire 360 degrees of sin/cos like that. they know that it's the same values out of phase with each other and could have calculated accordingly.. and that they're symmetrical and everything.. these are all properties we knew long long ago!!!
How much memory do the extra instructions require? And they must be executed on every cycle, with multiple jumps. (And no I'm not defending Ikari Warriors. I bought the game back in the day, hated it, and we called every bad game after that "so Ikari.")
Creating a "cheat sheet" of lookup values means that the processor doesn't have to spend extra time calculating any variations. The longer the cheat sheet, the more space is used in the ROM, but the less taxing the lookup process is on the CPU. The theory is solid and the trade-off can be justifiable in other contexts, but Micronics' decision to implement this as part of a complicated and taxing custom multiplication routine in the first place sort of undercuts the whole idea.
@@Sixfortyfive reread my post
The fact that there is a whole lot of ROM filled with $FF makes me wonder why they didn't just have a sine/cosine table for each velocity. That would have saved them the trouble of all that multiplication. Then again, it's hard to know how much space a game will need while you're making it.
Plus they didn't even use symmetry to cut down the number of entries to a fraction necessary.
They shouldn't have used 16 angles in the first place. A more reasonable 8 angles is pretty easily calculated by just using 1 / sqrt(2) magnitudes (instead of unit) when multiple axes are active.
@espfusion The issue with symmetry is that you need extra code to handle the symmetry. Handling symmetry is usually slower than a simple lookup. And if the table is small enough, then the size of the symmetry code can exceed the size of the memory saved from the lookup table.
The rare youtube channel which instantly presents information, rather than pad out clickbait interspliced with a million plugs, ads and shoutouts
THE LONG AWAITED MICRONICS EPISODES? I am here for it.
congrats on finally getting 100k subscribers! seeing that number hover at like 98.7 for the past several months has been killing me, like "these videos are incredible, where the hell is everybody??"
Thank you! It has been a climb to get that remaining 3%!
Twin stick controls are obviously the best (especially analog), but the hold-fire-to-maintain-aiming-direction method used in Shock Troopers on the Neo-Geo works pretty good too. So many of these old top-down run&guns would have held up so much better if they had it too.
As mentioned by someone else, the NES port of Smash TV used the rare idea of using two controllers for one player, one D-pad for movement, and one for firing direction. I always felt that worked well for the NES, although admittedly it limited coop since most people couldn't get four controllers hooked up to their system.
@@BibleClingerThe 5200 version of Robotron did the same(game even included a plastic device to clip two joysticks together).
Ikari Warriors was never designed to be a twin-stick shooter, and the pace of the game isn't balanced for that. Of course, it also wasn't balanced for this monstrosity of a control scheme...
I love the inclusion of Game Genie codes that will let me play around with your discoveries on the OG hardware.
if the game were to be rebuilt from the ground up I think the best control solution would be to have two movement "modes" switched between by pressing select: a "default" mode that lets you snap freely to eight directions and fire the way you're facing, and a "strafe" mode that locks your firing direction to the last direction pushed and lets you move around freely while facing that direction
What about B being a straff, like Mario holds B to run. Then select can be the grenade.
that, or make the movement instantly snap regardless of direction while still maintaining the rotation calculations so you sort of get to choose which direction you would've faced. definitely needs to rotate faster than 15 fps for this to work though lmao
I would have aim direction track movement direction when the fire button was released, and lock when fire was pressed.
It should be noted the Japanese controllers didn't have Start/Select on the player 2 controller.
@@todesziege I think I used to know that, but the memory definitely got erased over time. Good point.
Ah yes the "speed of excitement" 🤣🤣 Is that also taking into account the cinematic experience?
They just have highly specific ideas about what's exciting. Glaciers, sloths, molasses, that sort of thing.
“15fps - the Speed of Excitement. by Micronics” is a T-shirt I’d wear.
I wonder if it's possible to get this to run at 24fps for a true cinematic experience.
@@vxicepickxvNot reasonably on NTSC. And I wouldn't trust Micronics to code a 3:2 pulldown.
I have a feeling the dev was a clever mathematician but less clever bare metal programmer. Or perhaps more likely the programmer was caught between a strong headed designer and whoever held the money bags
I imagine they said "there's a fairly well known arcade game that we can translate to the NES so there's free advertising built in." There was probably a programmer and artist. They said "the arcade has a special rotating controller, so should we--" At that point they got cut off. "I don't know or care what you're talking about. You have 2 weeks."
@@-taz- Yeah that's probably fair. No 7+ year dev periods back in those days. Especially for outsourced arcade home conversions
On top of that, its entirely possible Micronics had zero access to any source code or assets, and had to remake the game entirely off the final arcade version... and probably just pictures and video at that.
When you look at Micronics' entire catalog, it seems more like they were just looking to do quick and cheap turnarounds. Look at their port of 1942. It's still 15 FPS and is roughly as bad as Ikari Warriors. Whether you believe the "it was just one guy trying to make a buck while in college" rumor or not, Micronics never really demonstrated much in terms of competent design.
@@carlcouture1023 But I bet they met their deadlines, and in the 80s as long as your game ran that's kind of all that mattered.
An easy enough optimization one could do (at least from a memory standpoint, might also save cycles) is that you don't need a full-sized lookup table for sine/cosine-you could go as low as 90° (maybe even 45°!) and just use some phase shift properties to switch from one area of the unit circle to another.
One way to implement a custom controller with rotation capability would be to just...use the Super NES gamepad. Obviously the connector wouldn't fit so you would have to either rig up a hardware adapter or rewire a new plug, but other than the physical shape of the connectors, the interface is essentially identical: NES and SNES use the same serial protocol for data, with the SNES pad just sending more bits corresponding to the added buttons. Then you could code it to use the L and R buttons for counterclockwise and clockwise rotation.
Of course it would still be way cooler to have a joystick with rotary switch to input quadrature and direction, just like the arcade. Who knows... maybe they would have inspired other games to make use of that controller too.
I don't know 6502 assembly, and this is the first time since my Data Structures class 25 years ago that I've encountered fixed-point decimals, but even just looking at the horrific mess that is the velocity calculation that Micronics was certainly Doing It Wrong. Not that there was any doubt there after they decided arbitrarily to introduce an entirely new rotation-splitting mechanic to movement that was NOT in the original arcade port. Or, y'know, after only getting the game to run at 15fps. Scary stuff.... appropriate for spooky season. Great video as always.
The rotation is like the arcade, they've simply changed it from 30 degrees to 45/22.5. They only have character positions at 45. It's generally easier to deal with 45 degree angles than 30 degree angles. This tank
As for the multiplication, the 6502 does not have a multiplication instruction (or division). You can easily perform multiplication by looping. This is a very "correct" way to multiply a fixed decimal by a whole number. The problem is that it is extremely slow, with a cost of, essentially O(n), where n is the whole number. It's probably just like you would see it in a "how to program the 6502" book. (A quick scan looks like the standard examples).
In fact, I think this whole thing is an example of a young programmer trying to be too "correct". As he says "The math is solid, but CPU cycles are sacrificed". It could have been done better by "doing it wrong", not because it was "doing it wrong".
All of that said, I think you have to remember that 15 FPS wasn't actually such a crazy thing back in those days. I just put on Ikari Warriors on the NES, and it's pretty sluggish and was never great, but it was far from terrible. The semi-tank momentum wasn't a great idea, but Ikari Warriors in the arcade was a sluggish game almost certainly on purpose, as those quarter munchers were. If they had fixed it, it would play much faster than the arcade.
In retrospect, most arcade conversions that didn't play like the arcade were better. That's one reason Commando is the better game. But that's more obvious now than in the 1980's.
I work in microcontrollers for industrial applications, and there are still many instances where use a fixed or implied decimal place. Lots of 16-bit math. If you ever want to see what general computing was like 30 years ago, find a PLC programming gig. It's actually steady work and pays pretty well - you don't get laid off after one project fails to sell well.
They also fucked up ghost n goblins nes making it a janky mess compared to arcade.
@@eightcoins4401 With Ghost n' Goblins I also think they literally interpreted the wrong elements due to lack of experience/wisdom/time/skill.
I think this game also gets an incorrect modern rep as being terrible because it is judged on the NES as a whole. This is a 1986 release. It was a massive hit then for a reason despite the performance.
It's similar to looking at early 3D games; they do not hold up graphically.
Also, there's a believable claim that Micronics was primarily one college kid at the time. This isn't unrealistic. For example, many years before he ruined the Xbox's market position with bad decisions, Don Mattrick was a 17 year old wunderkind porting games in record pace for Accolade.
@@kyleolson8977funny thing is, 30 degree angles would probably work better here, since sin(30) = 1/2, and sin(60) is approximated well by 7/8 (giving an angle of 61.04 degrees). Both are trivial to multiply by (shift right for 1/2, shift right by 3, subtract original and negate for 7/8).
I'd heard there was a rumor that in the early days Micronics was one person in dorm room.
I really wanna know... WHO WAS JOHN MICRONICS??
Jeremy Parrish has talked about this but hasn't really elaborated on it any more. This leads me to believe that there isn't any more substantive info. Until someone who worked there (possibly THE person who worked there) comes forward with the tea, we'll have to keep guessing.
These games have credits, lads, the answer is burned in the ROMs. I suggest looking up Micronics on GDRI and diving into their credits list if you're interested in the details.
The short answer is that no, Micronics was a team of programmers and artists like any other developer, BUT they're a small enough team that the Micronics "house style" is likely the work of the same handful of programmers.
It's very interesting to see how game programming changed. Now you compute trigonometric functions in code without even thinking about performance, here they had to implement a huge subroutine just to multiply speed by a value.
To be fair, even for its time the 6502 was a bare bones implementation. MOS traded capability for cost, and it was a good move because their customers preferred to build their own functionality than to pay more for features, especially ones they didn't need. By comparison, trigonometric functions were for all intents and purposes always supported on the x86 platform. The 8087 FPU coprocessor was released a year or so after the original 8086 and was available for about a year before the original IBM 5150 PC. That said, FPUs were pretty rare in PCs until the 80486 and game developers would have used simplified implementations anyway.
Even if you're thinking about performance, you want to compute it because reading memory (unless you're certain it's cached) is *so much slower* nowadays that you would be better off doing the math than using a lookup table. Back in those days, CPUs were so slow that reading a byte was just as fast as any CPU math operation.
Interestingly, while trig functions are still slow on the CPU, they're quite fast on the GPU. So, while you still have to avoid them in your CPU code, you can freely use them in your shaders, as the GPU hardware does a better job than most attempts to approximate them.
@@Roxor128 true, but if you need a couple calls per game object like here to get the rotation it's completely negligible even on CPU.
Wild that even as a grade-schooler who knew absolutely nothing about coding or frame rates, I could still tell when a game like Ikari Warriors or Super Pitfall (yes, we owned both at one time or another) just *felt* wrong. They simply didn't play like other games, and this deep dive into why is fascinating for now-grown-up me.
P.S. Runner up for "jankiest, most frustrating mess of a game" goes to Spelunker, an Irem/Broderbund collaboration straight from NES Hell.
god i love learning about weird quirks from vintage videogames while barely understanding anything that's being explained to me
I find I understand more and more as I watch these, it's super cool. There is an hour long documentary on here somewhere about the development of Elite for the BBC Micro where the guy takes a 20 minute aside into the 6502 and how it works pin for pin, greatly increased my understanding of the instruction set we see in videos like this. I wish I could remember who posted that...
@@TheWarmotor going by my youtube history I think your referring to this video
_Elite: "The game that couldn't be written"_
by "Alexander the ok"
@@aceae4210 DUDE! Thank you, that's exactly it! Awesome video :)
Same champ, same
@@TheWarmotor oo that sounds really interesting, im gonna check that out
I have to assume this control scheme was built by pasting together some existing trig libraries and, when the original control idea didn't work, going "oh well", and shipping it anyway, like every other 80's game rushed for a deadline.
You could store a lookup table for the velocities at "speed 1", add it three times to get "speed 3", include an additional table for larger values, and get the answers needed for the game in fewer total instructions while still having variable speed. If it were restricted to 8-way this would be even more true.
A lookup table for sines for any given scalar speed world be 32 bytes. Getting both a sine and cosine would be roughly 40 cycles, assuming a relatively generic retrieval code. Enough to bump the game to 20 fps? Probably not, but maybe it would get close enough that the devs would think that it's worth it to look for more optimizations.
7:59 Finally... Trigonometry has payed off.
For a custom replica of the arcade joystick, instead of mounting the entire joystick on a 12-way rotary switch, you could use a normal arcade-style joystick and put a rotary encoder on top, under the... the top part.
Between the shaft and the knob.
Yeah.
Point is, you don't really need to know what orientation it's in when the game boots. You can just assume it's "up".
Oh, that's a clever idea. I might build that.
I've programmed for many processors that didn't have a divide instruction - and that's in the much more recent past. I understand their pain and have often used bitfields with shifts and rotates (usually 1 cycle execution op codes) to process fractions. Often this has to be done with the frequently accessed part of RAM in the first 256 bytes of memory (sometimes less) or an 8bit processor has to page which is a slow operation for frequently used data.
In short, if you cannot normalize the values in a way that allows you to multiply and divide by bitshifts you are probably effed and need to find a more novel approach. Slowing down the framerate is one approach I suppose... But limiting directions to 8 and using a lookup table, balancing the game around movement speeds of x2 steps would be better. Vehicles move at speed 1, you walk at speed 2, planes at speed 4, bullets at speed 8 etc. Bit shift multiply/divide heaven!
All of this jank, to make a twin-stick shooter almost work on a D-pad?
Rotating stick, not twin stick. Similar concept, different approach.
Ralf & Clark after their NES game: Fuck this. I'm becoming a tournament fighter.
Well, they had two more arcade games first. (Victory Road and Ikari 3)
Lots of SNK characters became tournament fighters after SNK became "the fighting game company". The fighting game boom did a number on their creative output.
I COULDA HAD CRYSTALIS 2!
I wonder which is more surprising, the fact that the Ikari Warriors were later able to redeem themselves in the King of Fighters tournament, or the fact that standalone rotary dials are somehow not affordable...
Well the original arcade game was a pretty big hit. I wouldn't say they redeemed themselves as much as they had a cringe moment when they hung out with a bad crew (Micronics).
NES Arkanoid would like to talk to you about the affordability of rotary dials.
@@CptJistuce What are you talking about?
@@otaking3582 NES Arkanoid came with a rotary controller. Standalone rotary dials were quite affordable.
@@CptJistuce I'm talking about modern standalone rotary dials. I've been wanting to emulate stuff like Forgotten Worlds, but I ain't gonna pay $70 for a USB rotary dial.
I've been WAITING for someone to tackle this.
Okay, now that I watched the video. Here's my two cents.
I would eliminate the turn/rotation entirely, and integrate a more traditional directional control. If I tap that direction, I want the character to face that direction immediately, rather than have to cycle between turning animations.
That alone would improve the overall experience of the console version of Ikari warriors.
TACKLE is correct!
A few more of these videos and I’ll be able to program my own games… just wait!
You probably will. Someone who has watched all of Chris' videos who tries to make a game is going to be starting from a better place than someone who watches random tutorials and tries to make a game.
I do not understand any of this, but still love watching these👍
LOVE the digging into how it works... comparisons, tweaks... and future ideas for things!!
Thanks!
Fascinating that this code does have a lot of thought behind it, it's not stupid and hap-hazard, but still very suboptimal. As if they started programming, had the ideas and when they realized the NES's limitations, it was too late to change course.
Well Done, Only thing missing is the guy behind the couch! :)
Almost 12 years later and the question is still not answered:
Where DID the hair go?
@@OnionChoppingNinja I don't know man, I'm not a scientist 😂😂😂
I would have never imagined that the issue with this game is that it was too accurate.
This episode made me think of the jump in technology between the NES and the SNES, with the prime example, to me, of a rotational shoot'em'up being Desert Strike by EA. It's wild to think about.
I once had the pleasure of helping reverse-engineer the code on an industrial machine that had to execute its control code 100 times every second, so there was a hard limit of 10ms to execute all code.
But the timing always got thrown off when the machine was run by particularly skilled operators. Over the course of about a week (because I was still green and working with a programmer who's not trained in physics) we determined that a previous developer had written in a check for whether the joystick was moving along the x or y axis in which case it would skip doing the trig and return 1, -1, or 0. But if the operator strayed outside the generous deadbands on the joystick, it'd revert back to calling full-precision trigonometry functions. This would blow the execution time up from ~5 ms to 20 ms or more.
Since we couldn't simply stop execution when the timer was up (it would cause undefined behavior) then anybody who developed the skill to operate the equipment with some finesse caused the program's timer to suddenly run at roughly half the intended speed, ruining all the physical calculations. 😅
I only wish my lexicon included "this meeting could have been a lookup table" at the time...
No no no no, YOU hold MY tacos mister. That's what I pay you for.
Also, seeing Tiger Heli gives me a warm, nostalgic feeling of nine year old me with a couple of friends returning from Blockbuster, game in hand and a solemn vow to not rest until the game is beaten.
Someone got their hands on 3Blue1Brown's math animation code!
lol “This meeting could’ve been a look up table” got me. I love every video you put out. I hope you keep making content like this and I appreciate the hard work!
Now do a video on where the scrotum guns' hair went.
Micronics! Oh my god it looks like I played all of these Micronics games, besides Ikari Warriors the most famous one... I'll admit, 2 looked really interesting though. Bless the mess that is 15fps, but I still love when crappy developers punch above their weight (for example Color Dreams, I love these guys). I can't believe they actually coded 16 directions into this thing! It may be result of thoughtless yes, but I find it really interesting nonetheless. You did a great job, I bet this wasn't easy! I'd love to learn to code how you do, for real
Did you know this game has a player speed increase powerup? It doesn't first appear until well into the 1st stage, and of course it's hidden and easy to miss. It really make the game so much more playable and should have been the default speed in my opinion.
Great video, as always!
A huge mod to fix 'Ikari Warriors' would make for a great multi-part video series.
The Atari 7800 version of Ikari Warriors has blaster master controls, so you just hold down one button to strafe, and fire with the other button. The 7800 version is better.
This was one your best episodes yet. Congrats on reaching a well-deserved 100K.
Thank you for your kind words!
Interesting revelation regarding the arcade controls. I never mapped out the angles, but I always intuitively knew, and enjoyed, that the character turned faster per joystick click than the actual angle. It feels good and not at all incongruous. It just works in your brain. Also revealed in this video, a lot of problems with game controls stem from developers favoring some sense of artificial evenness or easy implementation over what feels good to the player and what's appropriate for the level of action in the game, even if it doesn't exactly jive with a programmer's or mathematician's mindset.
Another good, recent video on this concept is Kosmic's "The Misunderstood Genius of Super Mario Bros." There it is discussed that the vast majority of storage in SMB is code rather than something like music or stage data. Most of the game is handling game logic in all sorts of cases with the clear goal of benefiting the player. Comparisons are drawn to other platformers with much harder and harsher game logic.
I am starting to see that most of these videos have suggestions to make these games better, and then I get disappointed that they are not getting the love they deserve. :(
There is no reason to when the arcade game is readily available in SNK 40th Anniversary Collection
Thank you. You have single handedly corrected all the rage I had for games I rented from mom and pop shops, and felt like I was scammed out of $2, over the weekend. For those of you too young to know, but mom and pop shops were the Steam version of the 80's and 90's games. You only had those games to play, and you would play the crap out of games you didn't own, because you never knew when they were going to be taken away.
the fact the character takes a full half a second to turn was so astounding that even the music stoped
I am in physical pain.
ouch, ouch, ouch-ouch, ou-ou-ouch, ouch, ouch, ouch-ouch
I am subbed to this channel with the bell, but it didn't get suggested to me. Thank goodness that RetroRGB mentioned this video!
congrats on the 100K! much deserved!
Thanks!
I love these calculations. For whatever reason, the sine lookup tables remind me of how oscillator phase is handled on FM chips. For the envelope generator, they used a different trick to avoid multiplication there (logarithmic addition with exponent lookup tables). I can't imagine what hardware limitations prompted them to sacrifice precious CPU cycles to save ROM space, other than maybe they were contracted to use the bare minimum. Weird choices indeed, maybe clever in the wrong places...
The method of multiplying Speed with unit angular directional X/Y lookups is actually used in the first-generation Command and Conquer (they support 256 directions with support for 8 (infantry, some vehicles) and 32 (most vehicles, turrets) visual facings). It is used not only in velocity calculations, but also turret offsets when the turret is not centered on a unit and the unit rotates.
Of course, that game targeted (16-bit DOS / 32-bit) PC, while this game targeted a very early console.
Congrats for the 100k subs!
Thanks!
Dear lord that was a lot of math to take in during the morning.
you left something critical unanswered
where did their hair go?
I always wanted it to lock the direction when the fire button was pressed. So you strafe when firiing, turn when not figuring.
That would make a lot of sense.
This feels like a two man project - one was a game designer getting resources together based on the arcade, and the other was a business / science programmer who was used to writing math software on 6502. The problem is that Nintendo (as always) cheaped out. It was noted in the Pachi Com rant, it’s noted elsewhere, but the way Ninty abused the 6502 was utter madness. So, it’s my theory that whoever designed the movement here in Ikari Warriors was expecting a lot more than Nintendo gave them.
The blame does not fall on Nintendo. Whether they "cheaped out" or not aside, there were many many high quality games made on the NES. It is a poor craftsman who blames their tools.
@@pvanukoff I don’t entirely disagree with you. But the problem is, if you were accustomed to the 6502 in a scientific setting or nearly any other machine with a full implementation of the chip, you need to shift your paradigm to really grasp the NES. Some people could do that. Some couldn’t. Micronics, certainly, couldn’t. Hence my thought that the lead programmer was trained in math and/or science.
It was a two man project to play this game. And by "play" I mean "undergo torture."
@@-taz- A-B-B-A.
@@endymallorn Oh yeah, I forgot. I do remember spending a whole rainy Sunday at my friend's house to beat this game. That, and going to see "42nd Street" when someone gave my mom free tickets (and my dad didn't want to go) were the two worst days of my life.
Where did their hair go?
Where did their hair go?
I see a new DG video, I click.
There are not much resources about it, but Heavy Barrel on NES also attempted to emulate the rotary joystick (It contains the early graphics data matching the Arcade version) before they decided to stick with the standard current direction+aim route, just like Guerrilla War.
holy shrimp Ralf and Clark from king of fighters
Interesting that they allow 6 bits of integer part for the speed. I wonder if anything moves at a higher speed than, say, 15/4? Otherwise they could have cut the multiplication time in half by halving the loop count.
A classic trick before CPUs had fast multipliers was to create a fixed multiplication with one or a few bit shifts, say if you want to multiply x by 5 then you calculate x + 4*x, where 4*x can be done with a bit shift. Since the speeds seem to be pretty hard coded (at least the player seems to only have a few cases), I wonder if they could have gotten away with that kind of trick instead. Should have saved a lot more execution time.
this meeting could have been a lookup table. Nice :)
As a kid, I remember finding a few arcade cabinets that had rotating joysticks for the purpose of aiming your character. Sadly, I didn't get to play them at all.
As an adult in a math class who just reviewed trigonometry, I'm a little bothered by the positive angle increases going in a clockwise direction.
Regardless, this was an interesting video to watch as I folded my laundry. I find the decision making during these kinds of things fascinating.
Heavy Barrel and Time Soldiers were two other awesome arcade games with a rotary joystick. It took some getting used to, but when you did it offered some great control.
I wonder if a lookup table for velocities would be smaller than the sin/cos lookup tables or not.
I never knew I needed a channel like this. Ty for a flashback to a time when the world was a better place.
20:20 - Nah... just go play Guerrilla War!
It's completely insane to me that there were 15fps NES games in a time where it had the capacity to run in 60fps (like smb3)
It depends on what the code is whether you're gonna get 60FPS out of it.
This code is, unfortunately, far more complex than it needs to be.
Also, Ikari Warriors is a 1986 game with a 128K ROM and the most minimal of bankswitching hardware. Super Mario 3 is two years later, three times larger, and has the then-new MMC3 providing much more complex bankswitching and an interrupt generator. It isn't a fair comparison even if all other things were equal.
@@CptJistuce Yeah but it's the same console. It's not like I'm comparing 1986 to 2006. It's just baffling how poorly some older games (on this channel especially) were programmed.
While we traditionally associate 2D games with 60 FPS as a bare minimum in the modern day, you'd be surprised how many games back then would target lower.
I can't speak for the NES (aside for the example of Dr. Jekyll and Mr. Hide, which targets something like 12-15 FPS), but the IBM PC and compatibles in the early days often had games run slower than 60. Even Fallout 1 and 2; which came out in the era of Windows targeted 30 IIRC.
@@LonelySpaceDetective Doom's framerate was hard-capped at an ambitious-for-the-time 35, which it never reached and mostly serves to confuse people today who don't know that low-res VGA was 70Hz.
@@CptJistuce DOOM is a weird title for what we're talking about (I choose this phrasing because I do not want to get into 2D/3D discourse rn), being an FPS.
While I can see someone being surprised it's capped at 35, I can also easily see them being like "well, Super FX games ran super-slow so I can see why", or something like that. Hence, why I used Fallout 1/2 as the example, since those are games just about anyone would expect to target 60.
The limited ability to perform multiplication within 6502-derived processors is a factor that persisted into the 16-bit generation. Some staff from Treasure have gone into detail on how this influenced their decision to develop games on the Genesis over the SNES. Better and more complete native support for multiplication on the 68000 made their complex movement patterns for multi-jointed multi-sprite characters much more streamlined and efficient than they ever could have been on hardware without that capability. It's a good example of how developers of the time had to play to the hardware's strengths and how that ultimately helped define the libraries and image of the console platforms themselves.
Dude, i´m not an expert but i know the SNES Ricoh 5A22 cpu (a variant from the 65c816) has hardware multiplication and division. Not only that, but the SNES PPU also can do multiplication and division in hadware too.
@@jsr734 It's not that the SNES didn't have "any" native support for multiplication, but that the extent that it did wasn't as great as contemporary hardware, sometimes even older hardware. It's an interesting facet of the realities of video game programming of the time, and it filters into how developers sometimes self-selected for their platforms.
@@jsr734 The 65816's MUL was rather slow, leading to it often being outsourced to S-PPU or the SPC700.
The Genesis was generally just faster to do anything than the Super Nintendo though, despite its more limited AV chipset.
@@CptJistuce Interesting i have been researching and it seems multiplication and division is also very slow on the 68000.
On the SNES cpu multiplication takes 8 cpu clock cycles, multiplication on the Genesis 68000 cpu can take between 38 and 70 cycles.
Divisions on the Genesis cpu take around 140 cycles while division on the SNES cpu takes 16 cpu cycles.
Also it seems the SNES ppu can do faster multiplication than the main cpu with no need to wait for the result.
Always a great day when you got a new video :D
I wonder if it'd be possible to reprogram the game to use the controller on port 1, and an Arkanoid controller for the rotation on port 2.
Heavy Barrel did the same kind of thing in the arcade, but the NES port did not try to copy it
7:59 Yeah I remember making practical use of trig when I was programming an enemy to follow me around. Spare time during recess. I remember always having to make special exceptions for strong nauticals like due up/down/left/right because the calculations would divide by zero or use impossibly large numbers. Always wondered at the time if there was some standardized way of dealing with those cases.
Love watching behind the code videos. I'm curious if there a website that has patches for the various fixes/tweaks that have been made?
This is all very interesting, but What about the scrotum guns?
An NES rotary controller would be awesome, as long as all three Ikari Warriors and Iron Tank were reprogrammed to use it. I would buy into that stuff for sure.
awesome video! I think though you didn't hammer home how jank this whole experience is, this game is pure pain, it needs to played just for 5 minutes to experience the horror. I beat it using save states one time and even that hurt my brain. after watching this though, somehow the issue wasn't that the programmers sucked, it seems that this was an issue of the programmer being too good (or just someone with a deep love of 6502 and over engineering things) and the hardware not being enough (from a certain point of view). I do wonder how this got ok'd. how did jackal get it right and this just became a torture sim. I do hope that someday Ikari warriors nes gets a redemption arc
I was a bit surprised to discover that many things were over-engineered. The sprite priority system is also rather needlessly complicated.
Great video! No easy fix I guess! I wonder if someone at micronics had a really ambitious vision for this port that got cut short!
You know that someone at Micronics was just trying to impress Becky in QA with all of their trigonometry and algebra and MANUAL MULTIPLICATION code.
Thanks a lot, Becky. You ruined Ikari Warriors on the NES, all because Steve wanted to go out with you.
Ha!
I got the idea that Micronics were attempting to reproduce the rotary joystick experience in such a manner that a custom controller, had it come out for the NES system, could be deployed optionally. That never happened, making most of the work done here pointless.
It's like night and day, seeing the technical wreck of this game, but also the great implementation of Guerrilla War. Both of these games were SNK-created, and both used a rotary joystick originally. But whoever worked on the home version of Guerrilla War basically did everything right, unlike here.
The 6502 core in the 2A03 actually supports BCD, but Rockwell disabled one transistor in the mask so that it could never be enabled.
A little off-topic, but maybe an idea for a short section of a future video: any explanation for the code behind the flying glitch in this game? If you get in a helicopter then press A, B, and Up simultaneously, but keep holding down A or B, the result is that the character dismounts but continues sailing forward at helicopter speed while also being invincible. Presumably some failed transition out of helicopter state and into walking around state...
wow, i cant believe there was a time when people looked at the rotation thing and didnt immediately say "we need to remove this now"
Removing the game's signature feature is a bold approach to adaptation, to be sure.
I've played some versions of Robotron where you just shoot the direction you move. They kinda suck.
It's conceptually not really that different from twin-stick shooters, just, achieved with a single stick instead.
Hell, that's typically how modern ports handle games such as Ikari Warriors.
Unless you just meant in terms of porting to a console like the NES where there's only one d-pad or stick. In which case, fair, though you should understand that just as the other person said, removing a prominent gameplay mechanic is not something to be done lightly.
Fascinating; never noticed this despite hundreds of hours playing the NES version back in the day. Good thing there was an infinite lives code (ABBA).