• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

lomateron

Members
  • Content count

    515
  • Joined

  • Last visited

Community Reputation

491 Neutral

About lomateron

  • Rank
    Advanced Member
  1. If I have 10 different shaders for drawing 10 different shaded objects that need the same view matrix do I need to update this view matrix for every shader which means that I have to call gl.uniformMatrix4fv() 10 times every frame?   In directx 10 in one file I can have 10 shaders and only one global "viewMatrix" variable which means I only need to update the view matrix one time per frame. Can something similar be done in webGL?
  2. I have an ID3D10EffectVectorVariable in HLSL code it looks like this: int4 array; float4 VS() { uint x = 0; //"x" is loaded from texture can be a value bigger than 3 int grab = array[x]; if(x > 3) { grab = 0; } //blablabla } is this code safe?
  3. if I have a technique that uses the geometry shader, is there any reason to use the vertex shader to do something( except for passing input assembler data to the geometry shader )? Is it faster to do the heavy part of an algorithm in the vertex shader and use the geometry shader only to generate the extra mesh?
  4. HLSL trigonometric functions are sin() cos() tan() etc...
  5.   HLSL trigonometric functions have some magic going on behind it, that's why I want them to do a length() for uints, they could make something that will let the function calculate all vectors that have a length less than 2^32
  6. wait what? uint operations are more accurate than float operations, as I said you can change the definition of 0 to 1 at your own taste, so I can make (0 to 1) = (0 to 2^25) and this will make it 2 times more accurate than (0 to 1) float
  7. float operations have a margin of error too, when using uints you just have to change your definition of what 0 to 1 means, for example 0 to 1 in my world physics engine is 0 to 2^9 uint.
  8. just tested HLSL intrinsic length() vs my integer length2D() and length3D() my functions are deterministic, HLSL intrinsic length() isn't, tested on an old ATI vs a new NVIDIA, on HLSL 4. You should test it yourself and that should be enough reason, for the people that want determinism.
  9. so there is that case when the length of the vector is 1 and another case when its 0 and some other cases when it is bigger than 2^32 but there are a whole lot more cases when it actually makes sense and those outweighs the other, so it actually makes sense to make that function, its the same with float operations isn't it, its even worse, there are more cases when length() doesn't work with float vectors. what do I propose whent its bigger than 2^32? return the same value when any number is divided by 0.
  10. arrrgg I messed up in the title, pls read the whole question, I would like to request to the people that make the intrinsic HLSL functions to make a length() function for uint vectors that gets a correct answer for every vector value uint4(0 to 2^32,0 to 2^32,0 to 2^32,0 to 2^32)
  11. The problem is that float operations are not deterministic on GPU so sqrt() should support ints for those people that want determinism. I created my own sqrt() for ints, Its actually a function to get the length of a 2D uint vector but it has the limitation of only getting the correct results for numbers from 0 to 2^15. uint length2D(uint2 u, uint b) { //dot uint l = u.x*u.x + u.y*u.y; //aproximation of sqrt() b = b + ((u.x + u.y - b) >> 1); //aproximate it more using babilonian method b = (b + (l / b)) >> 1; b = (b + (l / b)) >> 1; b = (b + (l / b)) >> 1; return b; } "b" is the biggest value in the "u" vector   oops its actually a request for a faster length() function for ints that can support every vector dimension(from 2D to 4D) and correct answer for every number from 0 to 2^32.
  12. at 7:15 in this video https://youtu.be/XISqvBVyASo?t=435   He says it's grid free, you can download the demo to play with the balls and in some worlds you can move the balls anywhere you want, no walls
  13. My final optimized solution which has a near clipping plane and an infinite far plane: Only 2 variables of the Projection matrix are needed, the ones that modify Pos.xy so we don't need to pass the whole 16 floats of the matrix to the shaders. Lets call these 2 variables ProjecXY Now in the vertex shader instead of doing this: Pos = mul(Pos, Projection); do this: Pos.xy*= ProjecXY; Pos.w = Pos.z; Pos.z = NEAR_PLANE; //NEAR_PLANE = 0.5f and finally reverse the depth test instead of passing if smaller, pass when greater
  14. The near and far planes operation makes the depth resolution poop. I want every object in front and in the field of view of the camera to be rendered doesn't matter the distance, until its so small it can't be seen but still rendered.   In the vertex shader after the Projection multiplication I have tried this:   float4 r = mul(Pos, Projection); r.xy /= abs(Pos.z); r.z = Pos.z*MAX_DEPTH; r.w = 1.0f; if(Pos.z<0.0f) { r.w = -1.0f; } return r;   MAX_DEPTH  is (1.0f/16777216.0f) so that any float distance gets rendered...16777216 = 2^24   but it still doesn't works, well the mesh is rendered correctly but when the camera is near and you read the depth and positions pixels across the mesh they are off and this off thing increases as the pixels gets near the camera     I want to know what is happening to SV_POSITION after it leaves the vertex shader? I know that "xyz" get divided by the abs() of "w" what other operations happen in that part were it gets divided by "w"? if someone has already a way to render the way I want can you share it too?
  15. Using directx 10   I changed  DepthClipEnable = FALSE;   and changed the viewport to vpTRY.MinDepth = 0.0f; vpTRY.MaxDepth = 16777216.0f;   but I still can't render a 10.0f float value to the 32 bit depth buffer   What else do I need to configure?