Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

480 Neutral


About turanszkij

  • Rank

Personal Information


  • Twitter
  • Github

Recent Profile Visitors

6918 profile views
  1. turanszkij

    Beginning developing

    It's great to hear I'm not the only one. That is not true in my experience, but you need to think long term and keep at it. My general advice would be to keep programming on the side, and one day you will be good. But don't just wait for it, you need to practice, practice, practice, and apply for jobs, that's how you will know when you are good enough. Also try to keep a balance, and practice/pursue other interests. For me, this is drawing and martial arts (tae kwon-do) at the moment. Both of these can also be mastered with a lot of practice, and they really help to stay motivated and not burnt out with programming.
  2. Yes, this is usually also called "ray unprojection" from screen (projected) space to world space. I also taken that piece from my "getPositionFromdDepthbuffer" helper function.
  3. You should be able to multiply the screen-space position with inverseViewProjection matrix, divide by .w, and subtract from camera position, and finally normalize. I haven't tested this now, but should look something like this: float4 worldPos = mul(float4(screenPos.xy, 1, 1), inverseViewProjection); worldPos.xyz /= worldPos.w; float3 eyeVec = normalize(cameraPos - worldPos); I think that you are looking for this. But as ChuckNovice already mentioned, the frustum corners solution would be faster to compute.
  4. turanszkij

    How to do Cascaded Shadow Map

    The best would be if you said where exactly are you stuck, but a quick general guide: It means that you place (for example 3) shadow maps in front of the camera, each farther away from the previous and covering a bigger area. You can do it sort of like shooting a ray from the camera in the direction the camera is facing, then choose 3 points on that. For each point, just place a big enough shadow map that you need. Best would be to compute the size programmatically, but I suggest to just hard code it first. The ortho projection (for directional light) is the inverse of the scale * rotation * translation matrix of the shadow cascade. Use the previous matrix and render a shadow map using that, I won't detail how to render a shadow map, you should be already familiar with it if you are doing cascaded shadows.
  5. turanszkij

    How to do Cascaded Shadow Map

    This should give you a good starting point: https://docs.microsoft.com/en-us/windows/desktop/DxTechArts/cascaded-shadow-maps
  6. I don't have time to look over all code here, but just leave a suggestion: Familiarize yourself with RenderDoc or Nvidia Nsight, or even Visual studio graphics debugger. It will save you in the long run. Probably some of your GPU-side data is stale, and you can inspect all of it with a graphics debugger.
  7. turanszkij

    CopyResource with BC7 texture

    I think it should be fine when copying to/from the same formats, but once you need to copy anything to a compressed format that is not the same format, you are out of luck! Or you must convert it on CPU first Maybe you could convert it in compute shader, write it out to a linear buffer, then upload that to the compressed format texture, but I never tried this in DX11.
  8. I would rewrite that bit of code you linked just a little bit: while (!gameOver) { // Process AI. for (int i = 0; i < aiComponents.Count(); i++) { aiComponents[i].update(); } // Update physics. for (int i = 0; i < physicsComponents.Count(); i++) { physicsComponents[i].update(); } // Draw to screen. for (int i = 0; i < renderComponents.Count(); i++) { renderComponents[i].render(); } // Other game loop machinery for timing... } (Previously the loops iterated for numEntities times) Now you don't assume that each entity has all the components, just update however many components there are. For accessing an other component from an other, I will have the component manager know which entity a given component belongs to, then I can just query an other componentmanager by that entity ID. Then I either get back a component or nothing depending on if the entity had registered a component of that type for itself or not.. But that said I am still in the process of developing this, so I might not get a full insight.
  9. No, this is describing a system where entity is just a number. Then we also have component managers/collections for every possible component type. We can add a component to componentmanager with an entityID, and that means that an entity received that component. The component manager itself can decide how it wants to implement looking up a component by an entity ID. You don't have a "GameEntity with every possible component", only if you registered the entity to every possible componentmanager. The "for (int i = 0; i < numEntities; i++) loops" are iterated against a specific componentmanager of your choosing, which will iterate through every component, regardless of what entity owns it.
  10. I have started experimenting with ECS just now too. I want to address both Data Oriented Design and Entity-Component System. I really like the pattern with no Entity object, and entities being just unique numbers. The following article describes both of these goals in detail: http://gameprogrammingpatterns.com/data-locality.html
  11. I'm not completely sure that I understood the question. Your vertex buffer input will not be clamped. The output from vertex shader to pixel shader will be clipped outside [-1; 1] range for SV_Position, because it specifies clip space positions. TEXCOORD semantic has absolutely no meaning, so no extra clamping will be done.
  12. There is good reason to have deinterleaved vertex buffers (so multiple vertex buffers on multiple input slots). Let's say that you have two render passes for a mesh, one is using a simple shader that only uses the positions, while the other render pass wants position, texcoord, normal. If you have separate vertex buffers, then you can bind only the positions vertex buffer to the simple render pass, and achieve better performance because more vertices will fit into cache. Your engine code can mix-and match vertex buffers very easily in general and allows some nice tricks. You should always prefer DrawIndexed instead of just regular Draw when you have more than just a couple vertices to draw. This can trigger a behaviour where the vertex shader can skip processing vertices whose indices were already executed and still inside the cache. For vertex shaders, the input semantic names have no meaning apart from reflection information. With shader reflection API, you can retrieve semantics and maybe do some engine-specific logic on them. Also, it is good to have meaningful semantic names, because if you enable the debug layer, it will output semantic names in the error messages if there are mismatching input/outputs in different shader stages. For output semantics, you have semantics that start with SV_, meaning system-value semantics, which will bring special meaning and fixed function behaviour. You can always use D3D12_APPEND_ALIGNED_ELEMENT when your real data type size matches the size of the DXGI_FORMAT description provided to the input description. Otherwise, you can supply a custom size and the hardware will have to read from your buffers with that stride instead of the stride specified by the DXGI_FORMAT.
  13. Let's put it this way instead: my lack of C++ knowledge in the beginning was a problem that I needed to overcome. Sure, my code was very bad at the beginning, but constantly improved, and refactored, rewritten. It still has some very ugly parts still on my todo list. I would be more worried to never start. The things that you mention will come in time. If you can't multiply two matrices by hand, you probably just never needed to, and that's fine. When the time comes, you can learn it, it's really not difficult, just time-consuming. Of course, it always sucks when they ask something on a job interview that you have no experience with (I've been there). And don't feel bad that you have problems with strings in C++, those are their own beasts entirely with oh so many nuances.
  14. I've always wanted to create games with my own engine, so I started developing one after having made a couple casual games in XNA. I only just started learning C++, and I started making this 2D sprite-based fighting game, which eventually got 3D, then when I was no longer into fighting games so much, I decided to remove the game, refactor the whole code base and leave the reusable parts in. Now, after about 6 years development, it is an "editor", which I mainly use to implement rendering features, and just optimize and refactor endlessly. Was it worth it? I at least got a tremendous amount of experience out of it, and feel like a somewhat decent programmer. But as you can see, I don't have a shipped game yet made with this engine, and I only feel like I've gotten farther away from doing one instead of closer like I expected. So far, I see no reason why anyone would use my engine over commercial or even some open source ones (like Godot for example).
  15. Apart from the CPU cost of setting uniforms which was already mentioned, there can be GPU cost as well. Each individual texture sampler takes up GPU resources (registers), which can limit overall occupancy. This means that the GPU will be able to execute the shader less effectively. It is a good idea to combine multiple textures into one, because it will take up less registers for its descriptor (in DX12/Vulkan terms, but it will apply to every API), and also you can reduce sample instructions by sampling multiple textures with one instruction. Sampling multiple channels from a single texture also improves memory access latency.
  • 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!