Jump to content

  • Log In with Google      Sign In   
  • Create Account

Hawkblood

Member Since 21 Jan 2013
Offline Last Active Jun 26 2016 01:57 PM

#5296801 Anyone here a self-taught graphics programmer?

Posted by Hawkblood on 16 June 2016 - 06:49 AM

I have no formal training AT ALL. I started in the mid 80's with my first computer, a Tandy1000, but NO GAMES. A friend of the family came by to help set it up and showed me a bouncing ball program in basic. I was mesmerized by its simplicity-- just a few commands and I could get this ball to bounce around the screen! So I got books and taught myself how to program in basic. I made a few simple games-- Take that Dad! I quickly realized my games were becoming too advanced for basic to handle, so I asked someone about other languages. He suggested assembly. So I got a book and started using debug to write programs. If you have never used debug to write programs, count yourself lucky; it's a NIGHTMARE! Finally someone introduced me to an .asm compiler and I wrote code from there. Somewhere in the 90's another friend suggested I start using C++ and DirectX. I tried it out and it stuck ever since.

 

I wish I could say I work for some game studio, but sadly no. I suppose it's a combination of bad timing and lack of education. I was born in an era before personal computers or the internet. So, without the vast amounts of free information on the internet and no formal training, I struggled to get the information I needed.

 

I joined the military after high school. Now I have kids, so following my dream kind of went to back burner. Now I work in the oilfield and don't really have time to sit down and do any serious programming.

 

I would like to know how some of you landed your game programming job........




#5295509 how to make game with directx,opengl

Posted by Hawkblood on 07 June 2016 - 09:42 AM

The short and sweet answer to you question "why make engine using DX/OGL" is that you can make it VERY specific to what you want. Someone else's engine may have everything you need, but will likely have a lot of things you don't need just sitting there taking up space. Others may not even have what you need...... That's why I prefer to make my own.




#5293235 what good are cores?

Posted by Hawkblood on 24 May 2016 - 11:20 AM

Hodgman:

I'm currently creating the texture and map(ing) it in the main thread, then executing another thread that has a pointer to the mapped data and manipulating it there. Then when the thread tells my program it is done, the main thread unmaps the texture and I can use it in my render.

 

This method works fine, but there is still a slight dip in fps. If I could do everything in another thread and then tell the main thread when it can use the texture, then there should be no noticeable dip in fps (theoretically). I've spent the last two hours (nearly) looking up how to do this. The methods I came up with all failed except one, and that one is ugly and produces even more of a dip in fps than my original one. It also causes my screen to blink during the update!

 

I would love to see an example of how it is done. Even pseudo-code would be great.




#5293123 Mapping a loaded resource fails

Posted by Hawkblood on 23 May 2016 - 04:47 PM

E_INVALIDARG

 

That doesn't help...... It has something to do with the way DX11 does resources.

Here is what I'm wanting to do:

 

-load a texture from the disk

-make a "collision map" by sampling the alpha channel.

 

I'm using the texture as a sprite for purposes of a GUI. I don't want to have to deal with only rectangular buttons so I need a collision map for the mouse.




#5291342 when to use concurrency in video games

Posted by Hawkblood on 12 May 2016 - 04:26 PM

The things I use multithreading for is whatever takes a lot of processor time and I don't want the player to wait on it. My current project is a space sim that the player can go between stars and visit planets. I don't want a "load screen" that the player has to wait on so I can generate the planet textures. I use it for other things, but that's the big one.

 

If all you are doing with your threading is AI, then it shouldn't be a problem. Most systems will have at least a dual core processor now unless it's "grandma's internets computer for the face books"..... (sorry to offend anyone if they roll like that)

 

The problem with multithreading is knowing how to do it. Whenever you have a thread manipulating a variable or data structure, it makes them unavailable to other threads unless you declare it with "volatile".

 

I looked up this guy to learn how .

 

 

Multithreading is a powerful tool, but it's easy to lock up your code if you do it wrong.




#5290192 Getting the Direction using Slerp

Posted by Hawkblood on 04 May 2016 - 09:36 PM

I am assuming you are doing some kind of flight...... I rotate using a quaternion and then get the look-at using:

	D3DXQuaternionNormalize(&rotQuat, &rotQuat);
    D3DXMatrixRotationQuaternion(&m_viewMatrix, &rotQuat);
    m_viewMatrix(3,0) =0;
    m_viewMatrix(3,1) =0;
    m_viewMatrix(3,2) =0;
	D3DXMatrixInverse(&m_RotationMatrix,0,&m_viewMatrix);//for space flight 

	D3DXVec3TransformCoord(&m_LookAt,&D3DXVECTOR3(0,0,1),&m_RotationMatrix);

As you can see, I use z+ as my origin direction......

 

This method has always worked for me.




#5290191 Call a procedure with pointer as argument

Posted by Hawkblood on 04 May 2016 - 09:27 PM

You have to declare the item before you reference it. I'm not sure about the rest of your code, but you should have something like this:

sInven_Set MySword;
........
........ whatever code.....

//call the "addweapon" function
AddWeapon(&MySword);//this is a reference for "MySword" which is of data type "sInven_Set"

When you actually want to have a variable that holds info, you will have to initialize it. And then if you want to send it a pointer to it within a function, you use "&" to reference it. Your function declaration will look the same as you have it above, but when you call it you will use an actual initialized object's reference.

 

Please give more code if I'm in error about how you are calling the function......




#5290188 Procedural Universe: The illusion of infinity

Posted by Hawkblood on 04 May 2016 - 09:11 PM

Wow. There's a lot of talk about how it can't be done.

 

From Earth, most people (including me) can't discern each star in the galaxy or MOST stars for that matter. You only need a general shape of the galaxy and use some form of noise to generate stars within a discernible distance. This may still be a lot to handle for most machines, but it can be done.

 

I do think the octree idea may not be needed, but the idea of dividing the massive amount of space in the universe is the idea. You will, of course, have to decide on the universe's size and go from there. If you are trying to actually simulate the known universe, that's a tall order. If you just want to generate a random universe, then use perlin noise. Make a "universe scale" noise that just worries about where and what type of galaxies are in the universe. Then make a "galactic scale" noise to govern each galaxy-- this will be more involved as galaxies have varying shapes and sizes, but it can be done. Then you will need some process to create each solar system (only when within range of it)-- this will be even more detailed in that there are huge numbers of variables for planets and asteroid belts. Each planet will have a unique set of textures (use a cube-sphere) http://acko.net/blog/making-worlds-1-of-spheres-and-cubes/

This shows you the basics of making a cube-sphere with 6 textures to create beautiful looking planets and moons.

 

More specifics:

-use 3D perlin noise (or simplex noise) to generate galaxy "types" and space between galaxies. The actual scale doesn't matter here. Once they are created, you simply use the 3D cube space and densities and multiply by some super astronomical number to get your distances right-- play with it until you get something you like.

-use 3D representations of the different types of galaxies when viewing from a distance and grow in detail as you get closer. This will take some trial and error to get them to look decent.

-Once close enough to a galaxy, you will need more 3D noise to generate the "near" stars. This may take a lot of horsepower to do, but I have been able to show 30,000 stars using instancing on my GPU with great success. I'm sure I could do near 100,000 or even 1,000,000 without too much lag-- this has not been tried..... Most of the stars you see in the night sky are within that 30,000 that I am showing in my game.

-When close enough to a star to start seeing planets, you can generate the planets for that star. This is also complex. The way I do it is I start nearest the star and randomly generate a planet orbit and decide what type of planet it is (and its size) and I go to the next planet. Once I generate all the main planets, I go through each one and generate the moons according to its mass-- more massive planets will likely have more moons than less massive ones (duh). Once all the planets and all the moons are "typed", then I send information to my texture generator to make each planet's/moon's textures on an individual basis. I use multithreading to accomplish this to keep the game moving while I do textures. https://youtu.be/LL8wkskDlbs this is where I learned how. Be careful when multithreading! You can't access directx outside the main thread, so you will have to create all 6 textures, lock each one and send the texture process a pointer to each of them. When the texture process is complete, unlock the textures and they are ready to render.

 

-- have fun an program on!




#5289627 Procedural Universe: The illusion of infinity

Posted by Hawkblood on 01 May 2016 - 03:52 PM

I've had some of the same aspirations. The problem is scale. I came up with a different vector system than the D3D vector. I use __int64 paired with a float. I have posted examples somewhere on this forum .... or was it another forum? Anyway, the idea is to use the __int64 as the top level of the vector and the float as the lower precision (0.0f-1000.0f). This will allow you to have 2^64 km worth of distance. You would have to write your own operators of course, but that's not a problem. Once everything (from galaxy size down to planet size and even further) is using this coordinate system, you can make a relative vector to the camera and render using D3D as normal. You WILL have to use scaling methods to show everything correctly....

 

This is a link to one of my posts:

http://www.gamedev.net/topic/649931-progress-on-my-current-game-no-name-yet/

 

I'm at work right now, so I'm not sure it's what I think it is.....

 

In general, I have a small number of stars around Sol (30,000) that can be explored. The only "transition" that I will have is traveling between star. This is not because the coordinate system can't handle the size, it simply gives me time to generate the textures (procedurally) for the solar system the player is traveling to. I have since that post been converting everything to DX11.

 

Your "universe model" sounds like a good way to go. There is no limit to how large your coordinate system is. You can make a __int64,__int64,float system that would give you 2^128km scale--that's freak'n HUGE! That would give you a distance of 3.6x10^20 of our galaxy side-by-side in each direction. If you did it further, you can't even imagine the scale.

 

Using your method, each "intergalactic space" could be the top __int64 and within the "interstellar space" would be the rest...... Man, that's not a bad idea you have.




#5156983 Why does game GUI have to be rectangles?

Posted by Hawkblood on 30 May 2014 - 10:27 AM

Locking even a single bitmap each frame can cost you precious ticks. Your button will be an image of the button with transparency values. Lock it once when you load it, check the alpha of each pixil, and set an array of bytes (same diminsions as the image) to either 0 or 1, then use that array as a check for "is it on the button"......


#5151006 Planet sized terrain method

Posted by Hawkblood on 02 May 2014 - 04:31 PM

I am wanting to generate a planet's terrain. I want the detail to increase as the viewer approaches the surface. Here is a video showing it in action: (this is not mine, it's just an example)

The rough idea is to have 6 surfaces (cube faces) that will be "spherefied" once the detail level and the height map is applied. This will make a planet-shaped mesh with a rough surface. Each of the face of the cube is a separate quadtree object that uses the "distance" from the center (camera) to determine what detail level each chunk of the quadtree is at.

This works fine on approach, but I have a maximum level of detail that I can't get past. I'm using Perlin noise to generate the surface features, but it seems very plain until I get around 10 levels of detail. At 10 and higher, the noise starts to become lines like rows of plants in a garden. Here is an image:
Untitled.png

I'm really not sure where to start to correct this. I think there is a limitation to Perlin noise that is causing this. It may be the use of floats causing this or it could be the sample size..... Don't know.

If this limitation exists, I think I might have to come up with a way to generate greater detail using a trick I've been thinking about.....

I don't want to waste too much time on this because I want to get back to the meat of my game. I put this part of it off as long as I can...




#5149227 DX11 Hardware Voxel Terrain (your opinion)

Posted by Hawkblood on 24 April 2014 - 03:41 PM

Wow. What a mess of a file. When I clicked the link for the "lookup tables" it came out as a hot mess. Here is a more coherent format:TransVoxel.txt

 

EDIT: I originally placed it in a code fragment, but the page takes forever to load that way. So I uploaded it as a .txt file.

 

[Mod edit] The copyright holder of that file just asked for us to remove it, saying you don't have permission to be redistrubuting it




#5148376 DX11 instancing. Help.

Posted by Hawkblood on 20 April 2014 - 11:08 AM

As it happens (and it happens more than I would like), I posted something JUST BEFORE the solution presented itself.

 

The SemanticIndex for the second instanced description should have been set to 2.......




#5146609 Tips for Programming a GUI

Posted by Hawkblood on 12 April 2014 - 06:56 PM

I've made a few GUIs before. It can get tricky and time consuming. Break down the GUI into the simplest components you need to accommodate your program.

-button

-list

-textbox

-dropdown

-tabmenu

 

These are the basic ones I use. I also have "menu groups" which are like their own window and contain the menu items listed above (as needed). Each of these items you need to be able to reference in your program so that they can "do something".

 

If it's at all possible, you should try to find a third party GUI. If you are set on doing it yourself, I can help you if you want.




#5146569 DX11 HLSL help, please.

Posted by Hawkblood on 12 April 2014 - 02:33 PM

I finally figured out the specular problem. Here is the shader:

vs:

/////////////
// GLOBALS //
/////////////
cbuffer MatrixBuffer
{
    matrix worldMatrix;
    matrix viewMatrix;
    matrix projectionMatrix;
};


//////////////
// TYPEDEFS //
//////////////
struct VertexInputType
{
    float4 position : POSITION;
    float2 tex : TEXCOORD0;
    float3 normal : NORMAL;
    float3 tangent : TANGENT;
    float3 binormal : BINORMAL;
};

struct PixelInputType
{
    float4 position : SV_POSITION;
    float2 tex : TEXCOORD0;
    float3 normal : NORMAL;
    float3 tangent : TANGENT;
    float3 binormal : BINORMAL;
	float3 worldPos : TEXCOORD1;
	float3 cdir : TEXCOORD2;
};


////////////////////////////////////////////////////////////////////////////////
// Vertex Shader
////////////////////////////////////////////////////////////////////////////////
PixelInputType BumpMapVertexShader(VertexInputType input)
{
    PixelInputType output;
    

    // Change the position vector to be 4 units for proper matrix calculations.
    input.position.w = 1.0f;

    // Calculate the position of the vertex against the world, view, and projection matrices.
    output.position = mul(input.position, worldMatrix);
	output.worldPos=output.position;
    output.position = mul(output.position, viewMatrix);
    output.position = mul(output.position, projectionMatrix);
    
    // Store the texture coordinates for the pixel shader.
    output.tex = input.tex;
    
    // Calculate the normal vector against the world matrix only and then normalize the final value.
    output.normal = mul(input.normal, (float3x3)worldMatrix);
    output.normal = normalize(output.normal);


    // Calculate the tangent vector against the world matrix only and then normalize the final value.
    output.tangent = mul(input.tangent, (float3x3)worldMatrix);
    output.tangent = normalize(output.tangent);

    // Calculate the binormal vector against the world matrix only and then normalize the final value.
    output.binormal = mul(input.binormal, (float3x3)worldMatrix);
    output.binormal = normalize(output.binormal);

	output.cdir=normalize(-output.worldPos);

    return output;
}


ps:

/////////////
// GLOBALS //
/////////////


Texture2D shaderTextures[2];
SamplerState SampleType;


cbuffer LightBuffer
{
	float4 Ambient;
	float4 NumberOfLights;
	float4 PLPos[8];
	float4 PLColor[8];
	float4 PLRange[8];
	float4 DLightColor;
	float4 DLightDir;
	float4 SLPos[8];
	float4 SLDir[8];
	float4 SLColor[8];
	float4 SLData[8];//icone==.x, ocone==.y, range==.z
};


//////////////
// TYPEDEFS //
//////////////
struct PixelInputType
{
    float4 position : SV_POSITION;
    float2 tex : TEXCOORD0;
    float3 normal : NORMAL;
    float3 tangent : TANGENT;
    float3 binormal : BINORMAL;
	float3 worldPos : TEXCOORD1;
	float3 cdir : TEXCOORD2;
};

////////////////////////////////////////////////////////////////////////////////
// Pixel Shader
////////////////////////////////////////////////////////////////////////////////
float4 BumpMapPixelShader(PixelInputType input) : SV_TARGET
{
    float4 textureColor;
    float4 bumpMap;
    float3 bumpNormal;
    float3 lightDir;
    float4 color=float4(0,0,0,0);
	float3 viewDirection;

    // Sample the texture pixel at this location.
    textureColor = shaderTextures[0].Sample(SampleType, input.tex);
	
    // Sample the pixel in the bump map.
    bumpMap = shaderTextures[1].Sample(SampleType, input.tex);

    // Expand the range of the normal value from (0, +1) to (-1, +1).
    bumpMap = (bumpMap * 2.0f) - 1.0f;

    // Calculate the normal from the data in the bump map.
    bumpNormal = (bumpMap.x * input.tangent) + (bumpMap.y * input.binormal) + (bumpMap.z * input.normal);
    // Normalize the resulting bump normal.
    bumpNormal = normalize(bumpNormal);


	float3 h,l;
	float nDotH,nDotL,power;
	{[branch]
		if (NumberOfLights.x>0){//directional

			l=-DLightDir.xyz;
			nDotL = saturate(dot(bumpNormal, l));
			h = normalize(l + input.cdir);
        
			nDotH = saturate(dot(bumpNormal, h));
			power = (nDotL == 0.0f) ? 0.0f : pow(nDotH, 256.0f);
        
			color += DLightColor*(nDotL+power);

		}
	}
	{[loop]
		for (int i=0;i<NumberOfLights.y;i++){//point lights

			l=PLPos[i].xyz-input.worldPos;//use this for distance calc
			{[branch]
				if (length(l)<PLRange[i].x*1.25f){
					lightDir=l/PLRange[i].x;
					l=normalize(l);
					float atten=saturate(1.0f-dot(lightDir,lightDir));

					h = normalize(l+input.cdir);
					nDotL = saturate(dot(bumpNormal, l));
					nDotH = saturate(dot(bumpNormal, h));
					power = (nDotL == 0.0f) ? 0.0f : pow(nDotH, 16.0f);
					color += (PLColor[i]*(nDotL+power)) * atten;
				}
			}
		}
	}
	{[loop]
		for (int i=0;i<NumberOfLights.z;i++){//spot lights
			l = (SLPos[i].xyz - input.worldPos);
			{[branch]
				if (length(l)<SLData[i].z*1.25f){
					l /= SLData[i].z;
					float atten = saturate(1.0f - dot(l, l));
					l = normalize(l);
					float2 cosAngles = cos(float2(SLData[i].y, SLData[i].x) * 0.5f);
					float3 dl=SLDir[i];//SLDir[i] should ALWAYS be normalized on input
					float spotDot = dot(-l, dl);
					float spotEffect = smoothstep(cosAngles[0], cosAngles[1], spotDot);
    
					atten *= spotEffect;

					h = normalize(l + input.cdir);
        
					nDotL = saturate(dot(bumpNormal, l));

					nDotH = saturate(dot(bumpNormal, h));
					power = (nDotL == 0.0f) ? 0.0f : pow(nDotH, 256.0f);
        
					color += (SLColor[i]*(nDotL+power)) * atten;
				}
			}
		}
	}
    // Combine the final bump light color and ambient with the texture color.
    color = saturate(color+Ambient) * textureColor;

	
    return color;
}


The specular power is hard coded but it should be done as an input variable...... That shouldn't be a problem.






PARTNERS