Cave and the slowdown

[THE]

Cave yes, the blinded fan-boys not!

Great contribution to the thread.

Well I have read here many times bullshit about OMGZ the slowdown in Cave is intentional, this is not a bug it's a feature blabla...

Intentional slowdown ramps up smooth and ramps down smooth. The slowdown in their games is only in a way intentional as they didn't change the game design to overcome any slowdown to begin with.

[Taylor]

Yes, the slowdown is caused by the limits of the hardware. No, the patterns and stages were designed with these limitations in mind. It's intentional on all counts, you only need to play Mushi for 5 seconds to see this is the case.

If it was just some random side effect that happened when they printed the PCB you would find horrible sections where the frame-rate sped up and slowed randomly. And players prefer the feeling there is so much on screen the game has slowed to some triggered and hard-coded smooth transition.

[THE]

I have edited my previous post:

Intentional slowdown ramps up smooth and ramps down smooth. The slowdown in their games is only in a way intentional as they didn't change the game design to overcome any slowdown to begin with.

-

Yes I agree that slowdown is absolutely necessary in their games, I haven't said it's bad thing anyway. Without slowdown I wouldn't live long in Mushi and Esp II..

much on screen the game has slowed to some triggered and hard-coded smooth transition

Such things doesn't need to be triggered or hard-coded, the engine is always aware of the bullet count and can force a smooth ramp up/down if certain conditions are met. 100% Intentional slowdown can be perfectly timed and adjusted in speed of transitioning and slowdown factor like the designers want it to be. At least that's my definition of 100% intentional slowdown.

[ncp]

Just because they used hardware limitations to slow the game down doesn't mean it's not intentional, nor does it mean it's a bug.

[RHE]

It means they have less control over these 'intentional' slowdown for sure. However, in any case for me it's technically not a bug, it's rather a odd design choice or bad programming. I also don't think many programmers leave timing to the hardware limitations alone. Especially not with shmups, where precision and timing is very important. Another thing is, that every hardware has its own limits, which means the programmer must take the slowdown at the moments where the hardware wants it - different hardware means different point of slowdown.

And most players find slowdowns annoying, but lucky danmaku programmers.

[Taylor]

It’s a design choice but it’s not odd at all. It embodies one of the fundamental design pillars of the danmaku sub-genre; to make you look better than you actually are. It adds to the whole smoke and mirrors effect. You’re so awesome the game is slowing down trying to kill you. People like the hardware groaning into slowdown.

You do not see sections where the speed is subject to bursts through some patterns like it does in, say, the Cave-clone BWR. Because they know when these sections occur and purposely pump out extra bullets to make sure it works. They know their hardware. Mushihime-sama and its sequel use it so liberally it’s a core feature of the game. In other games, like Daioujou, it is not.

[RHE]

Must be bad programming then. And with design choice and don't mean the use of slowdowns I only mean the way they leave it too the hardware instead of programming them. To find slowdowns necessary and to like or dislike them just taste, personally I rather take less bullets at normal speed then many with slowdowns. And you can say its a feature with every game that has slowdowns, because a slowdown always makes a game easier. However, the odd thing here is the technical side.

So if slowdowns are that important for the sub-genre, and a feature as you say, then they should part of the programm even more, if you ask me.

I mean a pixel artist pixeling for a 16-bit console uses a limited color pallet to make the art shine. He's making perfect use of the limitation. Alternativly, the artist can draw a picure on true color and then converting it down to a 16-bit color pallet. The difference is to have perfect control of the feature to increase quality.

[TLB]

Must be bad programming then. And with design choice and don't mean the use of slowdowns I only mean the way they leave it too the hardware instead of programming them. To find slowdowns necessary and to like or dislike them just taste, personally I rather take less bullets at normal speed then many with slowdowns. And you can say its a feature with every game that has slowdowns, because a slowdown always makes a game easier. However, the odd thing here is the technical side.

So if slowdowns are that important for the sub-genre, and a feature as you say, then they should part of the programm even more, if you ask me.

I don't think so. I think they're done tastefully and sparingly enough not to detract from playing, but to enhance it enough to make it look even cooler.

[RHE]

And they can make a even better experience for you by programming them 100% intentionally.

[emphatic]

And they can make a even better experience for you by programming them 100% intentionally.

So you actually know EXACTLY how the CAVE hardware works? It's pretty arrogant to say something like this otherwise. Perhaps it's not possible to achieve the EXACT same slowdown through programming. Also, as the slowdowns are a bit different in DeathSmiles for 360 than it's PCB counterpart, doesn't this prove that they can't get the same effect (this could of course be due to them not being quite comfortable with programming on the 360 platform yet though).

[nikkos010]

Personally I've always liked the slowdown effect. It's got that matrix-like "bullet time" feeling where you get a chance to do something amazing. (Maybe that's where they got the term "bullet time") Maybe I'm not jaded enough, but I get a hell of a thrill when I make it though one of those massive screen-filling waves of death.

And I guess I don't understand how you can call it a "bug" as you can play the ROM unthrottled in MAME and still have the same slowdown effect. It's obviously programmed in. I think it was genius to take a hardware limitation and make it into an exciting "signature event" of the genre.

Edit: I know we're talking mostly about the newer stuff, but it's something that started in older stuff...

[zakk]

This thread is amazing. Next topic: rank and how you {hate|love| it.

[crithit5000]

This thread is amazing. Next topic: rank and how you {hate|love| it.

What the fuck do you mean, I'm supposed to kill myself? For points? To get more lives? AND I HAVE TO KILL THOSE LIVES TOO?!? What the hell kind of morals are these developers instilling in these crazy games? I'm so confused what is this I don't even

[GaijinPunch]

Intentional slowdown ramps up smooth and ramps down smooth. The slowdown in their games is only in a way intentional as they didn't change the game design to overcome any slowdown to begin with.

The fact that it's emulated perfectly in Death Smiles proves that it was intentional. If it was a side effect and not algorithmic in the leaset, not only would they likely not have bothered, they would've have gotten it right.

This thread is amazing.

As are all threads here. I especially love the use of "bad programming". Most Cave arcade games have somewhere around 80 to 100 years of programming experience for the main guys alone (~15-20 x 4 - 5).

[Dave_K.]

This thread is amazing. Next topic: rank and how you {hate|love| it.

Rank shmank. Just ignore it, if you are man enough, because max rank = max points! Seriously.

[Zeether]

Must be bad programming then. And with design choice and don't mean the use of slowdowns I only mean the way they leave it too the hardware instead of programming them. To find slowdowns necessary and to like or dislike them just taste, personally I rather take less bullets at normal speed then many with slowdowns. And you can say its a feature with every game that has slowdowns, because a slowdown always makes a game easier. However, the odd thing here is the technical side.

So if slowdowns are that important for the sub-genre, and a feature as you say, then they should part of the programm even more, if you ask me.

I mean a pixel artist pixeling for a 16-bit console uses a limited color pallet to make the art shine. He's making perfect use of the limitation. Alternativly, the artist can draw a picure on true color and then converting it down to a 16-bit color pallet. The difference is to have perfect control of the feature to increase quality.

UNDERSTAND A GAME'S CONCEPT FIRST

[adversity1]

Bad programming.

[THE]

Well, first we should get away from the term "Bug". Not 100% controlled slowdown is rather a glitch or just bad design.
Why is it bad design? Because you don't have 100% control over it. On a closed system like an arcade PCB you may have a lot more control as on crappy PC system or modern consoles with running an OS in the background. But still, just getting "random" interrupts and such alike will give you a different timing each play. This may be a lot below the ~15ms a frame takes. But still this can all be summed up to get a kinda random behavior of slowdown.

So you actually know EXACTLY how the CAVE hardware works? It's pretty arrogant to say something like this otherwise. Perhaps it's not possible to achieve the EXACT same slowdown through programming. Also, as the slowdowns are a bit different in DeathSmiles for 360 than it's PCB counterpart, doesn't this prove that they can't get the same effect (this could of course be due to them not being quite comfortable with programming on the 360 platform yet though).

Me, yes. Being a system programmer and to some extend hardware designer myself I'm able to fully understand and reverse engineer their hardware and software. At least their older stuff is quite simple (68k CPU).

It is possible to emulate the timings of every CPU nearly 100% perfect. But Mame for instance don't has accurate timings for most CPUs. Last time I checked not even for an important CPU like the m68000. Hell it took them around 10 years to find out the real frame rate of the NEO GEO... But if Cave would have the means to emulate the SH-3 CPU perfect and their custom FPGA based GPU too, you guys would get perfect timing for your ports.

And I guess I don't understand how you can call it a "bug" as you can play the ROM unthrottled in MAME and still have the same slowdown effect. It's obviously programmed in. I think it was genius to take a hardware limitation and make it into an exciting "signature event" of the genre.

AFAIR this was proofed wrong by a member here. He overclocked the m68k and got rid of the slowdown in DDP PCB or something.

The fact that it's emulated perfectly in Death Smiles proves that it was intentional. If it was a side effect and not algorithmic in the leaset, not only would they likely not have bothered, they would've have gotten it right.

Yes it's intentional, but it's not 100% controlled. Or why they needed to get IKD to program the slowdown in the port of DS for several month...if it were algorithmic they just would have needed to compile in for the xbox360 CPU and viola everything would have been perfect...

It not bad programming it's just a bad choice of handling intentional slowdown.

[toaplan_shmupfan]

Here's a really easy way to deal with slowdown: stop firing as soon as the slowdown occurs.

If the game speeds up, then it's obviously a hardware limitation issue rather than intentional slowdown, and so all of the objects on screen including player shots are likely contributing to the slowdown.

If the game stays slow in a specific section even after firing has stopped, then it can be considered an intentional slowdown section built into the game regardless of whether or not the programmers of the game pushed the hardware beyond its capabilities or if they purposedly added a game speed slowdown in that section.

[sven666]

you just dont understand!

[Taylor]

it's rather a odd design choice or bad programming

It’s a design choice but it’s not odd at all.

Must be bad programming then.

Okay.

[ncp]

you just dont understand!

well that's depending on taste...

[Udderdude]

So this is what happens when RHE ventures out of his own game threads.

Can't say I'm really surprised. :/

[THE]

Personally I've always liked the slowdown effect. It's got that matrix-like "bullet time" feeling where you get a chance to do something amazing.

The matrix-effect is something different. It's 100% controlled and has nothing to do with hardware limitation. It's archived by reducing the speed of movement and animation vectors for all objects (bullets,enemies,players...) . The frame rate of the game will still retain in e.g. 60fps.
And yes, a good programmer would do it like this on a powerful hardware like the xbox360/PC. If Cave would have chosen the sh-4 instead of sh-3 we maybe would have gotten this. Now as they switched to the evil side of the might (PC-hardware), their souls are lost anyway

[gray117]

okaaaaay ...

I think 'someone' is taking a dig at cave... and of course the deservedly outrageous percentage of people that like their formulae. Perhaps this just represents a personal taste and ethic? But I think that over stepped the mark when critising the intent of the games.

As an aside there are many games - and not even just shmups - which feature slowdown; often part compromise, sometimes for purely an aesthetic effect, sometimes marginal to play, sometimes integral to play.

It disappoints me that people try and distill this into a technical discussion... Firstly because I see little explanation of this. Secondly, because I feel it is often missing the point a bit: Competancy with hardware and the relative relationship with the hardware's capability have something to do with how a feature is implemented. But more important is the decision whether that feature is implemented.

I would be very suprised if slowdown in cave's case is not a purposeful combination of hardware, programming and game design. It happens so consistently, and in such a recognised and managed manner, that it cannot be purely just a happenstance of idly chucked together code, hardware, game and level design.

The devastating impression of even the game's hardware being broken by the brutality of the game is in itself something of an oxymoron - but does give a wonderful little aesthetic kick to someone whose brought into the reality of the game's conceits and, if managed properly, it can also take the form of an intriguing (as opposed to intrusive) gameplay element.

I can accept the idea that you could find this annoying/dirty or distracting in general (?), but especially without stating specific examples, the idea that this is an unintented fault of bad programming/design, strikes me as rather short sighted and not particularly constructive...

... would you suggest throttling/changing design - how would this be managed - tailored to gamers performance/setup in advance? In which circumstances would you think this would be of use? ... there's a range of areas where this coversation could spark some meaningful debate; at the moment it seems a bit like a bash and bait

ps. sorry for punctuation and grammer - I seem to often write more than I want...

[EPS21]

On a closed system like an arcade PCB you may have a lot more control as on crappy PC system or modern consoles with running an OS in the background.

Taito Type X and all the variants would like to have a word with you.

[Seelen]

funny, I was just wondering this yesterday. Noticed it got a little laggy and wasn't sure if it was just my ps2 port...so it's that way on the pcb too?

[RHE]

Looks like some people don' get the difference between accepting a limitation and use it as a advantage (Thats what CAVE does an its okay) and programming something 100% controlable. Hardware slowdowns are less controlable then programming them. That's my whole point. Gameplaywise every player has to decide for himself, to like or dislike slowdowns.

Or course bad programming is a bit harsh, but they can do better w/o much programming effort.

And they can make a even better experience for you by programming them 100% intentionally.

So you actually know EXACTLY how the CAVE hardware works? It's pretty arrogant to say something like this otherwise. Perhaps it's not possible to achieve the EXACT same slowdown through programming.

It must be a HUGE coincidence that the hardware produces a slowdown that's PERFECTLY suitable for EVERY game made by CAVE. Also, to assume their slowdowns are all intentional because they emulate it perfectly or they fail to emulate it perfectly is pretty naive. Maybe they just emulate to give the 100% original experience, and not because they believe it's perfect. Or they are only decent at programming so they failt at it. I don't think they'are bad at programming to make this clear.

The fact that it's emulated perfectly in Death Smiles proves that it was intentional. If it was a side effect and not algorithmic in the leaset, not only would they likely not have bothered, they would've have gotten it right.

Also, as the slowdowns are a bit different in DeathSmiles for 360 than it's PCB counterpart, doesn't this prove that they can't get the same effect (this could of course be due to them not being quite comfortable with programming on the 360 platform yet though).

Are you both speaking about the same versions of Death Smiles?

[toaplan_shmupfan]

I can accept the idea that you could find this annoying/dirty or distracting in general (?), but especially without stating specific examples, the idea that this is an unintented fault of bad programming/design, strikes me as rather short sighted and not particularly constructive...

I can easily state examples of obvious hardware stress slowdown from several older games, both console and arcade. Here's a few easy ones.

Sky Shark/Flying Shark (Toaplan): Stage 5 has a section where tanks emerge from two separate rocks at almost the same time, just shortly before the land section transitions to water. If the rocks have not been blasted open and the tanks have not already been destroyed before they start to emerge, there is very noticeable slowdown as the tanks start to emerge from the rocks even before they are actually visible. Another potential for slowdown on that same stage is the large amount of tanks after the large boss bomber has been destroyed, when the water ends and land returns just shortly before the game would loop back to stage 2.

Varth (Capcom): past stage 4 there are several places where slowdown occurs in addition to actual graphical flicker due to the hardware being stressed. This is seen in genuine Varth arcade cabinets and is not just a result of porting (Capcom Classics Collection PS2) or emulation (Ultracade).

ThunderForce IV/Lightening Force (Sega Megadrive/Genesis, Technosoft): One of the most obvious examples of hardware limitation slowdown is the Strite boss battle with Gargoyle Diver. Using Twin Shot, Blade, Free Way, or Hunter when also having Claw will easily result in slowdown of both the shot animation and the background scrolling. Stop firing, and the game speeds up to its intended speed. Start firing again, and the slowdown is once again present.

Hellfire (Sega Megadrive/Genesis port version, Toaplan): Set autofire to On. Start the game and listen to the speed of the background music. Now start firing--the music has slowed down! Stop firing, the music has resumed its original speed. The cause of the music slowing down also results in a very subtle slowdown of the graphic animation as well. (It's not very obvious when one just holds down the fire button most of the game but it's very obvious when one lets up on the fire button when not actually attacking enemies.)

So how does this translate to Cave manic games? Or any other shmup by any other manufacturer? Again, as I suggested before, stop firing. If the game speeds up when firing stops, it's a good indicator that the slowdown is due to hardware being stressed. If it doesn't speed up when firing stops, then it's a good indicator that regardless of whether it's a programmed slowdown or the programmers purposely stressed the hardware at that section of the game, that they still meant for the game to slow down in that section of the game.

[system11]

So how does this translate to Cave manic games? Or any other shmup by any other manufacturer? Again, as I suggested before, stop firing. If the game speeds up when firing stops, it's a good indicator that the slowdown is due to hardware being stressed. If it doesn't speed up when firing stops, then it's a good indicator that regardless of whether it's a programmed slowdown or the programmers purposely stressed the hardware at that section of the game, that they still meant for the game to slow down in that section of the game.

QFT