Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 17 Dec 2009
Offline Last Active Apr 27 2016 01:13 AM

Topics I've Started

Blood in a top-down shooter

04 December 2014 - 03:22 PM

I wasn't sure if this should go into a graphics section or game programming, so a flip of a coin decided to put it into general.
I'm working on a top down shooter game, and i'm trying to get blood splatter to be drawn at the locations where monsters get killed. The blood should stay on the ground forever, essentially covering the ground entirely after enough time has passed and enough monsters died. The camera is focused on the character (camera is z=-50, game stuff is at z=0), and the map itself is slightly bigger than what the camera sees, so it scrolls a bit until it reaches the edge of the playable area where it stops following the character on that axis.

My idea was to draw all the blood that was spawned in the current frame to a texture, and then draw that texture with alpha blending enabled after the background image, so it would be like a transparent blood-filled layer over the background image.
I can draw all the blood so it looks as i want it if i keep all the blood splatter information (world pos and a sprite index) in a vector, and draw them after the background. Image here. However, this is not going to work in the long run, seeing i want to have the ground covered in blood after a while.
If i set the render target to be a texture, draw all the blood generated in the current frame onto the texture, then setting the render target back to the backbuffer and drawing the background and then the texture over it, i get a weird result where the blood doesn't get spawned at the location the monster was at (problem 1) and the new blood overwrites the previously drawn blood (problem 2). Image before monster death and image after, both issues can be seen.
I'm probably missunderstanding how the render to texture process really works, which is causing my issues.
First off, is this a good way to do blood at all? I've read about decals a bit today, and am not sure if that's the way i should be going for, or if i can get decent results with this.
If this approach might work, then any ideas on how to setup this flow to get good results?
Some info.
Backbuffer is 1200x900, background image is 1200x900, drawn on a quad bigger than what the camera sees so the camera can scroll with the character, and i tried making the texture render target a wide array of values, with the results all being the same.
My transparency blend state is initialized with:

D3D11_BLEND_DESC blendDesc;
ZeroMemory(&blendDesc, sizeof(D3D11_BLEND_DESC));

blendDesc.AlphaToCoverageEnable = false;

D3D11_RENDER_TARGET_BLEND_DESC& rtbd = blendDesc.RenderTarget[0];
rtbd.BlendEnable = true;
rtbd.SrcBlend = D3D11_BLEND_SRC_ALPHA;
rtbd.DestBlend = D3D11_BLEND_INV_SRC_ALPHA;
rtbd.BlendOp = D3D11_BLEND_OP_ADD;
rtbd.SrcBlendAlpha = D3D11_BLEND_ONE;
rtbd.DestBlendAlpha = D3D11_BLEND_ZERO;
rtbd.BlendOpAlpha = D3D11_BLEND_OP_ADD;
rtbd.RenderTargetWriteMask = D3D10_COLOR_WRITE_ENABLE_ALL;

HRESULT hr = m_dev->CreateBlendState(&blendDesc, &m_transparency);

I appreciate any help, suggestions and critique! Thanks.

Opinion needed: returning values without null checks everywhere

13 May 2014 - 02:19 AM

Hi all.


Here at work, we have a class that stores non-POD objects by raw pointer, and has a get method that returns that raw pointer if the key was found (the storage is an std::map<key, value*> and the get method has a signature value* getThing(const key&); ). The objects are created elsewhere and simply stored in this class for ownership. A note to keep in mind is that c++ exceptions are disabled, and we're not using c++11 yet.


My issue with this is that everywhere the getThing method is called, we need to check for null, since if the value is not found, null is returned.

This annoys me to hell, since it bloats the code everywhere with null checks. I have a few ideas about changing it.


1. Add a 'bool exists(const key&)' method which does the obvious, and change the getThing to return a reference.

- The issue here is if someone calls getThing without checking if the value exists, then i don't know what to return? The .second value of the end iterator? It should cause a crash as soon as someone uses the reference, right?

- Since exceptions are disabled, i can't throw in case nothing was found, so i'm forced to always return something, and end.second seems like the only choice.

- Another problem with this is that the getThing method is const too, so i'm not sure if returning a plain reference will work (i remember it being a compilation error [in some cases]) or if the reference also has to be const, which makes it impossible to change the thing we get. A solution is to remove the const, but isn't nice.


2. Have the getThing method return a bool, and accept a double pointer or reference-to-pointer as an 'out' argument, so if the value is found, true is returned and the out argument is set to point to the found value.

- This seems ok and removes the need for a null check at the call site, but is again using pointers instead of references. I don't have anything against pointers, mind you, but i believe having references in the public interface of a class makes the code look cleaner since it's similar to the rest of it (using references everywhere instead of a mix of pointers and references, i find pointers fine for internals of specific classes).


I'd like to get others opinion on this, another perspective on how this could be done better and/or different. For all i know, maybe the current implementation is fine, and i just need to come to terms with it... Any suggestions are welcome.


Leveraging multiple monitors

08 April 2014 - 08:23 AM

Having recently bought myself two wide screen monitors purely for development purposes, i began thinking about potential design choices for games which could leverage the users' extra monitors.


I am not aware of any games that use multiple monitors in an interesting gameplay-wise way, similar to what the new consoles are offering with their "LCD screen on your controller" scheme, and having a minimap always shown on the other display (i remember seeing that somewhere).


Note that this shouldn't apply to multiplayer games because you want to have maximum fairness in those, where neither player has an obvious advantage just because they have more money to throw at peripherals, but rather single player games.


The choice also has to be optional because not everyone has more than one monitor, and the game still needs to be playable on a single monitor computer.


If you had the money/freedom/need to design an optional feature for multiscreen setups, what would it/they be? Minimap on the second screen? List of party members? Inventory always shown?


I'm interested to see what different people would do if they had the option. :)

Input on different thread

29 December 2013 - 05:10 AM

Hello everyone.


I googled for a while now, and am probably missing some keywords to find the answers to my question(s).

I'm planning on splitting my code so input is gathered in one thread, and the game logic is on another thread, so i can timestamp input on the main thread, and use these timestamped inputs in the game logic thread. This is on win32, and is influenced by L.Spiros posts.


The question i'm having is how to take the input messages on the game thread.

I'm completely new to multithreading, so i thought i'd ask first before trying any of the solution versions i have in mind, as i have no idea if what i would do is horribly wrong.


The basic idea are the two threads, main/input thread and the game thread (not yet bothering with render thread). Main thread receives the messages from the OS, timestamps them and stores them somewhere (this is the question), while the game thread only uses messages that happen up to the current time.


One way i thought i would do this is by having a container of events (std::vector? std::deque? std::list?) in the main thread, and events are always put at the end of the container by push_back() or emplace_back(). The game thread would then ask for events either one by one or in bulk, and would do this by looking to the front of the container and doing pop_front() for each event that happened before the current time. From my googling i found this is called single producer-single consumer, and i'm wondering if there's something in the STL that i can use for this instead of taking random/potentially unsafe code from the net.


Another way is to have the main thread send each event to the game thread as it is received and timestamped, and let the game thread store the event and use them when needed. I guess this is basically the same as the first one, only the container of events is owned by the game thread instead of the main thread.


Do i need to implement locking of any kind for this? Can i use the basic STL containers if i can guarantee i have exactly one thread doing a push/emplace_back(), and the other doing a pop_front()? Is yes, which container is best suited for this?


I appreciate any help :)

DLL question

31 July 2013 - 01:11 PM

Hey community!

I have a question about DLLs, and whether what i'm trying to do is possible at all.

Here's my issue. I would like to have all of my rendering code packed away nicely in a DLL, to which i would link in my main project. However, i would also like to keep the rendering specific API linkage (D3D or OpenGL) also packed in that DLL, so my main project wouldn't have to worry about what rendering API is lying underneath.

Note that i'm not trying to use runtime API switching or anything, as right now i'm only working my way up to learning D3D9, and if (heavy emphasis) at any point i'd try supporting another API, i would build the project with different files. But i'd like it that i only needed to change the graphics classes in question (like, instead of having a LPDIRECT3DTEXTURE9 member it would be an GL_int). The main project would never use these API specific members, only the renderer itself would use them.

I know i could solve this by making an interface for every class that has any API specific code in its header, but i really don't need to have runtime polymorphism since i'm only using one API in a build. I was thinking about doing something with typedefs, but i'd still be adding the graphics classes headers into the main project, which would in turn try to include d3d9.h, which i'm hoping i don't have to link in the main project. Even if i never get to a point where i would try adding support for OpenGL, it'd still be nice if all d3d9 linking was contained in the renderer DLL.

So in short, i'm trying to:
1. link my renderer DLL into my main project
2. only link the d3d libs in the renderer DLL (EDIT: oh, and that includes the include/lib/source directories as well)
3. not have to link d3d in the main project
4. not use inheritance for any of the graphics classes, but still be able to use them in the main project (and not use any API specific calls on those classes, mostly just getters)

I hope i explained myself well enough to get some advice. Thanks in advance! smile.png