Ok I am developing a game using Libgdx and everything was fine until I noticed that when my character moves, its texture becomes slightly blurred at the edges, as if it is blending in with the background in the android version. There seems to be a slight graininess to the image as well which becomes more noticeable when it moves. I THINK these problems might be related to texture filtering, but wanted to come on and ask here to see if anyone had experienced this before. Any insight appreciated.
EDIT: Here is an the image, you can see it's quite grainy on the whole. When it moves the graininess seems move, it is hard to describe, but it looks as if the pixels on the eater are moving relative to each other slightly.
The way I draw it is pretty straight forward the following is called in my render method:
idleTexture = new Texture(Gdx.files.internal("images/GreenGuy.png"));
spriteBatch.draw(idleTexture, x, y*ppuY,width*ppuX,height*ppuY);
All other work I look at does what I am doing, but I am not totally happy with the results. I have tried changing between linear and nearest filtering but this did not change anything. I have also tried just using a smaller image instead of shrinking a large one, but I still get the same problem of the pixels not remaining relatively static while the character is moving.
Related
I'm following a Pygame tutorial on YouTube published by Clear Code. So far it's gone well but I've run into an inconsistency between the demo on the video and the behaviour of my code, I'm pretty sure I'm doing exactly what the tutorial instructs, but my results are different.
I'm attempting to draw a border around a rectangle, the rectangle was created from a surface that contains some text as follows.
test_font = pygame.font.Font('font\Pixeltype.ttf',50)
score_surf = test_font.render('My Game', False, 'Black')
score_rect = score_surf.get_rect(center = (400,50))
#Later in the main loop
pygame.draw.rect(screen,'Pink',score_rect)
pygame.draw.rect(screen,'Pink',score_rect, 6)
My understanding is that the first pygame.draw.rect should colour in the area of the score_rect, and the second should create a border that goes slightly outside the area of the score_rect. This should leave a bit of pink visible all the way around the text. In the video I can see this happening, but when I run the code on my system the second pygame.draw.rect that specifies a border width doesn't seem to have any effect.
I've experimented a bit by removing the first pygame.draw.rect, this works mostly as expected I get a pink rectangular border around my text, but this border is strictly insisde the score_rect.
According to the Pygame documentation specifying the width argument should cause the border to go slightly outside the score_rect. However I'm not seeing this behaviour.
Link to Pygame documentation I'm reading
https://www.pygame.org/docs/ref/draw.html#pygame.draw.rect
Link to Youtube video I'm following, and location in video
https://youtu.be/AY9MnQ4x3zk?t=4879
Edit: Sorry I forgot to note my software versions
Pygame: 2.1.2
Python: 3.10.2
OS Windows 10
Any help would be appreciated.
I've come across people asking this exact question on other sites (not in a way that's very searchable, don't worry), so I'm mainly copy pasting my last answer.
In a recent version of pygame, draw.rect was changed to give "actual rectangles." This has an advantage of looking cleaner in many situations, and the algorithm for them is now significantly faster, helping performance.
I actually talked to someone with your exact same issue (like coming from the same tutorial) on discord, and we decided to use a rect.inflate() call to grow the rectangle out before drawing it behind the text.
For example, you could do something like
pygame.draw.rect(screen, 'Pink', score_rect.inflate(10,10))
Instead of both Clear's rect calls.
Or if you want to preserve the slight corner rounding you could do
pygame.draw.rect(screen, 'Pink', score_rect.inflate(10,10), border_radius=3)
So this just uses the return value of a Rect.inflate call instead of the original Rect itself. Inflate takes an x margin and a y margin, and returns a Rect larger/smaller by those amounts, but still centered in the same location.
So I am making this horizontal scroll site which has a ton of images. I planned on using svgs for the entire site, but with only 20-30 svg images of medium to high complexity used in the page, and chrome already seems to be showing som jank and high paint times for scroll (and firefox is even worse, though safari seems to do a lot better).
Scroll timeline
View the site (scroll works on mac only, windows users can use arrow keys)
My question is, if I were to use pngs instead of svgs, would it reduce the paint times and hence the jank? Why is the browser struggling with only around 20 odd svg images?
As was my doubt, the problem turned out to be something completely different. Browsers are more than capable of handling multiple vector images. But what they aren't good at (and understandably so) is at redrawing those images very often.
Problem
My long horizontal scroll site was quite wide (30,000px). I had a background-color property applied to one of lower z-index'ed div's to represent the sky throughout the scroll site. I didn't want the sky to stretch the entire 30,000px since it essentially didn't change much, and hence gave it viewport width and height, with:
position:fixed;
Not a very smart move. Turns out that this property was causing my document layer to be repainted on every frame. Initially I though it was normal for browsers to do so on scroll, since Robby Leonardi's site, which I used as reference also repainted every frame.
Solution
Thanks to this article by one of the chrome dev tools developers, I set aside conventional wisdom, and make the sky layer
position:absolute;
and stretched it the entire site width, and boom! The paint rectangles were gone. And the scroll performance was smoother than butter.
Other solutions I tried
Hiding elements not near the viewport to make painting lighter, as suggested by #philipp, but didn't yeild any appreciable difference. Also, it felt super-hacky, and it wasn't targeting the root cause of the problem.
I tried modularizing my site into scenes and using translateZ(0) hack on each scene so that only the smaller scenes get repainted instead of the document. This actually helped quite a bit, and scroll was decent. Then,
I gave all the svg images their own layer by using translateZ(0). I started getting FPS of around 60 now, but again, this wasn't the right way of doing things.
I once had a similar thing. The SVG was 10 or more times as wide as the one shown above, it contained ~20k elements and was about 3MB in size. The only Thing what brought back performance (since it was a jump and run game) was an algorithm which was able to find all elements whose bounding box overlapped the viewport. With this I could use display: none; to hide everything what is invisible.
That reduced the amout of visible elements to ~150 per frame and the game ran again fluently.
I used a balanced binary tree (avl tree) and a one dimensional range query, since the height of the viewport was always the same as the image.
Good luck!
[EDIT]
Forgot to leave something like an anwer. From my Experience are large/huge SVG Graphics a bottleneck in rendering, especially if there is a lot of scripting happening. If you do not need any Interactivity with the elements from the Graphic, so nothing than a large Background Image, I would recommend to use a Tile map, based on PNG images, that is the standard way in Jump'n'Run games with huges »worlds«, so you can gain perfomance in two Points:
Rendering is faster,
You can »lazy ajax load« tiles, depending on visibility, to prevent users to download the »whole world« at startup.
Additinally you could use something like PIXI.js to render with WebGL, what will push the performance drastically and with it comes support for Tilemaps and Spritesheets.
If you insist on the advantages of Vector Grafics (Scaling, Interactivity) than you need to find a way to hide as much elements as possible to keep the frame rate high.
when using DisplacementMapFilter along with perlinNoise i can get very realistic water effect
like the one presensted here
problem is it works nicely only with small pictures, using it with big pictures (like 1024x768 pix) is too heavy, specially on mobile devices and
that's why i was hoping to find a away to apply this effect only on random parts of the picture (in loop, each time other random part of the picture is effected)
is it possible?
I think only applying the effect on random parts or partially each frame will look strange (I think you will see the "cheating").
Have you tried generating a displacement map image with half the resolution of the picture and then scale it up (with smoothing turned on) before using it as a displacement map? Maybe the lower resolution won't be that noticeable?
I am working on a map application and I have come across an issue with how my tiles are laying while scaling.
Here is a basic look at my structure:
There is obviously a lot more going on, but you get the idea. Now, I scale the Map App Sprite to zoom in. When that scaling occurs, there is a gap between each tile.
You can see the gap where 4 tiles meet here:
I am caching everything as a bitmap. For each Layer (which all extend Bitmap), I have smoothing set to true and pixelSnapping set to PixelSnapping.ALWAYS (pixel snapping shouldn't help here, but it shouldn't hurt either).
Does anyone have any suggestions on how to fix this issue?
(For the sake of completeness, the Map app is built entirely using AS3 and it is embedded in a Flex app)
Using integers for tile x,y locations and calculating those locations correctly is most likely the fix here, unless the images have seams in them!
The code that calculates and sets the x,y locations would be needed to properly pinpoint the issue in the code.
But, also if you are scaling that container sprite, you would want to ensure that you scale so that the width/height of a tile is an integer value.
For example, if you scale your sprite that contains these tiles, the widths/heights of the individual tiles might not always be integers, therefore creating those seams you see.
What you could do in that case is do your scaling by adjusting your width/height values by integer values, taking into account proportions, as opposed to using scaleX and scaleY on your container sprite.
Without seeing your code it's difficult to be sure, but it is possibly just a visual artifact due to scaling - eg: a 250px wide bitmap scaled to 155% should be rendered at 387.5px wide but thats impossible so its rendered at 388px wide - with the 0.5px part rendered as 1px at 50% alpha to give 'appearance' of 0.5px.
Ensuring scaled bitmaps widths/heights are always integers may solve it?
This looks like a rounding error.
Without code it's hard to know: it would be a great asset to you and us if posted a barebones example of your tiling class. In the process of subtraction you may very well discover your solution.
I'd offer that you should test what happens when you scale and algin four 100x100 bitmap images at various fine grain steps, to detect if it's a Flash rendering issue or a defect in your class.
I'm new to canvas, so pardon the beginner question. I'm trying to animate a square on a canvas that changes colors, rotates, and scales up and down (this is just for practice). I'm just trying to grasp all of the concepts and create an example that does all of them at once.
What I want it to do is scale up to a certain amount, then once it reaches that amount, it scales back down to the beginning amount (and then repeats). The same goes for the color (continue animating, then go backwards through the colors). How can I accomplish this?
Here's an example of my code that I wrote:
http://jsfiddle.net/ggsFJ/1/
You'll notice a couple bugs:
Once the color gets to yellow, it stops animating.
The scaling obviously doesn't work.
The rotation isn't either clearing the canvas fast enough or something, because it's showing a trail of positions.
Where can I find some resources on accomplishing this? Any help is appreciated.
There's one small problem that's causing all the other problems (well, apart from the yellow - I'm not experiencing that particular one):
ctx.restore;
That line does nothing. You need to call ctx.restore using parentheses. Once you do that, the scaling works, and clearRect() will clear a non-transformed rectangle:
ctx.restore();
And here's the updated demo.
The problem I can see is with your restore method call.
You are just saying ctx.restore (possibly by mistake). It should be ctx.restore();