I'm currently working on a Worms game which involves terrain deformation. I used to do it with .GetData, modifying the color array, then using .SetData, but I looked into changing it to make the work done on the GPU instead (using RenderTargets).
All is going well with that, but I have come into another problem. My whole collision detection against the terrain was based on a Color array representing the terrain, but I do not have that color array anymore. I could use .GetData every time I modify the terrain to update my Color array, but that would defeat the purpose of my initial changes.
What I would be okay with is using GetData once at the beginning, and then modifying that array based on the changes I make to the terrain later on by some other means. I do not know how I would do this though, can anyone help?
I've done a bit of research, and I have yet to find a solution to getting rid of any GetData calls every time my terrain is modified, but I have found ways to "optimize" it, or at least reduce the GetData calls as much as possible.
Crater drawing is batched, meaning that rather than draw each one as it’s created, I add them to a list and draw all of them every few frames. This reduces the number of GetData calls – one per batch of craters rather than one per crater.
After drawing craters to the render target, I wait a few frames before calling GetData to make sure the GPU has processed all of the drawing commands. This minimizes pipeline stalls.
If I have a pending GetData call to make and more craters come in, the craters will stay batched until the GetData call is complete. In other words, the drawing and getting are synchronized so that a GetData call always happens several frames after drawing a batch of craters, and any new crater draw requests wait until after a pending GetData.
If anyone else has any other suggestions I would still be glad to hear them.
Related
I am new to react native and I trying to optimize performance.
My Touch events are very slow and I was going through RN documentation on performance and they have mentioned to use requestAnimationFrame with this example
handleOnPress() {
// Always use TimerMixin with requestAnimationFrame, setTimeout and
// setInterval
this.requestAnimationFrame(() => {
this.doExpensiveAction();
});
}
Now, this description sounds very vague and hard for me to comprehend its usage
Like, I have this touchable event in my RN app
<TouchableWithoutFeedback onPress={() => this.touched(this.props.coinShortName)}>
Which calls this method
touched = (id) => {
this.setState({selectedPostId: id})
if (this.props.coinShortName == this.state.selectedPostId ) {
this.setState({stateToDisplay: !this.state.stateToDisplay})
}
}
Question: Can someone please tell me on how I need to/should use it in my app?
I'm going to convert my comment into an answer, so I can format it better and hopefully help someone in the future too. I don't expressly recommend marking my answer as correct, but I think this answer should be here alongside this question.
This article here should give you some backstory on requestAnimationFrame: http://www.javascriptkit.com/javatutors/requestanimationframe.shtml.
I would recommend reading the article I linked above and then read my answer after.
I will just explicitly mention that requestAnimationFrame could appear similar to setTimeout(() => {}, 0), but if you had a Zack Morris phone made in 1985, its "as soon as possible" might be 5 seconds later, thus making your animation look terrible, similar to when your character lags across the screen in a video game. The function may have been called at the correct time, but it did not actually execute at the correct time.
It can be helpful to imagine a collection phase and a rendering phase. I'm sorry, I don't know the exact terms for this stuff, but human eyes see smooth movement at I think 20 FPS, but what that means is you have 20 "frames", so it's like calculating something 20 times. It's like collecting a bunch of kids and pushing them into a bus 20 times per second. Pushing them into the bus is an event, and it's analogous to repainting your screen. Sometimes kids can get left behind and extra kids picked up next time, so you can imagine the gains to perceived smoothness of flow over time.
It's important to note that optimizations are being made with respect to the next repaint, or the next time the screen 'changes'. requestAnimationFrame does work under the hood to ensure the animation occurs at the correct time and is smooth, meaning the pixels were where they were supposed to be at the right time. (I think you would derive a lot of meaning if you checked out the definitions for "what is a janky animation", and look at some of the discussion around that. I mention that because we want to understand more about the repainting process and what kinds of things are important and why)
I recall that requestAnimationFrame can ditch calculations that would occur too late. For example, if you click the button and a pixel goes from 0% to 25% to 50% to 75% to 100% (some arbitrary distance calculation). We could say that after 1 second, the pixel should have travelled 50% of the distance and after 2 seconds, it should be at 100%, the final resting place.
It's more important that the pixels are in the correct place at the correct time than it is for them to travel to exactly every place they were supposed to. requestAnimationFrame is helping you do this. If the screen is about to repaint, and "it" needs to run a calculation that would take too long, "it" just ignores it and skips to the next frame. It's like trimming fat to keep on pace and therefore, avoid jank.
requestAnimationFrame is a solution for the same challenges whether it's in your web browser or iOS or Android. They all do this process of painting the screen over and over again. You could start calculating something needed for the next repaint but start too late so it's not done when the next repaint occurs.
Imagine your animation was smooth but your phone received 20 push notifications all of a sudden that bogged down the CPU, causing your animation to be delayed by 16.7 milliseconds. Rather than display the pixel at the correct place at the wrong time, requestAnimationFrame helps by making the pixel be in the correct place at the correct time, but it may do some magic and not even try to paint the pixel sometimes when it would have otherwise, thus saving performance and increasing perceived smoothness.
I just realized this is a wall of text, but I think it will be informational.
These repaints occur about 60 frames per second, so requestAnimationFrame could fire like 60 times a second when it calculates is the most optimal time. There are 1000 milliseconds in 1 second, so 60 FPS is one frame every 16.7ms. If the human eye perceives smoothness at 20FPS, then it means you could in theory repaint every 45ms or 30% as much, and the animation would still be smooth.
My definitions may be inaccurate, but I hope they can help give you a sense what is happening.
As mentioned , you need to wrap your expensive action in an instance of requestAnimationFrame.
Usage
<TouchableWithoutFeedback onPress={() => this.touched(this.props.coinShortName)}>
touched = (id) => {
requestAnimationFrame(() => {
this.setState({selectedPostId: id})
if (this.props.coinShortName == this.state.selectedPostId ) {
this.setState({stateToDisplay: !this.state.stateToDisplay})
}
});
}
<TouchableWithoutFeedback onPress={this.handlePress}>
handlePress = () => {
this.requestAnimationFrame(() => {
this.touched(this.props.coinShortName)
});
}
it would be event better if you removed the useless id parameter in the touched function by using directly this.props.coinShortName inside so you could write
handlePress = () => {
this.requestAnimationFrame(this.touched);
}
Anyway, the touched function doesn't seem to be really expensive so I don't know if it will solve your performance issue
I'm trying to get pixel data from my X11 instance, I've seen this thread (How do take a screenshot correctly with xlib?) and the double for loop is taking just too long for me (over a million loops, as the system I'm building requires the highest amount of efficiency possible, sitting around for 600 miliseconds is just not an option). Is there no way to just get a raw array of pixels to avoid the for loop? I know the XImage class has a "data" member which is supposed to contain all of the pixels, but the organizational system that it uses is foreign to me. Any help would be greatly appreciated! The best end game here would be for me to just be able to have X11 write directly to /dev/fb0
Now my method is:
libvlc_video_set_callbacks //set the lock,unlock,display callback functions
libvlc_media_player_set_position //goto the snap time
libvlc_media_player_play //start playing
then in unlock callback function invoke 'libvlc_media_player_stop' to stop the play, and save the data which provider by display callback function.
This method had succeeded some times, but more times it will take my whole program crash.
I know it looks a bit stupid, but I cannot found any frame by frame control function in the libvlc include files.
Actually, the libvlc has a really poor handling of frame by frame since it is not the way it handles streams. Therefore, frame by frame - when there is some - is quite hacky and can be rather ugly. Going forward or backward one frame is often achieved by computing the length between two frames, and jumping to the corresponding datetime.
The only frame-related function in the library is libvlc_media_player_next_frame which seems to be conditionally supported and it also seems that some development is being done to later support libvlc_media_player_previous_frame.
Therefore, your method is probably as fine as any other would be. An alternative would be to replace libvlc_media_player_set_position by libvlc_media_player_set_time if you want to be able to set your time to the wanted millisecond. Yet another one would be to slow the playback down before snapping. None of these methods is really efficient though, but there does not seem to be any cleaner way to do so.
I'm doing a project with a lot of calculation and i got an idea is throw pieces of work to GPU, but i wonder whether could we retrieve results from GLSL, if it is posible, how?
GLSL does not provide outputs besides what is placed in the frame buffer.
To program a GPU and get results more conveniently, use CUDA (NVidia only) or OpenCL (cross-platform).
In general, what you want to do is use OpenCL for general-purpose GPU tasks. However, if you are insistent about pretending that OpenGL is not a rendering API...
Framebuffer Objects make it relatively easy to render to multiple outputs. This of course means that you have to structure your processing such that what gets rendered matches what you want. You can render to 32-bit floating-point "images", so you have access to plenty of precision. The biggest difficulty is what I stated: figuring out how to structure your task to match rendering.
It's a bit easier when using transform feedback. This is the ability to write the output of the vertex (or geometry) shader processing to a buffer object. This still requires structuring your tasks into something like rendering, but it's easier because vertex shaders have a strict one-vertex-to-one-vertex mapping. For every input vertex, there is exactly one output. And if you draw GL_POINTS, it's not too difficult to use attributes to pass the data that changes.
Both easier and harder is the use of shader_image_load_store. This is effectively the ability to read/write from/to arbitrary images "whenever you want". I put that last part in quotes because there are lots of esoteric rules about data race conditions: reading from a value written by another shader invocation and so forth. These are not trivial to deal with. You can try to structure your code to avoid them, by not writing to the same image location in the same shader. But in many cases, if you could do that, you could just render to the framebuffer.
Ultimately, it's pretty much impossible to answer this question in the general case, without knowing what exactly you're trying to actually do. How you approach GPGPU through a rendering API depends greatly on exactly what you're trying to compute.
I am creating a pacman in c and currently I am usisng a single thread for each ghost and each ghost represents a '#' but when I run it all the screen gets full of ghosts and not all the ghosts move just one or two.
Im using this logic
create a struct of 5 ghost, each ghost contains the x,y position.
create an array of 5 threads and each thread implements one ghost
each ghost moves randomly on the screen, for each space that it moves I print
a space in the old position and then I print a '#' in the new position.
Could you provide me please an example of how to implement the movement of the ghost,
or the implementation Im doing is the correct way?
Thank you
One thread per agent is not a very common approach to building games. It quickly becomes unworkable for large scenes. The conventional solution is to define a state machine representing a ghost, with some kind of "advance" method that gives it a chance to adjust its internal state to the next time quantum. Create multiple instances of this state machine, and call all their "advance" methods on each iteration of the game loop. All of this can happen in a single thread.
There's quite a bit more to it than this, but it'll get you started.
Trying to update the screen simultaneously from several threads requires a mutex around the screen update code.