Megaman X on the Amiga?

[Shatterhand]

Originally Posted by Mrs Beanbag

i really wish more people would transcend AMOS/Blitz, but it's quite a big jump all the way to asm without much in between.

Graphics look great though! But maybe consider using a hardware sprite for the main character so he can have his own separate palette, and thus be rendered more faithfully to the original.

I am learning Blitz, and I am get the gripes with it very quickly I think. I really don't see myself learning ASM (even more for an "obsolete processor") at this point of my life.

From what I've seen done with Blitz, I really find it to be capable enough.

[ReadOnlyCat]

Originally Posted by Shatterhand

I am learning Blitz, and I am get the gripes with it very quickly I think. I really don't see myself learning ASM (even more for an "obsolete processor") at this point of my life.

From what I've seen done with Blitz, I really find it to be capable enough.

Forget about ASM. You will need it only when you start pushing the machine hard. C is enough for 90% of any first game you will write.

It is more powerful than Basic and equally simple to learn. When you get to the point when you reach C's limit on. Amiga then you can learn assembly but there is no need to worry about it in the early stages.

You can code arcade perfect Pacman, Space Invaders, Donkey Kong, Lode Runner, and many others in C on a A500 without a single line of assembly language.

Basic on the other hand, you will reach its/their limits pretty early on.

[ReadOnlyCat]

Originally Posted by Mrs Beanbag

the SNES didn't have such a great CPU however,

Note that the SNES having a slow processor is a myth perpetuated by people who were only capable of comparing clock frequencies. The machine's CPU executes more instructions per clock cycle and seems to have roughly the same computational throughput as the MegaDrive's 68k if not higher in some cases.
Cf this discussion on 6502 forums of the subtleties of the 68516 performance. There is also a similar discussion on the Ars Technical forum with about similar conclusions.

People love to talk about the SNES's slowdowns but I have noticed plenty of slowdowns in MegaDrive games as well. The two machines processors seem overall very comparable in terms of performance.

Originally Posted by Mrs Beanbag

Amiga games are often Blitter bound (where SNES uses hardware sprites), so a higher-level language isn't necessarily so limiting, but AMOS, as i've discussed elsewhere, is limiting in a range of ways, not just limited to pure computational performance. C might be up to it, however, but i know nothing of Amiga C development, and it still leaves the programmer to do all the hardware banging, which can be a daunting prospect (moreso than the Asm itself, i think).

Well, it is only daunting if you proceed to bang the hardware directly but here is no reason why a good simple hardware abstraction layer library cannot be written in C which would be similar to what AMOS and Blitz offer.

Frankly that cannot be too hard to write. The sole problem is finding a volunteer to write it.

[Master484]

I have a working version for a Mega Man X module. It's the Storm Eagle Stage. File size 94k. Most samples ripped from the SNES ROM. Should convert to ProTracker with no trouble.

That sounds great, very close to the SNES original, well done.

And it's good to know about the file sizes, 100k for each music track is OK I think. I have no idea how much space the graphics and the code will take, but I would estimate that we will be able to fit an entire level to the memory without the need of mid-level loading breaks, at least on a 1MB RAM machine.

Could you make some simple sound effects too, like the x-buster shot sound and the explosion sound? The options menu of Megaman X has a sound test, so you can probably rip them easily from there.

And after that we'll have enough sounds and graphics to build the short demo level.

But maybe consider using a hardware sprite for the main character so he can have his own separate palette

That would indeed probably be the best option...when designing the graphics I just went for the 16 colors idea and had no idea that in addition to those 16 colors the hardware sprites can have their own palette. This realization opens a few more possibilities palette wise, for example I picked that deepest blue just because I wanted the blue parts of megaman to have exactly that SNES blue. But it's over saturated and doesn't go so well with some of the other colors. Most likely a palette upgrade should be made at some point, but I'll think about that only after the game engine is ready and capable of running the game.

Lionheart is OCS Dual Playfield (8+7 colours) with a lot of fancy Copper work, plus hardware sprites

That's totally amazing, I too thought it was 64 colors and needed an AGA machine to run. Well, there is proof that 16 colors are enough to make a decent looking game.

And when I hear all these things that the Copper has been used for in various games, I'm becoming more and more convinced that when designing a game for the Amiga, it should also be designed for the Copper and and all the other special chips that we have...they essentially give the Amiga a huge edge over other machines that don't have them, just like the special hardware in the arcade coin-ops do.

But as I mentioned before, I still have no Amiga programming experience whatsoever, so it's hard for me to design anything for the Amiga, despite having solid skills for making 2D games on the PC.

In addition to BlitzPlus, I also have basic skills in C++ and have used the SFML library to make an (unfinished and unreleased) game with it. And so I wonder if should try out C on the Amiga. Is it any different than in PC, and are there good/capable/easy-to-use C graphics libraries available for the Amiga? Or would I still need to use ASM with it to make a game like Megaman X?

---

But in all cases, I too definitely want to see a demo of Megaman X running on either AMOS or Blitz Basic. And make sure it's compiled to machine code first using the compilers that are available for them. Then we can really see how fast/slow they are, and either gasp our breath in amazament of the 50fps action that they delivered us, or have a good laugh when Megaman runs around at snail speed while graphics flash and glitch.

Coding of the BlitzPlus prototype is progressing well, a day or two more and it should be complete enough. I'll then post it here with a well commented source, and some of you can convert it to Amiga Blitz.

And I hope that Amiga Blitz has an equivalent command for this sort of thing:
Type GameObject
Field X
Field Y
Field Energy
End Type

And then we can use "go.GameObject = new GameObject" to create a new GameObject at any time. I believe Amiga Blitz has a this sort of command too, but I'm not sure. I'm just asking because the proto I'm making relies on structures like this...handling all enemies with this allows us to do that "press space and a new enemy jumps to screen"-thing.

[Shatterhand]

You can define new types on Blitz Basic, but there's no Object Oriented coding on it, so forget about instantiating classes like this.

So far, what I've seen to be the best solution is to have an array of "enemy types" per say. It's more messy to code than using object orientation.. it's like you always have all instances of that object ready, and then use just the ones you need. You need a bit more planning before starting typing code than you'd need programming in a OO enviroment.

[gimbal]

Originally Posted by ReadOnlyCat

Frankly that cannot be too hard to write. The sole problem is finding a volunteer to write it.

Another realism-prick remark: if it were that easy, it would already exist a hundred times over at this point in time.

[jbenam]

Originally Posted by lordofchaos

[ Show youtube player ]

I have a working version for a Mega Man X module. It's the Storm Eagle Stage. File size 94k. Most samples ripped from the SNES ROM. Should convert to ProTracker with no trouble.

File included.

Oh WOW. That's a sick tune! I love it, and I've played the SNES version to bits - I can only imagine how awesome would an Amiga version soundtrack be now

[ReadOnlyCat]

Originally Posted by gimbal

Another realism-prick remark: if it were that easy, it would already exist a hundred times over at this point in time.

Well, I am not too sure I appreciate being called a prick, but you are incorrect: there are plenty of possible reasons why an easy thing never gets done by people qualified to do it:
- they already have written similar code but not releasable (because coupled with other code) and have no additional time to spend on it.
- they do not need it themselves because they already are used to banging the hardware directly without such an abstraction.
- they are not interested in writing code for others.
- they have higher priorities on their own projects.
- they do not code for the Amiga.
- they do not code in their free time.
- they do not want to share what they consider their own baby (think demo coders of old).
- they did not think of it.
And I am sure you can find many other reasons if you spend the time.

Something easy does not necessarily gets done if the people who need it are not the ones who can code it. They is a clear non overlap of interest there.

Just take my example: I have been thinking of writing one such since arriving on the EAB about one year ago but there is no trace of it anywhere yet: this is not my priority as I am prototyping for now and this might require several projects of mine released (I.e., years) before it gets fleshed out along as I create new stuff. This takes time in that case not because it is hard but because I do not want to divert time from my current project so the "library" project progresses only very slowly in parallel when I can apply some current knowledge about what I am doing for it.

The reasoning "easy so should be there already" is patently false. Most innovations are easy in hindsight but there are only so many available hands, time and willingness to produce them.

Originally Posted by Master484

That sounds great, very close to the SNES original, well done.

And it's good to know about the file sizes, 100k for each music track is OK I think. I have no idea how much space the graphics and the code will take, but I would estimate that we will be able to fit an entire level to the memory without the need of mid-level loading breaks, at least on a 1MB RAM machine.

100k sounds (huhu) way too much. That is one fifth of the global RAM budget. I might be wrong but I would not go much over 1/10th of the total RAM.
Even if you target 1MB, then this seems still a lot: you also want to be able to store sound effects.

Originally Posted by Master484

And when I hear all these things that the Copper has been used for in various games, I'm becoming more and more convinced that when designing a game for the Amiga, it should also be designed for the Copper and and all the other special chips that we have...they essentially give the Amiga a huge edge over other machines that don't have them, just like the special hardware in the arcade coin-ops do.

The copper definitely is the neatest piece of hardware the Amiga has to offer!
It is a fantastic enabler.

Originally Posted by Master484

Is it any different than in PC, and are there good/capable/easy-to-use C graphics libraries available for the Amiga? Or would I still need to use ASM with it to make a game like Megaman X?

None that I know but there might be some.

I recall Samurai_Crow mentioning some work on it but I am not sure it is available. Any such library needs to be Amiga-or-less specific as the machine is not powerful enough to allow very generic abstractions.

[lordofchaos]

Originally Posted by Master484

Could you make some simple sound effects too, like the x-buster shot sound and the explosion sound? The options menu of Megaman X has a sound test, so you can probably rip them easily from there.

No problem, I started ripping them last night, will post when I have finished converting.

Originally Posted by jbenam

Oh WOW. That's a sick tune! I love it, and I've played the SNES version to bits - I can only imagine how awesome would an Amiga version soundtrack be now

Thank you, it was a lot of fun making it.

Originally Posted by ReadOnlyCat

100k sounds (huhu) way too much. That is one fifth of the global RAM budget. I might be wrong but I would not go much over 1/10th of the total RAM.
Even if you target 1MB, then this seems still a lot: you also want to be able to store sound effects.

I haven't optimised the module yet, might be able to get it down to about 70k, which is pretty manageable in most cases, I'd imagine.

[AnimaInCorpore]

Originally Posted by Master484

...they essentially give the Amiga a huge edge over other machines that don't have them, just like the special hardware in the arcade coin-ops do.

[john1979]

Originally Posted by ReadOnlyCat

Note that the SNES having a slow processor is a myth perpetuated by people who were only capable of comparing clock frequencies. The machine's CPU executes more instructions per clock cycle and seems to have roughly the same computational throughput as the MegaDrive's 68k if not higher in some cases.
Cf this discussion on 6502 forums of the subtleties of the 68516 performance. There is also a similar discussion on the Ars Technical forum with about similar conclusions.

People love to talk about the SNES's slowdowns but I have noticed plenty of slowdowns in MegaDrive games as well. The two machines processors seem overall very comparable in terms of performance.

Agreed. You've only got to play Super Aleste to see how much the SNES could throw around on screen without slowing down.

[Shatterhand]

Super Aleste is full of slowdowns. It's not as bad as Super R-Type or Gradius III, but they are there.

And I don't rememeber ever seen anything on SNES pushing a shitload of stuff on screen like Gunstar Heroes, Alien Soldier, Contra Hard Corps or Vectorman.

A lot of SNES games have slowdown with very few stuff moving on screen. I don't know why it happens, but it does, and it happens a lot more than on Mega-Drive games (even though, yeah, MD games do have slowdowns too, obviously)

[switchblade]

Originally Posted by Master484

And when I hear all these things that the Copper has been used for in various games, I'm becoming more and more convinced that when designing a game for the Amiga, it should also be designed for the Copper and and all the other special chips that we have...they essentially give the Amiga a huge edge over other machines that don't have them, just like the special hardware in the arcade coin-ops do.

You do realize that's not really a valid comparison? As impressive as the Copper is, it's abilities can easily be outmatched through an arcade machine's raw, processing power.

Granted, the arcade's raw processing power wouldn't be as efficient as properly utilizing the Amiga's Copper for certain graphical effects. But then again, most arcade coin-op games aren't really "professionally programmed" like certain Amiga games, if you know what I mean.

[lordofchaos]

The only people qualified to say something's easy with regards to coding, are the coders themselves. They might well say something is easy, but like everything else it's completely relative to individual ability.

[Galder]

Very cool -as it is already said: make it happen

[idrougge]

Originally Posted by Master484

And I hope that Amiga Blitz has an equivalent command for this sort of thing:
Type GameObject
Field X
Field Y
Field Energy
End Type

NEWTYPE.GameObject
X.w
Y.w
Energy.w
Type.w
End NEWTYPE

Originally Posted by Shatterhand

You can define new types on Blitz Basic, but there's no Object Oriented coding on it, so forget about instantiating classes like this.

So far, what I've seen to be the best solution is to have an array of "enemy types" per say. It's more messy to code than using object orientation.. it's like you always have all instances of that object ready, and then use just the ones you need. You need a bit more planning before starting typing code than you'd need programming in a OO enviroment.

I don't think object orientation is that helpful in platform games anyway. You already have your newtype (struct in C lingo) containing your entire enemy. The "new GameObject" statement is only useful in as far as the object having a constructor. But there's no real reason you can't have a function returning such a type with all fields filled in. It's mostly a matter of calling convention, and if you're not schooled in OO to begin with, it doesn't matter if your enemies are constructed by a separate procedure or a constructor method.

You make a linked list containing your enemies with

Dim List enemies.GameObject()

and place your enemies in the list using

AddItem enemies()

Using a list, you don't need to obsess about the bounds of an enemy array; you can remove or add enemies at your own leisure.

Your game loop will thereby step through the enemy list using

ResetList enemies()
While NextItem enemies()
enemies()\x+1
If enemies()\x = player\x Then enemies()\energy-1
Wend

[idrougge]

Originally Posted by ReadOnlyCat

Forget about ASM. You will need it only when you start pushing the machine hard. C is enough for 90% of any first game you will write.

Unfortunately, C without any helpful libraries to access hardware is just assembler with a different syntax.

Originally Posted by ReadOnlyCat

It is more powerful than Basic and equally simple to learn.

More powerful? Yes.
Equal simple to learn? Get real.

Originally Posted by ReadOnlyCat

You can code arcade perfect Pacman, Space Invaders, Donkey Kong, Lode Runner, and many others in C on a A500 without a single line of assembly language.

You can do that in Basic too, only much faster than using C.

Originally Posted by ReadOnlyCat

Basic on the other hand, you will reach its/their limits pretty early on.

You will, but at least in Blitz2, you can resort to some assembly optimisations with ease.

The performance disadvantage in a powerful basic such as Blitz versus C only holds true as long as your C code is either computation intensive or hardware banging. If you use a hardware abstraction layer in C similar to that of an advanced Basic, the extra cost in Basic may be summarised as:

1. Expensive setup of X coordinate (bounds checking, type conversion, stack handling)
2. Expensive setup of Y coordinate
3. Expensive setup of source bitmap address
4. Expensive setup of target bitmap address
After that, we are ready to call the Blit command, upon which we JSR into optimised assembly, whereupon the added costs of Basic are no longer relevant.

Don't want the extra setup costs? Choose your datatypes correctly, make sure your code works as it should, and turn off the debugger. Still not enough? Write some inline assembly. This doesn't require that you learn all the intricacies of 68000 assembly or of setting up custom chip registers. You only need to learn a subset of asm, and you could just pretend it's a very stupid little high level language.

[Mrs Beanbag]

Originally Posted by gimbal

Another realism-prick remark: if it were that easy, it would already exist a hundred times over at this point in time.

It already does exist, several times at least...

There exists, for instance, AMOS and Blitz, which have exactly the required APIs already programmed into them, sadly you need to write your programs in AMOS or Blitz in order to actually use them. In fact they are real kitchen sink projects that are as impressive in their comprehensiveness as they are frustrating in their closedness. It must have been far more work to write AMOS or Blitz than just to write a game functions library that could be used from C.

Then of course there is the proliferation of "Meta-APIs" like Backbone and Reality, game engines written in AMOS, which i have to say, in all my experience, i think these would be easier to write directly in ASM than in that particular language, but there you go.

Originally Posted by idrougge

Unfortunately, C without any helpful libraries to access hardware is just assembler with a different syntax.

More powerful? Yes.
Equal simple to learn? Get real.

Come on now, C is nothing like asm, the only difficult thing about it is pointers, but once you get your head around that it's plain sailing. It abstracts away the CPU architecture, registers, the stack, &c... I'd say it was more like Blitz with a different syntax. Afterall, arithmetic expressions are almost exactly the same, one just writes such things as "A=(B+C)*D", it even uses some of the same keywords as Basic, like "if" and "else" and "for" and "while".

You can do that in Basic too, only much faster than using C.

The disadvantage of C over Blitz, apart from performance (which i can't vouch for), is the lack of immediately accessible development environment. Although it binds you to a particular editor which i've heard is not very good, at least you don't have to mess around with command line tools and linkers, it's all self-contained, you just click "run" and it runs.

(Does Blitz have immediate mode? This is also nice for trying things out ad hoc.)

You will, but at least in Blitz2, you can resort to some assembly optimisations with ease.

The limit is not just the performance, it is the lack of structure, flexibility and expressive power.

[Master484]

You do realize that's not really a valid comparison? As impressive as the Copper is, it's abilities can easily be outmatched through an arcade machine's raw, processing power.

Well, maybe some of the more powerful arcade machines of the Amiga era (1986-93) could do something similar with raw CPU power alone, but even they would have to pay the price by investing a lot of CPU power to do "Amiga Copper tricks" such as making 16 colors to look like 64. Lot of arcade machines ran on the same exact same CPU as the Amiga, the 68000, and even the 14mhz versions of it weren't that fast. But what I was actually thinking about when making that arcade comparison, were other computers and consoles of those days. For example when you compare the Amiga to old PCs like the 286 and 386, or to consoles that existed at the time when Amiga arrived, like NES and the Sega Master System, in comparison to them many of the capabilities of the Amiga were "Arcade", it had specialized sound and video hardware to which they didn't have a direct equivalent.

And even later, when consoles like the SNES and Megadrive arrived, the much older Amiga hardware was still capable of doing most of the stuff they could do. And even when newer arcade machine generations such as Neo Geo and CPS-1 arrived, the basic A500 could still hold it's own even against them...the only real advantage that the coin-ops had was that they could quickly access their massive arcade cabinet ROM data storges and this way keep up loading and throwing big graphics into the screen at will witout any loading breaks.

Think about an Amiga game like Agony, that actually uses the Copper and all the other special chips to the fullest. Then imagine that same game, still running on an A500, but with 50 times more graphics and sound files contained in ultra-fast loading ROM chips, and the whole thing being made into an arcade machine and put into any game hall back in the 90'ies. Surely it would draw attention and people would queue to play it. Especially if it was a large sit-in cabinet with gothic art, a large monitor, hidden speakers for real surround sound, an elevated seat to which you would need to climb on (you're a flying owl after all), a huge joystick and doors that you could close to achieve total darkness.

And people would think it's raw CPU power that makes it possible...but nope, the extremely advanced special chips of a home computer released in 1986 make it possible. In 2D action games the CPU power is only needed for math operations and to give orders to the chips; this is why many "ultra powerful" arcade machines still just had the 68000 inside them; nothing more was needed.

---

100k sounds (huhu) way too much. That is one fifth of the global RAM budget.

Well maybe our budget for each level would then be 100k sounds, 200k graphics and 100k for code, in total 400k. This would still leave us about 100k of "creativity space" that we can then use for any purpose depending on the situation.

Although for the entire game this plan would mean the 12 disks that I mentioned before, so it may not be feasible for that. But at least we could make one epic demo level, and it'll run on an A500 with 512K RAM.

And it just came to my mind that the entire Megaman X game is almost like a collection of "level modules"; you choose one level, load it and play it. So even if a disk change would be required when entering a new level, this would still be OK, and not even nearly as bothersome as in games like Street Fighter 2 (two disk changes for each fight). And of course we'll make the game to support up to 12 external floppy drives.

[Mrs Beanbag]

level data can be stored compressed on disk, you wouldn't just store all the graphics as raw bitmaps. Even an IFF image has some level of compression. But you can certainly do a lot better than that.

Also maybe think about using synthesised sound effects instead of flat samples for everything? And 100k of Protracker mod is more than you might think. You can get a lot of good sounds using very short loops and effects commands. Plus you can share samples between modules, especially the percussion samples (which are impossible to loop).