Design suggestions?
Posted: September 3rd, 2015, 11:37 pm
In practicing SSE, I've decided to make some image filters, blending and lighten and so on. I'm having troubles deciding how I should go about implementing them. I tried a few different methods, but keep running into limitations with each.
Storing a surface in the filter class: The idea was I have the surface stored int he image filter class, and call one of the functions to manipulate the surface. The problem I had was that storing the manipulated pixels back on to the surface became cumulative. So each successive pass for each frame made the pixels brighter and brighter for instance when calling the Lighten function.
Passing a surface to the filter: The idea was that I could pass a source surface to the filter, and store the result in the filter's surface in the Go function, then call the filter.draw function in the ComposeFrame function of Game. The problem with this is the size of the filter's surface would have to match the surface being passed in. So the filter's surface would have to be resized for each different surface I wanted to pass through the filter. This would be slow always allocating and deallocating memory.
Passing a surface through the filter: There were two options here, one would have the same problem as storing a surface in the filter, where storing the converted pixels back onto the source surface would accumulate the result each frame. The second option was to just have the filter draw directly to the backbuffer, which provides the result I'm looking for, but doesn't feel right.
Passing a filter to a surface: What I would like is to have a filter be a class, where I just pass in the filter to the surfaces draw function, and then the surface will call the fitlers' Apply function and the surface will be responsible for putting the pixels on the back buffer and the filter will just work with the pixels passed to it. The problem is each filter needs a different set of inputs, so I'm not sure if this is possible. If I don't inherit from a base class, I would have to overload the Surface::Draw function for each type of filter I create.
Any suggestions?
Storing a surface in the filter class: The idea was I have the surface stored int he image filter class, and call one of the functions to manipulate the surface. The problem I had was that storing the manipulated pixels back on to the surface became cumulative. So each successive pass for each frame made the pixels brighter and brighter for instance when calling the Lighten function.
Passing a surface to the filter: The idea was that I could pass a source surface to the filter, and store the result in the filter's surface in the Go function, then call the filter.draw function in the ComposeFrame function of Game. The problem with this is the size of the filter's surface would have to match the surface being passed in. So the filter's surface would have to be resized for each different surface I wanted to pass through the filter. This would be slow always allocating and deallocating memory.
Passing a surface through the filter: There were two options here, one would have the same problem as storing a surface in the filter, where storing the converted pixels back onto the source surface would accumulate the result each frame. The second option was to just have the filter draw directly to the backbuffer, which provides the result I'm looking for, but doesn't feel right.
Passing a filter to a surface: What I would like is to have a filter be a class, where I just pass in the filter to the surfaces draw function, and then the surface will call the fitlers' Apply function and the surface will be responsible for putting the pixels on the back buffer and the filter will just work with the pixels passed to it. The problem is each filter needs a different set of inputs, so I'm not sure if this is possible. If I don't inherit from a base class, I would have to overload the Surface::Draw function for each type of filter I create.
Any suggestions?