Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Rose]

Vectors are pretty much just fancy arrays.

[Reelya]

The reason behind zero-based arrays, is that the array name itself is literally a pointer to the memory location of the first element. The index is used as an offset multiplied by the size of the elements. This prevents the program from having to do an extra calculation step to convert from a 1-based index to an actual memory location. So if you make an array "char myChars[10]", "myChars" is literally a memory pointer to the start of a free patch of 10 bytes of memory, since a char is 1-byte in size. Then "myChars[5]" is internally converted to memory location "myChars + 5", which is very quick to calculate.

vector is nice, but it pays to understand the low-level ways of doing things, since you can adapt algorithms to any language then, even if they don't have the same high-level "facilities".

One thing to look out for with templates like vector, is that each time you use a vector with different template parameters, an entire new class heirarchy is generated for the vector and all the classes it derives from, as well as new iterator classes etc. So if you spawn vector<int>, vector<float>, vector<string> and a vector of your custom objects as well, that's basically many of repeats of very similar code that is being spawned in your program, causing quite a bit of bloat.

[miauw62]

Vectors are pretty much just fancy arrays.

Yeah, but their size isn't fixed at compiletime, making them much nicer to use.
If you have a function that accepts a 2D array where the second dimension differs, you basically have to make it a function template, which also causes some bloat :V

[Reelya]

you can just pass the size as a parameter, or make a struct/basic class to pass all the values and data together. There's a lot you can do before considering templatizing all your functions for basic stuff.

[Spehss _]

Wrote a c++ function for rolling dice, ala "roll 1d6" or "roll 3d3" or "roll 2 d20", etc. Does rand produce a different output every time it's called or should I use another way to get a random number? Testing the dice roll function to generate a random map, and I get the same map layout every time, ie it's not random. When testing the output with cout statements, it gives the same output per different input; like if it's to roll 1d6, it rolls 5 every time 1d6 is rolled.

Spoiler: function (click to show/hide)

Code: [Select]

int diceRoll(int diceNum, int diceSides)
{
    int result=0;
    int counter=0;
    int roll=0;

    do
    {
        roll=(rand()%diceSides);
        result+=roll;
        counter++;
    }while(counter<diceNum);
    return result;
}

[Putnam]

That looks more like a job for a for loop, heh.

Anyway, yeah, you may want to call srand with some sufficiently random beforehand.

[Reelya]

Usually srand with some system timestamp does the job. Each program run starts with the same random seed value otherwise. You need to call srand only once when the program starts.

And as putnam said, any time you have a set number of iterations need, go for a for loop rather than while loop. The "do while" will also give the wrong result if zero dice are rolled (it assumes at least 1).

You also have a problem that rand()%diceSides will give a result from 0 to diceSides-1. Which is probably not what you want. The general formula is:

rand()%howMany + minimumValue

where "howMany" would be 6 for a d6, and minimumValue of 1

[Spehss _]

I feel like I'm opening a whole new can of worms by asking this. Currently I'm coding everything in the main.cpp file. I don't like how cluttered it's getting. Can I make separate cpp files to hold various parts of the program to be called on by main? I'm sure this is possible and I'm sure I'm describing object-oriented programming or something, but I don't know how to do it. Or at least not in C++.

[Reelya]

You use a .h file to declare all the functions, and have the main.cpp include that .h file

then, shift functions over to a new .cpp file that also includes the .h file.

Do this in stages, set up the .h file, compile everything working with it. then shift functions to the separate .cpp file one at a time until you know how it works.

[Mini]

rand() is pretty awful. I mean, you can totally use it but if you want a properly random distribution then you should really use something from the random header (it takes a little code to get set up, but having an actual random distribution is probably worth it).

If you do really want to keep using rand(): if you don't manually seed rand (with srand) then it's automatically seeded with 1, which means that same sequence every time. If you call it multiple times in the same program (without reseeding it) then you will get a sequence of randomish numbers (until the pattern starts repeating, how likely you are to have that happen depends on how many numbers you are generating, but if you start getting your map repeating then that's why). This is probably not going to come up if you're using standard dice numbers (ie 4-100), but rand()'s maximum can be surprisingly low, in Visual Studio the maximum is only 32767. Calling srand() with time() will cause issues if you run the program (or otherwise seed) multiple times quickly, because it updates slowly (apparently generally only once per second).

[Gatleos]

Experimenting with biomes.

Spoiler (click to show/hide)

Each one is just 3 overlaid diamond-square maps: elevation, temperature, and moisture. The temperature map is biased by latitude but not elevation. Darker greens are various types of forest, lighter is shrub/grassland. The yellows are desert. None of these maps seem to have mountains in them, but I'm not satisfied yet with the way they look when they do show up; they tend to show up as blobs, and are very patchy. There's not much to be configured with the diamond-square algorithm though, other than the starting resolution. I may have to find a different algorithm for the height map.

Or maybe the problem is that I'm using a flat cutoff for mountains. The main benefit of this is that mountains are never placed right next to oceans, but one of the drawbacks is that there is no way to shape mountain ranges the way I want them. All that can be changed is the cutoff value, and you will always get tiny peaks. OR maybe the tiny peaks wouldn't be a problem if I used a less harsh color for mountain ranges.

[anzki4]

Want to make sure I'm understanding this right. Say I have an array full of '#' chars.

Spoiler: array 1 (click to show/hide)

Code: [Select]

char arrayOne[10];

//this could be imagined as this:
//1  2  3  4  5  6  7  8  9  10
//#  #  #  #  #  #  #  #  #  #

Spoiler: array 2 (click to show/hide)

Code: [Select]

char arrayTwo[10][2];

//this could be imagined as this:
//  1  2  3  4  5  6  7  8  9  10
//1 #  #  #  #  #  #  #  #  #  #
//2 #  #  #  #  #  #  #  #  #  #

So that to access contents, arrayOne would be arrayOne[X] which would be slot X, or coordinate (X,0) on the graph, where arrayTwo would be arrayTwo[X][Y] which would be the slot at coordinate (X,Y) on the graph.

Another way to look at it is as array of arrays. Ie:

Spoiler: array 2 (click to show/hide)

Code: [Select]

char array[3][5];
//Would be
//1: Array1
//2: Array2
//3: Array3

//And Arrays1-3
//1 2 3 4 5
//# # # # #

[Reelya]

Or maybe the problem is that I'm using a flat cutoff for mountains. The main benefit of this is that mountains are never placed right next to oceans, but one of the drawbacks is that there is no way to shape mountain ranges the way I want them. All that can be changed is the cutoff value, and you will always get tiny peaks. OR maybe the tiny peaks wouldn't be a problem if I used a less harsh color for mountain ranges.

I'd recommend getting 3D visualization happening before you start optimizing. You can see whether those lone peaks are really anomolous spiky mountains or whether they're just the tip of a large rounded hill. The arbitrary nature of color cut-offs needs to be correlated with what the actual landforms look like.

Here's a quick idea for mountain ranges. Generate an initial height map, interpret medium values as your mountains, and interpret very high values as flat ground (maybe a bit over sea level, but inland plains). This will definitely give you linear ranges, as they will follow contours rather than being blobs.  So that there aren't mountain ranges around every land mass, you can merge in data from another noise map. This one won't need much detail, it should be broad and smooth low-octave perlin noise. Where this other map is low, make mountains flat, and where it is high, make the mountains high. Combine all this and you will get mountain ranges a controllable distance from the sea, but not all around the land-mass.

[Antsan]

That sounds like a pretty nifty idea.

[Gatleos]

I just realized I can utilize the height data to query each tile's distance from water and bias the moisture map based on it. Why didn't I already think of this.

I'd recommend getting 3D visualization happening before you start optimizing. You can see whether those lone peaks are really anomolous spiky mountains or whether they're just the tip of a large rounded hill. The arbitrary nature of color cut-offs needs to be correlated with what the actual landforms look like.

They're definitely the tips of rounded hills, since diamond square halves the range of random deviation each time it passes an iteration. This is what gives the land its fractal-like properties. I could try to designate tiles as mountains only when they're part of a steep slope, but there are a ton of problems with that and it might end up producing the hollow shells of the same blobs I have now.

Here's a quick idea for mountain ranges. Generate an initial height map, interpret medium values as your mountains, and interpret very high values as flat ground (maybe a bit over sea level, but inland plains). This will definitely give you linear ranges, as they will follow contours rather than being blobs.  So that there aren't mountain ranges around every land mass, you can merge in data from another noise map. This one won't need much detail, it should be broad and smooth low-octave perlin noise. Where this other map is low, make mountains flat, and where it is high, make the mountains high. Combine all this and you will get mountain ranges a controllable distance from the sea, but not all around the land-mass.

This could work too. I have a simplex noise generator set up, so I'll give it a shot.