Introducing: TestDX


Screenshot of program

I'm pleased to present you TestDX, a test&benchmark program that I've developed a week ago for one of courses in university.
This program tests a set of characteristics, some of which are related to behaviours in GameMaker games specifically.
Program includes English and Russian localizations, with additional ones being easy enough to add (if wished).
It can be considered non-interactive (apart from being able to pause tests at any time by pressing a key), however visual presentation is kept at good level, making two minutes, that it takes program to perform all tests, worth looking at.
To keep things 'transparent', a source is included in download. There is no set license for it, but makes itself useful, if you're curious, how everything works in test.
Some of code in source is quite rushed (often done in spare minutes), but I've added documentation to all scripts, and generally code style is kept intact.

Download

Description of specific test results below.
  1. Main display: size, bit depth, and frequency of display, as detected by standard available routines
  2. Hard drive: free & total space available on hard drive that contains the program
  3. Shape drawing: behaviour relating to drawing fixed-sized shapes (most noticeable on rectangles). How strange this may sound, but size of rectangles drawn via GameMaker draw_rectangle routine actually varies between computers depending on videocard & drivers.
  4. Time spent filling area: Speed of doing draw_point operations, in short. Is a good explanation to why it is not a good idea to make pixel shaders in plain GML.
  5. Maximum framerate: maximum reachable framerate on a (almost) blank room.
  6. Surface contents upon creation: When created, surfaces may contain transparency (intended effect), solid colour (normally black), or random data left there by previously running applications. This is why it is a good idea to clear surfaces before drawing something.
  7. Time spent analysing area: Speed of surface_getpixel calls.
  8. Texture fragment rendering: Some hardware may render an unnecessary pixel row when given a task of drawing a scaled fragment of texture (i.e. tile from tileset). This commonly observed in games, where 'pixelness' is achieved by calibrating view-port size without using any extra techniques. A separate post about eliminating this glitch is available.
  9. Non-standard sized texture rendering: Not all hardware handles drawing of non-power-of-two textures fine, and out of ones that do not, not all will automatically scale texture to nearest appropriate size, messing up visuals of models to use such textures.
  10. Related posts:

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.