Jump to content

  • Log In with Google      Sign In   
  • Create Account

Hawkblood

Member Since 21 Jan 2013
Offline Last Active Today, 01:24 PM

#5309687 How do I detect the available video memory?

Posted by on 06 September 2016 - 10:27 AM

I compared the memory info with what DX Caps program was showing me. It turns out my program is using the on-board video card and not my NVIDIA card. I have tried to change which adapter it uses, but it keeps crashing on my "EnumOutputs()" function.




#5309682 How do I detect the available video memory?

Posted by on 06 September 2016 - 09:29 AM

That's a place to start, but I would like to have the available as the program runs; creating and destroying textures..... I do need what you showed me, but I need more.




#5309516 Spherical camera movement for planets

Posted by on 05 September 2016 - 08:14 AM

If you're only moving a camera along a planet's surface where up is ALWAYS away from the planet, then you can do it like this:

keep track of the position (D3DXVector3(x,y,z))

keep track of your camera's current matrix with no position data (CurMat)

say you want to rotate the camera : D3DXMatrixRotationYawPitchRoll(&rot,y,p,r)

 

now set up your camera's position matrix (CPM) CPM=CurMat*rot

and put in your position to CPM

 

Hope this answers your question.

 

EDIT: the multiplication order is important. it may be CPM=rot*CurMat.

be sure to store the CPM into your CurMat before adding position data.




#5297981 Voxel LOD?

Posted by on 25 June 2016 - 07:30 AM

The trouble with the trees (that's an old song :D ) is that you won't be able to make your trees using the same voxel method as your terrain. I would have trees as a separate system that doesn't go through a LOD like your terrain, but instead each tree would LOD individually on a static XZ detail. I hope that makes sense.....

 

To try to clarify what I'm saying: Each LOD further away from the center bridges multiple vertices of the adjacent higher detailed LOD. That's the problem you are describing. So don't do that with trees. Keep the spacing between trees at a constant, just make them less detailed as they become further away from the camera. This ultimately means you will need to have two maps; one for the terrain (as you already have), and the other with trees and any other objects like rocks and bushes.




#5296801 Anyone here a self-taught graphics programmer?

Posted by 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 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 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 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 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 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 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 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 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 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 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...






PARTNERS