I have written a display manager for LWJGL (OpenGL in Java). Everything works very well except of the 3D rendering part.
The 3D rendering part uses a FrameBuffer and a Shader. After every resize i generate a new FrameBuffer and Textures with the new size. The Shader isnt using any resolution uniforms.
The main problem part:
When I resize my window, there is only the box of the old display size visible. The 3D object is rendered normally over the whole screen except of the box.
Keep in mind, 2D rendering, after screen quad rendring, is working well.
Here are two screenshots:
Normal Window
Resized Window
Would be nice to get some hints.
Edit: RenderBuffer size hasn`t been updated... FIXED
You also need to set the viewport to the size of your window or framebuffer. (see glViewport). Initially, the viewport will be set to the size of the drawable when the context is fisrt bound to, but it will never be implicitely updated at all.
You need to resize the viewport by calling glViewport whenever the size of the window changes.
Finally found the issue: when I was resizing my FrameBuffer, I missed to update the renderbuffer size, so the renderbuffer still was 800x600 but the screen was 1300 x 900
Related
however, i have a weird issue, when drawing, it seems the outside 1px of an image is stretched to fit a rectangle, but the inside is only stetched to an extend, i was drawing to 48x48 tiles, but drew a 500x500 tile to show the issue. [ 500x500 draws fine ]
the worst part seems to be, it chooses when to stretch and not to stretch. and also what to strech. im sorry this is hard to explain but i have attached a image that i hope does a better job.
it could just be misunderstanding how to use a draw with spritebatch
edit: Tile is 48x48 not 64x64, ive just been working all day.
This is because you are not rendering "pixel perfect" which means your image does not line up with the pixel grid of your monitor. A quick fix might be to set a linear filter for your textures, since by default it uses nearest and thus a pixel on the screen will inherit the closest color it can get. A linear filter will interpolate colors and make that line "look" thinner.
texture.setFilter(Texture.TextureFilter.Linear, Texture.TextureFilter.Linear);
If you are using texturepacker you can do this in one go by altering it's settings.
texturePackerSetting.filterMin = Texture.TextureFilter.Linear;
texturePackerSetting.filterMag = Texture.TextureFilter.Linear;
Or you could edit the atlas file itself by by changing the filter parameter to:
filter: Linear,Linear
This obviously costs more power since it needs to do more calculations for each pixel you drawn to the screen but I would not worry about this until your drawing is starting to get a bottleneck.
Another solutions is to draw pixel perfect which means you need to set your viewport to the size of the device gdx.graphics.getWidth, gdx.graphics.getHeight, in other words a ScreenViewport and draw your textures at exact sizes you want them. Of course this means a screen with more pixels sees more of your game world then a screen with less pixels and the more pixels a device has the smaller your textures will look. Another drawback of this is that you have to forget about any zooming or draw sprites for each level of zoom so they line up with the pixel grid of the device again.
Developing an app for Android and I'm required to have a fullscreen image rotate (spin around infinitely, pivoted at the centre of the screen) in the background.
I have tried rotating the ImageView using RotateAnimation which works well, except the image is cropped to the size of the parent view.
I have also tried expanding the parent view to a set size (750dp) but it doesn't work well across all the different screen sizes.
Does anyone know of an easy way to implement this, which would involve scaling to uniformly fit the screen size?
Cheers,
Dylan
Screenshot of the image:
I am trying to "resize" my game view within the screen using Libgdx. Indeed I need to let a black bar on the bottom and the left side of the screen. So as if you resize a square using your MS Paint or Gimp, I would like to do so with my game stage. (I've tried to upload a figure to set my issue clearer but apparently Stackoverflow forbids it for me)
I think I am mixing things up with Stage size, the Camera size and the Viewport. Any advice would be greatly appreciated !
If you are using stage then you can try to replace camera view your own with other viewport dimensions.
Camera newCamera = new OrthographicCamera(300, 200);
//... here is some other camera initialization code
newCamera.update();//recalculate camera matrices
stage.setCamera(newCamera);
//after that you may need to update sprite batch projection matrix
_gameStage.getSpriteBatch().setProjectionMatrix(newCamera.combined);
I'm developing 2D Side Scroll Android Game, using AndEngine.
I have problem with tiles quality.
If I will use DEFAULT texture option, for my texture congaing tiles, it doesn't look perfect, contours ARE NOT smooth, etc:
DEFAULT Texture options, uses such OPEN GL parameters:
new TextureOptions(GL10.GL_NEAREST, GL10.GL_NEAREST, GL10.GL_CLAMP_TO_EDGE, GL10.GL_CLAMP_TO_EDGE, GL10.GL_MODULATE, true);
But lately I realized, that if I will use such parameters (similar to BILINEAR parameters, except last one)
new TextureOptions(GL10.GL_LINEAR, GL10.GL_LINEAR, GL10.GL_CLAMP_TO_EDGE, GL10.GL_CLAMP_TO_EDGE, GL10.GL_MODULATE, true)
graphic looks smooth (i would say perfect, check image below)
Everything would be perfect, but while moving camera (Camera is chasing player) there are visible contours of those sprites, like for example on this screen:
I have been trying to use different OPEN GL parameters, but with no luck. I would be grateful for some help. With DEFAULT texture option, such problem doesn't exist, but quality is bad. Thanks.
Ps: I have been trying to cast integer on my setCenter method inside camera, but with no luck, some people were saying it should help, but it didn't.
This occurs because the function that is used for smoothing out the textures uses pixels that are outside of the pictures on the Texture Atlas. These are black by default so the pixels on the edges are poisoned by the black area outside.
I have temporarily fixed the issue by extending the picture an all sides by 1px and putting there a copy of the adjacent 1px line from the picture. Then I set my TextureRegion to contain only the middle of the picture with the padding being outside. The results are probably not perfect but the lines are no longer noticeable.
I have seen someone on the AndEngine forums say that in the newest version the problem is fixed, so you may try updating.
I've been trying to make off screen rendering to work, using Java3D 1.5.2. In my source code I've been trying to attach an extended Canvas3D that will do off-screen rendering to SimpleUniverse, but doing so will break the render:
62. // FOR SOME REASON THIS BREAKS RENDERING
63. universe.getViewer().getView().addCanvas3D(canvas);
The full source code is a bit too large to paste on StackOverflow so I made it available via Pastie over here.
Line 63 has been commented out and has the ordinary Canvas3D do on-screen rendering. It will render a cube and display this in a JFrame. However if you remove the comment the off-screen render will cause the on-screen one from not rendering. Also the off-screen rendering will return a "big black nothing" BufferedImage.
I'd like to know how to make the off screen rendering work, i.e. render the scene of a rotated cube to a buffered image. I've been looking at the Java3D provided example code for off-screen rendering and they do it as this as well (with the exception that they use the Raster object to render the off screen buffer back to an on-screen window).
It might be the physical dimension of the Screen3D that is wrong. The value is supposed to be size of the physical screen in meters. You can test with:
screen3D.setPhysicalScreenWidth(0.0254/90.0 * destWidth);
screen3D.setPhysicalScreenHeight(0.0254/90.0 * destHeight);
The values are from the top of the Screen3D javadoc. The problematic line worked together with the above code, at least for me :)
Setting the wrong physical dimension may also change the aspect ratio of the rendered image.