Thunder Force 4 = overhyped

[psycopathicteen]

Everywhere I see a review of this game it always says there are:

"hundreds of enemies onscreen"
"no slowdown"
"super fast action"
"20 layers of parallax"

All of that is bullshit. Here are the facts:

"up to 8 enemies onscreen at max"
"lags when there are atleast 5 enemies onscreen"
"they scroll the background very fast just to distract you from the slow moving sprites."
"6 layers of parallax, 1 water, 2 mountains, and 3 clouds. There are visible line-scrolling boundries between clouds layers."

[MottZilla]

You're only about 2 decades late.

[djcouchycouch]

Everywhere I see a review of this game it always says there are:

"hundreds of enemies onscreen"
"no slowdown"
"super fast action"
"20 layers of parallax"

Reference?

[kyuusaku]

This thread = overemotional

[psycopathicteen]

Everywhere I see a review of this game it always says there are:

"hundreds of enemies onscreen"
"no slowdown"
"super fast action"
"20 layers of parallax"

Reference?

http://www.meanmachinesmag.co.uk/review ... orce-4.php

It's ass-hats like "Damo" is the reason why I hate Sega fanboys.

[Shiru]

Still nice game, isn't? Didn't play it much, though. I remember the third better.

[psycopathicteen]

Still nice game, isn't? Didn't play it much, though. I remember the third better.

It's a nice game. It's just that the SNES has tons of games with more sprites and less slowdown, than ThunderForce 4. You just have to dig a little deeper than just playing arcade ports and Capcom/Konami classics.

[tepples]

Does TF4 even beat Recca in complexity and smoothness of motion? If not, we know the reason behind this Easter egg. Nintendon't? Ha!

You're only about 2 decades late.

So is everyone else on this board. I thought being 2 decades late was the entire point of NESdev.

[Shiru]

There is another easter egg as well.

[psycopathicteen]

Does TF4 even beat Recca in complexity and smoothness of motion? If not, we know the reason behind

Not even close.

[MottZilla]

Still nice game, isn't? Didn't play it much, though. I remember the third better.

It's a nice game. It's just that the SNES has tons of games with more sprites and less slowdown, than ThunderForce 4. You just have to dig a little deeper than just playing arcade ports and Capcom/Konami classics.

Not to mention games like the Parodius one that uses SA-1 which I don't recall any slowdown in. Some people really read a bit too much into the SNES's slowish CPU or overestimate the Genesis's cpu for being "fast". Plenty of Genesis games have slowdowns. The 68000 at around 7.5mhz isn't exactly lightening fast. The 12mhz 68000 in the Sega CD starts to make the SNES cpu really look slow but then if you are counting add-ons give the SNES the SA-1 and it doesn't look so bad.

It all comes down to how the game is programmed anyway. You can certainly have slowdowns even if you are on a platform with a faster CPU if you waste time.

[psycopathicteen]

Still nice game, isn't? Didn't play it much, though. I remember the third better.

It's a nice game. It's just that the SNES has tons of games with more sprites and less slowdown, than ThunderForce 4. You just have to dig a little deeper than just playing arcade ports and Capcom/Konami classics.

Not to mention games like the Parodius one that uses SA-1 which I don't recall any slowdown in. Some people really read a bit too much into the SNES's slowish CPU or overestimate the Genesis's cpu for being "fast". Plenty of Genesis games have slowdowns. The 68000 at around 7.5mhz isn't exactly lightening fast. The 12mhz 68000 in the Sega CD starts to make the SNES cpu really look slow but then if you are counting add-ons give the SNES the SA-1 and it doesn't look so bad.

It all comes down to how the game is programmed anyway. You can certainly have slowdowns even if you are on a platform with a faster CPU if you waste time.

I like this post.

It takes less than 1% of a frame for any post-NES system for the CPU to touch every byte in the sprite attribute table atleast once, and the spacial difference a sprite moves from one frame to the next has no impact on how long it took the CPU to "touch" that sprite. Collision detection between 2 sprites doesn't take very long either. I think the cpu usually spends more time looking for objects to apply the collision detection to, than it does actually calculating collision, and even that can be illiminated by storing "bullet objects" in a seperate batch of object slots.

Speaking of objects slots, I know a little speed trick that can be done on the 65816 but not on a 6502 or 68000. I like to move the direct page to the object slot of the object to be processed. This way I can easily reach everything in the object slot, and when I have two identical objects, it tricks the CPU into thinking it's writting into the same registers when it isn't.

[Shiru]

'Less than 1%' sounds very optimistic to me. That's 512 to 640 bytes, and in case with the SNES it arranged in not very convinient way (one bit of the X is packed these bits and sizes of with three other sprites).

Rough calculation for Genesis. 7.68 MHz, 128000t per frame, memory write opcode is ~10t (varies a lot). 12800 bytes written per frame / 640 bytes of sprite list = 20 times of the sprite list size per frame, one sprite list is 5% in the best case (doing nothing but writting data, like clearing or copying the list). Is my math seriously off?

[MottZilla]

I think a fairly considerable amount of time is spend "building" the sprite list each frame, atleast depending on the game. If you have more complex sprites, just moving a character like Sub-Zero in Mortal Kombat requires perhaps a different number of total sprite cells depending on the animation frame, and even if the animation frame is the exact same from one frame to the next you have to move each cell. And you aren't going to move a sprite by only modifying the X/Y coordinates unless in some very special case.

You'll going to draw characters instead with a function that takes a position and "meta sprite" definition and draw that character where needed. Now this isn't going to take all your time, but it will take some time. Calculating collisions and going through the whole list of potential collisions could take alot of time too.

Really it all depends how you spend your time and how well you optimize and eliminate waste of cpu time. You only have so much time to draw the sprites, process all game logic including collisions and movements, uploading new vram data, etc.

Nothing is free or instant. Any action is going to take some cpu time. The SNES has little CPU time to spare since it will range between 2.68mhz and 3.58mhz on average. The Genesis doesn't exactly have time to burn either.

The whole reason this is brought up is because of non-technical understanding fanboys spouting the same old hype. All they need is that clock speed number of the CPUs to justify that the Genesis has a "much faster processor" or whatever. Nevermind the totally different design and how it all applies to programming a video game.

[psycopathicteen]

Okay, I was wrong with the 1% thing, but it does take less than 1% for a post-NES system to perform a collision detection between 2 sprites.

I counted that the 65816 takes about 30 cycles to do a rectangular box collision algorithm. There are about 60000 cycles in an SNES frame. 30/60000 = .0005 = .05%

and in case with the SNES it arranged in not very convinient way (one bit of the X is packed these bits and sizes of with three other sprites).

A little while ago I attempted to find what was causing slowdown in Gradius 3, and I found the oam clearing routine, and the way they dealt with the the hi-oam was an unefficient way. Gradius 3 shuffles back and forth between the low-oam and high-oam, one sprite at a time.

The way I manage the high-oam is when I am writing a sprite to the oam, I "AND #$01ff" the x-coordinate, and "ORA #$0200" for big sprites. Then I store the result in both the oam buffer, and a second list that is 544 bytes after the oam buffer. Then I overwrite the high-byte of the x-coordinate with the y-coordinate, and overwrite the high-byte of the y-coordinate with the attribute word. After all the game logic has been calculated, I use the table of 16-bit x-coordiates, and build the high-oam with it.