Loading ...
Sorry, an error occurred while loading the content.

Making SVG Games and Multimedia Better

Expand Messages
  • Gordon Bowman
    We ve seen more SVG-based games popping up lately, which got me to thinking if there isn t a way that SVG could be improved to make such games perform better,
    Message 1 of 2 , Apr 27, 2004
    • 0 Attachment
      We've seen more SVG-based games popping up lately, which got me to
      thinking if there isn't a way that SVG could be improved to make
      such games perform better, as well as making them easier to create.
      I think there is.

      When you want to do SVG animation, SMIL typically performs better
      than script because it is implemented natively and can take
      advantage of its knowledge of what the animation is trying to do,
      optimizing it with techniques such as double-buffering etc. But the
      SMIL syntax is not designed for interactive graphics--even if you
      can dynamically modify the SMIL parameters using script and get it
      to work properly (future viewers will hopefully fix this), it's
      difficult to know what the animated attributes are at any given time
      since they're not part of the real DOM (although I think SVG 1.2
      will fix this), plus there's overhead involved in translating the
      real-world parameters like velocity and acceleration to SMIL
      attributes.

      If, however, we had a new element such as <object> or <sprite>,
      whose attributes include:
      - x
      - y
      - v (speed)
      - vDirection (direction it's moving)
      - vx (x-component of v, so you can avoid calculating vDirection, if
      that's easier. Maybe it should be dx.)
      - vy (y-component of v, so you can avoid calculating vDirection, if
      that's easier Maybe it should be dy.)
      - a (acceleration, maybe it should be dv)
      - aDirection (direction it's accelerating)
      - ax (x-component of a, so you can avoid calculating vDirection, if
      that's easier. Maybe it should be dvx.)
      - ay (y-component of a, so you can avoid calculating vDirection, if
      that's easier. Maybe it should be dvy.)
      - rps (revolutions per second)
      - drps (rate of change of rps)
      - cx (x-centre of rotation)
      - cy (y-centre of rotation)
      - angle (angle that the object currently has--can be set manually
      and is automatically calculated whenever accessed)
      - xlink:href (points to the element to be used for its appearance,
      just like a <use>)

      then we wouldn't need to use setTimeout() anymore to animate things,
      using a refresh interval that really should be specific to every
      computer's capability. Instead, this object takes care of all of it,
      making its animation look as good as possible on your machine, just
      like SMIL's implementation does. When you want to control the
      objects on the screen with script, you only need to manipulate the
      attributes of this element.

      If we added a boundingBox or boundingPath attribute, along with a
      bounding region handler ID, we could eliminate the need for script
      to track the object so as to know when it's left a particular
      region, but we could still write the script that handles it when
      that happens. We could even have some predefined handlers like WRAP,
      BOUNCE, DESTROY, etc.

      If we added an attribute to specify the ID's of all the other
      objects that we want it to perform collision detection against, as
      well as a collision handler ID, then we could eliminate the need for
      collision detection with script but still allow script to handle it
      when it happens. We could have some predefined handlers like BOUNCE,
      DESTROY, etc. We could even add a 'mass' attribute to help with more
      realistic collisions, though that might be stretching things.

      Other attributes like opacity would, of course, also be useful.

      As far as I can tell, such an element would be within the scope of
      SVG because it's still about graphics, just as much as SMIL
      animation is. It's just a different way of thinking about the
      animation, treating the objects in motion as real-world objects with
      physical properties like speed and acceleration. The result would be
      that SVG-based games and multimedia are much easier to author and
      perform much better.

      Anyone have any thoughts?
    • Andrew Emmons
      I think this is a great idea. My personal attempts at writing games using SMIL animation and a Mobile C++ DOM API (see SVGOpen 2003) were, although ultimately
      Message 2 of 2 , May 3, 2004
      • 0 Attachment
        I think this is a great idea. My personal attempts at writing games using
        SMIL animation and a Mobile C++ DOM API (see SVGOpen 2003) were, although
        ultimately successful, hampered by the limitations you describe. If SVG were
        to have a few elements specifically for handling sprites and bounding box
        logic, this would make it an even better starting point for a game
        development framework. This is especially true for mobile devices where SVG
        already provides cross-platform support in the form of vector graphics,
        animation, event handlers, etc.

        Andrew


        -----Original Message-----
        From: Gordon Bowman [mailto:gordon_bowman@...]
        Sent: April 27, 2004 4:40 PM
        To: svg-developers@yahoogroups.com
        Subject: [svg-developers] Making SVG Games and Multimedia Better


        We've seen more SVG-based games popping up lately, which got me to
        thinking if there isn't a way that SVG could be improved to make
        such games perform better, as well as making them easier to create.
        I think there is.

        When you want to do SVG animation, SMIL typically performs better
        than script because it is implemented natively and can take
        advantage of its knowledge of what the animation is trying to do,
        optimizing it with techniques such as double-buffering etc. But the
        SMIL syntax is not designed for interactive graphics--even if you
        can dynamically modify the SMIL parameters using script and get it
        to work properly (future viewers will hopefully fix this), it's
        difficult to know what the animated attributes are at any given time
        since they're not part of the real DOM (although I think SVG 1.2
        will fix this), plus there's overhead involved in translating the
        real-world parameters like velocity and acceleration to SMIL
        attributes.

        If, however, we had a new element such as <object> or <sprite>,
        whose attributes include:
        - x
        - y
        - v (speed)
        - vDirection (direction it's moving)
        - vx (x-component of v, so you can avoid calculating vDirection, if
        that's easier. Maybe it should be dx.)
        - vy (y-component of v, so you can avoid calculating vDirection, if
        that's easier Maybe it should be dy.)
        - a (acceleration, maybe it should be dv)
        - aDirection (direction it's accelerating)
        - ax (x-component of a, so you can avoid calculating vDirection, if
        that's easier. Maybe it should be dvx.)
        - ay (y-component of a, so you can avoid calculating vDirection, if
        that's easier. Maybe it should be dvy.)
        - rps (revolutions per second)
        - drps (rate of change of rps)
        - cx (x-centre of rotation)
        - cy (y-centre of rotation)
        - angle (angle that the object currently has--can be set manually
        and is automatically calculated whenever accessed)
        - xlink:href (points to the element to be used for its appearance,
        just like a <use>)

        then we wouldn't need to use setTimeout() anymore to animate things,
        using a refresh interval that really should be specific to every
        computer's capability. Instead, this object takes care of all of it,
        making its animation look as good as possible on your machine, just
        like SMIL's implementation does. When you want to control the
        objects on the screen with script, you only need to manipulate the
        attributes of this element.

        If we added a boundingBox or boundingPath attribute, along with a
        bounding region handler ID, we could eliminate the need for script
        to track the object so as to know when it's left a particular
        region, but we could still write the script that handles it when
        that happens. We could even have some predefined handlers like WRAP,
        BOUNCE, DESTROY, etc.

        If we added an attribute to specify the ID's of all the other
        objects that we want it to perform collision detection against, as
        well as a collision handler ID, then we could eliminate the need for
        collision detection with script but still allow script to handle it
        when it happens. We could have some predefined handlers like BOUNCE,
        DESTROY, etc. We could even add a 'mass' attribute to help with more
        realistic collisions, though that might be stretching things.

        Other attributes like opacity would, of course, also be useful.

        As far as I can tell, such an element would be within the scope of
        SVG because it's still about graphics, just as much as SMIL
        animation is. It's just a different way of thinking about the
        animation, treating the objects in motion as real-world objects with
        physical properties like speed and acceleration. The result would be
        that SVG-based games and multimedia are much easier to author and
        perform much better.

        Anyone have any thoughts?




        -----
        To unsubscribe send a message to: svg-developers-unsubscribe@yahoogroups.com
        -or-
        visit http://groups.yahoo.com/group/svg-developers and click "edit my
        membership"
        ----
        Yahoo! Groups Links






        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.