I have a very simple application in libgdx. It currently is supposed to cover half of the screen with pink texture. And it does that, the texture however is blinking. Basing on my own understanding of subject, as well as this thread:
LibGDX blinking
I need to enable double buffering. Or alternatively, write to my buffer. The thing is, either I am inept with google or it's very difficult to find any information how to manipulate buffers in libgdx. If someone could provide me with resources, explaining how to manipulate buffers, and how to create one, how to swap them with current display etc. I would be very grateful.
EDIT:
After searching the web some more, I found post on badlogic forum, claiming that libgdx has double buffering set by default. The question is, how does it work? When are the buffers swapped?
Libgdx has double buffering enabled by default (its really part of the underlying OpenGL infrastructure, not Libgdx). I don't think Libgdx exposes any controls over double buffering. There are some controls to disable vsync which might create some tearing, but are unlikely to be related.
The more likely way to get this behavior is if, somehow, your render method is only invoked once. This will draw into one buffer. Then, assuming render has become a no-op, nothing is drawn into the other buffer, they're switched, nothing is drawn into the original buffer, they're switched, etc. This can lead to the blinking behavior you're seeing.
If that guess doesn't cover it you'll have to provide more details. Which platform are you running on? Are you running a stable version of Libgdx or one of the nightly builds? How are you setting up the libgdx app configuration? What does your render method actually look like?
Related
I have been trying to "cut" an image for some time now, I ll explain why and what I tried.
So I wanted to create an hp "bar" except it's not a bar but a heart and so I though it would be easy all I had to do is have two pictures draw them on top of each other and then just cut one to make it appear as in hp was being lost, but I was not able to find a way to cut the image.
Setting the height just resizes the image as you might have guessed
I tried using textureRegion to kind of hack it but it didn't go so well
I found a method called clip begin which also uses scissors but for some reason that just doesn't seem to be working.
I might be using the clip begin wrong but I can't really find any real documentation on it, all I'm doing is:
image.clipBegin(x,y,height,weight);
image.clipEnd();
I almost forgot, I'm using a scene2d Image, might be a better way to go around it but not sure what that would be.
I would appreciate any ideas on how to do this, thank you.
You want to use the OpenGL Scissor support that Libgdx exposes. See the Libgdx Clipping wiki
and the Libgdx ScissorStack documentation.
The API isn't particularly friendly (its designed to support dynamically pushing multiple constraining rectangles, which as far as I've seen, isn't used very often).
The important point to remember with the scissor stack is that it only applies to actual draw commands that get issued. Since most APIs try to batch up draw commands, this means actual drawing might not happen when it looks like it should happen. To ensure clipping is happening you must flush any buffered draws before pushing the scissor (otherwise the wrong thing might get clipped) and you must flush any draw calls before popping the scissor (otherwise things you want clipped might avoid the scissors).
See libgdx ScissorStack not working as expected or libGDX - How to clip or How to draw on just a portion of the screen with SpriteBatch in libgdx? or Making a Group hide Actors outside of its bounds.
I'm currently working on a project where I need to plot the predicted footprint of a satellite on a mercator-projected world map with possible scaling/cropping/etc. done to the map.
I thought Cairo would be a good library to use for this purpose. There are Java-bindings available for it. However, I just can't find a way to make it render onto a SWING GUI (e. g. onto the surface of a JPanel). I thought about rendering into a byte buffer and plotting it out pixel by pixel using Java2D, but I can't find any API call to make Cairo render into a buffer (which is weird, as this is one of the most fundamental functionalities I'd expect to get supported by such a library).
Any way I can achieve this? I know there is Java2D, but it is fairly basic. I'd really appreciate a more powerful, widespread, well-tested, high-quality, free (LGPL) graphics library for this purpose. Cairo would be such a perfect fit, if I could get it to work with SWING somehow.
Thank you very much for your proposals.
One of the fundamentals in Cairo is that any non-abstract image context is bound to one of the supported back ends.
I've never tried the Java bindings, but it is likely they are a thin layer, not providing a a new surface type - you should use the "Image Surface" type.
On the C documentation for the Library, there is a "cairo_image_surface_get_data()" call
(here: http://cairographics.org/manual/cairo-Image-Surfaces.html ) which gives one acess to the buffer.
Maybe the bindings didn't expose this to Java due to the low level memory access required to actually use its contents. If that is true, then I propose you the following work-around:
(1)Render your results to a Cairo Image Surface, (2) Write a temporary file with the surface contents,(3) Read and display the temporary file with the Java 2D API.
Here is a example.
I found this examples on http://java-gnome.sourceforge.net
It create a gtk window, and actually a gtk DrawingArea widget, the onDraw() event uses cairo.
I compiled and run it on linux, it works good.
however java-gnome seems only have linux binary. Maybe somebody could make a windows binary, but need some work.
It is a gtk window, so have nothing to do with swing.
Maybe you don't need swing if gtk(java-gnome) can fit your needs.
If you must use swing, you can use cairo to render to a image in memory, then show it to JComponent by somthing like overriding paintComponent() method. I don't know the performance.
I've created a prototype for a 2d android game using the android canvas object. Unfortunately, the performance is suffering greatly due to the large number of bitmaps that need to be redrawn frequently.
I'd like to migrate the drawing code to opengl, but I have no experience with it, and I'm having a difficult time getting the views configured properly. I've tried a wide variety of methods, but I'm not sure if the view configurations were wrong, of if the drawing functions didn't match.
Since most of my touch events are based on the coordinates, I'd like to have the opengl canvas view's coordinate system match the touch event coordinate system if possible. This would allow me to reuse a lot of code and avoid a lot of coordinate translation.
Can someone provide code or a link to code that would accomplish setting up a view and drawing a textured element?
I do not know how this question got overlooked but if you want a light introduction to OpenGL ES then you should take a look here. It is pretty good an explains things slowly enough that it is reasonably easy to understand.
I want to be able to draw consecutive bitmaps (of type BufferedImage.TYPE_INT_RGB) of a video as quickly as possible in java. I want to know the best method in doing so. Does anyone have any advice where I should start? From what I've read, 2 options are:
1) Use GDI/GDI+ routines in a JNI dll working with JAWT (Im on Windows)
2) Use Java3D and apply Textures to a Box's face and rotate it to the camera
Im interesting in any advice on these topics as well as any others.
I have done a decent amount of GDI/GDI+ programming in VB when i created an ActiveX control, so using GDI should be painless, but im guessing Java3D will utilize the GPU more (I could be wrong) and give better performance. What do you think? GDI and JAWT with my previous experience, or start and new API journey with Java3D.
Thanks in advance. :)
To obtain a fluid animation (if it what you want to get), you need to use double buffering. For doing this, you will need to create a new java.awt.Image (or a subclass like BufferedImage, or if you want OpenGL accelerated processing, VolatileImage) for each frame you want to display. If you haven't already done so, call Image.getGraphics() to get a java.awt.Graphics object (can also be useful to add your content to the Image). At the end, when you hidden Image is complete, call Graphics.draw() to replace the current display smoothly.
VolatileImage is OpenGL accelerated and much faster. When VolatileImage.getGraphics() is called, it actually returns a Graphics2D, which is also part of the accelerated graphic pipeline.
It works on Windows, Linux and Solaris, but you need to have OpenGL drivers installed for your graphic card.
Some additional refs:
Accelerated graphic pipeline:
http://download.oracle.com/javase/1.5.0/docs/guide/2d/new_features.html
http://www.javalobby.org/forums/thread.jspa?threadID=16840&tstart=0
Double buffering:
http://www.java2s.com/Code/Java/2D-Graphics-GUI/Smoothmoveusingdoublebuffer.htm
http://www.heatonresearch.com/articles/23/page2.html
http://www.javacooperation.gmxhome.de/BildschirmflackernEng.html
I'm writing a game in Java, LJGWL (OpenGL). I'm using a library that handles a lot of messy details for me, but need to find a lot faster way to do this.
Basically I want to set every pixel on the screen to say a random color as fast a possible. The "random colors" is just an Array [][] that gets updated every 2-3 seconds. I've tried drawing rects and using images, both are pretty slow for what I want to do.
I think I want to learn how to write a GPU shader? That is the fastest way to do this? LJGWL exposes OpenGL api to java. Any basic tutorials on how to get started with OpenGL shaders? Or should I dynamically create a texture of some sort and then just throw up the entire texture, would that be faster?
If it were the case that you were statically displaying the same image, than using a texture or display list would suffice. But as you want to frequently update it, shaders really are the best option. Shader code executes on the GPU and modifies data in GRAM, so you have no bottle neck transferring from CPU to GPU. The next best thing would probably be a Pixel or Frame Buffer Object. Buffer Objects let you read/write to GRAM via DMA (without having to go through the CPU) so they can be pretty fast.
I haven't written any shaders yet, so I can't recommend any good resources. But SongHo's OpenGL pages are a good place to learn about Buffer Objects. (His examples are in C++ though)
Textures are the fastest way to draw something on screen, draw a texture mapped quad into the screen, it should be fast enough. When you need to reupload the texture data, use glTexSubimage2D to update it.
No need to use shaders.
I've yet to do any work with shaders in OpenGL, but given the same scenario in multiple occasions, I handled it with a texture I threw up across the screen on top, and it worked quite effectively.
I don't know how you are drawing your pixels exactly, but this limit you hit could be because of the amount of data you transfer (inefficiently?). Updating a screen full of pixels every 2-3 seconds shouldn't be hard at all. Although shaders bring you closer to the graphics card, they will never make inefficient methods fast, so...
Why is your code so slow?
What code? What code exactly did you try? What texture did you use, render to, ...?
Is it slow? How slow? How fast do you expect it to be?
How quickly can one get 1920x1080(?) pixels in video ram, what's your hardware, drivers, OS?
I think you need to edit/repost before we can help you solve your problem. Just because it is slow, is no guarantee at all that shaders will even be one bit faster.