Homebrew Issues with C++ arrays of classes

[Project68K]

I am having some issues involving using C-style arrays that are of a custom class type in C++ for my homebrew DS game. I was originally using the std:vector, but felt that it was too inefficient for a system like the DS, especially with the low ram and memory that it has. I refactored the code to allow for arrays of full of 10 falling objects. The falling objects are used for the player to collide with. I, however, am having some issues with it. If I start the game, and try to proceed as normal, it ends up giving me this:

This is not supposed to happen, as the array is only supposed to hold 10 values, and the sprite id goes incrementally from 23 - 32. What I think is happening is that since C++ does not check out of bounds, it is creating random values for array elements that are out of bounds. If I do a simple print to print the sprite ID of the element out of bounds, it will print either 0, or a random number.

Here is the code for creating the array:

void createFallObjectArray(FallingObject arr[], s16 pos[], int& spawnIndex) {
    
    for (int i = 0; i < fallCount; i++) {
        s16 randomNum = rand() % 3 + 0;
        // Set randomObj to a random number between 1 and 3.
        int randomObj = rand() % 3 + 1;
        arr[i].x_pos = pos[randomNum];
        arr[i].y_pos = -16;
        arr[i].spriteID = 23 + i;
        arr[i].rotID = i + 1;
        arr[i].objectType = randomObj;
    }
}

void handleFallObjects(float & spawnTime, float & dt, float & spawnDelay, FallingObject fallArray[], int& fallUsedIndex, u8& fallRotID, int& spawnIndex, s16 pos[])
{
    if (fallUsedIndex < fallCount)
        // Increase spawnTimer by dt.
        spawnTime += dt;

    // If the spawn timer is greater than or equal to spawnDelay.
    if (spawnTime >= spawnDelay)
    {
        NF_CreateSprite(1,fallArray[spawnIndex].spriteID,fallArray[spawnIndex].objectType,fallArray[spawnIndex].objectType,fallArray[spawnIndex].x_pos,fallArray[spawnIndex].y_pos);
        NF_EnableSpriteRotScale(1,fallArray[spawnIndex].spriteID,fallArray[spawnIndex].rotID,false);
        NF_SpriteLayer(1,fallArray[spawnIndex].spriteID,2);
        spawnIndex++;
        //fallRotID++;
        spawnTime = 0;

    }
}

I've tried many different solutions, and different types of arrays. Some have worked, but not to the fullest extent that could be inline with what I want. I have also linked the main.cpp as well.

If anyone has any tips or suggestions, I would appreciate that.

 

[plasturion]

Folder is empty so I can't check, but shuldn't be " void createFallObjectArray(FallingObject & arr[], s16 & pos[], int& spawnIndex)" ? Function needs a reference to previous made array, otherwise it create new one inside of block and after return changes will gone, or... maybe I'm wrong.

 

[Essometer]

Folder is empty so I can't check, but shuldn't be " void createFallObjectArray(FallingObject & arr[], s16 & pos[], int& spawnIndex)" ? Function needs a reference to previous made array, otherwise it create new one inside of block and after return changes will gone, or... maybe I'm wrong.

No, I think arrays decay to pointer type when passed as an argument to a function, so it will access the elements outside the function as desired. Making them a reference is not necessary.

 

[PewnyPL]

No, I think arrays decay to pointer type when passed as an argument to a function, so it will access the elements outside the function as desired. Making them a reference is not necessary.

Are you sure it's not a newer CPP standard? It's been ages since I coded any bigger CPP stuff, but I remember having to use references in this case. Devkitpro uses an older compiler, so if it's a newer standard it may not work properly. I could be wrong, however, no harm in checking how it works with the & in there, no?

Also, OP, what is calling the handleFallObjects method? Are you sure spawnIndex given to it is not already above the array size?

 

[Essometer]

Are you sure it's not a newer CPP standard? It's been ages since I coded any bigger CPP stuff, but I remember having to use references in this case. Devkitpro uses an older compiler, so if it's a newer standard it may not work properly. I could be wrong, however, no harm in checking how it works with the & in there, no?

Also, OP, what is calling the handleFallObjects method? Are you sure spawnIndex given to it is not already above the array size?

Absolut no harm in trying to pass the array by ref and see if it fixes it. I’m just saying that the compiler can not pass it by value as it has no size information of the array you pass in. You would need a template for that or specify the size of the array in the argument.

 

[Essometer]

:This is not supposed to happen, as the array is only supposed to hold 10 values, and the sprite id goes incrementally from 23 - 32. What I think is happening is that since C++ does not check out of bounds, it is creating random values for array elements that are out of bounds. If I do a simple print to print the sprite ID of the element out of bounds, it will print either 0, or a random number.

Sorry for the double post. When you switch from a vector to array, you need to keep in mind that as soon as you create the array with the FalllingObject, the data gets initialled. If FallingObjects is a “class type”, the default constructor gets called automatically. For structs, the memory that the array occupies is treated as the type of the struct, meaning there is random data inside the struct. Maybe you need to keep track of if the data was already initialised with real data or use default data for the FallingObject struct/class.

 

[Pk11]

Are you sure it's not a newer CPP standard? It's been ages since I coded any bigger CPP stuff, but I remember having to use references in this case. Devkitpro uses an older compiler, so if it's a newer standard it may not work properly. I could be wrong, however, no harm in checking how it works with the & in there, no?

Also, OP, what is calling the handleFallObjects method? Are you sure spawnIndex given to it is not already above the array size?

devkitPro actually updates very fast, faster than most PC compilers. It's currently on gcc 12.1.0.

To OP:
You might want to do type *variable instead of type variable[], they're really just pointers either way but that shouldn't be breaking anything... Really need to see where you're creating the FallingObject arr to see what's wrong. Though honestly imo you're wasting your time trying to avoid vectors if it's giving you issues, I checked and using std::vector costs about 10 KB on the binary size, and the DS isn't actually that limited on RAM, 4 MB is a lot.