Is such thing even exist ? European console can output 60 Hz without problem (same hardware, same cables), while some TV can't (hardly ever encountered nowadays). Hence, game developer made game output 50 images per second (thank goodness, some putted a "60 Hz" mode, while others lazy developer don't bother to put it ; after all, those europeans countries don't get well with technology, don't they ? (yes Squareenix, I'm looking at you)).
It is the job of a forum moderator to split digressions. Which is why I suggested using both seconds (for newcomers) and frames (for experts). The game Super Mario Bros. ran at 60.10 frames per second (NES native refresh rate) and used about 25 frames per tick of the game clock. Eventually, I plan to make LJ accessible to both newcomers and experts. Scheduled for the next few versions is a new user interface that supports rulesets. The general public can just download "T_tr_s for NES A-Type.ini" or "TA Death.ini" and copy it into rules.ini, and the advanced users can create those files using the new rule editor interface. It's like StepMania: some people just download simfiles, while others such as myself make them. Lockjaw Engine itself has no concept of "seconds"; everything is in frames. The frontends (lj.exe, lj.gba, lj.nds) always use 60 frames per second, plus or minus one. (Due to display timing issues, the GBA version uses 16777216/228/1232 = 59.73 Hz, and the DS version uses 33554432/6/355/263 = 59.90 Hz.) It depends. On a PC where vsync() gives 50 frames per second, such as a home theatre PC set to output a 576p/50 signal to a PAL TV, lj.exe displays 5 frames and hides the sixth. For a frontend on a closed platform such as a game console, with no fine user customization of rulesets, then I would probably be deploying the Lockjaw Engine under a Tetris license and would do whatever Henk wants. This could be a frameskip style method like what LJ currently does, or it could involve calling the game engine 50 times a second instead of 60 and changing the delays, depending on parts of the Guideline that have not yet been made public. (Anyone have the 50 Hz version of Tetris Worlds or any other such Guideline-based game for comparison?)
<sarcasm>Whoa, total ignore FTW!</sarcasm> Again, what is so wrong with nn/60 fractional seconds replacing ms?
I found another split point. Mostly the fact that "10/60 s" gives information to fewer people than "10/60 s (166 ms)". I see it as like a map giving distances in both miles and kilometers, even though a mile is defined as exactly 1.609344 km.
Both are plenty accurate, and not at all arbitrary. Tepples, if you want to display both, I think that would be plenty clear for everyone. I fully support that.
Fine, if that satisfies like maybe two humans and three imaginary little green men living in your head who are about the only ones who use ms for 60fps-based-games, so be it... <sarcasm>Of course, more clutter just HAS to be better.</sarcasm>
"166 ms = arbitrary number" arbitrary? 166 ms sounds about what i'd like to have my reaction time down to. i don't understand the huge need for "a number over sixty." milliseconds are accepted in many practical applications and are preferred in all academic and scientific ones. 26/60 makes me think "wtf is a number over sixty? do you expect me to have a calculator or something? just give me the info-- save the thinking for when i play" edit: i mean really... wtf is a number over sixty anyway?
nn/60 is merely a compromise over absolute time and frames. But if there just has to be two notations side by side anyways, there's pretty much no point in being a compromise in the first place - why not just put frames and ms side by side. I do think frames make sense to a more to people used to 60fps fixed arcade games, rather than used to variable framerate computer games. If LJ was a game that ran at whatever framerate the hardware was capable of, with lock times and other internal variables defined in ms, I'd have absolutely no objections on using ms. However, on a game that runs at 60fps fixed, a 1/60 frame is the smallest unit of time that the system can recognize - the other 15.666whatever milliseconds do not matter and have no meaning. When a lock time parameter decreases, they decrease by multiples of one frame, not multiples of one millisecond. One, two and three are much easier to handle than 16.666, 33.333 and 50. Again, if a lock time parameter could be decreased at increments of one millisecond, I have no objections on using ms. This is probably also harder to grasp since frame-level parameters become more important in forced-speed games than voluntary-speed games.
