Number of instructions executed, number of instructions in the code, and cycle times are all different variables. You can easily have fewer instructions that take more cycles, which is what I'm sure you were trying to demonstrate.Snake wrote:Well, my reply was in response to you saying that "4 times as many instructions executed" needed backup. I could have used a loop in my example, but I didn't, because although it would have looked shorter on paper, it would have been more instructions executed. I also pointed out that the 65816 version might be smaller cycle-count wise. Sorry, I thought that was pretty clear.
For reference on the cycles per instruction matter: Genesis games tend to achieve about 700,000 instructions per second and PC-Engine games about 1.5-1.8 million instructions per second (as I said earlier, PC-Engine is clocked slightly below Genesis). These numbers were obtained by profiling several games; I profiled PC-Engine and Lordus profiled Genesis. The numbers are a little biased given that they're sucking in the idle loops as well (done w/o any kind of idle loop detection/elimination of course) so they have a bit of a BogoMIPS quality to them, but they do include games that are genuinely pushing the CPUs pretty hard on both platforms.
PC-Engine isn't SNES and 65c816 isn't 6280, but the cycle timings should at least be in the same ballpark - 6280 has additional penalties for its memory translation, 65c816 will have 16bit instructions that cost more going over its 8bit bus.
I'm in no way trying to argue that 68k instructions aren't much more efficient than 65c816 ones, I just think that 4x is an exaggeration, I'd expect something closer to 2-3x for well optimized games written with the architecture in mind. But I'm not going to stand by that number because it's so difficult to actually verify. This is for instructions executed and not written, it's obviously worse for written because 65xx demands more inlining and unrolling, and has far less in the way of "macro instructions" that 68k does.
What kind of game are you talking about here? If there's a need to store the coordinates for anywhere on the level it means that you have to be able to traverse the level at any given point. If the game is automatically scrolling like a shooter then you don't have this requirement. You also don't have it if the enemies have a limited active/spawn range like many games do (Mega Man games for instance). For a sidescroller, 16 screens for a level, no, for an AREA is plenty. When you reach the edge you can stop scrolling and go to a new region (which many sidescrollers do). You'll also often only be scrolling heavily in one area, although it varies. In most games that actually let you persistently go back and forth between the entire area you aren't going to be constantly scrolling through it, in both directions no less. Of course there are going to be exceptions.Snake wrote:In a 16 bit game? Most games I've seen scroll 2 pixels per frame or faster. 1 pixel looks very slow. It takes no time at all to scroll 4096 pixels...
Just doesn't seem to be something that's necessary based on how typical games seem to be modeled.Snake wrote:No, of course I don't, do you have a reference that says they don't?
I have no doubt that some use 32bit for coordinates, the question is whether or not they really have to. I'm sure that many games do things they don't really have to do.Snake wrote:But I know that some do, and I'm sure a LOT do, because contrary to what you might think, it makes perfect sense to do so. However, that doesn't really matter. If you were to look, you'll find a significant number of SNES games use 32 bit addition *somewhere*, even if not for coordinates. I can say that with a lot of confidence. The SNES hardware multiply is insanely quick, and returns a 24 bit result. Games are definitely going to use it, and are definitely going to want to add results - and as I already mentioned, 24 bit adds are more work than 32 bit ones.
Yeah, there might be a 32bit addition somewhere, but at least I'm talking about critical code and not just needing the instructions for it at some point. Saying that games are liable to use the 24bit results of a multiplication are like saying that they often use 64bit results for 64bit adds when 32x32->64 multiplies are available - generally speaking, they don't. I mean, they do sometimes, but much less than they don't (games, that is).
I had a feeling you'd get around to using something like this - which is of course a fair argument for the strength of the 68k. However, the problem I have with it is that it's an instruction that doesn't have a constant execution time but scales with the number of shifts - the way I've generally been looking at this (or, the reason why I've been saying anything) is to ascertain an average number of instructions necessary vs an average number of cycles per instruction. When you start using instructions like this it throws off the latter.Snake wrote:It *IS* a simple add. It's not like it's hideously slow or anything, far from it, and definitely isn't something any SNES programmer would consider a 'bad approach'. It's neccessary, and it's good code. If 16 bit is good enough, you'd do 16 bit on the 68000 too, and it would be faster, and still be less instructions than the 65816 version.
I really wasn't trying to force the issue, but since you don't seem to be convinced, and this isn't a good enough example, I'll give you this one:
There, that's deliberately limited to only 16 bit, and something that will almost certainly appear in a lot of games. How many 65816 instructions is that going to take? If someone can do it in 4 or less, and without cheating by using a huge table, I'll be impressed.Code: Select all
asr.w #4,d0
Let me reiterate this a little bit. Would your argue that 68k games typically will need less than 1/4th the MIPS to execute an SNES/Genesis era game than a 65c816 game will?
I didn't realize that a high percentage of SNES/Genesis era games actually let you fire projectiles at such small angles, with many being limited to 8 directions (which don't need any fractional portion at all). Not wanting to limit your game engine is a pretty open ended argument, where exactly do you draw the line? Maybe some engines are just overengineered, but I'm sure that at least back then most of them weren't meant to be extremely versatile and reusable and I think what you're describing isn't a necessity for at least a large number of games (ignoring ones that don't require any kind of precision motion in the first place).Snake wrote:What if you wanted to fire a missile from any point on the screen to any other point on the screen? To get a missile to move from just off the left of the screen, to just off the right of the screen one scanline lower, you'd need at least 9 bit fractions. You'd definitely want more accuracy than that if you wanted these things moving at different speeds, or changing speeds.
Now you may think that that extreme example of moving just one scanline isn't going to happen often. But you still need way more than 4 bits to get any sort of accuracy here, and do you really want to limit what your game engine can do just to save a few cycles? Please say no.