Ineffective use of memory

Game Talk The Garage
1

There will be described my all finds with ineffective using of memory

field.h:

No need in that var. Priority is used only one time (in drawing function) and never changed. Can be replaced with case in the drawing function.

No need to use int. There’s no “time is stopped when you stopped here”. Use signed word instead.

int age; //The age, or time to live, of the field effect. 0 is permanent. int halflife; // In turns
For some insane reasons you use negative numbers to show that field is still alive. Rework that part a little to use positive numbers instead. Actually, there’s no so persistant field that require to use int. Use unsigned word.

signed char density; //The density, or intensity (higher is stronger), of the field entry.
The same. May be only 1, 2 and 3.

calendar.h

  int second;
  int minute;
  int hour;
  int day;
  int year;

This shit again.

catacurse.h

  int x;//left side of window
  int y;//top side of window
  int width;//width of the curses window
  int height;//height of the curses window
  int cursorx;//x location of the cursor
  int cursory;//y location of the cursor

unsigned word, please.

computer.h

int security;

Security 2^16-1, lol.
unsigned char.

construction.h

    int difficulty; // carpentry skill level required
    int time; // time taken to construct, in minutes

unsigned char and unsigned word, please.

creature.h

        int str_max, dex_max, per_max, int_max,
            str_cur, dex_cur, per_cur, int_cur;

        int moves, pain;

unsigned word for str/dex/int/per cur/max and pain

        int num_blocks; // base number of blocks/dodges per turn
        int num_dodges;

The same.

damage.h

the same.

dialogue.h

the same

effect.h

int duration; int intensity;
The same.

faction.h

 int good; // A measure of how "good" the value is (naming purposes &c)
 int strength;
 int sneak;
 int crime;
 int cult;

Any explanation?

game.h

I always wanter to kill negative amount of enemies.

  signed char temperature;              // The air temperature
  int get_temperature();    // Returns outdoor or indoor temperature of current location

?

int moves_since_last_save; int item_exchanges_since_save;
As always.

…

Damn, it’s boring. I am gonna sleep. I hope you got my thought.

2

Ok, one more.

item.h

[code]int fridge; // The turn we entered a fridge.
int last_rot_check; // last turn we calculated rot
int burnt; // How badly we’re burnt
int bday; // The turn on which it was created
int poison; // How badly poisoned is it?
int bigness; // engine power, wheel size
int frequency; // Radio frequency
int note; // Associated dynamic text snippet.
int irridation; // Tracks radiation dosage.

int count;
int totalcount;[/code]

itype.h

map.h

Are there above ground and under ground?

mapdata.h

int str_min; // min str(*) required to bash int str_max; // max str required: bash succeeds if str >= random # between str_min_roll & str_max int str_min_roll; // lower bound of success check; defaults to str_min ( may set default to 0 ) int str_min_blocked; // same as above; alternate values for has_adjacent_furniture(...) == true int str_max_blocked; int num_tests; // how many tests must succeed int chance; int explosive; // Explosion on destruction
One more again. Too big limits.

Radiation can’t be negative.

mapgen.h

Boom.

mapgen_function.h

int n_fac; // dir == 0 int e_fac; // dir == 1 int s_fac; // dir == 2 int w_fac; // dir == 3 int ne_fac; // dir == 4 int se_fac; // dir == 5 int nw_fac; // dir == 6 int sw_fac; // dir == 7 int zlevel;
unsigned char ~

3

A lot of those you’d want to convert to unsigned int’s, not to unsigned chars in order to preserve expandability. Notably anything involving an effect timer should be able to support longer periods of time since if it lasts for a couple of days can easily push into int territory. Fields are weird in the sense that fire utilizes it’s timer completely different than other fields IIRC, which is why it needs support for negative.

That said personally I’d rather err on the side of possibility for a many of these things rather than forcing limits to what we have now. Just because we don’t we don’t have anything that lasts long enough to need an int over a char right now doesn’t mean we won’t need it, and virtually none of these are used commonly enough that spending an extra two bytes on each one is going to have any significant effects overall.

4

As with any optimization, we need to see evidence that it’s actually causing slowdown or excessive memory use before making these changes. These proposals have a very real chance of introducing bugs, and no direct benefits.
If there’s either an item that is used a huge amount, or an object that is used in a very tight loop, this kind of thing can help, but unless that’s established there’s no benefit.