LODESTAR

Showing posts tagged voxels

Origin New procedural color preview Widescreen view & better selection controls in 3D Luminosity preview Symmetry

Version 0.0.144e is live!

This week was spent adding features to the sprite editor and I’m proud to say it’s done and time to move on to the animation editor. Here are some screens and the changelog.

I have nightmares about Java layout code.

Launcher:
* Fixed Windows Aero graphical glitch

Sprite Editor:
+ Palette string tags
+ Improved selected swatch indicator
+ Widescreen view
+ Center pane now uses all available space
+ Procedural HSB palette variance
+ Improved color preview in swatch editor and swatch selector
+ Scroll wheel scrolls through slices when hovered over slice view
+ Selection tool with selection size and location modification
+ Cut / copy / paste selection
+ Undo / redo paste selection
+ Fill, paint, delete selection
+ Select all
+ Crop to selection
+ Resize sprite
+ Clear palette button
+ Symmetrical editing: paint, fill, add, erase and most selection edits
+ Hold A, W, or D and scroll to move selection in 3D view
+ Hold A, W, or D + LShift to size selection in 3D view
+ Copy / paste palette swatches
+ Luminosity value for each palette swatch
+ Luminosity preview mode in 3D view
+ Swatch edits and pastes can now be undone
+ Redo functionality
+ Grid and sprite bounds visualization in 3D view
+ Origin editing
* Fixed timer thread shutdown bug
* Fixed duplicate filename extension bug

---------------------------------------------------------------
Language     files          blank        comment           code
---------------------------------------------------------------
Java           413          11046           4183          30782
PHP            309          10275           5858          26722
CSS              6            641             68           3242
GLSL            54            407            111           1579
Javascript      14            262             89           1192
XML             10            134             14            669
HTML             3              8              0             42
DOS Batch        1              0              0              1
---------------------------------------------------------------
SUM:           810          22773          10323          64229
---------------------------------------------------------------
Amid all the work on the press kit and publicity for the Kickstarter Campaign, I managed to do a little coding. The units can now hold an item in the left and/or right hand, or neither hand, without breaking! Null checks FTW.

Amid all the work on the press kit and publicity for the Kickstarter Campaign, I managed to do a little coding. The units can now hold an item in the left and/or right hand, or neither hand, without breaking! Null checks FTW.

The particles now have light. I turned off the unit light in the video so the particle light can be plainly seen.

I decided to fiddle with the camera controls after all. :)

The camera is no longer restricted to 8 directions and can be lifted for a more top-down view. This is controlled with the mouse now, too.

Particles! Again, I know. A little more technical this time…

As you can see from the video, the particle origin is not completely in sync with the ‘real’ unit position. The effects are still snapping to the grid, but the framework is there! Don’t look at the bugs, look at the… Particles!

I used a simple system of assigning each particle an initial location and speed in x,y,z direction, gravity in x,y,z direction, and life. Some other variables are set in there too, like how much life is taken from the particle on each update (delta) and the master speed of the particle. I measure the life of a particle in milliseconds, and delta is milliseconds passed since last update. This is what my poison particle looks like:

public class ParticlePoison extends A_Particle {

  public ParticlePoison() {

    /*
     * Master speed
     */
    speed = 0.02f;
    rotSpeed = 0.01f;

    /*
     * Life
     */
    life -= rand.nextInt(1000);

    /*
     * Gravity
     */
    yg = 0.1f;
    
    /*
     * Initial speed
     */
    yi = 100;
    xi = rand.nextInt(2) - 1;
    zi = rand.nextInt(2) - 1;

    /*
     * Rotation speed
     */
    ys = rand.nextInt(30) - 15;

    /*
     * Size
     */
    float scale = 0.6f * rand.nextFloat() + 0.2f;

    /*
     * Initial position offset
     */
    float x = (rand.nextFloat() - 0.5f) * 5;
    float y = -3;
    float z = (rand.nextFloat() - 0.5f) * 5;

    /*
     * Make the entity
     */
    entity = new Entity(
      new SpatialCube(), 
      new TextureCube(
        Statics.TEXTURE_ATLAS_WHITE, 16, 16, 32, 32, 
          new int[] { 0, 0, 0, 0, 0, 0 }), 
      new Transform(x, y, z, scale));
    
    /*
     * Well, color me a particle...
     */
    entity.particle = true;
    entity.lightColor = new RGBA(
      0, 0.4f * rand.nextFloat() + 0.2f, 0, 1);
  }

  @Override
  public void _update(int delta) {
    
    float t = delta * 0.001f;
    float st = speed * t;
    
    /*
     * Update rotation
     */
    entity.transform.ry += ys * rotSpeed * t;

    /*
     * Update position
     */
    entity.transform.x += xi * st;
    entity.transform.y += yi * st;
    entity.transform.z += zi * st;

    /*
     * Update color
     */
    entity.lightColor.green -= 0.001f;

    /*
     * Update speed
     */
    xi += xg;
    yi += yg;
    zi += zg;

    /*
     * Update life
     */
    life -= delta;

    /*
     * Check life
     */
    if (life < 1) {
      active = false;
    }

  }

Emitters are attached to units on unit creation. Emitters can trigger themselves periodically or be triggered by external calls. Emitters ask the particle manager to add particles. The particle manager iterates through active particles, instructing to update and removing inactive particles. If too many particles are shown, the particle manager starts dropping requests from the emitters until there is room. I may add a priority to each particle that fades with time. Then older particles with less priority could be overwritten. However, that requires the particles to always be sorted by priority. Each type of particle can use its data to update itself in an independent fashion.

My mending particles store two colors, a start color and a finish color. Then, during the update, the mend particle slowly interpolates toward the finish color.

Also, I’m not restricted to using a cube as the entity, or visual representation, for the particle. A single quad can be used, or a pre-loaded VBO, such as a 3d sprite component.

On another topic, I spent too much time fiddling, trying to get some code to look nice on Tumblr. If you want to put code on Tumblr, I recommend this. However, wrap your code in <pre class=”prettyprint”></pre> only, skip the additional <code></code> nonsense.

I had to fix a bug in the dungeon passage code that, under fringe circumstances, would fail to connect to a room by one block. While I was in there, I changed the passage width to be dependent on length.  Short passages are one block wide, medium length passages ( > 8 ) are three blocks wide, and long passages ( > 16 ) are five blocks wide. I think it helps liven up this algorithm a bit.

Also, dungeons now have a depth, so parts of the generation and population code can determine behavior from the depth. 

I’d like to make some of the rooms more organic.

And here is a video of the two areas with the new perspective.

So&#8230; I gave in and decided to try perspective again.
What do you think?

So… I gave in and decided to try perspective again.

What do you think?

Before I work on the battle system, I needed to make a font for damage numbers and the like. I&#8217;m going to use it for titles, map names, onscreen character information, and such. Unfortunately&#8230;
Note to future self: DO NOT hardcode your system font into everything! DO NOT trust the seemingly inarguable fact that you will never use more than one font. You will.

Before I work on the battle system, I needed to make a font for damage numbers and the like. I’m going to use it for titles, map names, onscreen character information, and such. Unfortunately…

Note to future self: DO NOT hardcode your system font into everything! DO NOT trust the seemingly inarguable fact that you will never use more than one font. You will.

Again, playing with the art style. Also added randomized texture selection and rotation.

For first two shots, I made 16 stone textures that line up on all sides, randomized the rotation and selection.

For the last shot, changed up the blocky texture, with the randomized selection and rotation. Now I think I’m approaching a finalized style (3rd picture). Something in-between the dirty organic and clean blocks. Clean blocks with bits of high-contrast noise.

Feedback welcome :)