Just keep scrolling, just keep scrolling, scrolling, scrolling…..

Doing some prep work for the Dragon boss in Wily’s Castle, and before the actual fight begins, there’s a bit of auto-scrolling on platforms where you don’t want to fall, and don’t want to touch the dragon. I initially though that since this mechanic was unique to this fight, I’d merge it in with the Dragon AI, but as I began to mess with the mechanics, I found that it was something I can have as a separate entity, insomuch that it’s going to be a part of the editor with 3 types. Normal, Auto-Scroll (1 pixel per frame in either direction), and Lock (no scrolling whatsoever).

Due to the nature of this entity, I had to make some adjustments to Megaman so he would never go outside the camera view, meaning when he does nothing and the camera starts scrolling past, he’ll be dragged along with it. Along with that, I had to make a basic check that if he got stuck in a spot when he’d get squeezed, then he’d auto-explode.

Work continues. Slowly, but surely

I believe I am still on track for a release before the end of the year. Nothing particularly big has happened as I have mainly been dealing with bugs in the program. I’m alternating between bug fixes and working on the main game, so nothing really important to report.

Vacation next week

I will be gone next week to go on vacation, so I’ll likely not be doing any development of MM2 PTC during that time.

Speaking of which, I’m now at a point where one could play the game and do everything to the point just before running the Wily levels. The select screen, loading/saving, etc have all been implemented. so what does that mean? Well, for the main game, I believe all that is left is constructing the Wily levels, programming the Wily bosses, and implementing the end cutscene. There are a few things related to those that I have yet to decide how to implement, like teleporters (which may not even be available for custom levels). The editor still has bugs, mainly when exiting the editor and loading another custom level, so those will have to be dealt with at some point.

My new year’s resolution was to get this project done before the year ended, and so far, it looks like I’ll be keeping to that schedule with possibly some time to spare.

PTC – MML audio scripting with NES-like audio in mind

So I’ve had a request about how to make NES audio with PTC long ago, and I meant to make this tutorial back then, but things got in the way and whatnot, so no more interruptions!

NOTE: This is not a tutorial for how to make MML-scripted music. This is just going over how you can produce sounds like the NES uses.

Ok, first things first. In order to get NES-like music, we need to know what the NES used for making the sounds it does. The NES contains an APU (audio processing unit) that has 5 channels to it: two pulse wave generators (or square wave), a triangle wave, a noise generator, and a delta modulation channel for playing DPCM samples (similar to WAV samples). For what PTC comes with directly, we have 4 total pulse wave generators, and we have 2 noise generators. There is no triangle wave, but thankfully we can create one. With all the things we can do, we are left with a problem. We do not have the means to mimic the delta modulation channel. So I can only focus on the main 4 channels. There are other “additional channels” used in games like Castlevania 3j, but I won’t go over those. I figure once you understand the basics with the 4 channels, you may figure out how to handle those other ones yourselves.

First off is the pulse wave generators. PTC has access to these via the instruments from #144 to #150. However, the difference between these instruments is their duty cycles, which is the ratio between the pulse duration and the period within the oscillator. For those that don’t know what this all means, it simply means the sound will be different with each instrument. The NES pulse wave generators come with 4 different duty cycles, which are 12.5%, 25%, 50% and 75%. These match up with 4 of the 7 instruments we have available in sequential order; 144, 145, 147, and 149.

Next is the triangle wave. There is no instrument that replicates this channel in PTC, but thankfully, both the manual on the PTC website and the help menu in the program itself shows how you can make one under the BGMPRG section. It’s real simple. The cycle starts in the middle, goes diagonally upwards, then downwards to the opposite side, then back up into the middle. It will look like triangles. Here is the string I used for making it with BGMPRG….

DATA “000810182028303840485058606870787F787068605850484038302820181008″
DATA “00F8F0E8E0D8D0C7C0B8B0A8A098908880889098A0A8B0B8C0C8D0D8E0E8F0F8″

The last is the noise channel. While we have an instrument that takes on noise, there are some problems. The noise instrument in PTC and the noise channel on the NES are different. The DS/i creates what is known as white noise for its channel, which one could say is a randomly generated waveform of various sizes and lengths. The NES “noise” is much like pulse wave generator, but with a pseudo random sequence at 16 different frequencies with a length of about 32767 steps. In most cases, the noise channel we have is good enough. However, the NES noise has 2 modes. One that is the entire length of 32767 steps, and the other that is a segment of 93 steps of the entire length. We can generate an instrument (like what we did with the triangle wave) to mimic this mode, but we run into yet another problem. This 93 step sequence can be anywhere in the entire length, based on when this mode was activated, so the actual sound can vary from one time of play to another. For this second mode (which I used for Quickman’s stage theme), I made it into an instrument like I did for the triangle wave. It won’t mimic the variation you hear from the actual music, but it’s close enough. This is the string used for BGMPRG….

DATA “D03030D030D03030D0D03030D030D03030D030D0D03030D0D030303030D0D0D0″
DATA “303030D03030D03030D030D030D0D0D030D0D030D03030D0D030D03030D0D0D0″

Ok, so we have some information of the instruments we can use, but what about making NES-like music. Well, that is not something I can teach you as I am pretty much a noob on the subject. So how did I recreate the Megaman 2 music? Well, that’s where I go from looking like a professional to being the average joe. I had the tools to read the audio files and put them into a representation that I could map easily into PTC. Anyone recall how the music for Shovel Knight was made? For those that don’t, there is a program called Famitracker that aids in making NES music in a tracker-arrangement that you simply add notes, octave, volume, pitch, etc, and then you can export it to the actual NSF format so they can be played on NSF players.

But how does that help? Well, Famitracker itself doesn’t allow importing from NSF files, but people who got the source for Famitracker and NotSoFatso (a player for NSF formats) put them together to make an importer, called NSF Importer (you can find it by Googling). It allows you to import based on track. When you import, you’ll find various information per column. For square channels, the order is <note, octave, volume, pitch, and duty cycle>. The triangle channel’s order is <note, octave, -blank-, and pitch>. The triangle does not have volume adjustments, but it mutes via rest notes (which look like — in the note column).

The noise channel is a bit different in representation. It has 16 frequencies (range from 0 to 15, with 10 to 15 being A to F), so it mixes note and octave together. Other info is volume and mode. I had to figure out myself the note/octave for each frequency, and while far from perfect, what I list below is what I came up with (octave first, then note). While I only listed 12 matches, the latter 4 all sound about the same due to our ability to hear them. They do, however, sounds like they get quieter as you go for a higher frequency, so taking the ‘B’ frequency and changing the volume when plotting into PTC could help mimic them.

0 – O2 C, 1 – O2 A, 2 – O3 G#, 3 – O4 C#, 4 – O4 G, 5 – O5 D, 6 – O5 B, 7 – O6 D, 8- O6 F, 9 – O6 G, A – O6 A, B – O6 B

Well, that’s about all I can share, as the rest needs to simply be tinkered with by your own will, because sometimes you need to try them out yourself to understand them. I will note that NSF Importer imports the data at a rate of 60hz, so in 1sec’s worth of time, it will import/play 60 rows (I haven’t tried PAL music that operates at 50hz, but I assume that’ll be 50 rows per second). Because the tempo is always set to 150 (be sure to set this in PTC) and it reads at 60hz, I calculated that the smallest length for a note is a length of 96, so base your note plotting by that. Please don’t ask how I calculated it, because that was over 1.5 years ago and I completely forgot how I figured it out. As I said when I began this explanation, this is not a tutorial for how to make PTC MML music, so determining  the length is not part of this, but I will say that when you double a length value (like from A1 to A2), the actual play length is split in half, and likewise, splitting a length in half increases the play length by double. So if a note played for 2 rows in NSF Importer (one having the note itself and one without), the length value in PTC would be 48.

. A few notes about plotting into PTC. The square waves in NSF Importer are actually an octave off, so be sure to adjust that. Because the triangle wave is mostly for bass sounds, it’ll sound rather low on the DSi/3DS, so be sure to set the volume to as high as you can for that channel. As said before, importing operates at 60hz (or 50hz), but what was not said is that NES is not restricted to this speed. Various notes may turn on and off quicker than a frame, so NSF Importer will miss them.

Hope this helps.

Progress Report for July

The AI for all 8 Robot Masters, including their weapons, is finished, give or take some tweaking and additional bug testing. I have now moved on to developing the main portion of the game, making the interface for level selection and progress data. I still have the Wily bosses to work on, but that’ll be afterwards. Unlike the original, which used a password system, this port will use saving instead (up to 8 slots). Information for the save is displayed, which involves which weapons have been obtained, how many lives and e-tanks you have, and even the difficulty you chose to begin the game (and yes, there will be normal and hard modes). Unfortunately because of all the work I’ve done getting the game working under editor conditions, the original design for loading levels used by the past demos is broken, so that is going under repair procedures.

I know…I know….

Long episode of no updates. Completely my fault. So many things going on, and this project was a small portion of that. Sometimes when I have a breather, it ends up being more than a breather. A few things to note that has happened recently.

First was an attempt to make a converter that would take in NSF files (Nintendo Sound Format, basically, NES music/sfx) and convert them into MML structure. I originally was going to put together a small article that would describe the instruments used for replicating the NES audio used in Megaman 2 PTC and how I was able to export them decently accurate, but after diving into that, I learned that certain NES audio players had their sourcse available, so I thought that maybe I could save people the trouble of manually making their own music copies by creating this program and doing it automatically. The output seems to work decently, excluding various effects like pitch sweeps. Unfortunately, attempts to find the main loop points for each musical composition has been less than stellar, likely because the exportation method works off examining the state of the channels at a rate of 60 times per second when the music updates at a far more significant rate. Since the base of the exporter/player is made by someone else, I’d have to examine their work and see if I can retrieve the data a lot more often, or find another way to export the audio. This converter has been put on hold until further notice.

That is what I’ve spent most of my time on since this last update, though I have worked on MM2PTC here and there among other things. Various other distractions came about, such as family unexpectedly dropping by for the week from Idaho, Mario Kart 8, and just recently, E3. At the very least, I can say that all the Robot Master AI is completed, but only Bubbleman’s weapon AI has been programmed. There is one problem that I’m hoping I can get passed. When the program reaches a certain number of sprites on-screen (around 8-9, which include enemies, bullets, etc), the program begins to slow down. In most cases during the main game, that shouldn’t be too much of a problem. However, bosses like Heatman use so many individual sprites at one time (weapon fire mainly) that I can’t help but imagine that their fights will become slow. I’m devising a method that I hope will not only improve those scenarios, but general performance as well.

Robot Masters, and user-made rooms

Sorry for the lack of updates. Been busy with things other than this project. I have continued working on the Robot Masters, but a lot of complications have been introduced as I worked on each one, so I had to make more adjustments to the overall code. As I mentioned in my last post, the Robot Masters won’t act exactly the way they do in the original game because of the inclusion of placing them in user-made rooms via the editor, though they should still act fairly close when introduced in an exact replica of their boss rooms.

Take for instance Bubbleman. He floats up into the water in Megaman’s direction and then floats down. The original room has a completely flat floor and no obstacles in between, so he would always float up and then down. But, what if the floor was raised in multiple spots, or solid platforms elsewhere? The original AI could have him floating up and up until he is off-screen above. In such a case, I changed the AI so that if he is to float around in the water above a certain point, instead off floating up, he’d float down instead. I even set them so that they can die in a pit (like if the room made for the boss has an open pit right below where they spawn). These took me time to devise, and while most can handle an altered room, some are going to take a bit more time.

Metalman comes to mind. His AI is rather simple. When being attacked, he’s jumps up to 3 potential heights, and throws a number of blades based on the height. however, introducing a room that is different from the original can mess things up. If a platform is above him, should he jump to it? How high should he jump to reach that platform, and how many blades should he throw in the process? If he’s too high, he should be able to drop down? Should he throw blades in that scenario? There are numerous variables to take into account with using the original AI and transforming it to become more dynamic in a unique room layout.

Currently, I have the AI for 5 robot masters done (excluding their weapon AI). The two remaining other than Metalman should be a cinch as their AI is originally designed to handle rooms with no flat floors and such. In other news, I had a request about how I was able to make the music/sfx for the game, so I will also work on a tutorial about that. It won’t be a tutorial about how to make MML scripts, but more about what instruments are used to produce the 8-bit audio.

Computer, menus, extras and editor

Sorry for the gap in updates. After dealing with the HDD crash mention in my last post, it became apparent that I was in need of upgrading my computer. So, I did quite a bit of researching as to what I could use/need, and with money saved up (along with my tax return), I purchased items and built a new computer. This dug into my time that I usually spend with this project, but I have done some work nonetheless. No more “terminal” interface appearance. Now the menu system has been implemented for going from one part the program to another. With that, extras have been included, such as the Audio Player and even the Credits. Using methods meant for the menus, I am also incorporating them into the editor so the method of displaying information doesn’t look so plain.

The robot master AI has been put on hold for the moment because I have to decide how I am to deal with them in custom rooms, much in the same way I had to alter/add AI routines for some enemies because they can be placed anywhere that are not normally allowed in the original game.

Desktop HDD out of commission, project still moving forward

Had the unfortunate incident of my desktop going out because the main drive stopped working. Thankfully, I had long since used DropBox to store all data and backup versions of my work, so nothing regarding this project has been lost. I can’t say the same for some of my own stuff like pictures and some documents. Drive won’t rev-up during the boot sequence, and so doesn’t get recognized by the system at all. Had someone tell me to try a “freezer-fix” because it might be the grease inside has become tar-ish, but I gotta find some silica gel first (packets usually placed with clothing, shoes, and electronics to absorb moisture). So, there’s a chance of at least getting the drive to run long enough to get some important things, but its general use is over. I’m currently using my laptop for everything now and not just for on-the-go.

As for the project, I’m working on the 8 robot masters right now. Haven’t gotten to the individual AI yet, but the general execution across all of the masters is about done, such as engagement, general hitboxes and responses, exploding and “level cleared” execution. I’m designing them to be usable in the editor (with some restrictions, of course). Some of the restrictions are as follows, to which a robot master will not appear if:

  • The sublevel they are placed in is longer than 1 screen segment.
  • Another robot master is already designated in the room.

They won’t necessarily be what ends the level, so technically, you could link 8 rooms together, and fight each of them sequentially. Transitions from room to room will be disabled during a boss fight, but will become enabled once they are dead.

A December Update

Sorry for the lack of updates. Been going against a bunch of hurdles with the program, but most have been dealt with. As of right now, all enemies and sub-bosses have been completed with their AI improved and adjusted. Dealing with the sub-bosses was a bit of a chore because they didn’t deal with just sprites, but also messed with the background as part of their visuals. Also, because of being able to place them anywhere with the editor, I also had to make numerous code adjustments (to prevent overlapping) as well as numerous palette execution changes with regard to them because of how they may use palette animations (so by doing a palette animation to one, it would have affected all others of the same type in visual range).

I’ve also been refining the code that deals with transition data (that allows moving from one sub level to the next) as I added gate placements. This did cause me to require changing map collision data so now, there will be a 1 tile invisible wall on either side. While this makes Megaman react correctly like the original did in this instance, it will affect how enemies will react to this wall, which are supposed to act differently. Shouldn’t cause much of a problem though. The transitions can either be activated by touching any open portion of the sides, or just one open portion. The gates can be placed on any open section on the left/right sides. The original game does not have gates leading up/down, but I wouldn’t cross that off the list just yet. It won’t be a focus atm.

Before I begin work on the bosses, I will be going through a stabilization session, to ensure that what can be created with the editor would not result in errors that stops the program.