• 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.

enigmagame

Members
  • Content count

    126
  • Joined

  • Last visited

Community Reputation

140 Neutral

About enigmagame

  • Rank
    Member
  1. With isFixed false I want the gradient influenced by the camera position. My shader is wrong, since the start point of the gradient is the bottom of the window instead of the bottom of the sprite. The question is: how can I modify the shader in order to have the gradient starting from the bottom of the sprite? Maybe I need the size of the sprite in pixel? Or there are other convenient ways?   The other question regards the "fixed gradient": if I want the gradient not influenced by the camera position, what is the convenient way? It's possibile to have these two behavior in the same shader?   Thanks.
  2. I'm searching a way to implement a linear gradient shader that behaves as the linear gradient in Photoshop (only the vertical case is necessary). It will be applied to 2D sprites. Currently I'm passing to the pixel shader these parameters: StartColor. EndColor. Offset: the gradient starting point. Length: the gradient length (the range inside where the colors will be interpolated). isFixed: a boolean parameter that indicates if the gradient must be influenced by the camera position or not. Here a first attempt of the vertex shader and the pixel shader that I've implemented: struct VsInput { float3 position : VES_POSITION; float2 uv : VES_TEXCOORD0; float4 color : VES_COLOR; }; struct VsOutput { float4 position : HPOS; float2 uv : TEXCOORD0; float4 color : COLOR0; float4 outPos : TEXCOORD1; }; VsOutput main(VsInput input) { VsOutput vsOutput; vsOutput.position = MUL(float4(input.position, 1.0f), WorldViewProjection); vsOutput.uv = input.uv; vsOutput.color = input.color; vsOutput.outPos = vsOutput.position; return vsOutput; } struct PsInput { float4 Position : HPOS; float2 UV : TEXCOORD0; float4 Color : COLOR0; float4 outPos : TEXCOORD1; }; float4 startColor; float4 endColor; float offset; float len; bool isFixed; float4 main(PsInput psInput) : COLOR { psInput.outPos = psInput.outPos / psInput.outPos.w; float yScreenSize = 900.0f; float yPixelCoordinate = 0.0f; if (isFixed) { yPixelCoordinate = 0.5f * (1.0f - psInput.UV.y) * yScreenSize; } else { yPixelCoordinate = 0.5f * (psInput.outPos.y + 1.0f) * yScreenSize; } float gradient = (yPixelCoordinate + offset) / len; gradient = clamp(gradient, 0.0f, 1.0f); return lerp(startColor, endColor, gradient); } I think something's wrong, for example, with an offset of 0.0, the gradient starts from the bottom of the window and not from the bottom of the sprite. Another issue is that there is no correlation between the fixed and non-fixed mode.   I'm pretty sure that there's something correct and something wrong in my approach, so I'm here for any suggestions.   Thanks.
  3. Given a light direction, how can I [i]move[/i] it according to the camera movement, in a shader? Think that an artist has setup a scene (e.g., in 3DSMax) with a mesh in center of that and a directional light with a position and a target. From this position and target I've calculated the light direction. Now I want to use the same direction in my lighting equation but, obviously, I want that this light moves correctly with the camera. Thanks.
  4. Nik02 thanks for the hint, you're absolutely right: thinking on the texture maps has completely moved my focus on the problem. I've just tried with two control points and the result is correct. Just another question: I've ramps with four, five or six control points, what is the best way to interpolate these control points and achieve a correct result? Bézier curve? Thanks.
  5. The material definition of a mesh is composed of these three components: [i]Self-Illumunation[/i], [i]Refletcion[/i] and [i]Refraction[/i]. Each of these components has a [b]Gradient Ramp[/b] as a map and the mapping mode is set to spherical environment. I'm searching for a way to reproduce these effects in a shader (the shader language doesn't matter). Is it possible? My first idea was to save the Gradient Ramp as a texture: you can see the result in the image below: [img]http://i45.tinypic.com/2ebu0c2.png[/img] It seems to be a [i]Blinn/Newell Latitude Map[/i] instead of a [i]Spherical Map[/i], but using the math behind the first, the result isn't correct. Thanks.
  6. [color=#333333]I'm searching for suggestions and resources on the possible ways to design a character animation system. I mean a system built on top of the graphics engine (as graphics engine I use Ogre3D, that provide an animation layer), [/color]and that's must be in contact with the logic of the game[color=#333333]. More in detail I'm searching about the [i]action state mechines[/i] (or [i]animation state machines[/i]), that is build on top of the [i]animation pipeline[/i] already provided by the graphics engine. So, a state-driver animation interface for use by virtually all higher-level game code.[/color] [color=#333333]It's for a sports title, maybe the question is non trivial.[/color]
  7. Hi guys, I'm working on a simple bowling game, using Ogre as rendering engine and Bullet as physics engine. I'm at the point to tune all the physical parameters, but how? Where I can find those? For example: - Ball friction - Ball restitution - Ball angular damping - Ball linear damping - Ball, any other... - Pins parameters - Lane friction - Lane restitution Thanks.
  8. Ok guys, I've found the problem, and it was a very, very, very stupid problem: the size of the sphere mesh. I was convinced, very convinced, that the size was 1, but I was wrong. [img]http://public.gamedev.net/public/style_emoticons/default/sad.gif[/img][img]http://public.gamedev.net/public/style_emoticons/default/sad.gif[/img][img]http://public.gamedev.net/public/style_emoticons/default/sad.gif[/img] I've created a new mesh, and this is the results: [url="http://imageshack.us/photo/my-images/90/deferredshadingd2011051.png/"][img]http://img90.imageshack.us/img90/992/deferredshadingd2011051.th.png[/img][/url] It seems correct. You confirm? Thanks.
  9. [quote name='Hodgman' timestamp='1305018618' post='4808888'] Solve your attenuation function to find out what the maximum range of lit pixels is, and then make your sphere that big. [/quote] Sorry, but I don't understand very well. I'm a bit confused. I've correctly understood the problem that you've explained, but not the solution.
  10. [quote name='Hodgman' timestamp='1305017631' post='4808882'] That's because there's no connection between the range of your light and the size of your sphere..... [/quote] Do you mean the attenuation? Because if I use the original attenuation formula described on the tutorial: [code] //surface-to-light vector float3 lightVector = lightPosition - position; //compute attenuation based on distance - linear attenuation float attenuation = saturate(1.0f - length(lightVector)/lightRadius); [/code] I obtain the same, wrong, result.
  11. [quote name='n3Xus' timestamp='1304936215' post='4808464'] You must make you sphere smaller or bigger depending on the maximum light range. You should have a unit sphere (a sphere with radius 1) and then scale this sphere by the maximum light range using a scale matrix, so you end up with a matrix for a sphere which is like this: sphereWorldMatrix=sphereScaleMatrix*sphereTranslationMatrix. [/quote] Yes, but I already do that, the vertex shader receive the world matrix (for the sphere) that you've wrote above. I think that the problem isn't here. The problem is the clear cut, that you can see in all the screenshot that I've linked in the precedents post. Small sphere radius: [url="http://imageshack.us/photo/my-images/51/mgdexample1020110508004.png/"][img]http://img51.imageshack.us/img51/7492/mgdexample1020110508004.th.png[/img][/url]] Big sphere radius: [url="http://imageshack.us/photo/my-images/820/mgdexample1020110508004.png/"][img]http://img820.imageshack.us/img820/7492/mgdexample1020110508004.th.png[/img][/url]
  12. [quote name='froop' timestamp='1304864116' post='4808085'] In that tutorial they reconstruct position from depth which is fine. [/quote] It's right, in fact storing also x and y positions don't change the results. [quote name='froop' timestamp='1304864116' post='4808085'] Are you sure that the sphere has the correct radius? I had this once when I used a sphere that was too small. [/quote] I don't understand very well. What you intend?
  13. [quote name='The King2' timestamp='1304850098' post='4808029'] As you can see I'm not using any vertexshader (just the standard one for texture-coordinates), and I obtain all the data I need from the g-buffer. Maybe you should try doing that, too. [/quote] Very interesting, you are right, at the moment I store color (diffuse), normals, and depth, not x and y positions. Then, as you say, I get the position from the vertex shader. I'm going to store also x and y positions. You're storing positions and depth on the same texture or using two differents texture?
  14. [quote name='The King2' timestamp='1304849009' post='4808020'] Well anyway, thinking about it your screenshot looks like there is something totally wrong. You noticed that that range of lighting is not defined by geometry but rather as if you would light a 2d-surface? At least from what I can tell. Did you make sure the outputs of your pre-deferred-past are all correct? I had a similar issue when I somehow didn't output the z-world-coordinate of each pixel correctly.. [/quote] It's a very interesting question in fact, for me, there is something that's going wrong on other place. But, where? [img]http://public.gamedev.net/public/style_emoticons/default/sad.gif[/img] If I watch the data in PIX it seems all correct (diffuse, specular, normal and depth). But, of course, I'm not totally sure.
  15. [quote name='n3Xus' timestamp='1304847814' post='4808007'] This is how I compute it: [code] // Note that 'dist' is the distance between the light position and the world position of the current pixel. float linearFalloff=saturate( 1 - dist/maxRange);[/code] [/quote] But this is the approach that I've used in the code posted above (where I've posted the whole PS). And as you can see the result isn't correct. [quote name='The King2' timestamp='1304847978' post='4808010'] [quote]With this the attenuation works fine (as you can see in the screenshot), but I've the same cutting edge effect. How can I solve that? I must tune the attenuation parameters?[/quote] Well try using it like this: Set the first attenuation parameter to 1.0f, the second one too, and the third one to 0.0f. Tell me how it looks like, for me its working this way. [/quote] This is the results: [URL=http://imageshack.us/photo/my-images/121/mgdexample1020110508115.png/][IMG]http://img121.imageshack.us/img121/3433/mgdexample1020110508115.th.png[/IMG][/URL] I'm very confused, I don't understand what's going wrong.