next »

[BleakProspects]

 

[BleakProspects]

Sadly, I'm having to put development on hold for the next couple of months so that I can focus on getting through with graduate school. After that (January - August) I will have infinitely more time to work on this. We will push to get an alpha out by spring.

[emacs]

:c

Good luck with grad school!

[Swaggermuffin]

Sucks to hear, but I wouldn't want a project--no matter how promising it is--to get in the way of getting your degree.

[Pineapple]

I still love you...

[Paul Jeffries]

Oh you big tease!  Good luck with the degree, man.

[virl]

Bleak, I'm doing something similar, but for iPad:

[Pineapple]

I love you too but not half so well as bleak

[christonian]

pm when you think this is YouTube ready I would love to do a indie showcase on this

[BleakProspects]

I started up development again. In the past two days I have done the following:

• Gutted the AI system to make it multi-threaded.
• Re-implemented dwarf building in the new AI system
• Fixed lights so they go over chunk boundaries. Also made them look better.
• Added a simple "flashlight" to the players' cursor so they can see in the dark (ala Dungeon Keeper)
• Added simple biomes. These are based on moisture and heat. Heat is randomly distributed and biased north/south and with elevation. Moisture is randomly distributed. Then I have the following biomes: Desert, Grassland, Forest, Taiga, Tundra, and Jungle.
• Experimented with anti-aliasing and different filtering techniques. Unfortunately, if you use AA or texture filtering of any kind with a minecraft-style texture map, you end up with horrible texture seams and artifacts, because the shader will extrapolate into neighboring textures. So no anti-aliasing or filtering for now until I can figure out how to fix this problem.

Some Images.

Here are the new lights (they go over several chunk boundaries here).


A map of the biomes. Each color is a different biome.


A desert


Taiga


A "jungle" (jungle trees are just big pine trees for now)

[Quarry]

Where have you been!?

[Pineapple]

<3

[Schrompf]

Experimented with anti-aliasing and different filtering techniques. Unfortunately, if you use AA or texture filtering of any kind with a minecraft-style texture map, you end up with horrible texture seams and artifacts, because the shader will extrapolate into neighboring textures. So no anti-aliasing or filtering for now until I can figure out how to fix this problem.

Clamp the texture coordinate in the fragment shader before sampling the texture. Halve a texel is enough except when mipmapping.

Other than that: I love where this game is heading!

[BleakProspects]

Experimented with anti-aliasing and different filtering techniques. Unfortunately, if you use AA or texture filtering of any kind with a minecraft-style texture map, you end up with horrible texture seams and artifacts, because the shader will extrapolate into neighboring textures. So no anti-aliasing or filtering for now until I can figure out how to fix this problem.

Clamp the texture coordinate in the fragment shader before sampling the texture. Halve a texel is enough except when mipmapping.

Other than that: I love where this game is heading!

Interesting idea, but how is it possible for me to clamp to a particular *subset* of the texture (ie, the sub-rectangle representing a block) in the fragment shader? Should I calculating this on the CPU and then sending it over to the GPU? I suppose it might be able to calculate on the GPU side by inferring from the UV coords of each triangle...

EDIT: Wow, apparently this is a huge problem https://developer.nvidia.com/sites/default/files/akamai/tools/files/Texture_Atlas_Whitepaper.pdf As you say, I should be able to do it if I avoid mip-maps.

[Schrompf]

I have a texture coord clamp solution working here right now, and it really works wonders for the clean appearance of scaled/rotated sprites. It's a pretty simple idea, even though nobody seems to be using it. I wonder why.

Here's what I'm doing:

Code: (hlsl)

struct VertexInput
{
  float2 vertexPos : POSITION0; // from vertex data
  float3 targetPos : TEXCOORD0; // everything else is from instancing data
  float2 size : TEXCOORD1;
  float4 texsource : TEXCOORD2; // texture atlas area, xy topleft, zw size
  float4 colour : TEXCOORD3;
  float2 param : TEXCOORD4; // x is rotation, yz is handle position
}

struct VertexOutput
{
  float4 pos : POSITION0; 
  float4 colour : TEXCOORD2;
  float2 tex : TEXCOORD0; // texture coord
  float4 texArea: TEXCOORD1; // texture clamping area - xy topleft, zw size. We need to stay inside that to stay clear of interpolation artifacts
};

.....

// in the vertex shader, determine which scale is going to be used by dividing screen size by tex source size
float borderSize = min( inp.size.x / inp.texsource.z, inp.size.y / inp.texsource.w);
// round down to next power of two 
borderSize = exp2( floor( log2( borderSize)));
// calculate the number of texels we need to stay away from the border. For highest mipmap level,
// 0.5 texels is enough to avoid interpolation artifacts, each further mipmap level needs twice that area
// but limit it to some sensible maximum
borderSize = 0.5f / clamp( borderSize, 1.0f/16.0f, 1.0f);
outp.texArea = (inp.texsource.xyxy + float4( 0, 0, 1, 1) * inp.texsource.zwzw + float4( 1, 1, -1, -1) * borderSize) * gInverseTextureSize.xyxy;

......

// then in the fragment shader, simply clamp the texture coordinate to the calculated texture area
// so that whatever fragment we render, interpolation never takes samples from outside the source texture area into account
float2 texk = clamp( inp.tex.xy, inp.texArea.xy, rein.texArea.zw);
float4 texel = tex2D( TexDiffuse, texk);

Quickly translated from my german shader code, so it might contain errors. But it's really that simple, I really wonder why nobody else is using it. I draw tens of thousands of sprites with this, arbitrarily scaled, rotated, positioned with subpixel accuracy, and there are no interpolation artifacts visible. The downside is that you'll need to come up with a better mipmap level calculation - the one given above is obviously aimed at 2D sprites only. But I'm pretty sure you can find some calculation that safely overestimates the mipmap level, especially when you're not bound to DX9 shaders like I am currently.

For starters, you can simply leave out the mipmap level calculation and use a fixed 0.5 texel offset from the border. That way you should be able to use at least bilinear filter and/or AntiAliasing. MipMapping will still come up with artifacts, though.

[BleakProspects]

Of course, what a great idea! Got AA working now:

[BleakProspects]

Mining a home in a snowcapped mountain:


I've been working on performance a bit, and have been making the way I generate chunks/biomes more streamlined by defining a biome in a data structure (previously I just had horrible switch statements and hardcoded values everywhere).

[Impmaster]

You are now my idol.


Just wondering a few things.

How long have you been coding in general?

Are you making your own engine?

What platforms will this be available upon?

What language does it use?

How much money will you accept from us?

[Ninja Derpify]

Oh man, I am very excited about this! 

[BleakProspects]

How long have you been coding in general?

In general, I think it's been 7 years. This language, like 4 years. This project, since June or July.

Are you making your own engine?

Aside from it being in XNA, yes. I started with a spinning cube. After the first day, it looked like this. I was following this tutorial by the guy who made Vox.

What platforms will this be available upon?

Windows only for now. It might be possible to port to XBOX later but this game would not work well on that platform. Mobile or Mac is also unlikely without some extreme work (I would probably end up porting it to Unity, which might be a headache.).

What language does it use?

C#. HLSL shaders. XML data files.

How much money will you accept from us?

I haven't started talking about funding yet. When the game is actually a game and rather than a toy I will probably release a small alpha for $1 and use the alpha-fund model. The game will gradually increase in price as it grows more complex. Of course, I could always accept donations The project is a hobby (I have a day job).