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

FromShadow

Members
  • Content count

    10
  • Joined

  • Last visited

Community Reputation

145 Neutral

About FromShadow

  • Rank
    Member
  1.   The snapshot shows the expected behaviour. He wrote that the parent ship rotates about the origin instead.
  2. I'm afraid to post the whole shader code due to copyright issues. If you have the book, it is printed in chapter 2.3. I wanted to use the original shader to prevent error infusion. What I can do is post my own adaptation of that code. It uses the original math/shader, but I added hardware instancing, so it should be ok. I also attached the class that manages the buffers. My main change is that the texture coordinates are now in input.Position.xy instead of weights.zw I applied your change to both versions, i.e. use float2 instead of float4 for the texture coordinates und tex2D instead of tex2Dproj. The output is the same every time.
  3. What you have to do is transform the difference vector between parent and child, not the child position itself. Rotations matrices always rotate about the origin, so the easiest thing is to (temporarily) change your coordinate system so the parent ship's position is the origin:     Vector2 d = childShipPositionPoint - parentShipPositionPoint; d = Vector2.Transform(d, Matrix.CreateRotationZ(15)); childShipPositionPoint = parentShipPositionPoint + d;   Let me know if this is what you are looking for.
  4. Hello everyone,   I followed the Chapter "2.3: Simplified High-Quality Anti-Aliased Lines" from the ShaderX7 book. I copy-pasted the shader file from the CD and carefully ported the managing class to XNA. I cannot guarantee that the buffers are correctly filled but I am pretty sure.   Have a look at the first screenshot. The perspective is not correct. I chose my Line texture to be a square to enhance the effect. Looking at the wireframe (second screenshot), you can see that the vertex positions are in fact correct. The error is in the texture lookup.   I assume I cannot upload the whole shader since it's from the CD, but here are the lines that set the texture coordinates:   VS_OUTPUT VS(...) { [...] // Calculate Vertex Positions (works) VS_OUTPUT output; output.textureUV.x = weights.z; output.textureUV.y = weights.w; output.textureUV.z = 0.0f; output.textureUV.w = 1.0f; return output; } PS_OUTPUT PS(VS_OUTPUT input) { return g_Color * tex2Dproj( FilterTextureSampler, input.textureUV ); }     where weights contains the texture coordinates in z and w. g_Color is the Line's Color and FilterTextureSampler contains the square texture.   I understand that tex2Dproj divides the coordinates by the w-component. But w = 1.0f everywhere! Can somebody explain what this is supposed to do? Changing "tex2Dproj" to "tex2D" makes no difference. Why can't I just take the usual texture coordinates?
  5. Thanks for the answers. I see now that fog really was the wrong approach. I have worked on the suggestions and thought I'd share the results: I had a hard time drawing a Skybox myself, mostly due to parallax errors in the corners and my inability to mask the transitions at the edges. For anyone searching, try Spacespace (http://alexcpeterson.com/spacescape). It does the job beatifully and I'm glad I stumbled on this. For the time being, I could get away with a single rendering pass, since there are no distant objects and the skybox is 10000 big, as suggested. The Skybox helped with orientation in a relative manner, like you can tell which way you are turning/looking. But what I needed was an absolute reference point, so I followed Prinz Eugn's advice and added a milky way band all arround one axis (It's actually tilted, but there is no way to notice, which I'm pretty happy about). The galaxy is additively blended over the background which works great. The galactic core on the side of the sky box further helps with orientation. I made it really bright and added directional lighting. sharp lighting really is the way to go, I more than doubled the intensity and it looks good. HUD: For now I added a line for each ship to indicate its current target. There is a lot to be done, like showing the estimated flight path (which should be curved rather than straight). Right now it is a wirefrime line, but I would want it to be a translucent and add a subtle glow effect. Particles: Added a threaded particle system. This makes things come to life, I added basic explosions and engine trails, but they are really ugly because I can't draw ;). I am working on that "star dust" thing right now, which will be hard because I cannot reposition particles right now to implement an infinite scrolling cube, only spawn new particles.I attached a few screenshots.
  6. Feeling like a total scrub now. Your correction works. The particles are visible now and do turn (arround some wrong axis, though). I think I can safely work from here. ^^ Thanks a lot, and sorry for this stupidity. Edit: Here is the new shader with a workarround using the View matrix for the billdboard orientation. This way I don't need to use float3 at all. [source lang="cpp"] VSOutput ParticleVS(VSInput input, InstanceData instance) { VSOutput output = (VSOutput)0; float lifeTimeFactor = (instance.T1 - T) / (instance.T1 - instance.T0); input.Position *= instance.Size * lifeTimeFactor; // transform to Screenspace float4x4 transform = transpose(View); transform[3] = 0; input.Position = mul(input.Position, transform); // Calculate the particle's position float dt = T - instance.T0; input.Position += instance.Position; input.Position += dt * instance.Velocity; input.Position += 0.5 * dt * dt * instance.Acceleration; float4 pos4 = mul(input.Position, World); pos4.w = 1; pos4 = mul(pos4, View); pos4 = mul(pos4, Projection); output.Position = pos4; output.TextureCoordinate = input.TextureCoordinate; output.Alpha = lifeTimeFactor; return output; }[/source]
  7. Hello, I am having a hard time billboarding my particles. I am following this tutorial: [url="http://xnauk-randomchaosblogarchive.blogspot.de/2012/07/3d-billboard-particles-tutorial-vi.html"]http://xnauk-randomc...utorial-vi.html[/url] The instancing is not a problem and works. I understand the formulas for billboarding given in the link, but when I implement them, the particles disappear. The difference in my implementation is that I represent the particles by a position only, while the tutorial uses world matrices. Here is the relevant shader code: [source lang="cpp"] struct InstanceData { float4 Position : TEXCOORD1; float4 Velocity : TEXCOORD2; float4 Acceleration : TEXCOORD3; float T0 : FOG0; float T1 : FOG1; }; struct VSInput { float4 Position : POSITION0; float2 TextureCoordinate : TEXCOORD0; }; struct VSOutput { float4 Position : POSITION0; float2 TextureCoordinate : TEXCOORD0; float Alpha : FOG0; }; VSOutput InstancingVS(VSInput input, InstanceData instance) { VSOutput output = (VSOutput)0; // Calculate the particle's position float dt = T - instance.T0; input.Position += instance.Position; input.Position += dt * instance.Velocity; input.Position += 0.5 * dt * dt * instance.Acceleration; // start using float3 because we need cross products float3 center = mul(input.Position, World); // looks fishy since input.Position is float4, but it works in the tutorial float3 eyeVector = center - CameraPosition; float3 pos = center; float3 sideVector; float3 upVector; sideVector = normalize(cross(eyeVector, (float3)(0, 1, 0))); upVector = normalize(cross(sideVector, eyeVector)); // Billboarding offset pos += (input.TextureCoordinate.x - 0.5) * sideVector; pos += (0.5 - input.TextureCoordinate.y) * upVector; // pack into float4 float4 pos4 = (float4)(pos, 1); pos4 = mul(pos4, View); pos4 = mul(pos4, Projection); output.Position = pos4; output.TextureCoordinate = input.TextureCoordinate; output.Alpha = (instance.T1 - T) / (instance.T1 - instance.T0); return output; } float4 InstancingPS(VSOutput input) : COLOR0 { float4 color = tex2D(TextureSampler, input.TextureCoordinate); color.a = color.a * input.Alpha; return color; } [/source] Now, I suspect there is something wrong with float3/float4 mixture. For example, If I change line 50 to [source lang="cpp"] float4 pos4 = input.Position; [/source] the particles are drawn correctly, but without billboarding, which is expected. However, if I try [source lang="cpp"] float4 pos4 = (float4)(input.Position.xyz, 1); [/source] which I assumed to do basically the same thing, I see nothing. Can somebody explain this? I don't see the difference between the these two lines (except for the w-compenent, which shouldn't matter, should it?). I have been fiddling with those conversions for two days now and I am very much lost. Appreciating any help.
  8. Thanks guys, you have been really helpful. I'm getting a copy of ShaderX7 from amazon. Also adding some Heads Up Display of ship information is a great idea and would be cool and helpful at once. Edit: I added a particle engine now and I found engine trails to work really good for that "3D-feel". Trying to add star dust now.
  9. [quote name='BagelHero' timestamp='1352323428' post='4998588'] Right now I can't help but thinking straight black is a bad idea. Perhaps a very dark tone of blue/purple might be better? If you offset the tone from pure black, then it might be possible for fog to work in a lighter tone; eg Black-Purple with Purple-Orange haze (Random example; I don't suggest actually using that). [/quote] Sounds good, I just tried making the skybox translucent and putting different colors underneath. blueish tones really look better than black. [quote] In terms of speed and distance, Perhaps some sort of "landmark" stars and planets might help somewhat? [/quote] What I am wondering is wether you add those landmarks as 3D objects, or do I blend them into my skybox? While I can't go for top-notch graphics (I'm doing this for fun), I wonder how game devs go about this. [quote name='Tobl' timestamp='1352325621' post='4998605'] Some guys a semester below me at my university just finished this for a little sideproject [url="http://ig.hfg-gmuend.de/Members/sandra_krauss/meine-projekte/kinect-projekt-starry-sky"]Starry Sky[/url] The fog is basically just a continuous stream of circles, coloured according to a certain scheme, getting larger and more transparent with time until they disappear. If you're really interested in implementation, I could get you their email-adresses, but for now, maybe it's just good for a little inspiration. [/quote] Cool project, maybe one could do something similar in 3D with a particle engine. Maybe not for large-scale fog, but it could produce some nice engine trails, I imagine. Hope I can go about that later. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]
  10. Hi everyone, so I'm working on a third person space shooter in XNA. The idea is to immerse the player in large scale battles with ships of different sizes and shapes, ranging from small interceptors to huge battle stations. So far i've primarily worked on the engine and i'm pretty happy with the results. For the graphics, I have only a Sky box, (very) basic ship models with diffuse lighting and some basic fog. My goal is to have a nice star background and to give the player a good perception of the other ship's 3D position/trajectory. So my question is, what do I need for that? Should I just add loads of fog? If so, what color should it have? white fog looks ugly when it's blended over my dark skybox. black fog works betters but all it does is smooth out my far clipping plane. Many space games seem to have static "stardust" that doesnt move so the player has a sense of his motion. But I can't spawn millions of particles all over space, and generating them around the player seems costly too. Also, games like Eve:Online don't look like they have skyboxes. distant stars seem to be light sources and have lense/flare effects, does that mean I need a full 3D galaxy model? appreciating any insight!