Jump to content
IGNORED

Honest Opinion - Elektronite Old School


sramirez2008

Recommended Posts

 

Just for people reading this thread......most people enjoy the game, but if you are going to play the game on PAL, it is probably too fast. If we update the game, we will deal with that issue.

 

Interesting, why does this happen? I thought games are typically slower on PAL, because their pace is locked to the video refresh rate, which is lower on PAL than NTSC.

  • Like 1
Link to comment
Share on other sites

 

Interesting, why does this happen? I thought games are typically slower on PAL, because their pace is locked to the video refresh rate, which is lower on PAL than NTSC.

It all depends on how the game's coded. The CPU clock on PAL systems is actually faster than the NTSC system, while the VBLANK on PAL is 50 Hz instead of 60. As a result, if your game logic is running "full speed" you will execute more game logic in a given amount of "wall clock" time. If all the code for updating MOBs, etc. runs at the video refresh rate, then it'll run slow. But if the game logic is running all the time, and just gets "sampled" at the refresh rate, it'll run too fast. Does that make sense?

 

Surely someone with far better Intellivision programming chops will pipe up and give a more detailed explanation.

  • Like 2
Link to comment
Share on other sites

It all depends on how the game's coded. The CPU clock on PAL systems is actually faster than the NTSC system, while the VBLANK on PAL is 50 Hz instead of 60. As a result, if your game logic is running "full speed" you will execute more game logic in a given amount of "wall clock" time. If all the code for updating MOBs, etc. runs at the video refresh rate, then it'll run slow. But if the game logic is running all the time, and just gets "sampled" at the refresh rate, it'll run too fast. Does that make sense?

 

Surely someone with far better Intellivision programming chops will pipe up and give a more detailed explanation.

 

Cool, I think you must be right. I had thought pretty much all game code in the Inty world was driven off VBLANK. I guess I must be wrong. I had thought that this was done in part because this is the way the EXEC works, but also because to do otherwise risks the screen update occurring mid way through a game loop evaluation. This would potentially lead to some strange glitches and really tough debugging. You can see a simple consequence of this in RCA Studio II games, where MOB flickering occurs because the game is running independently of the video refresh and sometimes the MOB is being moved at the point that the screen is redrawn. For example:

 

 

Obviously the hardware MOBs of the Inty would mean that this would not be a problem, but other things, perhaps similar to the way the car momentarily splits in two on Auto Racing when skidding round a sharp bend, might be more frequent.

Edited by decle
Link to comment
Share on other sites

I think I need to give this another play. I got the bare cart when it was first offered thought it was OK and then moved on. It didn't grab me with extreme detail or sound effects or something. Thanks ladies and gentlemen, you have motivated me to look agaup n. :)

Yah this one isn't about how pretty it looks or sounds it's just fun gameplay that has me hooked on it.

  • Like 2
Link to comment
Share on other sites

 

Cool, I think you must be right. I had thought pretty much all game code in the Inty world was driven off VBLANK. I guess I must be wrong.

 

Why do you think you're wrong? What intvsteve explained coincides with this notion. By the way, he is right.

 

Most games are programmed specifically for the NTSC Intellivision. This means that all timing (driven by the VBLANK "heartbeat," i.e. the television signal frame refresh rate) is calculated to run at 60 Hz, so all mechanics and logics are tested at this rate. Conversely, when played on a PAL machine, the VBLANK "heartbeat" runs slightly slower at 50 Hz, giving the CPU more time to execute instructions between screen refreshes. This gives the impression that the game is running faster, since more logic is executed within drawing frames.

 

The other part of the equation is the weird off-key sound in PAL. You see, the PSG sound chip of the Intellivision is not programmed via sound frequencies, but instead it uses counters representing the frequency at which the oscillator should vibrate in terms of the machine's main clock cycles -- or put a different way, how many machine clock cycles need to occur for an audio oscillation to trigger. For PAL, the clock rate is slowed down a bit in order to synchronize with the 50 Hz television signal.

 

If the music and sound were programmed using frequency values corresponding to a clock rate for NTSC (faster), then these will result in higher audio frequencies when applied to the PSG running at the PAL clock rate (slower).

 

The resulting effect is that the notes are slightly higher in frequency, and not exactly at the musical pitch they should be. That and the fact that the actual music score is running faster (along with the rest of the games logic), makes for a rather strange sound.

 

There are ways around this, of course, by programming a game differently. However, it takes considerable more effort. One way is to make two versions of the game, one for PAL and one for NTSC. As you can imagine, programmers who have a hard time getting one game out the door will not be very receptive at the prospect of coding or maintaining the game twice.

 

Another alternative is to run everything at 50 Hz (the common denominator between both), which entails slowing down the game timing on NTSC machines. This is usually accomplished by detecting whether the machine is in 50 Hz or 60 Hz mode, and skipping one VBLANK out of every six if the latter; essentially slowing down the execution of the game core engine down to match the former. If the music tracker is also adjusted to follow this trend, it will play music at a similar speed in both modes.

 

As for the note pitches, the only way around it is to define two different clock frequency tables corresponding to the musical note frequencies on each machine speed, and select which one the music player will use by detecting the machine mode.

 

These techniques are rather common now so they are being built into frameworks and libraries. I believe IntyBASIC supports some of it, if not all.

 

-dZ.

Edited by DZ-Jay
Link to comment
Share on other sites

DZ-Jay , what method does Carol use? It runs very smooth on NTSC, does it run that way on PAL too?

 

Nah, I was too inexperienced to program it for both NTSC and PAL. I know better now, but back then I only coded for NTSC, to the point that we never tested in PAL except on the emulator. It turned out that there was a major timing bug when played on PAL consoles and that the emulation was not accurate. Eventually both got fixed, the game and the emulator.

 

By the way, I do not want to suggest that running a game at 50 Hz to balance it between both TV standards would slow the game down perceivably. It does have to.

 

-dZ.

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...