Decreased S-CPU Velocity: Real or Imagined?

[tepples]

I sincerely doubt that you could even make the SNES run at 5fps

What kind of frame rate do you get out of games like Jurassic Park or some of the Super FX games like Doom, especially in more complex scenes?

[Drew Sebastino]

I didn't think it ever went slower than 10. Anyway, the main question is how much the frame rate drops every time it doesn't finish processing, like if the frame rate always got cut in half to where it went 60, 30, 15, 7.5. I just don't have a clue how it works, and it can't be any number because (at least to my knowledge) you cant have a game run at 59fps.

[psycopathicteen]

5fps means moving once every 12 tv frames.

[lidnariq]

If it's not a fixed rate you can have non-integer divisors. e.g. 59 could be "dropped one frame every second".

[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?

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.)

Wait, what game are we talking about now? x_X Bleh, ignore that, although maybe it's a good moment to split the thread since this doesn't seem to be about dynamic VRAM slot algorithms anymore (I bet that split thread would get locked rather soon like the other one, though...).

[Drew Sebastino]

I almost don't see the point in locking topics. All that happens is that the argument gets brought elsewhere to continue. I imagine people would get tired of arguing at one point or another anyway.

[TOUKO]

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.

Yes but you have only player and boss,and multiply instruction(if used here) is slow and you'd better use LUT .
A game like super aleste is much more cpu intensive, and here too i think the problem to have a snes port of AS is sprites limit .
This game like GH are designed to use the Md sprites capabilities to maximise sprites on screen with minimum flicker in H40 .

[Stef]

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.

Oh i see, "we cannot say it is not possible to make GH on SNES as nobody tried to do it"... ok in this case maybe we could run FarCry 4 on SNES but we will never know as nobody tried it ? I admit you can always find new ways to improve / optimize your code but at the end you need to find something proper at least for real game condition exploitation. Imagine you need to use 1 MB lut and having GFX organized in very specific way with many hard coded constraints then your engine is definitely not usable in real conditions. After the optimization then you have the maths... A lot of people believe the 65816 is better because of its better IPS but the problem is that you will never be able to clock the 65816 at the same speed than a 68000 (because of the memory). Actually even 3.58 Mhz was not possible when the SNES was released, fast ROM were used quite late in the SNES lifetime... But anyway, i accept to compare with a 3.1 Mhz 65816 (which is, i believe, an optimist estimation of the CPU speed while it is running from Fast ROM) so let's do the maths.

memory fill
68000 = 1 byte each 3 cycles (classic move) and ~2.2 cycles (with movem)
65816 = 1 byte each 2 cycles (STA DirectPage with 16 bits Acc)
memory copy
68000 = 1 byte each 5 cycles (classic move) and ~4.5 cycles (with movem)
65816 = 1 byte each 7 cycles (MVN) and 5 cycles (LDA/STA Absolute sequence with 16 bits Acc)

I don't know enough the 65816 but i believe we can't do faster and i used simplest addressing mode to get fastest usable "case" but even in these particular situations we can see that for basic operation as memory fill or copy the 68000 is on par in term of cycles number... when the 68000 has many more available cycles.

Then we can find an unlimited number of examples but i am thinking about the one posted in Sega-16 by tomaitheous to show the 6502 can be fast, even for 24 bits calculation :

Code: Select all

;24bit add for X and Y. 16:8 = 16bit for whole, 8bit for fractional

    ldx #$xx              ;2
    jsr AddVelocity       ;6        


AddVelocity:    
    lda x_float,x         ;4
    clc                   ;2
    adc x_float_inc,x     ;4
    sta x_float,x         ;5
    lda x_whole.l,x       ;4
    adc x_whole_inc,x     ;4
    sta x_whole.l,x       ;5
    lda x_whole.h,x       ;4
    adc x_whole_inc.h,x   ;4
    sta x_whole.h,x       ;5 = 41
    
    lda y_float,x         ;4
    clc                   ;2
    adc y_float_inc,x     ;4
    sta y_float,x         ;5
    lda y_whole.l,x       ;4
    adc y_whole_inc,x     ;4
    sta y_whole.l,x       ;5
    lda y_whole.h,x       ;4
    adc y_whole_inc.h,x   ;4
    sta y_whole.h,x       ;5 = 41
    
    rts                   ;6
              
                          ;41+41+6+6+2 = 96 cycles

The point of the method is to handle object displacement (player ship or enemies) and that the 6502 could even be faster here than a 68000 in term of number of cycles (Steve Snake wrote a method which was above 100 cycles for the 68000). But actually reworking a bit the data structure and the code for the 68000 ended to that :

Code: Select all

.loop:
    move.l (a0)+,d0    ; 12  X_inc
    move.l (a0)+,d1    ; 12  Y_inc
    add.l  d0,(a0)+    ; 20  X += X_inc
    add.l  d1,(a0)+    ; 20  Y += Y_inc
    dbra  d7, .loop    ; 10

74 cycles.

Ok, we were comparing against the 6502 which is not fair and i'm certain we can lower the initial 96 cycles number a lot with the 65816. But then, even if you are able to get the calculation done in 40 cycles with the 65816 you are still below the 68000 performance level.
Considering 7.67 Mhz against 3.1 Mhz you need a ratio of ~2.5 to be equivalent to the 68000, so here with 74 cycles for the 68000, you had to do it in 74/2.5~30 cycles to be on par... and this time i really doubt you can make it fit in 30 cycles with the 65816.

[Khaz]

Oh i see, "we cannot say it is not possible to make GH on SNES as nobody tried to do it"... ok in this case maybe we could run FarCry 4 on SNES but we will never know as nobody tried it ?

The audacity of this guy, making such claims about what is and is not possible on the SNES when he admits that:

I don't know enough the 65816

If you don't know enough then maybe you aren't qualified to be dictating what can and cannot be done on the system, huh? For example, are you even familiar with the concept of DMA? I would think that has some bearing on your calculations. And furthermore you missed my point entirely; the point was that pointing out subtle differences where the SNES doesn't come out on top is not proving ANYthing about what games can and can't run on it. This conversation is still ridiculous.

I'm sorry for continuing to post off topic.

[Drew Sebastino]

You see! Stupid shit like this happens if you don't be aggressive and take action.

I don't know enough the 65816

I don't know enough about the 68000, but you don't see me picking fights. If you're here just to bitch about things, go somewhere else.

You know, why don't we just do a topic split right here and now for a "Useless Hate" thread.

[Stef]

If you don't know enough then maybe you aren't qualified to be dictating what can and cannot be done on the system, huh?

I have played with many CPU with different architecture in my programmer life and the first assembly i ever touched (maybe 20 years ago) was actually 6502 assembly (on a VIC20). So even if i am not currently programming with the 65816 and don't know its ISA by heart I have a perfect understanding of its architecture and a good view its capabilities.

For example, are you even familiar with the concept of DMA? I would think that has some bearing on your calculations.

Are you serious ? I just wanted to compare the CPU performance just to point out the problem with the 65xx architecture.

And furthermore you missed my point entirely; the point was that pointing out subtle differences where the SNES doesn't come out on top is not proving ANYthing about what games can and can't run on it.

Oh really ? so please tell me how can you quantify it then ? The CPU is the heart of the system... if a CPU A can't compute as much than a CPU B then necessarily you can't replicate games from system B on system A at same speed, just pure logic. Honestly i really amazed that some people still dare to compare the 65816 to the 68000, the later one is so much more advanced there is no competition. Even with a 65816 running @3.1 Mhz you barely get about half of the performance than a 7.7 Mhz 68000 which requires slower memory, that is the point. You can definitely find particular situation where the 65816 will perform well (and why not even outperform the 68000) but generally the 68000 will be the clear winner and by a large margin.

You see! Stupid shit like this happens if you don't be aggressive and take action.

I don't know enough about the 68000, but you don't see me picking fights. If you're here just to bitch about things, go somewhere else.
You know, why don't we just do a topic split right here and now for a "Useless Hate" thread.

Why do you need to be that aggressive ? I was just replying about the hilarious stuff i read in this topic and i came with arguments and numbers. Still I agree it turns out of the topic and we should split it but imo it can be an interesting discussion if people try to think and speak without their biased point of view.

[TOUKO]

So even if i am not currently programming with the 65816 and don't know its ISA by heart I have a perfect understanding of its architecture and a good view its capabilities.

No, and i said you all the time, 65816 or hu6280 are not 6502 ..
Hu6280 is more faster than vanilla a 6502, and run at 7,16mhz, the 65816 is faster than the other two at same clock .

Do you remember you claimed that 68k was 4x more faster than 65816 ??
I told you they are close for a gaming machine,and at 2,58 the 68k is still faster, but not by a lot .

[Stef]

No, and i said you all the time, 65816 or hu6280 are not 6502 ..
Hu6280 is more faster than vanilla a 6502, and run at 7,16mhz, the 65816 is faster than the other two, but run at a lower clock than 6280.

Of course the 65816 is faster than a 6502. It's why i said we can lower the number of cycles of the previous code by a large margin on the 65816 (from 96 cycles with the 6502 i guess we can at least obtain 50 cycles on the 65816).

Do you remember you claimed that 68k was 4x more faster than 65816 ??

Please, i just invite you to find where i claimed that ok ?
As usual you probably mis-interpreted my words or put them out of context I always said the 65816 in the SNES (and so clocked at ~3 Mhz with Fast ROM) is about half of the performance level than the 7.7 Mhz 68000.

I told you they are close for a gaming machine,and at 2,58 the 68k is still faster, but not by a lot .

Yeah i know that but you are just wrong @2.68 Mhz the 68000 is actually *a lot* faster.

[TOUKO]

Please, i just invite you to find where i claimed that ok ?
As usual you probably mis-interpreted my words or put them out of context I always said the 65816 in the SNES (and so clocked at ~3 Mhz with Fast ROM) is about half of the performance level than the 7.7 Mhz 68000.

No stef, i'am sure of that, but i'am not sure to find where in the "snes vs md" (ton of posts) topic

Yeah i know that but you are just wrong @2.68 Mhz the 68000 is actually *a lot* faster.

A lot ??, you're hardly optimistic
Do you claim again that bad apple in 8 MB is impossible on snes ??,i don't see the "a lot" factor here

I'm just chocked people really compare your demo to GH

Huuuum, maybe like you compare your starfox demo ??
Or axelay scroll demo with nothing around ??

[Stef]

To be honest i am really impressed by the SNES version of BadApple but even more impressed by the fact that they figured a codec fast enough to work on the 65816 and to fit the video and sound in 8 MB.
Still currently even if 90% of the demo is done the last 10% which consist of getting rid of the last slowdowns will be really tricky as the code is already quite optimized. Also there is the sound streaming issue but i believe this one is easier to sort.
The MD version of the demo uses more complex compression methods. I used about 5/6 compression schemes for the tilemap and about 7 or 8 for the tile data... honestly i think my code is definitely not optimal on that point.
For sure the native 2bpp mode of the SNES help for the compression, in the MD version i need to encode 2 2bpp frames into a single 4bpp frame and that definitely reduces the compression ratio, also i have 25% more data to unpack compared to the SNES (wider resolution).

Huuuum, maybe like you compare your starfox demo ??
Or axelay scroll demo with nothing around ??

Ok for axelay but the starfox demo is a different, what cost the most and *by far* in this case is the 3D math calculations and the 3D rendering. If you get the engine done then you can consider to make a game from it without much troubles. Any game logic will have an insignificant cost on the CPU compared to the 3D stuff.