Sooo although I think this would be awesome but I don't know how easy it is as I don't do much in the brewery biz ... 

How hard (or easy) would it be to covert MERCS from a Sega game to a SNEs game ? I'd really like to see it but don't know where else Togo with the idea ....

Sega has blast processor, Nintendont. It might be difficult

What's blast processor ? I am like a 2 yr old so be nice

It's not going to happen. You're talking about a massive project to completely reprogram a game from a totally different system. Different CPUs, different Graphics hardware, different sound hardware. And what would be the point? To have the same exact game but running on a SNES? If you like Mercs and want a better version, try the PS2 version that emulates the CPS1 arcade version maybe?

Blast Processing was a marketing tactic by Sega. Basically claiming that the CPU was faster than the SNES

Google "RetroGen"

End of Discussion

It was faster than the SNES, but had comparatively poorer audio and I think the game cartridge was significantly more expensive per kilobyte than the SNES ones (at least the games are generally smaller). Many genesis games also didn't have save game batteries, notably Sega's own Sonic 2 which you had to leave on for hours NES-style to get all the emeralds and beat the game. I think SNES games also had the ability to look a bit sharper and more detailed with better colours. The SNES had less raw speed, but made up for it everywhere else... in particular it made it the ideal console for RPGs where speed isn't necessary but sound and static graphical detail/colours are. It's not a walk-over though like some would have you believe.. many games are better on Genesis, especially fast games like sports games.

http://www.theflatness.com/2008/11/snes-vs-genesis-eternal-s...     
    

That's a nice little article there, thanks. Ill be getting the retrogen I'm sure but just wondering how hard it would be to do this ...

No ps2 unfortunately but ill try to check that out too

Thanks for all the info guys, ill sleep a little better tonight

It is extremely important to remember that the 68000 and 65816 CPU are very different. Even if both CPUs ran at say, 7mhz, one of them is actually still going to perform faster than the other as it isn't all about clock speed but also what exactly happens each cycle. In general people tend to agree that the 68000 CPU in the Genesis performs faster than the 65816 in the SNES. But that doesn't offer a given advantage to every game. There are games poorly programmed on the Genesis, Mega Man Wily Wars comes to mind instantly. It suffers crazy slowdown and there is no excuse for it. It's sad that the Genesis with its far more advanced 68000 at over 7mhz running the boss battle with Cut Man slows down quite terribly compared to the NES with its 1.78mhz 6502. It shows truely poor coding will still make your game slow even if you have a fast processor.

How fast things scroll by or move through a level don't really give an impression of how fast the CPU is as it takes very little to just fling a bunch of crap around. What takes considerable CPU power is when you have to calculate alot of things in a very short amount of time. That's why games tend to slow down not when the background is moving fast, but when you have alot of objects on the screen. These objects take time to be calculated to draw them onto the screen with their proper graphics an attributes, but also they will tend to interact with the player, the background, or even other objects that are active.

About sound, both systems can sound great actually. And both can sound pretty shitty too. It's all about how well you make use of what you've got, just like the CPU. At it's peak the Genesis CPU should out perform the SNES CPU I would think. The SNES sound chips can probably in a real world situation (not just a demo) out perform the Genesis. But again that doesn't mean either is bad.

About the cost of ROM memory, you'd need to find some internal documents or talk to someone that was in the business back then to know. The speed of the ROM and size both factored into cost. The SNES and earlier titles all used ROM chips that were basically the same speed as those used for the NES graphics chip (chrrom). But later titles eventually got somewhat faster chips that did allow the CPU to run a bit faster. I'm unsure of the speed required for the Genesis. The were not neccessarily faster because the 68000 has a 16bit bus and may not need to access ROM as often or as quickly, I'm not really sure.

The SNES certainly did have an advantage in graphics. The Genesis was limited to four 16 color palettes for everything that appears on the screen. Background tiles and sprites. The SNES had sixteen 16 color palettes, with half for background tiles and half for sprites. This was very apparent in games like Mortal Kombat. Think about this, you have two random combatants, so two of four palettes are gone already. You also need some for the background of the stage and the status bar, plus for the blood/gore. And some characters shoot projectiles that aren't the same color as the character themself. That's why in MK1 Cage shoots this gray blob instead of his green force ball. They just didn't have enough color palettes. On SNES with so many more, you didn't run into color limitations so easily. Infact a character could have 30 colors if you layered sprites ontop of eachother. On Genesis this layering would be very costly because now you're using two of four palettes just for one character to have more color detail.

SNES also had several background modes, including mode 7 to allow for scaling and rotation. But it also had color effects to achieve see through water, fog, light, whatever you want. The Genesis had a higher resolution mode which allows for a wider play area. It has some features the SNES does not, both nothing that stands out.

But again with all this in mind, that doesn't mean either system automatically wins. It comes down to the software and what you do with it. If you poorly use the resources of the console then that's what you get. You can certainly make a bad SNES game or a bad Genesis game. But both systems have good games. Everyone will have their favorite system of the two but both have great games.

Oh cool, another SNES vs Genesis thread. Can't we ever just stick on topic without getting into this tiring discussion?

Watch out, last time I said this I got slammed because of the SMB project where *some* of the code was transcribed automatically. But still, with how much code you'll write to complete the port, it'd be much better to make a new game from scratch.

But yeah, it's possible. Anything is possible. You can program anything your heart desires. But like said, it's tons of work.

The SMB project is a poor example as proof of porting a Genesis game to SNES as being possible. No matter what you aren't going to "automatically" convert these games. It'll take considerable effort. Anyway, slammed by who? People that don't know the first thing about how programming for one of these systems works I would imagine? And I certainly didn't say it wasn't possible. I said it's not going to happen. Mercs runs in the 40 cell width mode too. SNES can't do 40 cells. Right there you'd have to redo the status bar on the right of the screen and all other screens like the title. That may require redrawing/shrinking various graphics.

I say it's not gonna happen because there is no point in anyone doing it when if you have the skills to do that there are likely other more interesting projects you could do.

what MottZilla said

That's because you said it was impossible, and I provided a link with proof that it was possible, as did other people.

He probably said impossible when he meant it was unlikely to happen and no one should expect some magic genie or program to poop out perfect conversions on demand. People think programming is like typing into a window, "make game like Halo but with Ghosts and Goblins and Unicorns" and press a button.

If you wanted to and had the proper skills, you could port Marvel Vs Capcom to the SNES. Yes it IS possible! All you have to do is disassemble the arcade program and fully separate the code and data, go through all of it to try and get a handle on what everything is and does. Then you *just* need to translate all that code from 68000 assembly into 65816 code and probably adjust all data pointers etc. You'll need to redraw all the graphics for the lower screen resolution, adjust the code/function of the game to reflect the smaller screen size. You'll need to completely reprogram the sound cpu program and convert all the samples, figure out how to load the samples needed at a given time since they won't all fit into the SPC's 64k of memory at once.

Yes, it's all possible. But what he was saying is given the huge task, you might as well say it's impossible. You're harping on him for a choice of words when he was just pointing out the task's difficulty.

It's also important to know that SMB1 is a game program for the Famicom that is not terribly complex compared to newer games. And it's had the benefit of others disassembling and reverse engineering it. The game given here, Mercs for Sega Genesis, is more complex and you're talking about going from a 68000 program to a 65816, opposed to trying to transcode a 6502 program to run on a 68000.

So anyway, Mercs on SNES via the Genesis version as a conversion is possible but such a large undertaking that it's not likely to happen.

You can read it for yourself: http://www.nintendoage.com/forum/...

He was giving horrible and inaccurate answers.

Well I read it and it didn't seem to me like he was saying "no it's impossible, end of story". He seemed to be saying essentially the same thing we all seem to agree on. There's no reason to pick on his wordings. Either way it doesn't look like there is anything to debate. We all seem to be in agreement in the big picture here.

Why yes, yes he did.

Question, I remember reading that Wily Wars was outsourced to an outside developer. And there is a rumor that Wily Wars is one of the few Genesis games to not be written in assembly, but rather in higher level languages like C++. The Genesis apparently was strong enough to handle C++, but it wouldn't be near as efficient as assembly.

Also, I think part of the reason why the SNES slowed down so much is because programmers were spoiled with it's displaying capabilities.  Flicker existed in NES games to alleviate CPU tension, where in SNES games flicker is near nonexistent, and probably meant that the CPU had to work overtime to keep the graphics visible as opposed to making them flicker temporarily.  Additionally, Genesis games appear to use flickering much more often than SNES games, and when the Genesis does slow down, it comes to a screeching halt.  Lightening Force does that in the first level!

As for porting games, while the effort required to do so is herculean, you could even port a high definition game with ludicrous animation fluidity like SkullGirls to the NES.  That's of course, if you know what you're doing; for ranged attacks, make the graphics flicker lightly, bankswitch graphics data rather frequently, dPCM vocal samples, etc.  It's doable, but it won't be worth the effort.

Flicker of sprites has nothing to do with the CPU. This is just like that rumor I saw all over saying that "slowdown in games intentional so the game doesn't crash".

Why do NES sprites flicker? The NES PPU can only display 8 sprites each line. Anything after that is dropped entirely from the frame. This would be very undesirable to just have objects completely disappear. So games are programmed to shuffle the order of sprites around causing "flicker" of sprites because some frames a sprite is drawn while other frames it is dropped. Slowdown during "flicker" has more to do with more objects being processed at that time.

The SNES usually doesn't show this sprite flicker for a couple reasons. Number one being that the SNES can display up to I believe 34 sprite cells per scanline, meaning the entire line can be filled up with sprites before anything gets dropped. Next because of the large amount of sprites before dropping occurs, some games may not cycle sprites at all so instead of flicker the sprites are just plainly dropped/not drawn. How you program the game and how your game uses sprites can make this flickering issue worse or better.

The Genesis I'm not sure but I've seen it say something like 20 sprites (perhaps of varying cell size) per scanline which sounds like you can probably fill up a large amount of the scanline before having drop. It depends on the game too, Final Fight CD seems to not cycle sprites, because sprites don't flicker they just get dropped if too many are on a scanline. Flicker if cycling is going on and slowdown at the same time is just a coincidence as there is alot of processing that must be done due to the amount of objects on the screen which also means alot of sprites being drawn which may mean flickering to give them all a turn being displayed.

The CPU doesn't draw graphics, it can't "work overtime" to stop flicker.

I have also heard that Wily Wars was programmed in C (not C++) rather than ASM. Inefficient programming in C would certainly bog down the 68000 in the Sega Genesis more than inefficient ASM. But they probably could have gotten reasonable performance if better programmers had been on the job. The 68000 at 7.5mhz is not a bad platform for C programming. The SNES can have games programmed in C as well, but the CPU itself may not have as great of C Compilers and the slower speed could mean you really need to make highly efficient code, or avoid writing any time sensitive parts in C. Some people have gotten reasonable performance on the NES and SNES using C compilers. But compared to the 80s and early 90s, the compilers *might* have advanced since then and gotten better.

Yeah, the SNES does 32 per scanline, 128 total. The Genesis does 20 per scanline and 80 total. The NES does 8 per scanline and 64 total, which is funny since the other machines can have 1/4th of the graphics on a single scanline, where the NES can only have 1/8th.  Understandable, since it would've been too expensive, and Yamauchi wanted a profit. 16 tiles per scanline would be MUCH better than 8, no?

Well the NES was a consumer machine designed in 1983. There is only so much you can do and stay in budget.

I think you had a mistake on your math. 256/64 is going to be 1/4th. 8 sprites of 8 pixels is 64. That's what the NES can do. The Gameboy has 10 sprites for 1/2 screen coverage possible. But ofcourse screen coverage possible isn't all there is since in a real game there will be overlapping sprites going on, maybe even hitting the limit of total sprites that can be displayed.

The SNES I've read the per line limit is 32 sprites but 34 cells, sprites can have more than 1 cell (8 pixels) if their size is configured so. The Genesis may be able to have more than 20 cells of sprites per line too. But you'd have to ask someone into Genesis development as I don't know for sure.

If you want to see something with crazy sprites, look at the NeoGeo. It has a single very simple background layer, usually it just has the credits and a status bar on it. Everything else, the actual game backgrounds and characters are all sprites. Ofcourse you could do that with arcade hardware.

When you think about the cost of supporting more sprites per scanline versus the benefits and taking into account how we know things played out, it wasn't worth it for the NES or other systems to support more sprites per scanline. Sure it would have been nice, but games got by without it. There's plenty of things we could think of to say, oh it would have been better if it had this.

Probably my #1 issue with an old system that I strongly feel should have been done is with the Sega Genesis. The Genesis when it came out was up against the NES but they knew that Nintendo would eventually come out with their own new platform and they should have been prepared for it. Infact I think in Japan the PC-Engine was already out. The problem I'm talking about is the miserable Color Palette. Now I don't mean the 9-bit color depth for the global selection of colors. That's fine, 512 colors total is no problem. I'm talking about having only four different 16 color palettes available for everything on the screen. Why!? While any addition would raise the cost of the system I think there was NOTHING more helpful to the Genesis design as it is than to have added another four color palettes. They didn't even need to add another bit to the background tile attributes either, they could have just given sprites and backgrounds separate sets of four color palettes bringing the total actual colors available at once up to something like 121. This would have definitely relieved some of the limitations developers had and made the games quite a bit more colorful. Infact if they could have offset the cost of that addition by cutting Master System support, that would have been worth it. Nothing against the Master System but Genesis needed that boost of color palettes badly.

Speaking of the Master System, that was really good with it's colors. It only used two palettes of 16 colors each, one for backgrounds and one for sprites. But that alone would make games look much more colorful (theoretically) than the NES could, such as backgrounds not having a vague feeling of being built around rectangles. Plus the sprite palette colors could also be used for the background, which considering the time, that was really cool. But yeah, the Master System, to invoke a meme, had no games, so it's not like it had a following of any sort at the time.

This might be me, but the Genesis' colors likely sound limiting only when you're comparing it to the SNES and even TG-16, as the latter had support for like 400 some colors at a time. However, most people used the insane colors of the other systems for stupid things like anti-aliasing or overabundant shading, with 6 shades of red for example. The Genesis likely required a mindset needed for the NES, and that was to keep your graphics colorful but at the same time simple, and try to reuse colors whenever possible. Considering that you could also potentially layer graphics together like the NES to give the illusion of more color, not to mention the ability to change the secondary palette to something else when new enemies show up, I think you could achieve brilliant results if you tried.

The music on the other hand was hard. Unless you were Yuzo Koshiro or Technosoft, or Sega themselves, it would be hard to make the Genesis sound decent.  Actually, come to think of it, I think most, if not all, of the Japanese developers for the Genesis were able of making outstanding music, while the westerners usually had a hard time unless they were Tim Follin or Rub Hubbard.  Understandable since Technopop's infamous sound driver, GEMS, was handed out as part of an official Genesis dev kit.

The Genesis colors were limited even without comparing it to SNES or TG16. They clearly needed more colors. The best Genesis games are not ports and don't look limited since they were carefully designed. Other games that were ports or not as well designed tend to show the limitations.

The Master System had a following in Europe mostly but there were those in the US and Japan that had it. I'd say they should have kept BC only for the European MegaDrive and cut it out of the NTSC version to cut cost to improve the color situation. But we can say whatever we want now knowing all that we do that they didn't.

The Genesis needed to have eight 16 color palettes at a minimum in my opinion. SNES had plenty, TG16 had tons. But Genesis was too few for sure. Doubling it probably would have made it far less noticeable of an issue.

Okay, here are my rules of porting a game from the Genesis to the SNES.

Color Palette: Round each Genesis color to it's nearest SNES color. Have a copy of the color palette available for both sprites and BGs to use.

Resolution: Just try to adjust the title screens and HUD to fit within 256x224. BGs and sprites can be left unmodified. If a boss fight uses a "level" that is just one 320x224, horizontal scrolling can be added.

Animation: Now this one is a tough one. The Sega Genesis has a bigger chunk of vram designated to sprite animation and faster DMA. My solution is to keep 16 pixels of fored blank on top and bottom of screen, so you can use DMA more. If there is already a HUD infront of a black bar, take advantage of the already small playfeild size, and move the HUD onto BG3.

Sound: Make a sample of every sound you use in the game.

Gameplay: You pretty much have to recode gameplay entirely from scratch.