Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

360 Neutral

About EvilDecl81

  • Rank
  1. Quote:Original post by ehmdjii hello, i was looking at the textures of some modern games and i noticed that most of them use textures of quadratic size. so i was wondering if there is any paritcular reason for this. memory-wise it shouldnt make a difference, since a 64 by 64 texture takes up the same amount than 32 by 128, right? also, most textures are no larger than 256 by 256. is performance getting bad at larger sizes? There should be virtually no difference between square and rectangular textures, except for any access pattern differences which result. The most important thing for texture performance is to always have a MIP chain, try to keep accesses of adajacen pixels local, and keep randomly accessed textures smaller. Keeping power of 2 dimensions is a good idea for most textures, because these can be swizzled and get much better cache behavoir then non-pow-2 textures.
  2. EvilDecl81

    HLSL PS loop and indexing

    Quote:Original post by NouseHLSL Hi, I'm trying to make per-pixel lighting in HLSL with pixel shader 3.0, but my code refuse to compile. I use DirectX 9 (April 2006) and I have a Geforce 6800GT. Here is part of my pixel shader: float4 kDLightDir[3] : register(c3); float4 kDLightAmbient : register(c6); float4 kDLightDiffuse[3] : register(c7); float4 kDLightSpecular[3] : register(c10); int4 kiNbDirLight : register(i0); for ( int i = 0; i < kiNbDirLight.x; i++ ) { float LdotN = dot(kDLightDir, inNormal); Diffuse += saturate(kDLightDiffuse * LdotN); } It gives me this error: "error X4556: Error: invalid register 'i0' in register binding." If I remplace the 2 constants I'm indexing in the loop, kDLightDir and kDLightDiffuse, by kDLightDir[0], and kDLightDiffuse[0] It compiles alright. Is constant indexing supported in pixel shader 3.0? I checked on google and I saw it is. I'm clueless, can somebody helps me? Thank No, you can't index constants in ps_3_0. you can only index t registers, looping is basically useless in pixel shaders.
  3. EvilDecl81

    What makes a melody a melody?

    Quote:Original post by Lode Some combinations of notes sound like a melody to us, others would sound like random series of notes that aren't music at all. Are there any rules, that describe why some combinations of notes sound like music and some not? Is there a cultural connection, could the right culture find ANY random combination of notes music? Or are there certain rules even for any culture that say that something could be music and something not. I don't seem to be able to find such rules, but still my brain has to know them, because it can tell what is music and what not... One thing I see is that in a lot (but not all) cases music is somewhat binary: exactly 4, 8 or 16 repititions of something sounds right, a time less or more would sound weird. Yes, there are tons and tons of 'rules' which define a melody. These vary heavily depending on the particular music style, but contemporary music theory (My music teacher called it "Jazz/Pop harmony" for lack of a better term) is extremely rich and supersets alot of clasical theory. In general, melodies are less structured then harmonies, but in all cultures there are fundementals dealing with the geometric nature of notes. There is natural progression of intervals which sound good, e.g. harmonic disonance, 5ths and 4ths at one end, to minor seconds and major 7ths at the other. Modern music uses a huge range of dissosance to accheive effect. This wasn't always the case, Classical music avoids it for the most part, and eastern music uses a 5 note scale to avoid tritones and 7ths. However, the amount of 'tools' availabe for a modern musican takes a lifetime to master. Culturally, once your used to certain types of chord progressions, music starts to build on that vocabulary, things like extended II/Vs are playing with what you are used to hearing. Occasionally you'll get some really awesome eary songs which mess with your head by twising what you are used to hearing - The star wars empiral march - using tritones and minor keys, or Led Zeppelins 'Kashmir' which used 4/4 time on the drums and 3/4 for the guitar and a different chord structure.
  4. Quote:Original post by fpsgamer Same question as the title: Is it still considered good practice to do vertex operations on the CPU when rendering terrain? Because this seems like a perfect job for a vertex shader -- which I imagine would be much faster. All three major terrain algos focus on the CPU (geomipmapping, quadtree, roam). You should almost never do vertex calculations on the CPU, it is almost always faster to use the GPU for this. Modern terrain rendering software algorithims are all centered around memory efficency, not vertex balancing - basically, methods for 'decompressing' the terrain as it comes into view. While I can't go into the specifics, most of our terrain tech is centered around texture composting techniques so we can have huge terrains that don't use alot of memory and are easily created by artists. The vertex/triangle count isn't an issue, except for data size. Many terrains are based on virtual textureing techniques, with 'infinite' textureing systems. Personally, these work allright but means it takes alot of time to make the terrain from the artist standpoint.
  5. Quote:Original post by fortia Hi! I've heard that you should be careful with the dynamic branching that can be done in SM3 pixel shaders. But to what extent? What happens in the pipeline when you put in if statements in the shader code? Naturally there will be a disturbance in the coherence if different pixels processed at the same time follow different paths, but exactly HOW does this affect efficiency? And if I where to write something like this: if(condition) result = float4(1,1,1,1); else result = float4(0,1,0,1); Would this disturb the coherence? My intuition tells me that because the two assignments here should take equal time to complete, the shaders would be running the rest of the code (after the if thingy) in parallell again. Is this right? Thanx This is a complex question to answer. First, your exampl isn't a good one because in such a simple situation its faster to evaluate both sides of the branch then to use flow control (the compiler will choose for you), but I'll talk about the case where you actually have heafty work. In the new HLSL compiler, you can actually micro-manage what the compiler does becuase of the coherence issue (Because the choice depends on coherence expectations), you can do this by saying [branch] or [flatten] in front of the if statement. Part1) Because Pixel shaders run in 2x2 groups minimum (often much bigger), and in lockstep (instruction pointer must be at the same place), you always pay the max cost of any pixel shader. This means if one pixel goes down path a, and the other goes down path b, you pay the cost a+b on all shaders. You gain something only when the shaders all go down the same path. The level of coherence depends on the hardware, although I would expect finer granulartiy in the future then we have today. The same is true for loops - you pay the cost of the the shader with the biggest loop. Part2) GPU's have a extremely different model for hiding latency then CPUs. Where CPU's use out-of-order instruction execution and rely on huge caches, GPU's take an opposite approach: The cache's are tiny (around 32k range), and everytime a memory access occurs, the pixel goes to sleep if the data isn't there, and the GPU goes on to another pixel. Though you'll never pry the exact number from nvidia or ATI, the number of pixels suspended and executing at any point of time is _vast_, in the hundreds, and likely thousands on newer cards. How does this effect you? When a pixel shader goes to sleep it has to save off all the current state, which amounts of the registers it is currently using. This means that a pixel shaders performance can be heavily dependent on the number of values in flight, or the number of registers used. The GPU has a giant register profile (instead of a cache), already in the half mb range for size (it's there cache). The more registers you use in a pixel shader, the less pixels can be in flight, and the more likley the GPU is to stall when a memory access (texture read) happens. Again, how does this affect branching? if you have two branches a and b then your potential register load is the MAX of the two branches, thus you can easily blow your register load out on a shader by branching and then start hitting memory stalls because the GPU can no longer swap enough pixels out. Conclusion: You have to simply expirment with the correct level of dynamic branching. It is highly dependent on the content, and the hardware running on. A small number of instructions hidden in a branch statement won't buy you much, so its more useful when you have giant chunks of code. I hope this helps.
  6. EvilDecl81

    PS3 European launch delayed till March

    Quote:Original post by Will F Hmm... The Associated Press is reporting that there will be 400,000 units at launch in North America, and 100,000 units in Japan - not particularly great news for Sony. Bad news for the whole game industry, already recovering from last year's sketchy x360 launch (the shortages). Many products were made with Sony's promise of 4 million units by end year, and it looks to be even worse then MS's launch... Sony's not going to have too many friends right about now.
  7. EvilDecl81

    Multisampling takes a hit

    Quote:Original post by blaze02 I recently went to antialiasing my meshes with the cheapest multisampling I could (because thats all my card supported). When my friend runs the game, it slows to a creep. In fact, I'd bet I could render the game twice as large and supersample it myself quite a bit faster. The framerate drops from 60 to 1 simply because of multisampling. He's using a Radeon 9800 XT with 256Mb. I'm using multisample_2_samples with 0 quality levels. That is the minimum amount of multisampling, right? Any ideas why his computer would crawl with this enabled? Thanks for any insight. Certainly not what I've seen with MSAA, in fact with our current title it doesn't make a huge perf difference to turn on or off because we aren't back-buffer fill limited. Worst case it would be 2x slower, because you are doubling your rendering. My guess is you have something nauty, like reading the texture back out again (the MSAA resolve happens to the screen, so you can't access the backbuffer)
  8. EvilDecl81

    Shadow Maps and Directional Lights

    Quote:Original post by Eric Friedman Hello all, I have a question regarding shadow maps and directional lights: I am using Direct3D for graphics rendering and I am using shadow maps for my choice of shadows. For a large outdoor scene, I am lighting everything with a single directional light ( the sun ). The algorithm for shadow mapping is to project all of the items into light space, which requires a position; however, as we know, directional lights do not have a position. I am looking for a solution to this problem without hitting the advanced topics such as perspective shadow maps. (I have read them time and time again and they are currently too advanced for me right now) On this topic here: http://www.gamedev.net/community/forums/topic.asp?topic_id=380865&forum_id=12&gforum_id=0 a suggestion is made to transform the frustum into light space, but yet again, how do we make the light matrix without a position and a place to point at? I assume we are going to need more than just the matrix that D3DXMatrixOrthoLH can produce? (This takes in a width, height, near and far plane distance to build a projection matrix) Any help would be greatly appreciated. Thank you -Eric EDIT: I have been reading around and people have mentioned that cascaded shadow maps are easier than PSMs; however I have not been able to find any papers or easy to understand algorithms for this. Any help or links to this topic would also be very useful. Thank you. What we do is create a ortho projection which is big enough to encompose anything currently visible on the screen. this works fairly well on an overhead camera type game, with the caveat being you'll want to lock ortho matrices so you don't see popping every frame.
  9. Quote:Original post by Nairou I've been trying to work out in my head the right usage arrangement for vertex buffers (i.e. one big buffer, multiple specialized buffers, vertex format conflicts, etc.). I turned back to Yann's Material/Shader thread, since this sounded similar, and if I'm reading his posts right, he seems to be creating a separate vertex buffer for each shader program, allowing the shader to specify the vertex format it needs and letting it do it's own buffer filling. Now... am I reading that right? Let's say the system has 50 different shaders in effect, creating a multitude of different materials in the visible world. Does that mean it would be switching between and individually rendering 50 different vertex buffers? Maybe this isn't really as extreme as it sounds to me, but I'd really like to know from anyone who has read the thread or is familiar with this sort of rendering whether I've got this right. Everything I've read so far talks about using just a single vertex buffer, and how expensive vertex buffer switches are. As exciting as the shader method looks, I want to make sure I'm headed in the right direction! I wouldn't over think things too much. Try to minimze the number of vertex format changes you have, and the number of times you change a shader. Both of these are very expensive to change. Changing a stream is usually less expensive then changing the format of the stream (depending on the hardware).
  10. Quote:Original post by ET3D Quote:Original post by Demirug We will see games that use both APIs very soon and for a long time. Even the biggest company could not life from the hardcore gamer market only. My guess is that "for a long time" will be about 2 years. So basically if you're starting to write a PC-only commercial game now, DX10 is a good enough bet. If you are going to deliver a product then that isn't sufficent, but platforms are rarely the sole perview of the Graphics Lead, this is deciced by the suits ;) At any rate, it's not too bad to make a cross-renderer for ps_3_0 class hardware and DX10, basically you treat DX9 as if it were DX10 (you actually get quite good perf this way, oddly). This is what we are doing.
  11. Quote:Original post by skyfire360 Heya! Time to get back into DirectX. With the exception of a Maya skinned-mesh exporter, I really haven't touched DirectX in a good six months... needless to say I'm a little rusty. While refreshing my memory on the D3D9 API, I began to wonder if it would be more advantageous to jump right in and learn the 10 API instead. I know the geometry shaders are a little bit of a paradigm shift, and that D3D10 is only available in software mode at the moment, but I know that someday I'm going to have to learn it. Any thoughts? Is it worth getting into D3D10 at the moment? If you are doing console development, then its worth becoming intiment with dx9 architecture, as both the ps3 and 360 are based on this (though you won't use d3d on ps3, it is basically a Gforce 7800) If you are doing PC development, or as a hobby then Dx10 is a good place to start. There are substantional differences in architecture from dx9 to dx10, many of them philosophical differences, since DX10 is designed for massive throughput from the CPU to the GPU, sacrifising some ease of use to acheive this. Hardware will be available, shortly ;) Among the shader differnces: 1) Near IEEE floating point on both PS and VS 2) Geometry Shader, 3) Improved control over super-sampling and multi-sampling (can be done on a per-triangle basis), samples can be read into pixel shader with sample patterns 4) Bit-wise operations for all shader cores 5) Shader constants have been grouped into constant buffers for better access Other then that, all the other state has been packaged into (IIRC) six different state packages, so an entire render call will consiste of very little overhead.
  12. EvilDecl81

    BRDF energy conservation

    Quote:Original post by leonhard Hi there! I've got a question concerning the energy conservation of BRDFs. It's always stated as Int_{Hemisphere} f_r(p, omega_o, omega_i) * cos(theta_i) * d omega_i <= 1 for all omega_o (f_r is the BRDF and we're integrating over the hemisphere around p, running through all directions omega_i; e.g. p. 250 in "Physically Based Rendering", for all those who also own this great book) But intuitively, I'd understand energy conservation the other way round: For every (fixed) incoming direction, the sum of all fractions for outgoing energy that are "splitting" up the incoming energy may not exceed one: cos(theta_i) * Int_{Hemisphere} f_r(p, omega_o, omega_i) * d omega_o <= 1 for all omega_i But this doesn't seem to be equivalent (even considering the reciprocity of the BRDF). Can someone tell me why the first version is correct / what's flawed with my interpretation? Regards, Leonhard A BRDF can be greater then 1, because we are talking about an infinitly small point on a function, it's a distribution function. This is very similar in concept to focusing light in a parabolic mirror, the total light coming out is less then the light coming in, but it's all focused in one direction which is much stronger then any incoming ray (e.g. greater then 1).
  13. Quote:Original post by dv Are there alternatives to the D3DXCompileShader() function? Best thing would be a static lib. I have to ship the d3dx_XY.dll with my stuff because I use the compiler from D3DX. Since this is the ONLY thing I use from D3DX, it would be nice to have another compiler. Are there any? You don't (and shouldn't) need to compile your shaders on load, you can just use the obj format, or even generate a header file with the /Fh option, e.g. get a dump like (in a header file): const DWORD g_NULLPS11[] = { 0xffff0101, 0x0017fffe, 0x42415443, 0x0000001c, 0x00000023, 0xffff0101, 0x00000000, 0x00000000, 0x00000100, 0x0000001c, 0x315f7370, 0x4d00315f, 0x6f726369, 0x74666f73, 0x29522820, 0x44334420, 0x53203958, 0x65646168, 0x6f432072, 0x6c69706d, 0x39207265, 0x2e32312e, 0x2e393835, 0x30303030, 0xababab00, 0x00000051, 0xa00f0000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000001, 0x800f0000, 0xa0e40000, 0x0000ffff }; Then just say pDevice->CreatePixelShader(g_NULLPS11 , &pShader ); (This shader is a pixel shader that writes 0 to the output)
  14. EvilDecl81

    HLSL X1K branching

    Quote:Original post by edwinnie hi there! I wonder if shader derived texture coordinates would interfere in dynamic flow control. I wonder if the code below will generate branching instructions: *** Source Snippet Removed *** thx! Edwin If you use the beta compiler (fxc10.exe) in the new SDK you can force the compiler to use branches by using attributes: [branch] if(a) { ... } And this will generate an error if it cannot branch. Otherwise, the decision to branch or not is independent of gradient instructions, gradients will always be moved outside of it statements if needed.
  15. Quote:Original post by Jetto OK I just wanted to know How much Math would be required lets say if you worked on a game..Or like to Program a game. I heard you neeed math skills and many gaming colleges have tons of them. Heres my problem..Math Is one of my Weakest Subjects..And I would gladly Worl more with my math if it heavily required it.( I hate math) So does the industry require ALOT of it? and if so what kind of math It depends on the position. I would expect a strong canidate for a Graphics position to have a minor in mathmatics, while a network engineer wouldn't require much.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!