No announcement yet.

AquaMark3 - Early Access FAQ - V1.00

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • AquaMark3 - Early Access FAQ - V1.00

    We just got this in our inbox direct from Massive in Germany:


    Q: Why is AquaMark3 more balanced than HalfLife2?

    A: we don't want to comment on other developers or their applications. we are
    sure that valve has good reasons for what they are doing and why they are doing
    it this way.

    ---

    Q: Did Valve do something wrong or is it too hard to tell?

    A: you have to ask them not us.

    ---

    Q: Do you think that there will be games out there that are crap on a specifc vendors hardware?

    A: no. as a game developer you have to create revenues by selling your product
    to as much customers as possible. so it makes no sense for you to create a
    technology which gives a substantial amount of customers a bad experience. you
    may decide to implement special features for an oem version of your game. this
    makes perfect sense but is not an option for a benchmark. if you do not depend
    on the retail or any oem business and you are able to recoup your development
    costs from other sources you might be more flexible.

    ---

    Q: Had any hardware vendor influence with the development of AM3?

    A: as a developer of high end 3d engines and games we traditonally (have to) work
    close together with all major cpu/gpu vendors since years. they tell us about
    their current and coming hardware so that we can decide early enough where we
    will go technically from our side we provide them with valuable input.
    often their driver and hardware teams really get a harsh 'reality check' when we
    tell them how games do look from inside.

    but we do not favour a specifc vendor simply because this could hurt the sales
    of our products because we might exclude customers. so we have to be solomonic
    when we design engines and technology. not because we are keen on being
    solomonic but we do want to give a good experience to all of our customers.

    this is basically the same with all game developers. however, for a game you
    might decide to do a special version for oem which support a specifc hardware
    feature but this is not an option for a benchmark (and traditionally not for the
    retail version). as a game developer you have to implement your algorithms in a
    way that all customers do get an optimum gaming experience and the most out of
    their hardware. but because gfx cards do change fast it in general makes no
    sense to implement a specific algorithm especially for a specifc hardware
    generation. you have to find a general and efficient way.

    ---

    Q: Why is driver X faster than driver Y?

    A: driver and hardware are closely tied together and we think that any driver
    improvements which give an overall speed increase to the customer are good (no
    matter which vendor we are talking about). you have to remember, that we as
    developers use an api (dx9) which is generic and ideally solomonic. so we can
    not code to the metal and get the best out of a specific hardware. so the
    hardware vendor has the task to map the api optimally to the hardware. this may
    turn out to be a laboursome and painful task as you are aiming at a moving
    target (i.e. constantly chaning game engines). so you should think of the driver
    team as a constant service you as a customer get after you bought your hardware.

    the development of a driver is a continous process. you have to notice that the
    source code size of a driver easily exceeds the source code size of a modern
    game! for this reason, there is always room for improvement.

    in many cases the improvement is necessary for reasons which are often
    underestimated. the problems for the drivers performance arise from changes in
    the paradigm of game techniques which are on the other hand driven by the cpu
    performance. a change in game rendering techniques may dramatically change the
    driver demands. for instance contemplate the number of drawprimitive() calls
    which can be executed per frame. in previous games the average number of calls
    per frame was about 100-300. an unefficient implementation in the driver did not
    contribute significantly to its overall efficiency. with increasing cpu power
    and changing rendering paradigm (z first, multipass, materialdriven) the number
    of drawprimitive() calls per frame has multiplied tenfold. suddenly this new
    situation leads to a performance bottleneck in the driver which could could not
    have been foreseen. in this case the drivers code improvement becomes essential
    to get up-to-date. depending on the real situation this could easily lead to a
    performance increase which seems to be astonishing and somehow nonserious.

    another unexpected performance increase simply comes from driver cleanup and
    refacturing. especially driver models which claim to support all generations of
    hardware within a single concept may suffer from compatibility restrictions.
    purifying the driver code from needless ballast may also lead to unepected
    performance increases.

    ---

    Q: What is SVIST for and why it is so slow?

    A: the svist technology is very smart, we have to guarantee that we color the
    pixels of a specific ps type WITHOUT rewriting or altering the original ps code.
    that's why it is very complex and slow. but we have to be very accurate and
    precise.

    however svist is a key feature in terms of transparency for all users of am3. as
    you might read in our white papers we are convinced that the amount of rendered
    pixels of a specific ps type is more relevant to any game and especially a
    benchmark then just claiming that there are ps2.0 in the benchmark.

    there are benchmarks out there who i.e. implement trivial ps2.0 for particles
    which is insane. particles are typically rendered without any ps at all. with
    svist this is visualised for you. if you change the advanced settings you will
    notice that the svist visuals will change which reflect that the engine uses
    different code path for different situations.

    besides we are able to tell you with svist the exact amount (absolute, relative
    and in percentage) of pixels drawn through a specific ps (or even simple
    texturestages like the particles).

    we are convinced that svist is one of the coolest features of am3, however we
    are wondering if people will get the point about it because you have to think
    about it before you see it's beauty. we hope that there are enough smart guys
    out there that will tell the others about it.

    ---

    Q: The AutomatedTestingTechnology is cool, but I do want to fully customize my runs!

    A: no problem you can do this. when you set the advanced options your settings
    are written to a control textfile. by the command line options of the 'plus'
    version you can create a batch file an feed as much benchmark settinhgs to am3
    as you want. this option is be described in your documentation. we implemented
    this especially for power-users.

    ---

    Q: What about the excel sheet?

    A: it is designed for visualisation of multiple measurements! Give it a try,
    you can use it oout of the box or take it as a starting point for you customized
    result visualisation.

    ---

    Q: What is special about ARC?

    A: ARC gives you more options and tools for comparison of your benchmark results
    than any other online benchmark database tool. just have a look at the many ways
    you can filter and set comparison options. it is the most powerful online
    database for benchmarks currently available.
    Cameron "Mr.Tweak" Wilmot
    Managing Director
    Tweak Town Pty Ltd
Working...
X