Hacker News Reader

Comment by fredoralive | Hacker News Reader

Erm. No, like lots of games during the era quite a lot of stuff is tied to the frame rate, so the 50Hz region game just runs slower than the 60Hz one as next to nobody bothers to adjust for it. The clock for the hidden weapon does run at the same rate for both unfortunately, hence it being harder to get in 50Hz regions.

View on HN

Incorrect. I’m looking at the source code. It’s not perfect but it’s not just “slowed down to 50hz” like people claim.

When you say looking at the source code, what do you mean here?

AFAIK the source for FF9 PSX (and all the PSX ff games) has been lost as Square just used short term archives

Also, FF9 does not run at a constant framerate. Like all the PSX FF games it runs at various rates, sometimes multiple at a time (example: model animations are 15fps vs 30 for the UI)

In terms of timers, the bios does grant you access to root timers, but these are largely modulated by a hardware oscillator

(Incidentally, the hardware timing component is the reason a chipped PAL console cannot produce good NTSC video. Only a Yaroze can support full multiregion play)

It’s definitely not lost…

What code are you looking at?

FFIX for PSX would have been written in C (or possibly C++) with PSY-Q. It will not be one program - those games were composed of multiple overlays that are banked in / out over the PlayStation's limited memory.

From what I know the PC release was a port to a new framework, which supports the same script engines, but otherwise is fresh code. This is how it can support mobile, widescreen, Steam achievements etc.

FF VII-IX were reimplemented under a custom engine.

Except I’m looking at the original source, not the remake, the crappy C/C++ Square engine. Not C# unity code.

There are a number of timers and things used. But the claim that it runs slower is absolutely false. It’s just perceived that way because it’s “drawn” slower.

Firstly, could you elaborate what code you're looking at? Square have never shared the source code for these titles and were not even practicing real version control at this time (see: Eidos FF7/8 debacle)

Secondly, it absolutely will run slower. Animations will take longer to complete; FMVs will play at a different rate ; controller sampling will be reduced.

My scepticism isn't coming from hearsay or ignorance: I have written PlayStation software, and PSX software is not parallelised, even though it can support threading and cooperative concurrency. The control flow of the title is very locked into the VSync loop, from your first ResetGraph(0) right to your final DrawOTable(*p).

In addition, I have done a bunch of reversing work on the other two PSX games, and they are not monolithic programs. They can't be because there simply isn't enough RAM to store the .TEXT of the entire thing at once. So when you say "the source code", I'm inclined to ask - for which module? The kernel or one of the overlays?

Good for you. When I say the source, I mean all modules, the kernel, the graphics, everything. Cheers. While we didn’t use version control the way we do today, we still had it… some of us also made copies.

It’s not lost except to maybe Square Enix’s corporate but they don’t know where anything is.

Wouldn't a slower tick make it easier as you get more wall time to do the same challenge.

No? Wall time (that the challenge runs on) is unchanged, game time (Vsync) is running at 83% of full speed (50Hz vs 60Hz), so if something tied to frame rate (animation, walking speed etc.) takes 1 second to do on NTSC, it'll take 1.2 seconds to do on PAL etc.

Reply on news.ycombinator.com