Jump to content
  • Advertisement

Noggs

Member
  • Content Count

    172
  • Joined

  • Last visited

Community Reputation

141 Neutral

About Noggs

  • Rank
    Member
  1. You're right without MRT deferred rendering will be very slow. However there is a compromise which allows you to apply the lighting in screen space with a single texture lookup, at the cost of rendering the geometry twice. It's generally known as light pre-pass or deferred lighting if you want to research it. I implemented it on a netbook which didn't support MRT and it worked really well once I tweaked the G buffer packing. You have to pack a lot of information into the first pass which can lead to quantization errors if you can only render to a 32 bit target. Rough description: G-buffer pass Render all geometry outputting a texture containing [depth, normal, specular/roughness]. This is where the packing comes in (e.g. depth 16-bit, screen space normal 8bit, specular value 8 bit). Lighting pass Render all your lights in screenspace into a lighting rendertarget looking up the G-buffer texture for surface information. Render pass Finally render your geometry a second time to the back buffer looking up the lighting render target for lighting information.
  2. Noggs

    XNA Problem with boids!

    Basically you want them to collide with the building. If you want them to act like bee's then think about what is really happening. A bee has a high forward velocity which updates it's position forward every frame. When it hits a window it will be reflected back - basically the velocity vector will have been reflected from the window. Then its wings will flutter like mad (applying a forward acceleration) and the bee will eventually stop moving away from the window and start going towards it again. So if you detect a collision, reflect the velocity vector and you should get the behavior you want.
  3. Noggs

    [DX9] Issues with lighting

    You're basically talking about shadowing I'm afraid! It's not exactly straightforward to implement but there is quite a lot of information out there. Two popular techniques are shadow mapping and stencil shadows. I'd start with the DX sample ShadowMap and see if you can figure it out from there.
  4. I don't see why you'd want a 2 dimensional array in the C++ version. The vertex data probably needs to be contiguous and the only way to guarantee that is to new a single array.
  5. Precalculating is a good idea but really 100 raycasts against static geometry is not a big deal. 1000 probably isn't if you're targeting PC only. To get things going I'd just do a bounding sphere test and if raycast towards any units that pass the bounding sphere test. If you notice it is too slow (and you have profiled to be sure it's the raycasts) then try alternating doing odd units one frame and even units another frame.
  6. Noggs

    Memory Stomp

    Are you talking about VRAM or GPU mapped system ram? What kind of address are we talking about relative to the start of that memory type? If it's the mapped area then I seem to recall you are not supposed to use the first 4k of that memory after the command buffer space due to a possible overrun in the command buffer (but you probably account for that already). Something that indicates it's not DMA to me is that DMA's need to be 16 byte aligned, so I don't see how unaligned single bytes could be modified. To be sure you could wrap your SPU dma puts in a function that checks the range it is writing to to confirm it's not coming from there? Another question - what is the erroneous value written into memory? Is it always the same? Sure is a crazy issue you have to let us know if you get to the bottom of it!
  7. Noggs

    The GD Coding Typo Dictionary (TM)

    Add a little spice to your headers #define FASLE (true)
  8. Maybe I've missed something fundamental but why is this the case? I must admit I'm not familiar with exactly what Verlet integration entails but I have done a lot of work with framerate compensated physics. With a zero acceleration the pos += (pos-oldpos)*dt will result in a constant speed. Where does the deceleration come from?
  9. Noggs

    Time for a batched render?

    I feel I must add the obligatory "Be sure to profile this!". It is often slower to perform the check than to simply multiply the matrices each frame. The cost often comes from cache misses and pipeline stalls, not to mention the added complexity of the code to do these checks. Ideally your matrices would be in one big contiguous array and your function would rip through the input array transforming to the output array. Minimizing cache misses maxing out the CPU instead of waiting for data from RAM.
  10. Noggs

    Cache behavior

    It's probably worth pointing out that to get good cache performance it definitely helps to have an understanding of how caches work internally, but ultimately there's so many different processors with different cache sizes, etc, that you will struggle to target each one individually. Following a couple of simple rules is normally enough. Keep frequently accessed classes as small as possible Allocate those classes in blocks or in a contiguous array Variations on this would be if you have a big class that you can't get any smaller, separate the "hot" data (data accessed frequently) from the "cold" data (infrequently accessed). Allocate the hot data in one block and the cold data in another, then construct your class bringing the two together. There is lots more to it but if you follow those main points you'll probably be making better use of the cache.
  11. Transform the normals and light direction into view space as well! You would normally want to do all calculations in the same space. The advantage of viewspace is that the view direction is fixed, but you will need everything to be in viewspace for it to work.
  12. I thought the point of Dark BASIC is that you would build the game in Basic not C++? If that's not the case and you're not familiar with C++ then I'd say your task is impossible. If it is using BASIC then start from one of the samples that displays a 3D object on-screen - ideally with a chase-cam component (if they exist in DB). Once you get that working then start adding motion to the aircraft. Simple aircraft physics is quite easy, start with acceleration in the forward axis, then add the ability to pitch up and down (rotate around the side axis) and then finally add roll (rotate around forward axis). Remember to apply forces in the local space of the aircraft. Take it one step at a time and try and tackle tasks first which will give you the most value for the effort you put in.
  13. I'm sorry I don't quite follow what you are asking. You need texture UV coordinates as they are so that a diffuse texture will render correctly - as you said. I'm a bit rusty and I don't have any reference with me but it's something like this. To sample the depth buffer in the particle rendering you already know the world position, so in the vertex shader multiply it by the view/projection matrix to give you the vertex position in screenspace. Pass this through to the pixel shader as an additional texcoord. In the pixel shader sample the depth buffer using that information.
  14. Seeing as each of the particles has the same depth mask pattern on it it may be that the tex0 parameter is wrong. I'd do a couple of tests which would be draw the depth buffer sample color on the particles, and also draw the depth buffer on screen. See if you can spot a pattern. The tex0 parameter comes from the vertices, so are you computing the gbuffer uv coordinates on the CPU and passing them as part of the vertex stream? I'd check that calculation - it might even help to draw the tex0 coordinates as color on the particle.
  15. Noggs

    Physic Level in XNA

    No PhysX is not a managed library and so you won't be able to use it on Xbox 360 under XNA. A very quick google search revealed a few names: JigLibX, Bepu, Oops!, Henge3D, I'm sure you can find others. Part of the criteria for choosing which one to use will be how it integrates within the content pipeline and how you can generate a collidable mesh from your geometry.
  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!