[QUOTE=neos300;31697518]Well using
float k = pow(10,floor(log(i)+1));
Makes the output numbers extremely high (4294965185, for i = 763 to 799) so I guess I'm doing
float f = p->Get(i / k, 0.5);
SetPixel(i, f * k, true);
wrong[/QUOTE]Would diving i by k when setting f, and then multiplying by k later cancel out?
Missed the log10 posts, disregard above
Complete code:
[cpp]
float k = pow(10,floor(log10(i)+1));
float f = p->Get(i / k, 0.5);
SetPixel(i, f * k, true);[/cpp]
Makes terrain, but the floats roll over when they reach 0 (I think) so they get to that high number I posted.
[QUOTE=Neo Kabuto;31697551]Would diving i by k when setting f, and then multiplying by k later cancel out?[/QUOTE]Yes.
[editline]12th August 2011[/editline]
[QUOTE=neos300;31697565]Missed the log10 posts, disregard above
Complete code:
[cpp]
float k = pow(10,floor(log10(i)+1));
float f = p->Get(i / k, 0.5);
SetPixel(i, f * k, true);[/cpp]
Makes terrain, but the floats roll over when they reach 0 (I think) so they get to that high number I posted.[/QUOTE]Don't multiply by K again, that just cancels it out
[QUOTE=Neo Kabuto;31697551]Would diving i by k when setting f, and then multiplying by k later cancel out?[/QUOTE]
The point is the perlin noise generator only takes numbers between 1.0 and 0.0 and I need to rescale it back up to put it on the screen.
But from now on, shouldn't we keep this stuff in the WDYNHW?
[QUOTE=neos300;31697590]The point is the perlin noise generator only takes numbers between 1.0 and 0.0 and I need to rescale it back up to put it on the screen.[/QUOTE]Scale it back up to a huge number? no you don't, It'll either be in the range 0-255 or 0-1
Also, if you're intending to use floats with a lot of decimals, consider doubles.
-snip-
[QUOTE=danharibo;31697603]Scale it back up to a huge number? no you don't, It'll either be in the range 0-255 or 0-1[/QUOTE]
It comes back 0-1 but I'm rendering it as 2D so I need to get the pixel positions.
<I'm a retard>
[QUOTE=neos300;31697658]It comes back 0-1 but I'm rendering it as 2D so I need to get the pixel positions.[/QUOTE]So, rather than multiplying it by the next highest power of 10, wouldn't it be better to multiply by whatever it is out of in the end (I.E. Maximum terrain height)?
Got it to work by changing f * k to f* 300 + 300 to get a value out of 600, the leftmost part of it (1 - 100 I think) isn't working but that might be the perlin noise generator.
[editline]12th August 2011[/editline]
[QUOTE=Neo Kabuto;31697693]So, rather than multiplying it by the next highest power of 10, wouldn't it be better to multiply by whatever it is out of in the end (I.E. Maximum terrain height)?[/QUOTE]
Just did that.
Now, screenshots?
[QUOTE=esalaka;31697685]Have you tried making f a constant? You might want to scale the terrain with a constant factor to the screen. That might give smoother terrain.[/QUOTE]
I'm not sure what you're getting at, f uses i (which is declared by for(int i =0 etc) to generate the perlin noise.
[editline]12th August 2011[/editline]
Anyhub hasn't been working for me lately.
[img]http://img11.imageshack.us/img11/6016/screenshotak.png[/img]
[QUOTE=neos300;31697733]I'm not sure what you're getting at, f uses i (which is declared by for(int i =0 etc) to generate the perlin noise.[/QUOTE]
I realized that, hence the snip :v:
[QUOTE=esalaka;31697765]I realized that, hence the snip :v:[/QUOTE]
Thread is moving so fast that my eyes can't keep up.
That is pretty terrain, by the way.
Now all I need to do is make it draw lines from the ground to the terrain so it looks like actual terrain.
[QUOTE=neos300;31697169]esa's method didn't work, and I'm a math noob what are a logarithms and how would I use them to solve my problem?[/QUOTE]
Logarithms are the opposite of exponentials. They grow by one for each order of magnitude.
i.e.:
log10(1) = 0
log10(10) = 1
log10(100) = 2
log10(1000) = 3
etc.
You haven't described the problem clearly enough to tell whether a non-linear scale is even useful.
Wow I am late.
[img]http://img807.imageshack.us/img807/3236/screenshotjn.png[/img]
Shit, wrong direction.
I actually like that noisy terrain to the left, I can use that as the badlands or whatever.
It's probably the lower accuracy boundary or something
[editline]13th August 2011[/editline]
precision*
With the help of Xylorast, who had the same problem as polkm, I've found a mistake in my context attributes snippet. You need to insert the value [i]WGL_CONTEXT_FLAGS_ARB[/i] before [i]WGL_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB[/i], otherwise it'll be invalid and strange things begin to happen.
[QUOTE=Overv;31698373]With the help of Xylorast, who had the same problem as polkm, I've found a mistake in my context attributes snippet. You need to insert the value [i]WGL_CONTEXT_FLAGS_ARB[/i] before [i]WGL_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB[/i], otherwise it'll be invalid and strange things begin to happen.[/QUOTE]
Like what strange and invalid things?
[QUOTE=awfa3;31698395]Like what strange and invalid things?[/QUOTE]
The function might fail, I'm making it sound more exciting than it is :v:.
[QUOTE=Overv;31698411]The function might fail, I'm making it sound more exciting than it is :v:.[/QUOTE]
Ahh ok. So whenever we have a attribute that doesn't require a value like WGL_CONTEXT_FOWARD_COMPATIBLE_BIT_ARB we have to put that before? Or just once for all of the flags
[QUOTE=awfa3;31698485]Ahh ok. So whenever we have a attribute that doesn't require a value like WGL_CONTEXT_FOWARD_COMPATIBLE_BIT_ARB we have to put that before? Or just once for all of the flags[/QUOTE]
No, as it turns out such attributes do not actually exist. There is always a identifier/value pair and all attribute arrays are ended with a [b]single zero[/b]. That's what happens when you make me work at 4 in the morning :tinfoil:.
[editline]bla[/editline]
Just have a look at changes in the context creation section.
[quote]The difference is that WGL_CONTEXT_PROFILE_MASK_ARB is only supported in OpenGL 3.2+[/quote]
So according to this, my attribute list should be:
[cpp]
int attribs[] = {
WGL_CONTEXT_MAJOR_VERSION_ARB, major,
WGL_CONTEXT_MINOR_VERSION_ARB, minor,
WGL_CONTEXT_PROFILE_MASK_ARB, WGL_CONTEXT_CORE_PROFILE_BIT_ARB,
0
};
[/cpp]
[editline]12th August 2011[/editline]
I'm running OpenGL Version 3.3
Reworded it, this is getting slightly ridiculous.
[QUOTE=Overv;31699350]Reworded it, this is getting slightly ridiculous.[/QUOTE]
Don't worry, we all appreciate it. :smile:
The people here who are using OpenGL on Windows may be disappointed because of the slight delay caused by writing the Linux context creation chapter, but compared to Windows it's hilariously easy. The functions needed to create a forward-compatible context are built in, so there's no need for any of those ridiculous dummy objects.
Sorry, you need to Log In to post a reply to this thread.
