why are you using Hz and ms for description of timing ??? shouldn't be more easy to understand to use "frame" or "img/sec" as most of the game ?
Apparently, he want his game that does not run on a 50Hz device to be unambiguous with the antiquated 50Hz PAL standard. It's a bit ironic that he has confused a European with his notation, eh?
hmmm, 10 years ago, when my american super nes with FFVI wasn't compatible with my television it was an issue. Actually i don't understand how a PC/Mac OS/linux can be affected by the "limited" speed refresh of the screen. never seen a 50 Hz CRT monitor...
Speeds of moving objects in a video game have to be specified in terms of some time base. Should "1G" and "lock in 30 frames" be faster on a PC connected to a 90 Hz monitor than on a PC connected to a 60 Hz monitor?
what i don't understand is why you abolutely want to correlate the underlying engine of any cycle program even if it is time based, with the refresh rate of the monitor material... how much cycle LockJaw engine is performing during 1 sec ? is it fixed ?
It doesn't. The word "frame" is not used because people might confuse frames at the engine's fixed 60 Hz update rate with their monitor's refreshes.
The players of this game do not confuse them. The players of this game do not confuse them. The players of this game do not confuse them. The players of this game do not confuse them. The players of this game do not confuse them. The players of this game do not confuse them. The players of this game do not confuse them. The players of this game do not confuse them. The players of this game do not confuse them. The players of this game do not confuse them. The players of this game do not confuse them. The players of this game do not confuse them. The players of this game do not confuse them. The players of this game do not confuse them. The players of this game do not confuse them. The players of this game do not confuse them. Puh-lease.
Sorry 'bout that, I snapped. Well, anyways, if it absolutely MUST be non-relative non-ambiguous seconds, why not just use a fractional notation, like 1/60 seconds? That's still absolute time, and also compatible with the 60fps frame notation as-is, and can be converted to milliseconds fairly easily if one was so inclined to count in ms.
No. 1/60 frames or 1/60 fractional seconds. Two units just make it even worse than one. The people you are trying to save from confusion do not exist. You're causing more confusion from users who actually exist (eg. Ezzelin, Cubicz), in exchange for the presumptive convenience of people who don't. Really. They're not there. Again. The players of this game do not confuse 1/60 frames with 1/50 frames, monitor refresh rates, or anything else. Presuming they will and using units hardly ever used in fixed-framerate-game-parlance is causing more confusion instead of less. Sticking to the established practice of 1/60 frames will cause less mess instead of more. The players of this game do not confuse them. The players of this game do not confuse them. The players of this game do not confuse them. The players of this game do not...
Does any Tetris brand product sold outside Japan use "G" in its manual? And if frames are so fundamental to the public's understanding of the game, then why does the chronometer in TAP use min:sec:centi instead of min:sec:frame?
Forcing people to learn what a Hertz is is a heinous crime. I suggest we write to the supreme court about this.
hey ! what's this new topic ? i'm not the author of this mascarade ! When they need to know about the time measurement on a game engine based on a determined cycle repetition witch most of the time for the concerned type we are discussing is 60 images per seconds, advanded players naturally count the displayed images. It is the most reliable way to get the information, and because the refreshing screen display is "always" more or equal to the game engine cycle speed. i'm really sorry for you, about the fact that it is a kind of natural standard and the "frame" word just fit better than always using "images per seconds" yeah TAP use a time chronometer... Won't you think it is natural to display people a "real time conversion" when the amount of "frame" become too huge ? Frame is perfect when used for short period. But, everybody have no use to know is best performance as 1426785 frames.... but i agree that public don't care about frames counting, or about understanding the engine or all those kind of geek things. Sooooo, you will argue now that your astonishing visual LockJaw game is designed for large public ? hmmm with all your so geek mimic personalisation functionnality ? hey wake up guy ! you are on the geekest forum out there about TETRIS... and by the way you didn't answered my question, does LockJaw use a determind cycle speed repetition like 60 cycles/ sec (for example) ps : c'est comme pisser dans un violon...
That's for total time in the macro scale. This is about DAS delays at the micro scale. The macro scale uses centi time since frame-level inaccuracies matter less, and enthusiasts rarely need to refer to total time using frames. TAP is also a commercial product which needs to cater somewhat to the general laypeople who are used to centi time. When weighing how many people refer to which units how frequently, centi time wins over frames. The micro scale discussion only comes into play among enthusiasts who know what a frame is, and does not involve laypeople. Frames are used since accuracy matters, and that's what the actual program implementation runs on. When weighing how many people to refer to which units how frequently, frames win over ms hands down. LJ doesn't need to use frames for total play time either, only for the prefs options that only people who know what they are doing are going to tweak with anyways. Really, what are you going to lose with the nn/60 fractional time notation? It's absolute, it's compatible, it's unambiguous against 50fps TVs or monitor refresh rates, and it can work with GBA, DS and PC consistently. Jago: It runs at 60fps.
Well, I was never confused by any of the different time units, for the record, I was merely asking about the inconsistencies between versions of Lockjaw. I honestly don't care which units are used. However, it isn't entirely correct to say that Lockjaw wouldn't ever run on a 50Hz display. What if it was ported to a PAL console at some point? Also, who's to say that Lockjaw shouldn't be able to run internally at a different rate at some point? Out of all the suggestions I've read in this post, I like x/60 seconds. It's still time based, but is immediately convertable to frames on 60Hz displays, which is what most people think of these days. Perhaps the values can be internally kept in ms for accuracy, and displayed as x/60 seconds for readability? There could even be a preference for time display, although I'm not sure how difficult that would be.
If nothing else, this has taught me exactly what a Hertz is, I only had a rough idea before. This whole debate seems to stem from a key difference in ideas, brought to a head over an issue (much like political debate). Some see this game as a specialist community project that won't leave this forum, whereas tepples is setting standards early on that, when (if?) this game goes gold, it could be mass distributed and the population at large would know whats going on. In other words, it seems like it is being designed from the ground up to appeal to a larger group than currently uses it.
See mention on the reason TAP uses centi time for total elapsed time. Things that have exposure to laypeople are okay to use (and should use) laypeople-friendly units; things for enthusiasts who know what they are talking about will still need to be dealt in what is closest to the actual program implementation. Even if LJ eventually expands to a larger audience, it's most likely that laypeople will pretty much be unaware of/ignore those detailed settings entirely, be it in ms or frames or n/60 or n/50 or whatever. (They should be kept inside some kind of "Advanced Settings" menu anyways.) So mass familiarity and enthusiast familiarity do not necessarily conflict.
