PC Report guide

[LDK 9]

This article is a rough guide on how to write PC Report articles. Here you'll find information about proper article structure, benchmarking process, screenshots, graphs and more. Also this should be taken only as a guide and not set of rules. Write the article as you like, just make sure it properly describes quality of a game port.

Structure

PC Report article should follow this structure, but don't be afraid to include or exclude sections as you see fit. When in doubt, see older articles for examples.

• Teaser paragraph - PC Report series introduction (copy two lines in cursive from older article) plus little bit about the game and what should reader expect in the article.
• System requirements - lists of minimum and recommended hardware specs and short commentary. If benchmarks are included in the article, state hardware specs of the machine and how the testing was conducted (built-in benchmark, custom demo, run through the game - which map...)
• Video settings - screenshot of video settings menu and short description. Be sure to mention lack of features like field of view slider in first/third person games, lack of resolutions in mobile ports etc. FoV should have its subsection here if applicable.
• Performance analysis - benchmarks and comparisons of main effects. Be sure to include at least overall performance, quality comparison and few words about optimization if you are not doing all the effects. Linking (not embedding!) full resolution screenshots in PNG format is recommended.
• Controls - screenshot of controls menu and its description. Mouse and keyboard implementation is the main focus here so be sure to test mouse acceleration and keyboard customization. Controller support and screenshot of its mapping can be also included.
• Audio settings - screenshots of audio setting. Be sure to check subtitles, closed captions options and volume sliders. If it is possible, test surround sound support.
• Conclusion - closing thoughts and overall summary of the article. Here you can repeat significant weaknesses and strengths.

Benchmarking

Benchmarks are a great way to figure out performance load of each graphical setting, but it is rather time consuming. The key in benchmarking is repeatability: each pass has to return consistent results withing usual 2-3% margin of error. Use build-in benchmark when possible.

 

When build-in benchmark is not available, you'll have to create your own by playing one segment of the game over and over again. Choosing this segment is very tricky. It has to represent performance load through the game and if possible it should contain wide variety of effects (smoke, water reflections, dust, cloth simulations...), but be ready to change your benchmarking segment to test specific effects (water reflections cannot be tested in scene without water for example).

 

Segment should be at least one minute long. Cutscenes can be very good for this purpose, but make sure there are no significant performance spikes (framerate drops to zero when loading next scene or shoots up to hundreds when only black screen is displayed) and scene is sufficiently long.

 

When no suitable cutscene is found, benchmark has to be from direct playthrough. So choose level/mission, that represents overall game performance and play through minute or two. Then reload and repeat. For example benchmark in AC4:BF was me running from one viewpoint in one large city to another during daytime. I had to wait during the nights and different weather patterns because these runs would have very different results. Little easier was CoD:G, where suitable scene was the very first mission. Player is forced to run in a strict path and everything is exploding around.

 

When suitable benchmarking scene is selected, make a few test runs to see, if your results are consistent. If they are, you can begin testing. Fraps has benchmarking tools, but feel free to use any other applications that can capture average framerate.

 

Another important thing to watch out is framerate limiters so be sure to disable vertical synchronization when testing. When a game has a internal framerate limiter, you'll have to capture average GPU utilization from GPU-Z or another application. This will show you average GPU load from which you can figure out performance impact of each effect. For example a game has limiter to 30FPS, average GPU utilization is 43%. Enabling MSAA 4x keeps framerate on 30, but rises utilization to 51% so there is almost 20% performance impact.

 

After collecting all necessary data, put average framerates into the graph and make sure, everything is described. Template with some automation can be downloaded from here. It contains blank tables for several effects, automatic difference calculation between settings and automatic generation of graphs. Graph generation is probably compatible only with MS Excel 2007 and newer.

 

 

Feel free to create your own graphs completely different from this in case you've captured something interesting and this type of graph is not sufficient (frame times for example). However do not use elevated start on Y axis, start should be always zero!

 

Screenshots

Screenshots are very useful tool to show difference (or lack of) in selected settings so be sure to include them in your article. All images can be uploaded into our gallery, just create a new gallery. Do not use article Attachments as there is a 500kB limit restriction.

 

The best way to show difference is by embedding screenshot comparison slider:

[compimg]image_1_address.jpg|image_2_address.jpg|864|540|Image 1 description|Image 2 description[/compimg]

Addresses can be obtained by navigating to the specific image page in the gallery, right-clicking on the image and selecting "Direct link to this image file". Do not use full resolution screenshots as they will be scaled to 864 x 540 px resolution anyway and it would just unnecessarily bloat article size. If you want to show full resolution screenshots, upload its PNGs to the gallery and link it directly from the text.

 

GUI and menu screenshots should be also scaled and/or cropped to 800 px width if possible.

[imgG][sharedmedia=gallery:images:1000][/imgG]

Important image sizes:

• Article header resolution - 600 x 300 px
• Screenshots in slider - 864 x 540 px
• Anti aliasing comparison width - 800 px

Important image formats:

• JPEG, JPG - lossy format, small size but loss of fine details, works well for menu screenshots and rough quality comparisons.
• PNG - lossless format that preserves pixel accuracy but for a price of a large file size on screenshots with a lots of details. Very small size on screenshots that contains windows dialogs.
• BMP - Fraps default output format, pixel accurate, but very large file size. Never use BMP.

Anti aliasing comparison

If the game directly supports anti aliasing, it would be good to show differences between each method:

 

 

And this is how you can make one in Photoshop:

• First you have to find a static scene where you can show each AA technique on the same sample. Important is to include wide variety of angles as some methods does not work well on angles around 0° and 90°.
• Create all screenshots here without moving camera.
• Import all screenshots into image editor as a layers, name your layers by used method.
• Find high contrast edge with several suitable angles - tree branches, wooden planks against bright sky... Make sure to select polygon edge and not texture map with transparency because normally used AA doesn't work on these (leaves, wire mesh in a fence..).
• Align all layers to compensate slight camera movement if necessary.
• Make selection of the sample and copy-paste it to the new document. Do not move selection and copy-paste rest of the samples from other layers.
• Repeat for texture samples as nowadays many AA methods feature horrible texture blur.
• Align all samples next to each other - this will be final product.
• Select Image and Image Size (Alt-Ctrl-I).
• Insert appropriate width, make sure that Constrain Proportions and Resample Image are checked and switch resample algorithm from the Bicubic to the Nearest Neighbor. This will scale up all the samples and preserves original pixels shape and boundaries - doesn't blur anything.
• Insert labels for each AA method, save as PNG (important!) and upload to the gallery.

Size of the sample is also very important because you are enlarging very small pixels to be clearly visible. Basically you are limited by 800 px width of final picture as larger images are scaled down by IP Board and you don't want that. Another thing to consider is how many AA methods is in the game or you want to include in one row. Do not forget to include sample without AA!

 

Now the fun starts - you want to only double or quadruple initial sample resolution. Only that way you'll get perfect pixel accuracy - one pixel will scale to four or eight pixels.

 

So from above example I have 6 different samples in 800 px width. That is roughly 133 px horizontal for final sample resolution. 132 divided by 4 is 33 and this is initial horizontal resolution of the sample. Vertical resolution is chosen appropriately from that size. From that example one sample has initial resolution of 33 x 50, that is scaled to 132 x 200. Twelve samples in two rows and you'll get final 800 x 200 px resolution.

 

Number of samples and their initial sizes, two rows of samples:

1 - 200x50   5 - 40x502 - 100x50   6 - 33x503 -  66x50   7 - 28x504 -  50x50   8 - 25x50

Recommended applications

Here are few recommended applications. Free versions are linked.

• Screenshots, benchmarks - Fraps, GPU-Z, MSI Afterburner, RadeonPro.
• CPU, memory utilization, process information - Process Explorer
• Image editing - Adobe Photoshop, GIMP
• Graphs - MS Excel, LibreOffice
• PNG optimizer - PNGGauntlet

Cheat sheet

[h2]System Requirements[/h2][h3]Minimum[/h3][LIST][*][b]CPU:[/b][/*][*][b]RAM:[/b][/*][*][b]HDD:[/b][/*][*][b]GPU:[/b][/*][*][b]OS:[/b][/*][/LIST][h3]Recommended[/h3][LIST][*][b]CPU:[/b][/*][*][b]RAM:[/b][/*][*][b]GPU:[/b][/*][/LIST][h2]Graphics settings[/h2][h2]Performance analysis[/h2][h2][/h2][h2]Controls[/h2][h2]Audio[/h2][h2]Conclusion[/h2][i]PC Reports are a series of quick first impressions regarding the technical aspects of a PC game. This report was written by PCGamingWiki contributor LDK. For an up to date account of <game> fixes and improvements, please visit its respective [url=http://pcgamingwiki.com/wiki/Pillars_of_Eternity]PCGamingWiki article[/url].[/i] [center]Thank you for reading. If you enjoyed our article and want to us create more articles, more often, please consider donating to [url=http://www.patreon.com/PCGamingWiki]PCGamingWiki's Patreon campaign[/url]:[/center][center][youtube]

 

Click here to view the article

[Andytizer 269]

Many thanks for this fantastic writeup LDK, I'll be referring this to do my own benchmarks/comparisons for the next report I write :).

[LaserMoai 1]

Somebody should fix the last sentence here according to this complaint of mine. Thanks in advance.

http://community.pcgamingwiki.com/page/blog/_/features/port-reports/pc-report-the-witcher-3-wild-hunt-r183?st=0#comment_5844