Forums

Re: Swing meter experiments

• bubbadork 984 Posts

  Thu, Apr 11 2013 9:56 AM

  I recently made some experiments regarding generating a browser swing meter without Flash or image animations. There are three versions.

  1. This is an HTML5 progress bar. It works well in Chrome, fairly well in Firefox and Maxthon, and is entirely strange in IE 10. It runs on a 10 ms timer and lays down 8 pixels for each of those intervals.

  2. This is an HTML/CSS implementation. It runs on a 10 ms timer and lays down 8 pixels for each of those intervals. It works well on Chrome and fairly well in Firefox, Maxthon, and IE.

  3. This is an HTML/CSS implementation. It is triggered every 10 ms but lays down however many pixels are called for by the passage of absolute system time. It works well in Chrome and fairly well in Firefox, Maxthon, and IE.

  The methods are identical provided that the interval timer is precise and accurate. That is problematic if other processes are running. The benefit of method 3 is that it will consume the proper amount of time even if the interval is inaccurate. As an extreme example, if you only got two intervals instead of the expected 100, the bar would be painted in two huge increments in the correct amount of time whereas the other two methods would paint in 100 increments but would take nearly a minute to do so.

  I also tested these with FRAPS (a movie maker) running. I saw no discernible effect whereas FRAPS will definitely garfle up the WGT swing meter.

  You may find these tests at http://www.daweidesigns.com/progress.html

   

   

• andyson 6,415 Posts

  Thu, Apr 11 2013 11:54 AM

  How about a version at 60fps?  Yours is trying to drive my display at 100fps and it only goes up to 60.

• bubbadork 984 Posts

  Thu, Apr 11 2013 3:54 PM

  Okay, tomorrow.

• bubbadork 984 Posts

  Fri, Apr 12 2013 7:30 AM

  Okay, I made some changes. Same three types of meter. Added selectable frame rate, meter length, and swing time. All three meters swing at the same time.

  The first two are, as before, a fixed number of time elements. If the timer is inaccurate, the swing time will be inaccurate. The third uses the same timer pulses, but fills the bar according to how much actual system time has elapsed.

  The ratio of monitor refresh rate to frame rate is not of much importance. It may drop a frame, but it gets all it needs (or all that are available, for lower frame rates).

  The problem comes when the graphics ability is overcome by the frame rate or when the system timing events are overcome by the frame rate. Those effects may be cumulative or amount to several frames being dropped or being reproduced at improper intervals.

  Test page in same place: http://www.daweidesigns.com/progress.html

   

• andyson 6,415 Posts

  Fri, Apr 12 2013 10:49 AM

  ??

  

  Screen shot of Chrome with FPS counter enabled while meter is running.

• bubbadork 984 Posts

  Fri, Apr 12 2013 12:19 PM

  OK, I didn't understand that myself, when I know how many times I'm calling the interval counter, and how often. I did some searching on the web and didn't find anything really definitive. I postulated that the progress bar might be the culprit. I know how often I'm setting its value, but have no idea how Chrome is implementing the paint scheme. Because it has a gradient, and because, even at rest, it has an animation going, I surmised that they are painting it as often as they can.

  The version now shown has the progress bar removed and only my constructed CSS meters. With that version, the FPS meter follows the selection.

  It's interesting to note, also, that as I'm typing this response the FPS meter on this page occasionally peaks out at values up to 60. Since there is no animation going on other than reproducing my text as I type it, Chrome obviously makes some decisions on its own about how often it should try to repaint the screen.

  At any rate, the test suite now works as expected. The 100 fps setting cannot be provided by the browser, 60+ being the apparent practical maximum. That means some frames are being dropped, so the apparent smoothness is probably equal between the two selections.

  I would value additional comments from you or anyone else, as I find the meter implementation problem interesting. I'm thinking of doing further meters that actually use real animation (images) and a recent provision of browsers called "requestAnimationFrame." This method supposedly calls upon the browser to run at its highest possible rate.

• andyson 6,415 Posts

  Fri, Apr 12 2013 2:46 PM

  Too bad the progress bar method didn't work out.  I appeared to be the most precise.

  I confirm it now runs 30FPS or 60FPS on my PC.

  I ran a quick test, ran a McAfee virus scan in the background, (a WGT meter killer), which took my CPU utilization up to 25-50%.  Neither of your meters stuttered or froze.  I also plan to see if a gradient background and meter image has any effect.  I saved your page, hope you don't mind, and modified the CSS replacing the background colors with background images of both inner and outer styles.

  

  

  Here's the images I used:

  Meter   Background

  Any way to gradually increase the meter speed just as WGT does?  It starts slow and speeds up at the end.

  I think "Bubbadork's Ding Trainer" is the next logical use of your work.  Make the width and speeds truly variable so we can match our meters, club and ball combos.  Click, hold, release, click to ding.  Measure the distance from the ding line.  Record stats....

  Going back to watch more of the Masters.

   

• bubbadork 984 Posts

  Fri, Apr 12 2013 4:54 PM

  There's no problem making an accelerating meter. The "perfect time" version fills the meter according to a linear function. It could well be a non-linear function.

  A simple method of presenting a horizontal gradient would work in the same way but would not present a really smooth gradient, given the timing constraints.

  A truly smooth horizontal gradient would be presented by using images of the bar (one for background and one for foreground) and unveiling the foreground incrementally as the swing progresses.

  The construction of the bar with ding line, precision areas, etc., is really just a matter of image selection.

  I, too, found the timing to be relatively free of additional tasks. I ran a movie of a Flight Simulator flight and experienced no visible effects. Of course, there is going to be a limit. The processor cores have a finite amount of time.

  I'll be playing with this, no question. Hell, I spent a few hundred hours writing my own flight physics, and that only included in-the-air time.

  Thanks for your responses and suggestions.

  Incidentally, the progress bar was totally worthless in IE. Those guys had the best browser back at 4.0 (when their only real competition was Netscape) and have apparently been working hard to eff everything up, since.

• Tightrope 1,072 Posts

  Fri, Apr 12 2013 6:10 PM

  I don't like your experiments. They seem to indicate that I have been wrong about my "gradients kills" theory. It's no fun being wrong. They are all stuttering on my screen. Not much, but very similar to the WGT meter. And they have no gradient.
  
  Seriously, of course I like it. Even if they will prove me wrong. Still, I feel there must be a way to make the marker move in a more harmonic way. What if it is a box, maybe 3x10px, or a dot, that moves, you think it would make a difference?
  
  What Flash have, that your tests doesn't (I assume), is hardware acceleration. There some interesting stuff here:
  http://www.htmlgoodies.com/html5/client/unleash-the-power-of-hardware-accelerated-html5-canvas.html#fbid=ohCW1_6gGhR
  
  But it is not really anything that would apply to the game.

• bubbadork 984 Posts

  Fri, Apr 12 2013 7:57 PM

  My purpose is to show that this element of the game can be produced in a way that is functional in a browser based game. I have no desire to reproduce the WGT meter in all its cosmetic, but unimportant, details.

  It is my belief that these first approaches are superior to the Flash-based WGT meter in that they are usable under circumstances where the WGT meter drastically fails. Your personal experience may suggest otherwise. That's the purpose of this thread.