# Feedback

We want to hear what you think!

We value your suggestions, criticism and general thoughts about what we are doing. You can give feedback in the comments below, or send mail to editor@devmag.co.za.

• http://josephknight.com JosephKnight.com

Increase your rate of publication. You have quality articles, an attractive site, but people will not become return customers or set you as their browser home page without consistent, daily or near-daily updates.

An article doesn’t have to be 5 pages long. There are incredibly vast sources of game dev content out there. We’re not looking for someone to constantly create original material, (although we do expect original concepts and fresh perspectives from at least some of the posts) what we do want is intelligent aggregation of content relative to our specific interests, with relevant commentary and the addition of helpful tips to push us forward and inspire us in our own game dev and design endeavors.

Anyone can sign up for a Google Reader account and subscribe to a series of blogs, but the format for reviewing that data is not visually stimulating and usually a bit disparate. You already have a foothold on making your content visually engaging… now we want more of that content flowing through your site.

With encouragement,
Joseph Knight
JosephKnight.com

• Dev.Mag

Hi Joseph,

Thanks for your feedback. We have been thinking about these issues quite a bit lately: length of articles, publication frequency, level of uniqueness. Can’t say yet what the future will bring, but feedback like yours will help us decide.

Thanks again!

Herman Tulleken

• Schillie

Great Website! I’m already finding many interesting and instructional articles, and I’ve only known about Dev Mag for a day or two. Thanks for consolidating all this high quality information into one place.

I hope to see more articles in the future, and I wish you luck on building your user-base!

• Dev.Mag

-Herman

• Josh S.

Your articles are very helpful. I’d like a little help with the follwing line of pseudocode in “How to Use Perlin Noise in Your Games”, generateSmoothNoise():

sample_i0 = (i / samplePeriod) * samplePeriod;

Isn’t this the same as

sample_i0 = i;

If it isn’t, could you explain why you do it this way? Perhaps it’s a part of programming in C?

And another request: for absolute beginners who can’t figure it out on their own, could you add the variable data types into the pseudocode?
As you probably guessed, my implementation of your pseudocode wasn’t very successful. I’ve been wrangling with the code for some time now, but still can’t make out what the problem is. I’m thinking that maybe there was something off-key with the aforementioned line of pseudocode.

Keep up the good work!

• Dev.Mag

Hi Josh,

You are not the first to ask that question; look at the last group of comments. It boils down to integer division that gives floored results. I have changed the text now as well. At some stage I will also put in the types; it never occured to me that this could cause confusion.

Using pseudocode for this kind of algorithm seems like it is not such a good idea; it relies on many unstated assumptions (such as variable types), and also caused errors in the transcription from actual code. Definitely a lesson for us!

Herman

• http://n/a Josh S.

My remark about the variable types, now that I think of it, seems redundant. My apologies. I thought that was one of the confusing points, but after some thought realized that it’s perfectly clear what the variable types should be.
Sorry to bother you with so much code. Here is my Java version of generateSmoothedNoise():

public static double[][] generateSmoothNoise(double[][] baseNoise, int octave, int width, int height) {
double[][] smooth = new double[width][height];
int samplePeriod = 1 << octave;
double sampleFrequency = 1.0 / samplePeriod;

for (int i = 0; i < width; i++) {
int sample_i0 = (i / samplePeriod) * samplePeriod;
int sample_i1 = (sample_i0 + samplePeriod) % width;
double horizontal_blend = (i - sample_i0) * sampleFrequency;

for (int j = 0; j < height; j++) {
int sample_j0 = (j / samplePeriod) * samplePeriod;
int sample_j1 = (sample_j0 + samplePeriod) % height;
double vertical_blend = (j - sample_j0) * sampleFrequency;
// blend the top two corners
double top = Utilities.interpolateCosine(baseNoise[sample_i0][sample_j0],
baseNoise[sample_i1][sample_j0], horizontal_blend);
// blend the bottom two corners
double bottom = Utilities.interpolateCosine(baseNoise[sample_i0][sample_j1],
baseNoise[sample_i1][sample_j1], horizontal_blend);
// final blend
smooth[i][j] = Utilities.interpolateCosine(top, bottom, vertical_blend);
}
}
return smooth;
}

I believe I translated the pseudocode accurately, but the result says the opposite. Since I can’t post an image here, please go to this website and look at the current post. In a word, the image is blocky. Not correct and blocky like the first few octaves generated by this method in your article, but with oddly shaded bottom-right corners that contrast sharply with the surrounding area. Thanks again for the help.

• Dev.Mag

Hi Josh,

I think the including the types will help make it clear that integer division is used and help illuminate the lines that confused you (and others).

Quickly looking at your code; I cannot see a problem. The cosine interpolation may be the culprit. Put in linear interpolation, and see if your interim images look better. Otherwise, there might be a problem with the pseudocode o_0.

First, test that it is not an issue with the size of the image; test the algorithm with a power-of-two image. (I see your image has 6×6 squares, if you use a power-of-two image, You should also have a power-of-two number of squares).

Second, verify that the blend variables are calculated correctly. Make the pixel colour the same as vertical_blend; each square in the image should look the same, with a downwards ramp from black to almost white.

Do the same with horizontal_blend (in this case ramps are left to right).

Third, test that the correct pixels are sampled. Make the pixel colour the left colour. You should then have an image with blocks of different shades of grey. Save the image, and repeat the experiment, but this time, make the pixle colour the right sample point. Now compare the images – they should be the same, except translated to the left (or right) by the sample_period.

If this test passes, do the same with top and bottom.

Try that, and let me know if you find the problem.

- Herman

• Josh S.

Whoa. That’s a lot of testing to do.
I’ve followed all your suggestions to the letter, and you can see the results here. The only test that (seemingly) failed is the top-bottom one. Looking at the two images from every angle, I can’t see the connection between them. Can you? Is there supposed to be one?
UPDATE: You were right about the interpolation! I changed every one to linear, and the blockiness has disappeared altogether! My only complaint is that the result doesn’t look that similar to what you got in your article. Not as clumpy. Please look here. Are the results okay?

• Josh S.

Sorry, that first link is broken. Here is the correct one.

• Josh S.

I don’t understand how changing from cosine to linear interpolation fixed the problem. Is my implementation the one at fault?

• Dev.Mag

It is most likely your implementation. Using cosine interpolation should increase the clumpiness a bit.
Is this what you are using? Below, t is horizontal_blend (or vertical_blend)

1-cos(t*pi))/2


You can further improve results by renormalising, or using a different persistence value as described in the article. I will do a follow up with some additional implementation and debugging tips inspired by your questions Thanks!

– Herman

• Josh S.

• Dev.Mag

I finally replaced the problematic pseudo-code with proper C# code. Hopefully others will find it easier to implement. -ht

• Josh S.

Definitely. Plus it looks pretty.

• http://4250games.wordpress.com Yudhanjaya Wijeratne

A few things I think would do the mag good:
a) A strong[er] eye on the indie scene, particularly international indie gaming competitions
b) Keep the mag from getting too technical – newbie game developers like me aren’t drawn to long listings of C++ code.
c) Keep some humor in it. I’m not talking of comic strips; a humorous article?
d) Showcase software which would be useful to game developers – it would be great if you paid especial attention to free stuff, like Unity and Construct.
e) Increase your page count. Yes, I know it’s not easy on you guys – but how about reviews of those indie games that you come across? We don’t need the latest AAA news; there’s Gamasutra and Joystiq for that – but more indie reviews? Yummy.

All the best!
– ALCH3MIST

• Dev.Mag

Hi Yudhanjaya,

Thank you for the precise feedback. Your points will help us make future plans. Keep well,

- Herman Tulleken

• piotr

hi there,
great mag, thank you for your work!

I suggest to add a “Home” button to your main menu to improve the site’s usability (having a link on the logo is not enough).

bye
p.