Cave and the slowdown

[RHE]

No, I admit my mistakes at any time. Like the lack of hardware testing for DUX. But it's completly beyond me why some people like you always try to bash my games, while I discuss about other games. That shows some odd obsession about my personality that you and some other people here have.

[lgb]

wow haha, who the fuck is it who's been going about CAVE for the past month

[RHE]

I don't know. I only remember debating them twice at this board including this thread. Once because of their releasing different editions of one game philisophy, which I like and once because of their odd design choice. And in fact it's not against CAVE, it's just that they do make games frequently, with this design choice I find odd, so it's fair to take them as a discussion base.

[lgb]

you keep saying "bad programming", so that might be it

consider that you completely downplayed a fairly major bug and failed the provide many of the original expectations of your own product; CAVE is quick to fix what they break, no fuss no muss

[Matsunaga]

Cave makes better games than you, stop wining.

I should stop winning or whining?

Nevermind the spelling. The slowdown is CONTROLLED seeing that it's exactly the same every time you play. I can play Dodonpachi on PSX without slowdown, But I can turn the wait on and I know that every time, it's going to slow down on the 2nd boss's final attack. It's not just some random crap that happens to be in their games, they know when it's going to happen, because they program it that way. I don't know what the point of your post is, other that to rip Cave for some odd reason.

[dan76]

So, I've just figured out that RHE and THE are behind Last Hope - Jesus titty fucking Christ...

[Acid King]

No it's not. And the designer doesn't control the point of the slowdown, as it's the hardware that does it.

I'd bet a thousand dollars that the designers know certain patterns are going to choke the hardware and induce slowdown. They're designing the games around the way the hardware responds to the bullet patterns. I'd bet that they even clean up sections of slowdown where the game speeds up or slows down too fast. Some of their patterns aren't even possible without the slowdown (I'm looking at you, Mushi TLB). This is the most inane argument I have seen on this board in a long time. It's like you're arguing that because they design the games and patterns around the hardware, their use of slowdown isn't purposeful when, in all likelihood, they know how the hardware is going to respond when they design certain patterns.

[Pringer]

No it's not. And the designer doesn't control the point of the slowdown, as it's the hardware that does it.

I'd bet a thousand dollars that the designers know certain patterns are going to choke the hardware and induce slowdown. They're designing the games around the way the hardware responds to the bullet patterns. I'd bet that they even clean up sections of slowdown where the game speeds up or slows down too fast. Some of their patterns aren't even possible without the slowdown (I'm looking at you, Mushi TLB). This is the most inane argument I have seen on this board in a long time. It's like you're arguing that because they design the games and patterns around the hardware, their use of slowdown isn't purposeful when, in all likelihood, they know how the hardware is going to respond when they design certain patterns.

Another way of saying this: The designers finish the alpha and run through their early design of the game. It quickly becomes obvious that in any screen with more than say...657 bullets, if the player is firing the game slows down. Now the designers tweak the game to feature this key number in whatever sections of the game they feel the slowdown would benefit the game. If they also happen to find out that 1278 bullets with the player firing from the bottom 10% of the screen cause the game to crash or slow to an undesirable chug, well they'll likely avoid that number.

Which I might point out is exactly the same as tuning a car, or really optimizing any system. Pretty standard practice.

[Ex-Cyber]

Well, as the ESPRADE PCB isn't supposed to be overclocked I don't really see your point.

The point is that it's not deciding to skip updating a frame and wait for the next vsync, which is the most straightforward way to implement consistent artificial slowdown. That is, you'd have a bit of code that looks something like:

Code: Select all

if ((bullets > slowdown_bullets) && (waitframe == 1)) {
	waitframe = 0;
	waitvsync();
}
else
	waitframe = 1;

/* rest of game update loop goes here */

With an overclocked CPU, the call to waitvsync() would waste more CPU cycles instead of waiting for a shorter amount of time, so the slowdown would be the same. This isn't the only way to deliberately introduce slowdown, but I can't think of a decent way to get detailed control without something like it. None of this eliminates the possibility that they just stuck in a delay loop and played with the period until it "felt right", sort of like those slowdown TSRs for running old DOS games. I think it's more likely that they just adjusted enemy/bullet patterns until they had suitable slowdowns, at least on the older hardware.

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.

I don't understand...

The Type X family is a series of "arcade boards" that are basically just industrial-style PCs running Windows XP Embedded.

[Taylor]

Where exactly is the proof that it was intended? Looks like I missed it.

Entire games built around the slowdown like Mushihime-sama.
The slowdown not being jumpy during patterns because they purposely overload the screen when they expect slowdown.

For me its cleary not intentionally, because on a different hardware with more power they couldn't get the same effect at the same point for the same game.

Cave make their games for one piece of hardware, as you acknowledge later in this post.
Some get ports that (try to) emulate the slowdown.

Its just that in fits the gameplay pretty well by conicidence or rather by logical consequence.

It's the latter. To suggest the designers are not accounting for slow-down and it's all a happy accident is insulting. There are limits to hating a company, surely?

[RHE]

Nobody here says these slowdowns are complete random crap that only happens by a stupid accident. I'm only trying to point out the difference between making slowdowns 100% artifical and controlable because you believe they must be there, and exactly there, and using limitations to leave a small part of the gameplay experience to the oddities of the hardware. It's just not possible to have perfect control over it, the way they do it. They only can workaround it. And a developer that makes games for high level players should know this. Just like I should know that its important to make a lof of hardware testing and allow custom controls, because it's important for a flawless gaming experience. And people telling me this many time. So I find it valid discussing the oddities about other developers.

I just find this an interesting topic to discuss about though.

The way some people here defend these slowdowns looks like CAVE has a slowdown department at their building, that decied what hardware to take and what not, depending on the level of slowdown.

[lgb]

I think actually see where you're going with this, but it's explained anyway

again they don't really work around it so much as they simply create their games for it; they aren't trying to get around the bar, they're trying to make sure each game gets past the bar by default. they picked that hardware and its contents out in the first place, so of course any games they make on it are made with their concepts in mind

what you're saying applies more to if CAVE were making its games on other hardware... such as the xbox. this discussion is perfect for that field, though I feel it would get much bigger than mere slowdown (and it would be more fantastic for it)

[marcoid]

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.

This.

[THE]

Kind of irrelevant though, the discussion was not about why the slowdown occurs but whether or not it was intended from a design POV, with THE citing the fact they have smooth transitions as evidence it was not. We have established that, yes, obviously it is intended.

I have to admit that having just smooth translation is not evidence enough. In case of 100% intentional slowdown you could just turn of the slowdown on the original PCB by disabling the slowdown code and every port to a more powerful system still has perfect and identical slowdown to the original independent of perfect emulation of the original CPU.

So where in the CAVE games do they specify that you are supposed to run the game on modified hardware, or different hardware than they ship the game with? They USE the way the hardware throttles the speed of the game (the music doesn't struggle when the games slow down, as this is in no way a desired effect) by programming it that way.

Wrong, you clearly never programmed for an arcade system based on the 68k/z80 combo
or any other multi CPU architecture. Early Cave games seem to have only one CPU but the music is most likely played due to a timer interrupt.
Both concepts can play music without getting distracted much or at all from overload of the main CPUs.

The slowdown is CONTROLLED seeing that it's exactly the same every time you play. I can play Dodonpachi on PSX without slowdown, But I can turn the wait on and I know that every time, it's going to slow down on the 2nd boss's final attack. It's not just some random crap that happens to be in their games, they know when it's going to happen, because they program it that way.

Wrong, the port has just a nearly cycle perfect emulation of the 68k CPU. Such libraries are available for sale and it looks like it was used for the PSX version of their ports. So it just exactly emulates the uncontrolled slowdown of the original PCB.

The Type X family is a series of "arcade boards" that are basically just industrial-style PCs running Windows XP Embedded.

I know, that's why I didn't understand his posting. The Type-X is not an arcade board, it's just a more or less standard PC equipped with a JVS interface, a USB dongle and an easy to swap HDD.
On such a system the developer will never have 100% control of the game it always depend on the OS, just imagine the OS decides to defrag the HDD or swap out some memory to the HDD while your are fighting against the TLB (those are just examples, in reality Taito will have disabled such things, at least I hope...). Anyway if you want 100% control you will need to program your own OS/Firmware like it's done on "real" arcade boards.


It seems I'm the only one here who has the technical background to fully understand the technical sides of this discussion . So it's useless to continue it...

[emphatic]

It seems I'm the only one here who has the technical background to fully understand the technical sides of this discussion . So it's useless to continue it...

^^ Well if YOU say so than it must be true, as you're never, ever wrong.

[THE]

It seems I'm the only one here who has the technical background to fully understand the technical sides of this discussion . So it's useless to continue it...

^^ Well if YOU say so than it must be true, as you're never, ever wrong.

You must confuse me with RHE, my narcissism is quite under control and I really like Cave games (before ds2). Anyway this discussion seems quite futile to me.

[Jockel]

It seems I'm the only one here who has the technical background to fully understand the technical sides of this discussion . So it's useless to continue it...

^^ Well if YOU say so than it must be true, as you're never, ever wrong.

You must confuse me with RHE, my narcissism is quite under control and I really like Cave games (before ds2). Anyway this discussion seems quite futile to me.

Were you just insulting your brother?

[Zeether]

OH SHIT SON

[E. Randy Dupre]

No, I admit my mistakes at any time. Like the lack of hardware testing for DUX. But it's completly beyond me why some people like you always try to bash my games, while I discuss about other games. That shows some odd obsession about my personality that you and some other people here have.

Actually, I'm just bashing you and your attitude. I've not said shit about your games.

[Matsunaga]

What a stupid and pointless thread. Who started this load of shit? And no, I'm not wrong.

[RHE]

No, I admit my mistakes at any time. Like the lack of hardware testing for DUX. But it's completly beyond me why some people like you always try to bash my games, while I discuss about other games. That shows some odd obsession about my personality that you and some other people here have.

Actually, I'm just bashing you and your attitude. I've not said shit about your games.

And I'm critizing the attitude of most poeple here, including yours. Take a lot a Matsunaga, he's just not able to admits he's wrong like all the people here in this thread. That's why I call arrogance. I mean probaly he isn't wrong but as long the doesnt give any arguments, I surely don't believe him. From the facts here at this thread he must be wrong or missing the point. Furthermore calling a thread pointless but still trying to argue at it, and then telling it pointless again by failing with his arguments doesn't make him shine either.

In fact most people here don't care about the technical side anyway, they just want to defend there favourite games. Probably you have to be arrogant I know it all better nerd to play shmups these days.

[nikkos010]

The question is if the slowdown is intentional.

1. The very existence of slowdown proves it's intent. These games are programmed, tested, and tweaked, and tested. If CAVE did not want the player to experience slowdown, They wouldn't have programmed the game to stress the hardware Any attempt to refute this becomes an attack on the programmers themselves.

2. Just because they didn't use your preferred method, doesn't mean that it's unintentional. This argument is based squarely on your ego. If you want to go argue coding practices, go find the programmers.

3. The fact that you can overclock the processor and no longer experience the slowdown is a non-issue. The game was programmed for a specific system, not an underclocked system, not an overclocked system. Pointing to this to prove your assertion of unintentional slowdown is misleading at best.

I am not a CAVE nut-hugger. I love Progear and DDP. (And I'd likely love Ketsui, if I ever get a chance to play it) I don't like their other shooters, mostly for aesthetics. If you want to debate the merits of individual games, feel free.

[MathU]

Cave fanboys strike again.
In before the lock.

[Matsunaga]

Myself and many others here have made good points, but your miniscule intellect refuses to acknowledge them. Give it up.

[Casey120]

Good thread started by THE turned into a cluster fuck by Cave fanboys missing the point totally and RHE pouring gasoline on the fire !


Very Nice !

[ncp]

Well more like Cave fanboys not noticing that RHE tried to change the argument from "intentional" to "100% artificial". THE tried to say it is not intentional which is wrong and dumb, and then RHE either realized how stupid that was, or didn't even read the post to begin with, and changed to "100% artificial" which it is obviously not as proved by robivy's esprade experiment. And then RHE and the Cave defense force went back and forth for 3 pages saying the same thing over and over.

[jonny5]

this thread was actually split off from teh yagawa thread.....THE took it offtopic and spawned this cluster fuck

i think this thread just proves that you shouldnt question the work of god's....you just worship it and bask in its glory

[toaplan_shmupfan]

These games are programmed, tested, and tweaked, and tested. If CAVE did not want the player to experience slowdown, They wouldn't have programmed the game to stress the hardware Any attempt to refute this becomes an attack on the programmers themselves.

Okay, first of all calling out a possible gameplay issue is NOT an attack on the programmers themselves. Second, just because a game is programmed, tested, etc. does not mean everything is intentional.

Ever do any QA testing? Doesn't have to be game QA, could be for any software or firmware application. There are several possibilities as to why an issue exists in a current release and it doesn't always mean it's a bug, nor does it always mean it's always intended to be there. Consider the following:

Scenario #1: QA writes up an issue, project manager determines this is sufficient severity to fix and so approves the issue for fixing, development fixes the issue, QA regresses the issue and confirms it is fixed, the issue is closed. (User should not see that issue in the current release, whenever it is released.)

Scenario #2: QA writes up an issue, project manager determines to be low enough severity (for example, corner or edge case scenario, or it has a workaround) not to fix, issue is determined as something like will not be fixed or deferred to a future release, issue still exists in the current release. That means the release has a known issue, it is not intentionally there, it just wasn't determined to be high enough visibility or severity to fix.

Scenario #3: QA writes up an issue, project manager determines that it is a side effect to the design and therefore not an issue to be fixed. That means then issue exists to the user in the current release but to the development team, it is not an actual bug but rather only an issue related to the design (and so if the design does not change, the design issue will not be resolved.)

Note that scenario #2 and #3 differ because of the differences in what constitutes an bug vs. a design issue. (That said, to the user, a design issue could still seem like a bug.)

Now, considering just those three scenarios among any others that are possible--you be the judge as to whether each occurrence of slowdown is intentional (i.e, directly programmed in), a possible design issue (i.e., known limitation of the hardware), or an actual bug (i.e., due to behavior not predicted by any programming or playtesting).

[Elixir]

Scenario #5: There's actually tiny little elves inside the ROMs who deliberately slow the game down to a grinding halt when there's a million things on screen.

[ncp]

Scenario #4: There is no Scenario #4.