Results 1 to 7 of 7
  1. #1

    Bug reporting and Slow-Downs

    Ive noticed that print()ing large amounts of data to the console slows the game down. Does this also apply to when Blender reports coding errors to the console? In other words: should I address EVERY SINGLE bug in my game in order to increase performance? Including even the "un-noticable" bugs? Or does BGE disregard these bugs when exported as an executable? By the way...im about to launch my game....follow me guys



  2. #2
    DO NOT ignore console errors!! even if you have to post a "Known Issues" section.

    python is a special thing, it doesnt require to be compiled, so that means it can half work. running in standalone wont help at all, in fact, it could make it worse. most languages require you to compile the code first, which means you cant even start the program until all the bugs are out.

    each time an error occurs, that script will STOP, then start again from the top next frame. leaving these unattended will cause unexpected behavior or new bugs which will be harder to find. in bigger more complex projects, one error can cause the whole thing to come crashing down long after the error occurred. also, bugs can be used to exploit the game, no matter how small.

    most errors can be fixed with an if-then statement. ill be happy to help troubleshoot and debug.

    to answer your question, yes, errors can have a pretty serious impact on performance. each time an error occurs, python tries to figure out what went wrong and tell you about it in the console which eats up processing time.
    System "IVAN" (rev 1.3b) - Win7 64bit - Blender 2.74:
    CPU- Intel i3-3220 3.30 Ghz | GPU- EVGA GTX 970 | RAM- GSkill Ares 16GB 1600 Mhz | MB- ASUS P8Z77-V LK



  3. #3
    That's what I suspected. The Unity Engine wont even compile a game if there is a single error. Even without doing a "bug-sweep" my game still runs pretty good. So I'll try to not lose too much sleep over it. But I guess I'll be up all night injecting try: and except: statements into my code. Thanks again for the input man!



  4. #4
    Member sdfgeoff's Avatar
    Join Date
    May 2010
    Location
    Kalpana One
    Posts
    5,113
    I advice checking before rather than try/except. Particularly for dictionary/list lookups (which is probably where your code currently fails). Check list length, or use "if 'key' in some_dict" rather than waiting for it to fail.
    Try/except should be used when you cannot know if an action will fail or succeed (such as receiving from a socket, writing a file).
    "Someone applied a roof texture to that wall" - martinsh

    Website: www.sdfgeoff.space



  5. #5
    Member JustinBarrett's Avatar
    Join Date
    Jul 2009
    Location
    Trier(near), Germany
    Posts
    2,154
    squah those bugs...even if they do not 'seem' to interfere with gameplay...they will impact performance, or cause secondary bugs that will confuse the parser(or whatever ) and you may not see errors for secondary bugs and those could lead to bigger problems.
    "The crows seem to be calling my name." Thought Kaw.
    Myrlea, "The Shepherd's Quest" formerly "Valiant" [project]



  6. #6
    Thanks for the advice guys. I almost have all the bugs addressed and am about ready to launch!!!!! Please subscribe lol



  7. #7
    Moderator Monster's Avatar
    Join Date
    Jan 2006
    Location
    Germany
    Posts
    13,675
    Please be aware - in Programming there are different types of errors:

    Compile errors - As the compiler does not understands your code it can't generate machine code = no application to start

    Runtime errors - This happens while the process gets into erroneous state while running the code. If not told otherwise the execution leaves the current code block (till it exits the process).

    Logical/Business errors - This is behavior that is not supposed to happen. Typically they can't be detected automatically. You just wonder why things happen that you do not expect (or vice versa).


    Within the BGE the difference between compile errors and runtime errors is not always visible as the compile starts while the game is already running.

    You should always care about errors. When the console prints an error it means this is an error you do not expect. This also means your game is in a state you can't be sure about. E.g. was a point counted or not?

    You should never just catch errors that you do not know about (= all errors) unless you are 110% percent sure you know what you are doing (e.g. establishing an alternative error handler).

    This means a pure "try:..except" without a specific error type should not be in your code. If you do it you hide the fact an error occurred without dealing with the specific situation [Not looking at the console window does not mean there is no error - you just do not know about it]. More worse the problems that will arouse due to the error will still be there with all the unexpected results. But you have no idea why you get this results. This makes support really really hard.

    When you get errors you have several options:
    - You review your code ensure this situation will not happen again (code change)
    - You turn the error into an expected error by catching the specific error and ensure the process remains in a valid processing state (e.g. by closing a file).
    - You modify the environment that the error will not occur again



    To answer your question: when you have errors ... performance is not the number one priority anymore.



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •