Megaman X on the Amiga?

[LuMan]

I like where this thread is going...

Some thoughts.....

The title screen doesn't need to be limited to 16 colours if you don't want it to be. When you load the level you can free the current screen/slice* along with the palette and remake a newer, lower-colour screen/slice and palette.

Using a sprite (as opposed to a bob) for the main character definitely speeds things up. You can even create 'safe colours'* to make collision detection only happen for certain colours, so you can still have some form of background without resorting to dual playfield techniques.

The upgradable armour has to stay. It's a feature that really adds to the game. It would be better to reduce the anim frames for the main sprite by 1 in each direction than skip the armour upgrade bit (imho).

I would love to put a quick demo together, showing 8-way scrolling with a fully animated main character, but I can only code in Blitz (to a barely passable degree) and really ought to be concentrating on finishing my other game project. However, if tiles and sprite were made available then, maybe, folk would be motivated to put something together.. (nudge, wink, )

*Like I mentioned, my coding skills on the Amiga start and stop with Blitz, hence the references to stuff I know can be done in that language.

[Shatterhand]

I do own a SNES and can play Megaman X on it. But fuck it, playing it on an Amiga would be uber cool, that's it

[Master484]

Now, why 12 disks? The SNES game fits on a 1.5 Megabyte rom. The PC version (which runs on a 486-33mhz and requires 4mb ram) occupies less than 5 mb of HD. The game should fit on 4-5 disks, maybe even less.

Well, I just throwed that 12 disks in the air because the game has 12 levels I think. But I agree that most likely it would fit into 4 or 5. And if graphics are compressed and all tricks used, then it might even fit on a single disk, just like Turrican 2.

to get more raster time for 32 colors i would leave the 256x224 resolution and use a NTSC overscan res a la bomberman

That might be one option. And I think Toki is another example of this; limited screen size to get more colors on screen.

The title screen doesn't need to be limited to 16 colours if you don't want it to be. When you load the level you can free the current screen/slice* along with the palette and remake a newer, lower-colour screen/slice and palette.

Yes I thought that this would be the case, although I think 32 color picures on the disk would still consume more disk space than 16 color ones, although I have no idea how much more.

Using a sprite (as opposed to a bob) for the main character definitely speeds things up. You can even create 'safe colours'* to make collision detection only happen for certain colours, so you can still have some form of background without resorting to dual playfield techniques.

Indeed, the Megaman character doesn't have so many colors and it's quite small, maybe possible to make with a sprite or two? I know sprites have some limitations on size though, but maybe it's possible. So if we would use 3 sprites for the normal bullets, that would leave us 5 sprites for Megaman, because the Amiga had 8 hardware sprites right?

And I also agree on the upgradable armor feature, it would be a shame to leave it out. And I just realized that it wouldn't actually consume memory, but rather disk space, to have all those different versions of the Megaman sprite in the disk. But maybe if Megaman itself would be composed out of multiple hardware sprites, then this might be used as a partial solution.

But still, having Zero as a playable character would be super cool too, and this also is just a matter of disk space. Although some frames for Zero would need to be hand drawn, because he only partially exists in Megaman X. But I can draw sprites in this style, and could surely draw the missing animation frames. You can see some Turrican/Megaman inspired pixel stuff that I have made here: http://opengameart.org/content/open-gunner-starter-kit . And although I don't claim to be on the level of the Capcom artists, surely I can do something if the need arises.

---

Also I thought about the wall jumping / wall sliding controls, and how they would work on a single button joystick.

On the SNES it works like this: when player jumps into a wall, Megaman clings to it and starts to slide downwards. As long as player presses to the direction of the wall, Megaman stays on the wall and slides down. If player releases the control pad to neutral position, Megaman releases his hold from the wall and drops down. Pressing the Jump Button while on the wall causes Megaman to jump out of the wall at normal speed. And pressing the Jump Button and the Dash Button at the same time causes Megaman to jump out of the wall at "dash speed".

But on the Amiga single button Joystick I think this all can still be done. One solution might be this: When player jumps into a wall, Megaman clings to it, and at this point the game controls enter a "wall mode". In this mode doing nothing will cause Megaman to slide down, and only two joystick directions are checked, UP and either LEFT or RIGHT depending on the direction of the wall, if wall is on the right we check LEFT and vice versa. Pressing UP will cause Megaman to jump out from the wall at normal speed and pressing LEFT or RIGHT will cause the jump to happen at dash speed. Additionally we could also check a third joy direction, DOWN, which would cause Megaman to release hold of the wall and drop down normally without jumping.

---

And I made some more stuff, here is a 16 color version of the level select screen, again side by side with the SNES version:



Again we see how this rainbow-colored graphics style allows us to use our 16 color palette to it's maximum potential. Although this image took a while longer to convert, from an incredible 93 colors to 16 and some improvements in a few places. But the end result looks very nice, and if you didn't know it, at first look it's even hard to tell which one has more colors. And even after looking at it for a while, the random observer would probably guess that the Amiga version has more.

---

I would love to put a quick demo together, showing 8-way scrolling with a fully animated main character, but I can only code in Blitz

Blitz Basic is good enough, it's quite a powerful tool from what I have heard and seen; and in fact every Blitz game that I have seen on the Amiga have runned smoothly at 50fps. And AMOS too should be capable of doing a game like this. And the benefit of those languages are that they are both Basic and human readable...so if a programmer abandons the project it's much easier for someone else to take the source code and continue the project. But if Assembler/ machine code would be used, then only an expert in Assembler could step in, and I think those people are quite rare nowadays.

I wonder how different Amiga Blitz Basic is from it's PC successor, the Blitz Plus? Because I have used Blitz Plus quite a lot, and have done stuff like this with it: http://m484games.ucoz.com/index/m484gcs/0-34

But anyways, this project is also a good test for Blitz Basic itself, now we can see how much it can really do. And why not at the same time we could test AMOS too, surely there are some AMOS programmers out there. Come on everyone, let's make Megaman X with AMOS and Blitz Basic, it will be great, will run at 50fps and fit on a single disk.

And in fact I already have an idea for a Test Demo. Let's make it a simple arena fight, where the player can press space bar to create more enemies on screen. One space bar press, and a new enemy jumps to the screen. No limit to the enemy number. This way we would find out how much stuff can be put to the screen, and know for sure where the limit goes, both for Blitz/AMOS and for the Amiga. And after that we will know answers to the color, screen size and memory questions.

---

But first we need the graphic assets. So, I'll begin to rip the sprites, all frames for Megaman, a few of the smaller enemies, and some tiles. This is enough to make our demo. Then we put the demo to an ADF file, and everyone can try it out.

I'll post the gfx here once I have ripped it and converted the palettes.

[Shatterhand]

You could use a copper list on the Selection Screen to get more colors, since it doesn't scroll. That's kinda easy to do with Blitz Basic, make each row of enemies with its own palette. Even though it indeed looks pretty good with 16 colors.

Also every level could have that old rainbow background instead of just a single color. Lots of games did that because it's really easy to do and look a lot better than a single color.

I still am getting the grasps of how Amiga uses its sprites channels.. but I think if Megaman is never wider than 32px , he may have his own 16 color palette and use 4 hardware sprites, leaving the other 4 for his bullets (though the charged up bullets take more than 16 pixels).

My experience coding on Amiga is only with Blitz Basic too, but I don't have enough experience (or free time) to tackle a project like this.

[Master484]

You could use a copper list on the Selection Screen to get more colors, since it doesn't scroll. That's kinda easy to do with Blitz Basic, make each row of enemies with its own palette. Even though it indeed looks pretty good with 16 colors.

Yes, copper could be used on the title and the level select screen or maybe make those screens with 32 colors like was suggested before. It does looks good with the 16 colors, but I had to use the brown quite a lot, and that may not be everyone's favourite color.

Also every level could have that old rainbow background instead of just a single color. Lots of games did that because it's really easy to do and look a lot better than a single color.

This is what I too have been thinking; Turrican 2 has just 16 colors (or actually it was 18 when I last time counted them), and that is then supplemented by having rainbow coppers in the background. And so I thought that this would be a good way to handle things in this project too. But would such a copper generated rainbow background require the use of a "dual playfield", and how much would it affect game speed?

Also I would have one stupid question about the sprites that I'm currently ripping/making: I assume that Blitz can "flip" all sprites easily, so that I for example need to create the walking animation frames for only one direction, and then Blitz can generate the frames for the other direction by turning the sprite around horizontally? I assume this is the case, but just asking to be sure.

[saimon69]

@Master484
if you mean with precalculation once and save to disk then yes, flip in real time is in my opinion not feasible, i remember a similar talk on the Rygar thread (and that one is in assembly)

To really take advantage of Amiga hardware i would suggest to make the game installable on hard disk as option.

[Master484]

if you mean with precalculation once and save to disk then yes, flip in real time is in my opinion not feasible

Ok, so we'll need the image files for both directions then. Luckily it's easy for me to flip all the sprites with Paint.

Things are progressing fast, I have now ripped all frames for the Megaman character and put them all to this one big png image:



The next stage is to re-color them to the 16 colors, rip all the other stuff we need, and then I'll save them to individual images and put the whole package here.

Megaman has 59 frames, but these are only the frames where he is facing right. When we add the left facing frames it's 118 frames in total.

The run cycle is 10 frames, but that doubles to 20 because of the "running while shooting frames". But I believe we can cut the guy to 3 sprites, so separate the legs, arms and the head/torso to their own sprites. This might be necessary anyway if we want the armor upgrade thing. But I think we should first see how much memory it'll take in this "full form", and think about the separation process after that, if needed.

Bullets and charge shots are 22 frames, the "death frames" of the big bolts when they hit enemies and enemy shields take the most frames, 10 frames go to those (can be easily cut to 6 if there is need). But otherwise the green and the blue charge shot have only 3 frames when airborne; they are very skillfully designed to create that pulsating effect.

---

About the dimensions of the sprite, the maximum X width is 38 pixels, and the maximum Y height is 46 pixels.

But in exactly two frames we go over these limits: The "dashing while shooting" is 48 pixels because of the gun part. So I think we should cut this sprite right away into two parts; simply make the gun part separate for this frame as I have demonstrated in the image. And one of the ladder climbing frames has a Y height of 49 pixels. But I can easily shorten this sprite to 46 Y pixels, so I'll do that for the re-colored version.

So we would have all Megaman frames in the size 38*46.

---

Also I have a question about the "transparent color" of the sprites. I assume that this can be any color, and then you tell Blitz to treat that color as transparent? So when I send the final images, I'll leave that pink color as the transparent color?

---

And some random thoughts about the speed of the SNES version; the game runs at 50fps, but it doesn't take much action for slowdown to happen. The easiest way to test the limit is to go into Spark Madrills stage, and move to a position where two of those blue robots are at the screen at the same time. When they shoot at the same time, slowdown happens, and more if Megaman also shoots. So two 40*60 sprites, Megaman, and 5 smaller bullet sprites + 2 layer parallax scroll are enough to trigger slowdown. I would imagine that the limit for the Amiga would be somewhat similar.

But on the SNES you barely notice this slowdown, because you're concentrating on fighting the enemy and dodging their bullets...and in fact the slowdown often helps you to dodge the enemy missiles, and so in a bizarre way it actually adds to the gameplay.

Also another thing that I noticed: When certain enemies blow up, multiple pieces of debris fly from the explosion. And those pieces flash constantly; every second frame they aren't shown at all. And they seem to be divided into two groups that flash during different frames. This way there is always debris shown on screen despite the flashing, but the power required to shown them is halved. Most likely there is a system which gives them running ID numbers during object creation; those with an even number flash during frame 1, and those with a odd number flash during frame 2, and so on. Or that's how I would program it.

It's a small trick of course, but some nice effects could be achieved with it, such as 10 pieces of metal flying from some explosion, which would count as only 5 to the video chip because only 5 are shown per frame.

And about the boss battles, the bosses are about the same size as the blue mech robots, 40*60. And their attacks have many animation frames, but it's interesting to notice that none of them have any walking animations. Only Vile in his battle mech form has a walking animation, but in addition to that he only has the fist punch and no other moves. The 8 level bosses have multiple moves, but when they move around, they always do this either by jumping (2 frames for that) or then the movement happens as a part of their attacks.

So the bosses too sound like they can be done, especially if they're loaded separately, which can be easily done in the "door corridors" that are located before each boss...in fact I'm sure that SNES version too uses these corridors to load the boss graphics and boss musics.

[lordofchaos]

That's some fine work! Really hope this momentum can be sustained long enough for further development to take place. Perhaps I should start looking at some music conversion, I haven't even heard the music of the original game yet.

Difficult to plan for music without established limits, number of channels, max file size, format etc..

We could really use some more direction/feedback from a potential coder for the project, I can completely understand the reluctance to commit, especially considering the time required from the programming perspective.

Having a goal for a "working level" seems quite realistic, wouldn't need to incorporate all the elements of the game, just the basics.. And rather than try to carbon copy level design from the original perhaps have Amiga specific design, retaining the overall feel of the SNES version but having unique maps more suited for Amiga?

[Master484]

@LordofChaos
Thanks. Momentum is indeed important in a project like this, so let's keep running to achieve at least the first milestone, which is the demo level.

About the music conversions, almost every tune in Megaman X is great, the Storm Eagle stage music is probably my favourite: [ Show youtube player ]

But if you want a short and easy music track to convert, then maybe the Sigma Battle loop would be a good choice:
[ Show youtube player ]

Or maybe even this great Gate Fight tune from Megaman X6:
[ Show youtube player ]

Would suit the short action demo level quite well I imagine.

I have no idea about the channels or anything else though, but at this early stage any music will do. I don't think even the coder could know anything for certain at this point.

And speaking about the coding side, this project is indeed megalomanic, and I totally understand how it must look from the programming perspective. What we are basically asking here is that someone comes forward and codes us a game that is even more advanced than Turrican 2, and does that as quickly as possible and for free.

I myself have completed some big programming projects in the past using BlitzPlus for Windows. But despite this I'm not sure if I could make a game like Megaman X for the PC using BlitzPlus, even if I had all the gfx and sound ready. Or yes, I could do it, but I imagine it would take an entire year of full time work at the least.

The full conversion task would of course require an expert programmer, or a team of expert programmers, who would basically need to work full time coding the game in order to finish it in reasonable time. And as I mentioned I would estimate that a project this big and hard would take about one year if just one person would code it. And although coding it part time at evenings and weekends could also bring results, but this way it would of course take three times longer. And the longer it takes, the more likely the project would end up abandoned at some point.

Of course one option is that I could try to learn Amiga Blitz Basic myself and turn into that programmer. This might be possible, but I would imagine the learning process would still take me a few months, despite the fact that I'm skilled in BlitzPlus, which is the Windows "big brother" of Blitz Basic. Things work very differently on the Amiga I would imagine.

And if I would also need to make the graphics stuff at the same time, then I would basically have to turn into Megaman myself in order to succeed.

---

But of course what we are Right Now trying to do here is just a simple demo, only one room with some scrolling and a few enemies, just for the fun and to see if the whole thing could work at least in theory. A technology demo so to speak, on the subject of "action games with big sprites with a hundred animation frames".

And this is of course totally possible. It doesn't really matter if the demo level alone would fill the entire memory or would run at 7 fps, it would still be fun to see.

And when I upload the 16 color versions of the sprites here, everyone is welcome to use them; anyone can then test this "Megaman X" theory with the programming tool of their choice, and post their demo levels here for us to try out.

And if the results look promising, then we can start brainstorming things further.

--

And rather than try to carbon copy level design from the original perhaps have Amiga specific design, retaining the overall feel of the SNES version but having unique maps more suited for Amiga?

Yes, this is what I've been thinking too. A totally faithful 1:1 conversion would be boring in a way. The Amiga version should definitely have an "identity of it's own" and look and feel like an Amiga game, in the good sense.

The levels, the places of the armor capsules, plot elements, everything should be different. We should make a new game, not just copy an old game.

We could even add new levels; for example on the SNES in the first level we can see Vile's huge airship that comes to rescue him...but after this the airship never shows itself again. But that would be a great place for an extra level, for example as an intermediary level after you have beaten the 8 bosses...Show a cutscene where Sigma sends Vile to attack the home base of X and his aliies, and then have a furious short fighting level at the base, followed by Vile's airship level. Just one idea that I have, there are more of them.

This is why I would like see an OCS/ECS conversion rather than an AGA conversion...Because in the OCS/ECS we are forced to do things differently, and this will result in an unique and new Megaman experience. The Gameboy Color version too did many things differently, not only because it had to, but to bring something new to the fans, there were for example additional bosses.

And also this is why I definitely want Zero to be a playable character; because this addition alone would make the Amiga version better than the SNES version at least on one field. Let's make the SNES fanboys jealous of our version of Megaman X.

[Shatterhand]

I may be wrong, but I think have a 38 px wide or a 48 px wide sprite won't make much difference on performance. Blitting anything wider than 32 px means you are going to work with 48px even if the image is just 38 px wide. And if using sprites, you are always working with multiples of 16 for each sprite channel used.. so having 38 or 48 means you'll use the same amount of sprite channels anyway.

And you don't need dual playfield for copper rainbow. You change just the transparency color.

[commodorejohn]

Originally Posted by Master484

This is what I too have been thinking; Turrican 2 has just 16 colors (or actually it was 18 when I last time counted them), and that is then supplemented by having rainbow coppers in the background. And so I thought that this would be a good way to handle things in this project too. But would such a copper generated rainbow background require the use of a "dual playfield", and how much would it affect game speed?

Nope, no dual playfield needed. All it requires is for one color to be reserved as the backdrop, then change that color as the beam travels down the screen. It's not going to affect game speed any more than any other copperlist effect, which is to say barely at all. (It's been a while since I looked at the HRM, so I can't remember if the Copper gets any dedicated cycles, but in the worst case it'd be like four cycles stolen per line.)

[Master484]

Ok guys, I have now ripped and converted everything we need for the demo level.

I put a ZIP file to the attachment of this post, it includes both PNG and IFF versions of the graphics.

So check it out and tell me if the IFF files work OK, I have never worked with IFF before, but I converted those with XnView and I believe they're OK.

I didn't include all frames for Megaman, just jump, run, dash, the shooting frames and the basic wall sliding frames. There are also two enemies, one explosion, and one enemy bullet. And the level tiles are very basic, but enough for test purposes.

And I just realized that I forgot the X-buster shots, but I'll send them later, in the meanwhile just use the enemy bullet for Megaman's shots too.

[kamelito]

collision detection explained, include megaman.
http://www.emanueleferonato.com/2012...d-platformers/

Kamelito

[Master484]

Ok I converted the missing X-buster shot sprites to IFF as well, they're in the attached ZIP file.

Also I made an energy bar, which is included with the files.

Here is a picture that shows how it works:



This way we could build the bars out of 16*16 sprites/bobs maybe.

Another way to do this might be to have just one big sprite for the whole bar, showing fully energy all the time, and then we would draw a black filled rectangle over, changing the size of the rectangle according to energy level. I assume Blitz can do simple drawing commands like that?

---

So, the graphics for the demo level are now ready, and it sounds like LordofChaos is working on a music tune.

Now we only need a programmer to put together a simple demo level.

It doesn't need to be great, just make a simple platformer using the Megaman sprite and the enemies, and make Megaman able to run, jump and shoot, and add some simple collision detection. The advanced stuff like wall sliding and dashing are not necessary at this point.

We only need a demostration of the running speed. If possible, add a frame counter display to the screen, and also make it so that when Space Bar is pressed a new enemy drops to the screen, so that we can see how much stuff can be put to screen before slowdown starts. And also you can make everything with bobs to make things easier, let's see how slow or fast they are.

---

I'm also considering that I should try out Amiga Blitz Basic myself...I read some threads in the coding section and the syntax seems to be very close to BlitzPlus. So where can I download it, should I use the classic Blitz Basic or that newer "AmiBlitz" thing, are the manuals and other documentation available somewhere, and what is the recommended way to use it with the WinUAE emulator, like should I configure it to be an A500 or A1200 or does it matter? Just give me good instructions so that I can get started, and I'll make this game.

[ReadOnlyCat]

Originally Posted by Master484

So, the graphics for the demo level are now ready, and it sounds like LordofChaos is working on a music tune.

Now we only need a programmer to put together a simple demo level.

It doesn't need to be great, just make a simple platformer using the Megaman sprite and the enemies, and make Megaman able to run, jump and shoot, and add some simple collision detection. The advanced stuff like wall sliding and dashing are not necessary at this point.

You do not seem to realize that this is a way harder task than anything related to converting graphics. This prototype you are talking about requires a full fledged platforming engine. And even harder comes the tweaking of the gameplay afterward.

These two steps should be done first. All the rest is completely secondary.

[Master484]

@ReadOnlyCat
The game engine is indeed the most important part, and we have now reached the point where someone should create one. Anyone is free to try to make it, but I think I too will also take a shot at it...I am games programmer myself, having made stuff on the PC, and I can't just sit here and ask others to make me a game.

I just found out that I actually had both AMOS Professional and Blitz Basic sitting on one USB stick. The Blitz files weren't in ADF format though, just a collection of folders with various files in them, and I couldn't run it. But AMOS Professional was in ADF format, and it runned fine in WinUAE, so I think I'll use it, seemed "basic enough" for me. I just need to figure out how I can load those IFF images into it.

And also I run one interesting test program in AMOS titled "Sprites vs Bobs"...and I think I'm beginning to understand the problem that we have here; sprites are fast but bobs are slow. Slow as snails in fact.

[ReadOnlyCat]

Originally Posted by Master484

@ReadOnlyCat
The game engine is indeed the most important part

The second most important one actually. The most important one being the gameplay.

Originally Posted by Master484

And also I run one interesting test program in AMOS titled "Sprites vs Bobs"...and I think I'm beginning to understand the problem that we have here; sprites are fast but bobs are slow. Slow as snails in fact.

Bobs are fast too, you should be able to display a dozen of reasonably sized ones every frame without issue in 4 (and possibly 5) bitplanes mode.

I suspect the culprit is AMOS there which might be doing a lot of unnecessary copying/redrawing. Their bob routines are probably designed for the most possible generic use and could do a lot of things that are not needed in many cases (save and restore background every frame, etc.).

[S0ulA55a551n]

Originally Posted by kamelito

collision detection explained, include megaman.
http://www.emanueleferonato.com/2012...d-platformers/

Kamelito

really interesting read, thanks. Had just started messing about with pure basic on another project and this will come in very useful

[JudasEZT]

I think that if you don't program an engine or something similar.. you'll not be able to design real gameplay at all.

Originally Posted by ReadOnlyCat

I suspect the culprit is AMOS there which might be doing a lot of unnecessary copying/redrawing. Their bob routines are probably designed for the most possible generic use and could do a lot of things that are not needed in many cases (save and restore background every frame, etc.).

While thats very true.. you are able to control the way your bob are displaying with SET BOB command..

Also is good to take in mind the UPDATE EVERY command. With that you'll have to be able synchronize the timing you display your bobs onscreen.

I like the idea that scrolling and player main sprites being moving always 50fps, while other elements doesn't need to update that fast. My guess is that that can be reached with Amos. ( and try it doesn't look like the typical Amos-stuff )

having said this,.. take a look a what can be reached in Blitz Basic having good acknowledgements of programming.
[ Show youtube player ]

[idrougge]

Originally Posted by ReadOnlyCat

I suspect the culprit is AMOS there which might be doing a lot of unnecessary copying/redrawing. Their bob routines are probably designed for the most possible generic use and could do a lot of things that are not needed in many cases (save and restore background every frame, etc.).

I think the biggest culprit in AMOS might be very slow logic, and an environment that doesn't allow for elegant logic. You'll need to be a good programmer to make an advanced platform engine run quickly enough in AMOS to leave enough time to actually update the screen, and if you're that kind of programmer you'll have advanced to Blitz at the very least.