Cave arcade shmup PCBs - is slowness artifically induced?

[PC Engine Fan X!]

the above topic says it all...

PC Engine Fan X! ^_~

[cigsthecat]

the above topic says it all...

PC Engine Fan X! ^_~

Everyone stop and take a minute to remember exactly where you were when you read the first concise PCEFX post.

[Circa2113]

the above topic says it all...

PC Engine Fan X! ^_~

Everyone stop and take a minute to remember exactly where you were when you read the first concise PCEFX post.

[PROMETHEUS]

that was just now... I think.

[SFKhoa]

the above topic says it all...

PC Engine Fan X! ^_~

Everyone stop and take a minute to remember exactly where you were when you read the first concise PCEFX post.

Oh my god, you're right. This is the first ever.

[EOJ]

Slowdown is definitely at least partly programmed in some of the newer releases. The best evidence is Mushi futari 1.5 Maniac mode and Ultra mode. Maniac mode has lots of slowdown in parts, while Ultra has parts with 2x-3x as many bullets as Maniac mode, with those bullets running twice as fast, and little to no slowdown.

[PC Engine Fan X!]

Okay everybody, you guys got me on that one...yeah, sarcasm at it's finest -- only on Shmups.org..... ^_~

What happened was I was all set to start typing my message concerning "Slowness in arcade PCBs, is it artifically induced by Cave?" when I heard the doorbell ring. It turns out that it was a Kirby vacuum saleslady trying to earn a Hawaiian vacation. She looked hot as well. ^_~

Believe me, you don't want to be pressured into buying a Kirby vacuum system from traveling salespeople -- my sister was pressured into buying one and to top it off, the salesguy ended up selling her the demo model, WTF!? Fucking scumbags.....

From that previous incident, I've learned my lesson when it comes to encountering such traveling salespeople coming in the front door..... ^_~

After looking at the price list for such a Kirby vacuum system earlier today, $1,500.00 to $2,400.00 USD -- no fucking way would I pay that kind of $$$. That's just fucking bullshit..... ^_~

Anyways, back to my topic post...where was I?

Do you think that Cave does artifically induce "slowness" in their arcade shmup PCBs in certain stages to help out the shmupper (or is it just the hardware getting bogged down with so much work that the magical 60 frames-per-second framerate starts to go "downhill" from there)?

You'd think that with today's exceptional CPU processing power found in modern day arcade PCBs, that such slowdown wouldn't happen --- especially with shmup titles. ^_~

PC Engine Fan X! ^_~

[EOJ]

Only PC Engine Fan X! could drift this discussion into talk about the exorbitant prices of Kirby Vacuum cleaners. I am constantly amazed.

[PC Engine Fan X!]

Stay tuned, there's more coming your way... ^_~

For TWE,

Thanks for the heads up on how Cave does induce such slowness in their arcade shmup titles to benefit their players... ^_~

I suppose in the discussion roundtable meetings of such arcade shmup titles in current production would go something like this:

Arcade PCB Staff member #1 -- So if we artifically induce "slowness" in this portion of the stage, it should give the player the intial impression that he or she is doing a great job dodging and weaving through this bullet storm...on the other hand, if it were made so that it moves at regular speed, then it could be a deterent of player's morale -- cheap-ass death in bullet hell storm. The player should be made to think that it is he or she who made a mistake resulting in the loss of a 1up and not that of the hardware issues/framerate issues.

Arcade PCB Staff member #2 -- I totally agree with you on those issues but we still have to balance the gameplay in terms of slowly ramping up the difficulty for our maniac shmup base and still cater to the nonchalant and occasional shmup crowd customer base. We should get in contact with our beta-tester shmup players as to their helpful user-feedback suggestions & comments to see if any further improvements can be implemented to such stage currently being constructed (new ideas and gameplay mechanics explored for later possible arcade PCB revisions down the road to generate more revenue for our brand "X" arcade PCB company + arcade operators).

PC Engine Fan X! ^_~

[bpe]

Hm, I'm not sure if more bullets and no slowdown means it is artificial. There could be a relation with the type of bullet. If the bullet is circular and has a fixed movement (ie it keeps flying in some direction), that is very easy and very fast, and that's also what ultra mode bosses often do when they start spamming. All the bullets can be drawn with one call, as they all look the same anyway, and computing the new position is dead easy : new = last + move.

On the other hand, little needle-like bullets have an orientation, so every bullet must be treated separately; for drawing you need to sort them by sprite.. and if they do stuff like slowly homing in on the player, that also means a little script is running on every bullet. Both are a lot slower (... well, assuming sprite blitting on that hardware is anything similar to sending batches of polygons to gfx hardware on PC). Ok, "a lot" = relatively speaking.

Also.. sometimes the speedup is so badly timed that it'd be pretty stupid if it was intentional. Good example is Mushi1, stage 3.. Too many deaths there due to sudden speed-ups which make you crash into something due to getting there faster than you thought. If that's intentional, any decent designer would ease that out a little... I hope

[system11]

I'm calling BS on the whole 'slowdown is intentional' theory. I always have.

BS.

BS!

Now, what I'm prepared to accept is that they control the slowdown sometimes. For arguments sake, let's pretend the game can cope with drawing 1000 large bullets before dropping frames. Now let's say it's currently drawing 800, launching a 300 spread will now cause it to tick past 1000. Well, Cave drop the speed right there, and don't up it again until that pattern has completed, assuming we're now below the threshold.

That's how I'd do it - a sort of graceful slowdown rather than a totally uncontrolled mess. Not deliberate, controlled. I'm sure if they could run the games at 60fps all the time, they would.

[EOJ]

Also.. sometimes the speedup is so badly timed that it'd be pretty stupid if it was intentional. Good example is Mushi1, stage 3.. Too many deaths there due to sudden speed-ups which make you crash into something due to getting there faster than you thought. If that's intentional, any decent designer would ease that out a little... I hope

Well, you're talking about the PS2 port, right? The PCB doesn't have the 'speedups' in Stage 3 you speak of.

[EOJ]

I'm calling BS on the whole 'slowdown is intentional' theory. I always have.

BS.

BS!

Okay, then explain to me this: in Mushi Futari Maniac mode, on the Stage 2 icicles, there is a swarm of bullets emitted, with a really marked deal of slowdown. In Ultra mode, at the exact same spot, there are about 2x-3x as many bullets and they run MUCH faster. All the character sprites are the same in these spots in both modes. So what's the reason for Ultra running much faster than Maniac even though it has loads of more bullets on the screen?

[nietzschedancing]

Artificially induced or not, it's saved my arse on numerous occasions.

TWE - you've just given me an incentive to take on Ultra mode to sample this. Bring on the pain .

[SFKhoa]

Also.. sometimes the speedup is so badly timed that it'd be pretty stupid if it was intentional. Good example is Mushi1, stage 3.. Too many deaths there due to sudden speed-ups which make you crash into something due to getting there faster than you thought. If that's intentional, any decent designer would ease that out a little... I hope

Well, you're talking about the PS2 port, right? The PCB doesn't have the 'speedups' in Stage 3 you speak of.

I think he's saying how DURING the slowdown, it returns to normal speed and he ends up ramming into a bullet faster.

[GaijinPunch]

I'm calling BS on the whole 'slowdown is intentional' theory. I always have.

BS.

BS!

Whether it's intentionally induced on Cave PCBs is beside the point. There is definitely some throttling going on though. Like the PCB knows when it's not churning out as much frames as it should, it won't just jump back to 100%. It gradually goes into it. Otherwise, you'd see a strobe affect throughout most of the games. Whether this is a low-level feature of the architecture or a high level feature of the code is another story.

Now, what I'm prepared to accept is that they control the slowdown sometimes.

Yeah, I guess that's kind of what I meant, sort of. Been drinking tonight. Maybe I should read entire posts first.

EDIT: You ever played ESPGaluda II? There's some seriously weird shit going on w/ the bullet speed in that game. For that, I in fact do think slowdown is induced (beyond the obvious kakusei feature. It's much more predictable.

[MX7]

The way I see it, cave are more than capable with eradicating the slowdown in their games, but in those 'oh shit' moments, it'd be impossible to navigate out of the flack for a mortal. Thus I think they leave the slowdown in rather than try to work round it, even forcing slowdown in some cases with lots of diddy bullets that'll never go anywhere near you. Yeah.

[EOJ]

Also.. sometimes the speedup is so badly timed that it'd be pretty stupid if it was intentional. Good example is Mushi1, stage 3.. Too many deaths there due to sudden speed-ups which make you crash into something due to getting there faster than you thought. If that's intentional, any decent designer would ease that out a little... I hope

Well, you're talking about the PS2 port, right? The PCB doesn't have the 'speedups' in Stage 3 you speak of.

I think he's saying how DURING the slowdown, it returns to normal speed and he ends up ramming into a bullet faster.

Right, but that doesn't happen on the PCB, like I said. So I assume he's talking about the PS2 port (where it does happen, and it's quite annoying).

[zakk]

I'm calling BS on the whole 'slowdown is intentional' theory. I always have.

BS.

BS!

Now, what I'm prepared to accept is that they control the slowdown sometimes. For arguments sake, let's pretend the game can cope with drawing 1000 large bullets before dropping frames. Now let's say it's currently drawing 800, launching a 300 spread will now cause it to tick past 1000. Well, Cave drop the speed right there, and don't up it again until that pattern has completed, assuming we're now below the threshold.

That would be...intentional wouldn't it?

I'd think at this point they have a pretty good estimation/techinique to determine how many active bullets they can handle before the hardware becomes overwhelmed. The designers intentionally exceed the safe level; perhaps with some sort of a smoothing/controlled entry/exit algorithm in the code so it doesn't suck total ass. I doubt that the often-used 234234234 bullets spewing out the top and sides of the boss and exiting the screen without coming near the player thing is done just for looks-only.

[SFKhoa]

Right, but that doesn't happen on the PCB, like I said. So I assume he's talking about the PS2 port (where it does happen, and it's quite annoying).

I would figure that this would be the case on the PS2 version only, since I read that even the slowdown in the PS2 version wasn't emulated correctly? Correct me if I'm wrong.

[iatneH]

I doubt that the often-used 234234234 bullets spewing out the top and sides of the boss and exiting the screen without coming near the player thing is done just for looks-only.

Eliminating safe-spots a la Raiden III first boss would be my first guess..

Although I'm sure you know you can do the same thing on one of the patterns of Ketsui 4th boss...

[bay]

Artificially induced or not, it's saved my arse on numerous occasions

i definitely rely on the slowdown that is present in many of the cave games at certain moments to maneuver the hell out of a bad situation

[louisg]

Like bloodflowers said, I've always assumed they control it on modern games with some kind of smoothing formula. From glancing at the specs (which could always be misleading, but...) I'm not sure these arcade systems are really all that powerful. For instance the main CPU of the PGM is a m68k running at 20mhz. I think they know it'll slow down. Not that I'm saying it's purely an accident-- it seems like the devs take slowdown into account when they design the game and work it into the whole manic style.

[bpe]

Uh, first off I'm not talking about the PS2 as I never played that. Then again all the PCB action was more than a year ago so I may remember it worse than it was.. But still, there are probably other examples of games that people can point out and say, if this slow-down is intentional, they should have moved the go-back-to-normal point to some time a little more convenient/less retarded.

At the same I like the idea of having slowdown start by accident, but then keeping it up a little longer than necessary. This seems like the only reasonable alternative because I'm not sure how you would implement a "ease in" period. Either the hardware can get everything done at 1/60s, ie 16 milliseconds, or it can't. If it can't, and it takes 20 msecs, you can't run the game at 50FPS, because the hardware has to wait for the vblank, the vertical synchronization of the CRT beam. If you wouldn't, you would get tearing, that is, the top half of the picture would be the old frame, the bottom half the new frame, and this looks like shit. So the result is : if you've missed your chance, you have to wait the next 16 msecs out, even if you're already finished doing the math after 20-16 = 4 msecs, and you'll sit the next 12msecs out doing nothing (ie "busy waiting").

End result: it runs at either 60 FPS, 30FPS, or 15FPS. There's no ease in/out unless you allow tearing.

Also, I'm not sure they could overcome it even if they wanted to. If you have hard limits on the number of sprites supported in hardware (such as on say Nintendo DS) or you have hard limits on the number of batches you can send to the gfx (such as on PC), then you're stuck.. and at 20 Mhz, saying "screw the hardware, I just write my own sprite blitter" is not an option... Well.. maybe it is, I don't know. If PCBs run at 320 x 240 or so, that's kind of close to 386 era games.. I don't know, it just might work


Edit: what's 234234234 mean ?

[GaijinPunch]

End result: it runs at either 60 FPS, 30FPS, or 15FPS. There's no ease in/out unless you allow tearing.

Uhnmmmm.... can you explain the varying degrees of slowdown found in the aforementioned games then?

[bpe]

Seems to me that's exactly what it's doing ? It never slows down "a little bit", it promptly chops the framerate in half.

[GaijinPunch]

How many of these games have you played, and how much of them? Half is drastic, although I don't claim to know exactly to what degree the games slow down. I'd like to see some calculations on ESPGaluda II's various speeds. The end of the game it comes to a grinding hault.

But, we can make one of two assumptions based on nothing else other than playing the less-than-stellar Cave PS2 ports compared to their PCBs.

Either:
-The SH3 hardware has low-level algorithms incorporated that take care of all this for the programmer, where the PS2 definitely does not.
-It's programmed in to be somewhat smooth.

It could actually be a combination of both. Given that Cave is known to program their games w/ some low level Assembly (I believe Mihara said a Cave rep was stationed at Arika to help them w/ the DOJ & Galuda code) I wouldn't be surprised if there's some built in functionality on the board, and the programmers know how to tinker with it to their liking.

[ktownhero]

Instead of debating the issue, is there anybody around here that speaks/writes Japanese? Just email them and ask.

[PC Engine Fan X!]

Instead of debating the issue, is there anybody around here that speaks/writes Japanese? Just email them and ask.

For ktownhero,

Y'know, that's a good idea...how about it Gaijin Punch or NTSC-J?

I'm sure the shmup community would like to know more (straight up from the creator/developer) about this interesting topic of "slowndown" issues in Cave's arcade shmup PCBs.

PC Engine Fan X! ^_~

[GaijinPunch]

Y'know, that's a good idea...how about it Gaijin Punch or NTSC-J?

I doubt anybody at Cave (even Ikeda, who probably knows the HW best) would bother. Last I checked, leaking development styles wasn't too kosher.

Much better chance of getting some type of straight answer out of Mihara, who would know better than anyone here.