Author Topic: Overflow etc.  (Read 4289 times)

Offline Greven

  • Bot Destroyer
  • ***
  • Posts: 345
    • View Profile
Overflow etc.
« on: August 08, 2005, 07:41:59 AM »
Just a few simple questions...

Why is there so many overflow errors and other unexpected errors in DB?

I know DB is big in codelines etc., but overflow problems aint that hard to stop, only checking if the variable is near the maximum limit. Or has stated elsewhere making all variables long or single. Will that slow down the simulation speed????????????
10010011000001110111110100111011001101100100000110110111000011101011110010110000
011000011000001100010110010111101001110100110010111100101000001000001111001011101
001101001110011011010011100011110100111000011101100100000100110011010011100110110
010110000011100111101001110110111101011101100110000111101001101001110111111011101
01100100000111010011010001100001110111010000010001001000010100001

Offline PurpleYouko

  • Bot God
  • *****
  • Posts: 2556
    • View Profile
Overflow etc.
« Reply #1 on: August 08, 2005, 09:16:01 AM »
We have literally thousands of variables in DB. They are in all different formats too, a whole lot of them are integers which is where we get most of our overflows.

While it is pretty satraight forward to check that numbers aren't too big for th evariable type, the problem lies in the shear number of if-then statements needed to achieve this. Every time a variable is modified (possibly 100s of times per cycle), a check must be done and checks take a finite amount of time.
In order to speed up the program we try to centralize these checks to one or two places but sometimes this doesn't cut it, particularly when a bit of code gets modified in such a way that it effects a variable that on the face of it shouldn't be effected, and pushes it over the limit in another place entirely.

For example, changing the range of a shot in one routine can make a poison shot in another part of the program come back with a value of 33000 or something equally bizarre.

The whole thing is just hyper complicated.

I still thinnk the best thing to do would be to make every variable either a double or a long.

DB was originally written with the mindset that shorter 16 bit variable would be faster but on modern 32 bit windows environments, I am pretty sure that 32 bit variables are actually just as fast if not a little faster.

Besides this we could then remove all those checks and that would speed up the program too.
There are 10 kinds of people in the world
Those who understand binary.
and those who don't

:D PY :D

Offline Endy

  • Bot Overlord
  • ****
  • Posts: 852
    • View Profile
Overflow etc.
« Reply #2 on: August 09, 2005, 11:07:45 PM »
I can just barely see some of the complexity, when using notepad to view some of the stuff, and I'm amazed you're even able to find your way around :blink:

However you guys manage it, my hat is off to you :clap:

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Overflow etc.
« Reply #3 on: August 10, 2005, 02:53:13 AM »
It's a bit easier in Visual Basic because things are autoformatted for you.  The only real way to understand the program anymore is as a collection of independant modules.  If you try to start at the beginning of the program and run through it in your head like that you'll go mad.

Here's how I work: "gee, I want to add something to the mutations code", so I load up the mutations module and find where it's doing something similar to what I'm after.  Then I just sort of copy and modify.

Next release will have the code slightly more readable, with some of the monsterously long functions broken down a bit more.

For the love of all that's Holy someone besides PY and me make a crack at coding something.  Anything.  There's a whole list of things to be coded in the suggestions forum, some only would take a few hours or maybe a day if anyone had the time and drive to try.

You can even DL VB from the FTP (soon all speech will be in acronym form :P)
« Last Edit: August 10, 2005, 02:55:36 AM by Numsgil »

Offline Greven

  • Bot Destroyer
  • ***
  • Posts: 345
    • View Profile
Overflow etc.
« Reply #4 on: August 10, 2005, 06:47:05 AM »
I am ok programmer ín VB, but I always get scared when I look at the code! It is so %#=%/#%)=()= hard to read and understand. I like my self to get a overview of all things in a particular program, but in DB it is so hard, becuase a lot of the variables & function (etc.) has some stupid italian name or something like that, and I dont what to use 200 hours just to understand the main part of the program, and figure out what it does, if I did I could write a book about it. (No fun) ;)
« Last Edit: August 10, 2005, 06:48:36 AM by Greven »
10010011000001110111110100111011001101100100000110110111000011101011110010110000
011000011000001100010110010111101001110100110010111100101000001000001111001011101
001101001110011011010011100011110100111000011101100100000100110011010011100110110
010110000011100111101001110110111101011101100110000111101001101001110111111011101
01100100000111010011010001100001110111010000010001001000010100001

Offline Ulciscor

  • Bot Destroyer
  • ***
  • Posts: 401
    • View Profile
Overflow etc.
« Reply #5 on: August 10, 2005, 08:48:13 AM »
I really wouldn't trust myself to code anything really serious.
:D Ulciscor :D

I used to be indecisive, but now I'm not so sure.

Offline PurpleYouko

  • Bot God
  • *****
  • Posts: 2556
    • View Profile
Overflow etc.
« Reply #6 on: August 10, 2005, 08:55:43 AM »
Believe me, the "stupid" Italian bits don't really make much difference to a general understanding of the code.
Num and I have probably spent well in excess of your 200 hours getting a real grip on this program. Once you get to that point though, the Italian text just kind of fades from view like it was never there. The code is self explanitory without the comments.

The most tricky thing is usually tracing a procedure call back to its ultimate origin and then figuring out where a particualr variable class was defined and in which module.

Just try tracing the defining point of "mutarray" to change the number of elements that it contains and then add a new one and go through every instance of it in the entire program to modify the calls.

I have had to do this 3 times now and my brain hurts just thinking about it.  :wacko:
There are 10 kinds of people in the world
Those who understand binary.
and those who don't

:D PY :D

Offline Ulciscor

  • Bot Destroyer
  • ***
  • Posts: 401
    • View Profile
Overflow etc.
« Reply #7 on: August 10, 2005, 08:58:50 AM »
My main fear would be that adding one tiny procedure would mess up something somewhere else in the program.
:D Ulciscor :D

I used to be indecisive, but now I'm not so sure.

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Overflow etc.
« Reply #8 on: August 10, 2005, 10:18:40 AM »
You never know until you try.  As long as you approach the code as an incomprehensible whole with lots of little, easilyunderstood pieces you can usually start changing things.

Anyway, PY or I can check over any new code someone else's done to see if it screws up something else.  It's not terribly difficult.

Check out the Awaiting Programming subsection is suggestions for ideas I've gathered that aren't terribly difficult to achieve first time programming.  Like Setting body points at sim start.
« Last Edit: August 10, 2005, 10:22:05 AM by Numsgil »

Offline PurpleYouko

  • Bot God
  • *****
  • Posts: 2556
    • View Profile
Overflow etc.
« Reply #9 on: August 10, 2005, 10:27:26 AM »
Quote
My main fear would be that adding one tiny procedure would mess up something somewhere else in the program.
Happens all the time.
Why do you think we still have bugs to fix?
You makes yer mistakes then you fix 'em. Only way to learn.
There are 10 kinds of people in the world
Those who understand binary.
and those who don't

:D PY :D