Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Bug Programming Software Technology

Unreal Engine Code Issues Fixed By Third-party Company 72

An anonymous reader writes: Unreal Engine is the famous game engine that was used to implement such games as Unreal Tournament, BioShock Infinite, Mass Effect and many more. On March 19, 2014 Unreal Engine 4 was made publicly available from a GitHub repository. It was a big event for the game development industry. One of the companies that took an interest in this was PVS-Studio, who created a static C/C++ code analyzer. They analyzed the Unreal Engine source code and reported to Epic Games's development team about the problems they found. Epic suggested a partnership with PVS-Studio to fix those bugs, and their challenge was accepted. Now, PVS-Studio shares their experience in fixing code issues and merging corrected code with new updates in a major project that shares its source code.
This discussion has been archived. No new comments can be posted.

Unreal Engine Code Issues Fixed By Third-party Company

Comments Filter:
  • The big question for me is do coding errors affect video rendering issues?
    We tend to blame drivers for this, but recently there are opinions out there that suggest that the game code itself is responsible (as well).

    • Re: (Score:3, Insightful)

      by Anonymous Coward

      Of course they can. If you calculate stupid stuff, the result will be stupid stuff.

    • Only idiots "tend to blame drivers" for that shit.
      The vast majority of changes in driver updates for AMD and nVidia are hacks for specific games to fix their broken shit and get them to not run like ass.

      • by Anonymous Coward

        Only idiots "tend to blame drivers" for that shit.
        The vast majority of changes in driver updates for AMD and nVidia are hacks for specific games to fix their broken shit and get them to not run like ass.

        Yeah, "idiots" like Rich Geldreich, an OpenGL expert that worked at Valve for many years. His scathing assessment on the quality of drivers resulted in widespread news coverage, including a /. article [slashdot.org]. For those of you interested in reading the original post, it's at http://richg42.blogspot.com/2014/05/the-truth-on-opengl-driver-quality.html. Note that most of the other game developers posting in the comments agree with him.

        So, which company are you shilling for, sexconker, vendor N or vendor A? Inquir

        • I don't have any real experience or hard data with [ the open source AMD and Nouveau ] drivers, because I've been fearful that working with these open source/reverse engineered drivers would have pissed off each vendor's closed source teams so much that they wouldn't help.

          Which is just fucking great.

      • by donscarletti ( 569232 ) on Tuesday June 16, 2015 @08:29PM (#49926215)
        You don't know what you are talking about. Drivers never quite follow the DirectX, OpenGL spec and always have some idiosyncrasies on this card or that to make them generate correct-ish results faster by cutting corners. I find my card getting completely different results to the reference implementation on a monthly basis (sometimes even missing draw calls completely or rendering with the wrong state). I found this particularly true when using DX9 style render states on DX11 class hardware. Neither AMD nor Nvidia will change a driver for you unless you can prove to them that the application is using the spec correctly and the observed results are demonstrably wrong. If you are an independent developer it's even worse since they don't make it easy to contact them.
      • Only idiots "tend to blame drivers" for that shit.

        I haven't had to go through this in a while, but there was a long time (back in the GEforce single-digit version days) when you would regularly have to reinstall an old driver to play a specific game. It doesn't really matter whether that old driver had a special case that they took out later, or whether they just broke something; either way, driver changes will regularly take out programs. The driver developer can then go blame it on the software developer, but they may well have done it wrong the first ti

      • I had a Radeon 7960 video card when I got ID Software's "Rage" for $2.50 during a Steam Black Friday sale a few years ago. The 7960 exceeded the minimum hardware specs for this game. The moment gameplay came up it chugged at 2FPS. New drivers, old drivers, hacked drivers. Nothing could make that game run. I recently got a Nvidia 720 video card and the game ran fine. Go figure.
    • by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Tuesday June 16, 2015 @09:16PM (#49926389) Homepage Journal

      The big question for me is do coding errors affect video rendering issues?

      Sure. Just remember that the video driver is a whole bunch of code. It's code all the way down.

      • by Ihlosi ( 895663 )
        It's code all the way down.

        If you haven't encountered hand-soldered transistors, you haven't gone "down" far enough.

        • If you haven't encountered hand-soldered transistors, you haven't gone "down" far enough.

          Back in high school I built a burglar alarm kit, does that count? It was enough to convince me that what I really wanted to do was use microcontrollers, or better. Now that you can just buy I2C modules and plug them together, I feel relatively vindicated. Someone has to design those things, but it doesn't have to be me.

  • Slashvertisment (Score:5, Insightful)

    by Dunbal ( 464142 ) * on Tuesday June 16, 2015 @07:14PM (#49925835)
    Why do I feel like this is an ad for the code analyzer?
    • by TimSSG ( 1068536 )

      Why do I feel like this is an ad for the code analyzer?

      Maybe, because it is one. Tim S.

    • Let me quote:

      "This activity benefits everyone: readers enjoy learning from others' mistakes and discover new means to avoid them through certain coding techniques and style. For us, it's a way to have more people learn about our tool. As for the project authors, they too benefit by gaining an opportunity to fix some of the bugs."

      I added the bold.

    • Re:Slashvertisment (Score:5, Informative)

      by turp182 ( 1020263 ) on Tuesday June 16, 2015 @08:06PM (#49926101) Journal

      I believe you didn't read the link. It was written by PVS staff, and states very clearly that the effort was to promote their product:

      As a way of promoting our PVS-Studio static code analyzer, we've thought of an interesting format for our articles: We analyze open-source projects and write about the bugs we manage to find there.

      They made it to Slashdot, so the effort was a success on some level. And maybe more people need to be aware of code analyzers (we just enforce code conventions and obvious bad practices).

      • by Kjella ( 173770 )

        They made it to Slashdot, so the effort was a success on some level. And maybe more people need to be aware of code analyzers (we just enforce code conventions and obvious bad practices).

        Maybe you should stop enforcing obvious bad practices first? :)

        • We're actively working on that, specifically on older systems where habit is more common than good practice ("this is how we have always done it").

    • Considering there are tons of bugs [viva64.com] in open source programs ... you might be right :-)

      Intel Galileo UEFI analysis (May 2015)
      Godot Engine analysis (April 2015)
      FreeCAD analysis (April 2015)
      Haiku OS analysis: part 1, part 2 (April 2015)
      Vim analysis (March 2015)
      CoreCLR analysis (March 2015)
      LibreOffice analysis (March 2015)
      MatrixSSL analysis (February 2015)
      Linux kernel analysis (January 2015)
      Powder Toy analysis (December 2014)
      Spring RTS analysis (December 2014)
      Miranda NG analysis: part 1, part 2 (November 2014)
      NS

    • by bitflip ( 49188 )

      It's an ad, but it's one of the better ones. It isn't all hype - they demonstrate the effectiveness of their product on code we all have access to.

      I learned a few things, too (I haven't touched c++ in awhile, so I guess that isn't a very high bar).

    • I definitely didn't get that impression coming through my dell monitor, maybe it was due to the speed it loaded, thanks iinet, anyway I'm thirsty in a way only an ice cold coke can quench.

      Sent from windows laptop. ...Seriously everything is one giant marketing exercise nowadays.

    • by jandrese ( 485 )
      It kind of is, but they put in so much information that I can't hold it against them. Look how many code fragments with common errors there are in there. This is a quality article.
    • by Anonymous Coward

      If PVS' code analyzer can help a developer find bugs that would either go unfound, or would take more $$$ than the cost of the code analyzer to find, then bravo to PVS for making a development tool that not only works, but is priced correctly based on the value it brings to the project.

      That PVS then joins an open source project and uses its code analyzer to help identify and fix bugs in the project, with the intent of that activity promoting their product I think is a good thing.

      PVS didn't have to do this,

  • This isn't exactly timely.. this happened march 2014.

  • ... in the code at all costs to make it look pretty, and, hey, everyone's supposed to know the operator precedence rules. Which promptly come and bite them in the rear, see the "suspicious sum" paragraph.

    I can see why one of the MISRA rules states that "limited dependence" should be placed on C operator precedence and expressions should be clarified (to the reader, not to the compiler) by using parentheses.

  • Company releases product as open source project. Other company submits code to open source project. Why is this even news?
  • The problem with articles like this one is that they tend to under-represent the benefits of static analysis. Products like PVS-Studio are designed to work with C++ and because they have to run in a big compile job, they get run in batch at the end of each day.

    This is a problem because (a) C++ is very hard to statically analyse so performance is often poor and (b) the most critical time when you need/want static analysis feedback is when you're actually writing the code itself.

    So let me insert a plug here f

If all else fails, lower your standards.

Working...