Decreased S-CPU Velocity: Real or Imagined?

[Drew Sebastino]

You missed something:

3.54MHz do not a fast system make

Dat Gramar. Anyway, I'm pretty sure it's 3.58. I know I'm nitpicking, but come on. It's as easy as typing "SNES" on google and looking at the Wikipedia page.

Same for BTU, if is the cpu which limit to 3/4 sprites on screen, why capcom don't put a faster processor for FF 2/3 like he did with MMX series ???
Simply because is the pixels sprite limit / scanline the real limiting factor,and a faster CPU cannot change this fact .

Again, I can't stress enough how video hardware is generally more important to a video game system than processing power. I do think they could have at least added another enemy though and just said "oh well!" when the "cheese grader effect" (that's what I like to call it anyway. Yeah, I know I'm wierd) kicks in.

[TOUKO]

In the post above I was referring to the sonicretro guy stating "maybe slow Sonic's max speed to 5 pixels per frame so that it doesn't look excessively fast" making no sense, because lowering the pixels-per-frame movement speed of Sonic's character wouldn't speed up the CPU at all, it would just make it look like the game is lagging, even when it is running at 60fps.

Yes, moving a sprite with 5 pixels or 50 is the same in term of CPU cycles, and sprites moving/repositioning is not cpu intensive at all .

Again, I can't stress enough how video hardware is generally more important to a video game system than processing power.

Yes more powerfull hardware you have less processing power is needed .
But it's better to have the two if possible, because with cpu power you can do more
But the snes ppu is not good for me in the sprite department,too convoluted and bad designed, and force coders to spend a big amount of CPU cycles to deal with .

[Drew Sebastino]

But the snes ppu is not good for me in the sprite department,too convoluted and bad designed, and force coders to spend a big amount of CPU cycles to deal with .

I don't think the high oam thing is too bad, but the 1/4 of vram thing is certainty an issue. Not being able to use 8x8, 16x16, and 32x32 sprites is a major annoyance though. (I could care less about 64x64, considering there isn't nearly enough vram for sprites or overdraw to justify its existence.)

Just thinking, wouldn't Sonic (or any sprite really) moving at 5fps actually take more processing power? Then you would have to deal with sub pixel velocity.

[Stef]

psycopathicteen> Sorry you took it as a critic... actually i was mainly speaking about the fact you were using only 1 type of enemy, with simplistic IA, explosion animation physic and so on. I'm just chocked people really compare your demo to GH... Maybe your dynamic sprite allocation system is complex enough but still, try to fit it in a real game with all the game logic and others calculations aside to see if it still works...
Honestly GH is one of the most impressive game on Sega Megadrive, do you really believe you can replicate it accurately on the SNES which does have a weaker CPU and a dumb PPU design ? If you really believe that, sorry guys but your are really naive or just fanboy blind.

And speaking about the 65816 vs 68000, i never compared them on their clock, you definitely can't compare different CPU architecture on clock... The MD 68000 runs at 7.7 Mhz compared to the 2.68 (or ~3.1 Mhz with Fast ROM) 65816 but if we compare the BUS speed then the 68000 only runs at 1.92 Mhz. If you want to compare these CPU on cycles then do it on BUS cycles, it's more fair And it's why i really think the 65xx architecture is just bad: it requires very fast memory to work with and their efficiency definitely sucks. The 65816 uses faster memory than the MD 68000 and does far less with it (of course the 8 bits data BUS does not help but that is a tribute for the 65xx inspired design).

If you really want to compare 65816 versus 68000, don't adapt your 65816 code in 68000 code, of course you won't use the same algorithm on the 68000 which has plenty of registers and a 16/32 bits architecture. At least you try to optimize your code to take benefit of the 16 bits data bus, here (in Sik's code) we can see we have 2 bytes accesses, that is already a good indication that original code has not be designed for the 68000, of course sometime you don't have the choice but almost time there is way to adapt for 16 bits accesses.

[Drew Sebastino]

psycopathicteen> Sorry you took it as a critic...

What else is he supposed to take it as?

actually i was mainly speaking about the fact you were using only 1 type of enemy,

That's about all there is in the game.

with simplistic IA,

That's about how it looks in the game.

try to fit it in a real game with all the game logic and others calculations aside to see if it still works...

What other game logic is left exactly? Maybe a second player and other weapons, but not much else. I'm not saying that that's it, but
the CPU intensive stuff is for the most part done with. Adding more levels doesn't cause slowdown, it just takes up more memory. I guess you could be talking about the bosses or the stage set pieces (like the mine cart things), but those don't look like they'd be very processor intensive.

Honestly GH is one of the most impressive game on Sega Megadrive,

I'm sure the Megadrive can do better. If you're going to pick a game to have a fetish for, pick a better game.

weaker CPU

I thought we'd gone over this...

a dumb PPU design ?

I know, the SNES only having 64 colors was a really stupid design choice. The Megadrive is way better because it has 256 colors.

If you really believe that, sorry guys but your are really naive or just fanboy blind.

I'm really not sure what to say...

And speaking about the 65816 vs 68000, i never compared them on their clock, you definitely can't compare different CPU architecture on clock... The MD 68000 runs at 7.7 Mhz compared to the 2.68 (or ~3.1 Mhz with Fast ROM) 65816 but if we compare the BUS speed then the 68000 only runs at 1.92 Mhz. If you want to compare these CPU on cycles then do it on BUS cycles, it's more fair

I like how you made the MD go up .1 megahertz and the SNES go down .4 megahertz.

65xx architecture is just bad: it requires very fast memory to work with and their efficiency definitely sucks

It takes about twice the amount of cycles to do the same thing on the 68000 as the 65816, and we're talking about efficiency...

If you really want to compare 65816 versus 68000, don't adapt your 65816 code in 68000 code

You're right. He should try to adapt the code from the 68000 to the 65816 instead.

[Khaz]

psycopathicteen> Sorry you took it as a critic... actually i was mainly speaking about the fact you were using only 1 type of enemy, with simplistic IA, explosion animation physic and so on. I'm just chocked people really compare your demo to GH... Maybe your dynamic sprite allocation system is complex enough but still, try to fit it in a real game with all the game logic and others calculations aside to see if it still works...
Honestly GH is one of the most impressive game on Sega Megadrive, do you really believe you can replicate it accurately on the SNES which does have a weaker CPU and a dumb PPU design ? If you really believe that, sorry guys but your are really naive or just fanboy blind.

I don't have any idea what you're basing your assumptions on. You can argue all you want about the advantages of each processor but at the end of the day I'm still not seeing any reason that it can't be done. You haven't done any math here, you're basically saying "because it's inferior in these few respects it can't POSSIBLY run this game" which is ridiculous. Do you really think that GH is so painstakingly optimized and pushing the limits of the system so extremely that a very-nearly-equivalent system couldn't possibly do the same thing, no matter how you made use of its advantages? That is a HUGE assumption. You have absolutely nothing to back it up.

The only way you're going to prove your point is if you or somebody else actually does try to port GH to SNES. And if they fail that only proves that THEY couldn't do it - not that it can't be done. This conversation is frankly ridiculous.

[Drew Sebastino]

Thank you Khaz. I'm 99% sure the reason psychopathicteen quit the GH port was because he got sick of it and didn't feel like finishing it, not because it wasn't possible.

[93143]

Oh, it's on now!

Espozo and Stef: let's see if we can't not get the thread locked this time (ie: have something approximating a rational discussion) - it's a useful thread and it'd be a shame if this digression sank it...

And speaking about the 65816 vs 68000, i never compared them on their clock, you definitely can't compare different CPU architecture on clock... The MD 68000 runs at 7.7 Mhz compared to the 2.68 (or ~3.1 Mhz with Fast ROM) 65816 but if we compare the BUS speed then the 68000 only runs at 1.92 Mhz. If you want to compare these CPU on cycles then do it on BUS cycles, it's more fair And it's why i really think the 65xx architecture is just bad: it requires very fast memory to work with and their efficiency definitely sucks. The 65816 uses faster memory than the MD 68000 and does far less with it (of course the 8 bits data BUS does not help but that is a tribute for the 65xx inspired design).

We actually have clock data and instruction cycle counts for both SNES and MD, and it is possible to write equivalent code and compare wall clock time (obviously, the larger and more functionally complete the code sample the better). Complaining about 65x being a bus hog and requiring faster memory doesn't come to the point; the consoles are what they are, and have been for a quarter of a century.

On the topic of FastROM, notice how psycopathicteen's original example snippet only has a single slow-access cycle out of 21 cycles? Not all code is that insular, but to get near 3.1 MHz average speed you'd have to be doing non-indexed 16-bit direct page WRAM accesses pretty much exclusively; most instructions have a lower RAM access fraction than that. (If you're really desperate, I think you can set direct page to $4300 and use the DMA registers as fast RAM; as long as $420B and $420C are zeroed, nothing too horrifying should happen...)

[Drew Sebastino]

Espozo and Stef: let's see if we can't not get the thread locked this time (ie: have something approximating a rational discussion)

Aww... That's no fun!

[tepples]

I'm not saying that that's it, but the CPU intensive stuff is for the most part done with. Adding more levels doesn't cause slowdown, it just takes up more memory.

Compression costs CPU time. I remember reading an interview stating that Gunstar Heroes would be over 2 MB if uncompressed. The same interview states that complex jointed bosses also cost CPU time, and I'm guessing that the 68000's multiply instructions help with that.

And speaking about the 65816 vs 68000, i never compared them on their clock, you definitely can't compare different CPU architecture on clock... The MD 68000 runs at 7.7 Mhz compared to the 2.68 (or ~3.1 Mhz with Fast ROM) 65816

I like how you made the MD go up .1 megahertz and the SNES go down .4 megahertz.

I'm assuming the extra .4 MHz came out of two things: slow RAM and RAM refresh.

I'm 99% sure the reason psychopathicteen quit the GH port was because he got sick of it

The other 1% being a cease and desist letter?

to get near 3.1 MHz average speed you'd have to be doing non-indexed 16-bit direct page WRAM accesses pretty much exclusively

How many cycles does STA [$69],Y take?

[psycopathicteen]

psycopathicteen> Sorry you took it as a critic...

What else is he supposed to take it as?

actually i was mainly speaking about the fact you were using only 1 type of enemy,

That's about all there is in the game.

with simplistic IA,

That's about how it looks in the game.

Here's how I always thought the AI in Gunstar Heroes work.

Roll the dice. If it lands on X, perform action Y. Roll the dice again to determine how long before the enemy performs a another move. Repeat.

[93143]

How many cycles does STA [$69],Y take?

Two or three ROM/internal, four or five RAM. How often do you actually use direct indirect indexed long stores? Or any indirect indexed instructions?

(I've only ever programmed test codes and mockups, and I don't hack ROMs, so I don't have a good idea of what game logic actually looks like...)

...

@psycopathicteen: If you load an indexed sprite sheet into the GIMP, copy it to a new RGB file, rescale it with high-quality interpolation, and copy-paste it back into the original indexed image (delete the original first if there's any transparency involved) so as to force it back to the original palette, there should be a fairly minimal amount of work involved in touching up the resulting rescaled sprites. Just be sure to delete any graphics that don't share the palette and re-index so you know you won't get misplaced colours. This gives much better results than simple nearest-neighbour rescaling.

Proof of concept attached:

super_tie_fighter.gif (11.24 KiB) Viewed 1742 times

The other 1% being a cease and desist letter?

...wait, did he actually get one?

[Sik]

Oh wow, there's bullshit from both ends here. First the "let's limit Sonic's speed to 5 pixels per frame" on one side, then the other side taking it to mean "make the game run at 5FPS". WTF?

Also I want somebody to try the table look-up method on the 65816 to see how it performs there.

[tepples]

The other 1% being a cease and desist letter?

...wait, did he actually get one?

If so, I'm not aware. It was a guess. But I wouldn't put it beyond a lot of major video game publishers nowadays, especially with the growing willingness of courts to enforce exclusive rights in "look and feel".

[Drew Sebastino]

Oh wow, there's bullshit from both ends here. First the "let's limit Sonic's speed to 5 pixels per frame" on one side, then the other side taking it to mean "make the game run at 5FPS". WTF?

I know the original quote was unknowledgeable, but what happens when you still can't get all the processing done at 30fps? I sincerely doubt that you could even make the SNES run at 5fps, and there's absolutely no question that the SNES version wouldn't run as slow as 5fps even if it could. (I know it would pain him dearly, but even Stef could admit that.)