Hello, I'm just learning about the data types in C after some googling, and I'm beginning to understand the limits of var and the advantages of the others like int and double.

So is there a way to define an array in C that is bigger than 999999? I tried:

#define huge 123456789

Int big_boy[huge];

That crashes on startup.

Also, I was able to at one point define this array:

Int nodes[9999999];

This actually worked until I tried saving the game, which I ran out of memory.

This might be only true for C/C++ and not necessarily Lite-C since I didnt reverse engineer it yet:
Those arrays get "allocated" depending on where you put the definition to.
If its global it gets "allocated" in the .data or .rdata section of your resulting/compiled PE file.
If the definition is on the stack, this data is directly allocated on the stack.
Theres another way to get memory dynamicly at runtime, which is called malloc.
It can allocate memory on the fly and also free it again, also you dont want the engine to save this array since you can read it yourself from a file if you need it. The engines save function is a way more complex then you might think, it has an internal structure (linked list) to keep track of all objects and there state in the game.

TL;DR:
Arrays are designed for data you know the size of, if the size is by any mean dynamic you have to use malloc/free

This array is a global array, and by stack, you mean a local array created by an entity, correct?

There are two important memory areas when you're running your program. One area is called the stack and one area is called the heap. The stack saves everything that is required when a function is called and starts running. All variables that are declared inside of your function are saved on the stack. When another function is called and your current function is still running, this other function data and all it's variables are stored on the stack by stacking it on top of the memory of the first function. Because everything is stacked on top of each other it is called the stack memory. When a function is done the memory the function has used on the stack is freed. The idea of the stack is, that only the memory of the function on the top of the stack can be freed. Everything below this memory has to wait. And you can only put new needed memory on top of the stack. This is called the last-in-first-out principle.

When you're running the function with this huge array all the memory that is needed for this array is occupied on the stack. If the stack is full no other memory area on top of the stack is free to store more data. You'll get a stack overflow and the program crashes.

The stack is small. With Acknex you can place about 10 000 functions on top of each other until the stack is full. If you use large arrays this will happen even faster.
You need another memory area to store such huge data. This area is called the heap. Gamestudio can use about 1.5 GB of your system memory for its heap. To save data on the heap you need to use special functions. For arrays use the function called malloc.

Acknex provides a special version of malloc called sys_malloc:

int* nodes;

nodes = sys_malloc(huge * sizeof(int) ); //needs about 470 MB

Wow.... thank you Ezzett, that was really helpful and informative. So the heap is like a bigger contiguous storage space? This is much safer to use, correct?

why Does that int, with sys_malloc require 470 mb? thats huge! When do I use sys_free? Before the game exits?

One integer needs 4 bytes of memory. You allocate 123456789 integers. This are 4 bytes * 123456789 = 493 827 156 bytes. If you calculate 1 MB = 1024 KB and 1 KB = 1024 bytes this will be around 470 MB.

The heap doesn't need to be contiguous. It is provided by the operating system. Gamestudios nexus, which is also saved on the heap, should be contiguous. This helps to avoid memory fragmentation. Memory fragmentation can be a big problem. Your huge array is also allocated in one contiguous block of heap memory. If you have enough free system memory (let's say 1 GB is unused) but this free memory is fragmented in many small blocks (and each block is smaller than 470 MB) then you can't allocate the memory for this array. sys_malloc will return NULL if it couldn't allocate memory on the heap.

Other problems are memory leaks. You have to free the heap memory you used if you don't need it anymore. Maybe before exiting the game or maybe earlier. It depends on how long you will need the data stored in it.

sys_free (nodes);
nodes = NULL;

If you don't free the memory area and you lose/change your nodes-pointer to this memory area you can't use this unfreed area for future memory allocation. You'll need to restart your game to get the memory back.

If your game is closed all allocated memory is freed by Windows. You don't need to free memory before closing the engine, but it's a VERY BAD practice to do this. Maybe you'll never find a memory leak if you don't free memory because you count on Windows help to do this.

Therefore heap memory is not safer to use.

Thank you Ezzett, That was amazing. I looked all over my script, and saw many huge Var arrays that I made "just in case i wanted 10k entities to store vars each" and didnt realize many of these huge arrays were taking up megs!! I shortened the arrays after

I tried:

int* nodes;

nodes = sys_malloc(huge * sizeof(int) ); //needs about 470 MB

and GS gave me an error on compile saying:

Wrong type P_MUL:POINTER:LONG:POINTER

Hmm, it works for me. It looks like you are multiplying a pointer variable with a long variable. Of what type is huge?

My mistake. The below snippet doesnt give me errors. Did i do this right? I wanted to make it the maximum value:



I did that not inside a function or anything, just where the other vars are declared. After doing this, can i do the following?

mega_nodes[2147483647] = 2147483647?

which is to go to the last slot and give it a value.


A question:

1. 2147483647 x 4 = 8589934588 bytes, which comes out to 8.589 gigs! This is allocated in the GS Nexus, correct? I dont notice an increase in MB in the nexus statistics panel. I duplicated the sys_malloc with multiple different ints, each to the max int value, and my memory usage nexus-wise hasnt increased. Is this because nothing was actually stored in the array, and its just marking this memory area as "DO NOT TOUCH" for any other memory calls?

How do you expect a 32 bit process to be able to allocate 8gb data?
How would you address the memory when a 32 bit app can address a maximum of 4gb?
This obviously wont work with such high numbers. As pointed out before the maximum you can allocate is arorund 1.6gb

What exactly do you want to do? You haven't pointed out the goal of all this but from my perspective this approach seems a bit strange. There's probably a better way of doing this.

It is impossible for Gamestudio to allocate this much memory because Gamestudio is a 32 Bit application. On Windows a 32 Bit application can allocate just about 1.5 GB. This means that Acknex's limit is also at about 1.5 GB.

sys_malloc will return NULL if it can't allocate the memory. Your mega_nodes pointer is a NULL-pointer. Using it as usual will crash your game. Check every time before using a pointer which can be a NULL-pointer if it is pointing to NULL. When it's not, then you can use it, but not before checking.

The nexus is memory for your level. When you create a level in WED and load it via level_load, then your level needs memory for textures and blocks and so on. Gamestudio allocates a memory area on the heap and calls this area nexus. This speeds up playing the level because everything needed is already stored inside the nexus when you start your level. After that loading is done Gamestudio doesn't need to load more data from your hard drive which saves time and lowers the risk of running out of memory while playing. If you don't work with level_load you will have nothing to do with the nexus.

When you access an array the last slot is at the position 'arraysize - 1' because the first slot is at position 0. The second slot is at position 1, the third slot is at position 2, ... and the last slot is at the position which equals 'arraysize - 1'. If you try to access a slot at a later position you will produce an error because you're outside the bounds of the array.

Hey everyone! See if you can bear with me:

The reason for all this is because, I am porting an old A* code from George's AUM all the way from A6. In the script, it uses a big array to store path information, its a big array that should be big enough to hold Max_nodes*Max_nodes. So since a Var array cannot exceed 999999 slots, the maximum amount of nodes I can have in the level is roughly 999, since 999*999 = 998,001.(in a test level, I kept the max nodes to be around 980 just because). My test AI pathers can run around this huge level perfectly fine (aside from adding local avoidance). I am a little hesitant to move to a different pathfinding code just yet, because I know this one already, and I can get it working if I keep the node count under that limit, and I am perfectly fine with that. I can just increase the range at which nodes can connect to each other, as well as be stingy within reason when placing nodes in the level. (I have downloaded Superku's pathfinding, and I will be trying that in a new project when I get to that point as well.)

But I want to see how far I can potentially go with this current pathfinding, mainly in how many nodes I can push. At one point, I was able to have 1600 nodes, and have the AI's run around correctly as well! But the problems here was that:

1. Path calculation for 1600 nodes took a long time, so I was looking into ways to save paths for each level beforehand. (I have found a way to do this using game_save with SV_info, and with array names ending with _i. Using memcpy seen in another thread, I was able to copy the saved array into the working array. But this also got me thinking about how data types are stored and read)

2. I wasnt using sys_malloc, and if I wanted to save the game, I ran out of memory!

3. The code would crash randomly at the start, and at times it would crash and give me seemingly random errors in unrelated functions, which meant memory wasnt being managed right.

So thats why Im looking to see how big an array I can get, which will let me know how many nodes I could feasibly attain. If I can correctly allocate a big array, as well as be able to find any position in it using the multidimensional maths, I could then see if I can add more nodes.

It may not be feasible to have 4000 nodes in your level for a finished commercial game, because you have GUI, graphics, animation, physics, sound, music, input, collision detection, all competing. But if Im doing foundational stuff, I would like to try to see how far I can get it now, and when I have the worst case scenario running correctly, I can worry about pulling back when it comes time to make an actual level.

Is this for your sword fighting game? Steering behaviors for ai characters is a much better choice for huge outdoor levels than pathfinding which is better suited for tight corridors and labyrinths. And steering behaviors are calculated very fast. Maybe pathfinding is the wrong technique here.

Hey Ezzett! Yes its for my sword fighting game! My game will have a mix of both corridors as well as wide open areas, but im leaning towards smaller tighter arena places.

Is steering behavior the technique to fill the whole walkable area with "force" directions? Pushing entities towards their goal?

Steering behaviors work by giving an entity a goal (a position in your map) an tell the entity what to do with this goal (walking over to the goal, running away, pursuing a moving goal, velocity matching and so on). You do this by giving your entity a velocity or acceleration. You can add collision avoidance so that entities run around objects while getting to their goal. Of course, this will not work for tight or complex geometry, here you need pathfinding. But you can combine entities to groups and create coordinated movements and it will look really complex and "intelligent" while being fast to compute and not so hard to implement, depending on your programming knowledge.

I read about this topic in the book 'Artificial Intelligence for Games' by Ian Millington. In the book he uses high level pseudo code, but he offers source code for many (not all) techniques on www.ai4g.com. For example, if you look at the code for some steering behaviors at https://github.com/idmillington/aicore/blob/master/src/steering.cpp
you'll see that each steering behaviors consist of just a few lines of code.

https://www.youtube.com/watch?v=PJCSvRh9ljI