Thunder Force 4 = overhyped

[tepples]

Super Mario World was also a launch title, and launch titles tend to be inefficient for two reasons. First, they're developed on preliminary hardware and much of the development effort is spent on continuously porting it to final hardware. Second, developers haven't yet discovered good workarounds for the hardware's quirks such as psycopathicteen's soft-OBC1 routine.

Finally, hacks tend to have more enemies per screen than the original game, when the original game's developers may have removed enemies from the map or, if a big group of them is necessary for a particular scene, taken time to optimize their code. And hacks, having been made by experienced players for experienced players, need more enemies for more difficulty.

The first two Sonic the Hedgehog games for Genesis used time-intensive compression methods to store all the tiles, meaning they couldn't replace as many tiles between sections of a level as Sonic 3 and later, which used a codec with faster (but less space-efficient) decompression.

[Sik]

I just went with those two because they were popular.

The first two Sonic the Hedgehog games for Genesis used time-intensive compression methods to store all the tiles, meaning they couldn't replace as many tiles between sections of a level as Sonic 3 and later, which used a codec with faster (but less space-efficient) decompression.

Um, no? Sonic 1 doesn't use any more compression than your average game. Sonic 2 does, but even then, in both cases it's just at load time, so compression doesn't factor in at all when it comes to slow down (only to increasing load times, thereby the title cards). Sonic 3 had some important changes to the engine but then again it doesn't slow down unless you abuse debug mode.

In other words, Sonic 2 is just sloppy as hell.

[tepples]

For the record:

STH1 uses the Huffman-based format cracked by Nemesis used widely throughout the Genesis library. STH2 uses a mix of "Nemesis" and an LZSS variant format cracked by Brett Kosinski. STH3 uses the Kosinski format more often.

[psycopathicteen]

Even code that does not have to deal directly with hardware, are written inefficient in SNES games, but not in Genesis games. A lot of SNES games are filled with subroutines where they push every register on stack, do something that takes 3 instructions, pull everything back from stack, and return. I never saw this happen in Genesis game code.

[tepples]

I wonder if the habit of pushing registers on the 65816 but not on the 68000 is because the 68000 has enough registers that it can get away with having an ABI that designates some as caller-saved. The 65816 has A for data and X, Y, D, and S for addresses; the 68000 has D0-D7 for data and A0-A6 and A7* for addresses. For equivalent code on both platforms, the 65816 might have to spill variables to direct page more often.

Or the fact that C compilers for 65816 might not have been very advanced, and the publisher of a multi-platform game didn't necessarily want to have to pay someone to code something in 65816 assembly and again in 68000 assembly. Even compilers targeting ARM aren't perfect; look at the grumbling about "HLL" in GBATEK.


* I list A7 separately because exceptions treat A7 specially.

[psycopathicteen]

I almost never use pushing and pulling in subroutines. I just don't expect the registers to be the same before and after a subroutine.

[tepples]

In other words, you use a all-caller-saved convention. Does this include only AXY, or also the data segment (B), frame pointer (D), and accumulator, index size, and decimal bits of flags (MXD bits of P)?

In any case, parts of my games use a convention of treating X as callee-saved, referring to the index of the player, unit, sound channel, or other thing being worked on at the moment. Think of it as like the "this pointer" in C++.

[Sik]

In other words, you use a all-caller-saved convention. Does this include only AXY, or also the data segment (B), frame pointer (D), and accumulator, index size, and decimal bits of flags (MXD bits of P)?

Probably just whatever the caller subroutine is expecting to use later.

And yes, the 65816 having way less registers is likely to be the cause. Also I don't think anybody even dared to use compilers on the 65816, it'd be way too slow, although C on the 68000 was reasonably efficient so compilers were more common there (still rare though, games were mostly asm). I think it was mostly Western studios that used compilers though, not Japanese studios (and Japan made the bulk of games).

That said, it was probably easier to just contract a company to do a port than to work on both platforms simultaneously =P

[tomaitheous]

When I optimize my 68k code, I end up using more than half of each set (A and D) most of the time. I'd say that I pushed/popped more on the 68k than I have ever done on the 65x. Though I don't want to make it out to seem I did a lot of stack work on the 68k, 'cause I don't. Just more so than the 65x.

Japanese developers in general, of that era, were never that great at writing ASM code IMO, or from what I've seen. Euro coders on the other hand, obsessively proficient at it - but I never liked their games. Go figure. 68k gets you pretty good bang for the buck (code) without much effort. That's probably why it was soo popular with Japanese arcade developers. But then again, they still wrote crappy code. Just a few examples: Gradius II arcade board was a dual 12mhz 68k setup and it still slows down. One of the Metalslug games (2nd or 3rd one?) had to be fixed cause the game slowed down like crazy.

psycopathicteen: You should really try to hack/patch SGnG and Gradius III. Even if that would require a faster speed rom setup, too.

[Sik]

I nearly never find myself using the stack on the 68000. In fact I only do it in two situations: when I literally run out of registers (by this I mean I exhausted all of D0-D7 and A0-A6, which is extremely rare) or when I'm storing an array (e.g. the pathfinding algorithm in Star Chaser). Otherwise RAM is pretty much touched just to store permanent state meant to stay around across subroutines (and often across frames).

Also I'm not surprised European developers were proficient at it, they had the Amiga after all =P

And yeah, arcades are probably the worst example of optimization - why optimize when you can just throw more money at it? Code was usually extremely inefficient (once they got beyond what they had in the early '80s). Also reminds me of how Sega used three 68000s in their arcades, but two of them went wasting doing a single task that barely took up any time - all of the processing really was in the first 68000. I can't help but think the only reason they added those 68000s is to make the hardware more expensive to clone.

[psycopathicteen]

I did post a slowdown reduced patch for SGnG in another thread.

[OneCrudeDude]

And yeah, arcades are probably the worst example of optimization - why optimize when you can just throw more money at it?

Same could be said for gaming PCs today. In the 90's and the early part of the 2000's, PC tech was expensive and advanced VERY quickly, so developers had to target specific hardware and hope to get it done before the hardware was too old. Today, companies such as Bethesda can churn out the most sloppy game ever, but people will still buy and play these games because fans provide free patches that fix every massive issue with the game, and if that don't work, they just spend money on buying a new GPU. At least with consoles, you have a set of limitations you need to abide by, which is exponentially more strict than PC hardware, and never changes. A game developed for a console has a guarantee of working like the way it should, look at Metal Gear Rising. The PC version doesn't even need powerful hardware to run at full settings, even if they recommended an i7. Then there's curious cases like Saints Row 2, where they apparently took the console code and ran it through an interpreter, essentially making it a glorified emulation. Quite sad that the proud and arrogant PC Master Race focuses their efforts into running years old console ports the way they should be played.