Hi! I'm going to talk of what I've progressed so far, blurring, rivers, some infrastructure for tool switching and a little splash screen

[font='comic sans ms']Now With Splash Screen[/font]

In my last entry I talked about how the new GUI was going, had ridges up and running, plus the binding from the UI parameters to the actual terrain parameters.

Now I will talk on what I've progressed so far, blurring, rivers, some infrastructure for tool switching and a little splash screen

[font='comic sans ms']Splashin'[/font]

Pretty sweet splash image right? Well no, but you get the idea The circle thing actually draws each piece one by one to complete the full circle again and again until the main window is loaded, like every cool loading circle thingy that is so cool these days.

Main thread creates a SplashThread that does the splash frame instancing and drawing, while the Swing Event Queue executes the runnable that instantiates the main window, passing to it the SplashThread. Once the main window is instantiated (not visible yet), the runnable signals the stop to the SplashThread, which closes the splash frame and the main window gets set as visible.

This one is made out of an AWT Frame and an AWT Label, I choose those since they take slightly less to load up, and since the splash screen is the first thing that you should see, it should load fast.

I discovered that Java has an actual API to do these splash screens, loads up a .gif/jpg/etc even before the VM that executes your .jar starts, but I haven't used that, I'll will in the future.

[font='comic sans ms']And there was rivers[/font]

I got river generation working! Yay! That means that I grabbed the old river generator and made a new one that functioned better with "one at a time" river generation.

River generation is in the same precarious state as before, they can hang the whole program since the condition for them to finis his to reach 0.0f height, and since they don't write their heights modifiers until they're finished, they can get stuck and hang everything.

I added parametric "turbulence" so you can actually say how much your rivers randomly vary in direction in spite of the landscape.

[font='comic sans ms']Debug view[/font]

Prolly the most useful feature is the "DebugImagePanel". For displaying the heightmap I had a class that inherited from JPanel but draw itself from a BufferedImage.

Bad thing is that height values are only one part of the whole thing, there is also the state map, direction map, and I could make use of an non colored heightmap view.

So I implemented the debug panel that can draw four images on itself, thus allowing me to view when exactly everything changes (because I can't remember all the stuff I did, when or where).

Upper left is raw heightmap, upper right is a colored heightmap, lower right is the state map (white is NULL, blue RIVER, brown RIDGE) and lower left is the direction map, which is used so the river particles know where to go at each position.

There is no "strength" for the river direction, that means that all height differences are equal. I could probably work out some "direction strength" coefficient so the directions aren't as plain.

[font='comic sans ms']

Tool madness

[/font]

Now, the issue I'm having right now is that I need to come up with some abstraction for the tools. See, when you switch from ridge to river, there is a bunch of state changes that go around.

You have to grab the blur bean, blur the selected map with its parameters, generate the direction map, and let the user draw what they want. But what happens if the user goes back to ridge tool? Then you have to discard blurred heights, re initializing all heights to 0 and re write the existing ridges to the map.

Worse, what happens if you undo a river? You have to zero everything, write ridges, blur them, create the direction map then draw the rivers again. Madness!

I have to come up with some abstraction for what it is a tool, besides the Listeners and parameter JPanels they use.

[font='comic sans ms']Moar dependencies[/font]

The only good thing of all of that is that by chance the way I designed the generators lends itself to the undoing of particles. I just have to grab the particle collection, remove the last one, and that's it. Particles contain every position they touch so by deleting particles I delete all their effects. That doesn't means that they're removed from the heightmap, generators receive a map as a parameter so they cant grab a map and undo their changes.

Moreover, if only the generators know what changes are going to be made (river carving, position state, etc), how are they going to back up what they did? They can't know every single map they have touched.

My idea is to create some sort of undo system that grabs a generator, a map and saves up every single thing that could be touched. I don't want to couple generators or maps with undo actions since they're pretty much an GUI tool.

[font='comic sans ms']El Fin[/font]

So that's it for now, I'll see what can I do about the tools and undo operations, bye!