News:

The Forum Rules and Guidelines
Our forum has Rules and Guidelines. Please, be kind and read them ;).

Game Bug Explanation

Started by transporter, August 29, 2013, 03:40:51 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

transporter

So, there's something I never understood about programming. How can a new feature cause a bug, crash, or other error with a previous feature? It seems quite often (at least, that I notice) that a feature that could have been stable for a while can stop working or break once a new one is released. Why would that be? With my limited experience with programming (which might be the explanation itself) once I fix any errors with the base code, any new features or functions could only break within their specific coding, and not when it interacts with the rest of the code or functions.

Sarlock

It's common, especially with a large, complex program such as Simutrans.  When you affect one section of code with a change you can cause inadvertent effects in another piece of code.  With a large program it is hard to anticipate all of the possible impacts of making a change, especially a major one.  You do the best you can and then work to stamp out the unforeseen bugs as quickly as possible.  Perhaps some of the experienced programmers can give a few specific examples of how this can occur.
Current projects: Pak128 Trees, blender graphics

Ters

New code may alter assumptions of old code. Things not previously possible, and hence not coded for, suddenly become possible.

There are also the really nasty things like memory overruns, where code writes to memory locations it is not supposed to, corrupting random data, or even code. Sometimes code that has appeared stable, suddenly starts revealing it's true buggy nature. An example would be a memory overrun bug that just writes two bytes out of bounds. Since memory allocations happen in blocks, lets say of 32 bytes, this will not crash if the data structure is only 28 bytes. The erreneous write then happens at byte 30, which is not in unallocated memory, and hence an illegal operation, or in someone else's memory. But if the size of the data structure grows by four bytes, to accomodate a field needed by a new feature, the erreneous write now happens at byte 32, which is outside the allocated block.

This is just a few things I can think of in a hurry. It's complicated stuff this, which is why it breaks so easily. Low level languages like C++ is somewhat more fragile at this point than higher level languages like Java, C# or PHP.

ӔO

There was a bug that was fixed recently, where having a large number of pax or goods waiting at a station could corrupt a save file.
I think it was more than 65,535, which is 16 bits.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

An_dz

There also exist the bugs that are not bugs, but simply a behaviour that looks weird. Making an old, working behaviour become wrong. On graphical programs like Simutrans this may happen quite often.

kierongreen

As has been said already - new code may have unintended side affects. In an ideal world all functions would be completely independent of each other. For a game like simutrans, where data is shared across many functions and speed is essential this model is just not practical.

transporter

I've run into the allocated memory problem with C, but not to the extent that it would crash. Just gives some weird answers. Most of my experience is with simple math and pattern work. But one of the main problems you say, is having to write mostly in one large chunk right? So is the whole executable considered one big base function with the other texts and paksets what it retrieves?

Ters

Quote from: transporter on August 29, 2013, 02:02:19 PM
But one of the main problems you say, is having to write mostly in one large chunk right?

I'm not sure what you mean. I'd compare most code to lots of big and small lumps, some brittle and some more solid, held together with strings of varying quality and scotch tape. Some code isn't visibly held together at all (this doesn't happen with Simutrans, but with some of the modern languages and development methologies).

Sarlock

It also adds to the complexity when a project is large enough to require several authors to contribute to the code.  At this point, there is no one individual who has full knowledge of the entire program and thus there is more potential for bugs to crop up when one person's code has unintended impacts on another person's code.
Current projects: Pak128 Trees, blender graphics

transporter

What I meant is that when I was programming in C, there would be one main function at the beginning that would call on other smaller functions. So this one commanding function would, say, take a inputted number then grab another function to add 1, then a different to subtract 2, and print to the screen the new number. Is SImutrans set up like that where the executable is one big main function which grabs the supporting texts and paksets, or is the executable itself a series of functions?


@Sarlock that makes a lot of sense

Ters

Quote from: transporter on August 29, 2013, 04:30:53 PM
What I meant is that when I was programming in C, there would be one main function at the beginning that would call on other smaller functions. So this one commanding function would, say, take a inputted number then grab another function to add 1, then a different to subtract 2, and print to the screen the new number. Is SImutrans set up like that where the executable is one big main function which grabs the supporting texts and paksets[?]
(Quote is slightly truncated for better transition to the answer.)

Not at all. Such a thing is virtually impossible to write beyond the most trivial programs. Simutrans is a big mixture of functions and objects with methods, sprinkled with some assembly code and dynamic dispatch via function pointers. Not exactly a showcase example of how to program, but not too bad compared to other real programs of comparable size.