Skol
Sorcerer
Group: Members
Posts: 465
Joined: May 17, 2006
|
#1 Posted Nov 2, 2009, 1:25 pm
|
Anyone familiar with this?
It's my understanding that RoM takes all of the areas and compiles into one big string (MAX_STRING must then hold). So as your game increases in amount of rooms, mobs etc, you'll need to increase MAX_STRING. Then, MAX_PERM_BLOCK, is the largest block of perm allocated memory right?
Anyway, having issues and wondered if the MAX_PERM_BLOCK should be raised (stock is 128k, 131072 bytes).
Any help would rock, thanks guys.
|
|
|
Runter
Wizard
Group: Members
Posts: 1,074
Joined: Jun 1, 2006
|
#2 Posted Nov 2, 2009, 1:31 pm
|
It's my understanding that MAX_STRING is simply a define for maximum size of strings in the codebase. Such as maximum size a buffer should be.
It uses it's own little memory system where it allocates one large block when the program starts and gives pieces of it away. So my guess would be that is what MAX_PERM_BLOCK is. If you're actually running out of memory inside of the constructs of this system it would be my guess that this number should be increased.
To be honest, though, in Roms I've dealt with in the past I've pretty much scrapped this and simply replaced it with new/delete or malloc/free calls.
|
|
.........................
-Heath
For once you have tasted flight Ruby you will walk the earth with your eyes turned skywards,
for there you have been and there you will long to return. --
Leonardo Da Vinci Yukihiro Matsumoto
|
|
|
|
Skol
Sorcerer
Group: Members
Posts: 465
Joined: May 17, 2006
|
#4 Posted Nov 2, 2009, 1:44 pm
|
Crap, found it in string.h in RaM... looks like unchanged memory use, just moved.
Code (text): 1
2
3
4
5
6
7
8
9
10
11
12 | 32
/*
* Memory management.
* Increase MAX_STRING if you have too.
* Tune the others only if you understand what you're doing.
*/
#define MAX_STRING 1413120
#define MAX_PERM_BLOCK 131072
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Skol
Sorcerer
Group: Members
Posts: 465
Joined: May 17, 2006
|
#11 Posted Nov 2, 2009, 3:15 pm
|
Here was my most recent approach:
Code (text): 1
2
3
4
5
6
7
8
9
10
11
12
13 | extern int port;
#if (port == 8662)
#define MAX_STRING 6291456 // Coder port 6x 1024*1024
#else
#if (port == 8650)
#define MAX_STRING 9437184// 9*1024*1024 (on 11/01/09)
#else
#define MAX_STRING 8388608
#endif
#endif |
Unfortunately, while it does know what 'port' is, it appears to be going to the default (8388608) according to my memory function:
Quote:Ansalon Port: Coder (8662)
Affects 226
Areas 7
ExDes 263
Exits 1646
Helps 730
Socials 244
Mobs 158(158 new format)
(in use) 304
Objs 371(371 new format)
(in use) 446
Resets 731
Rooms 745
Shops 16
Ponds 18
Strings 6074 strings of 956238 bytes (max 8388608).
Perms 7897 blocks of 661408 bytes.
While I could simply increase the size, I wouldn't mind increasing it only on that specific port. Although it doesn't appear to be causing any higher memory or cpu usage with the higher rate on the lighter ports.
|
|
|
|
|
|
|
|
|
Davion
Idle Hand
Group: Administrators
Posts: 1,188
Joined: May 14, 2006
|
#15 Posted Nov 2, 2009, 8:52 pm
|
Skol said:Anyone familiar with this?
It's my understanding that RoM takes all of the areas and compiles into one big string (MAX_STRING must then hold). So as your game increases in amount of rooms, mobs etc, you'll need to increase MAX_STRING. Then, MAX_PERM_BLOCK, is the largest block of perm allocated memory right?
Anyway, having issues and wondered if the MAX_PERM_BLOCK should be raised (stock is 128k, 131072 bytes).
Any help would rock, thanks guys.
MAX_PERM_BLOCK actually has very little to do with the shared string code. It has to do with the function alloc_perm(). alloc_perm is the function called every time you allocate one of your recycled structures (affect, char_data, pc_data, etc). MAX_PERM_BLOCK limits the size of these structures (128k+ structure, wowzers :P). All alloc_perm() is, is a fancy call to 'calloc'. It'd be pretty safe to just bypass it entirely. You can change all your calls, or just do a simple hack ->
Code (text): 1
2
3
4
5
6
7
8
9
10
11
12
13
14 |
void *alloc_perm( int sMem )
{ void *mem;
if( (mem = calloc(1, sMem) ) == NULL )
{ perror("alloc_perm");
exit(1);
}
nAllocPerm += 1;
sAllocPerm += sMem;
return mem;
} |
That'll do error checking, and maintain the 'memory' command.
|
......................... 
|
|
