Tag Info

New answers tagged

4

You can reduce the instruction count by using vector operations: e.g. instead of edr = bool4((w1.x < w2.x) && ir_lv1.x, (w1.y < w2.y) && ir_lv1.y, (w1.z < w2.z) && ir_lv1.z, (w1.w < w2.w) && ir_lv1.w); you can write edr = (w1 < w2) && ir_lv1; Operators in HLSL ...


4

I got this working. It does not use the hqx filter, it uses the xBR filter (which I prefer). For me, this is not a problem. If you require the hqx filter then you'll want to convert the .cg files into their appropriate XNA equivalent. For completeness and searching reasons, I will be editing the question to be more concise and then posting all the relevant ...


1

In addition to the other answers here you can use dithering to some extent. Dithering is where the edge of an object's pixels are lighter/darker in color to match the background making for a softer edge. For example, say you had a 4 pixel square I'll aproximate with: OO OO If you were to move this 1/2 a pixel to the right, nothing would really move. But ...


0

Floating point is the normal way of doing this, especially if you're eventually rendering to a GL target where the hardware is quite happy with a shaded polygon with float coordinates. However there is another way of doing what you're currently doing but slightly less jerkily: fixed point. A 32 bit position value can represent values 0 through 4,294,967,295 ...


0

mouse_x,mouse_y = pygame.mouse.get_pos() color = some_surface_object.get_at((mouse_x,mouse_y)) will return array [0=>R, 1=>G, 2=>B] in demical values [122,25,224]


6

The sprite's position should be kept as a floating point quantity, and rounded to an integer only just before display. You can also maintain the sprite at super resolution and downsample the sprite before display. If you maintained the sprite at 3x display resolution,you'd have 9 different actual sprites depending on the subpixel position of the sprite.


14

One way in which many old-skool games solved (or hid) this problem was to animate the sprite. That is, if your sprite was going to move less than one pixel per frame (or, especially, if the pixels/frame ratio was going to be something odd like 2 pixels in 3 frames), you could hide the jerkiness by making an n frame animation loop that, over those n frames, ...


3

The only real solution here is to use bilinear filtering. The idea is to let the GPU compute the value of each pixel based on the four sprite pixels that are overlapping with it. It's a common and effective technique. You simply need to place the sprite on a 2d-plain (a billboard) as a texture; then use the GPU to render these plains. This works well but ...


16

There's a number of options: Do as you do. You've already said it doesn't look smooth. There are some flaws with your current method though. For x, you could use the following: tempx += speed * dt while (tempx > 0.5) move sprite to x+1 tempx -= 1 while (tempx < -0.5) move sprite to x-1 tempx += 1 this should be better. I've switched the ...


1

Use: pygame.Surface.get_at(x,y) to get a pixel RGBA value. http://www.pygame.org/docs/ref/surface.html#pygame.Surface.get_at



Top 50 recent answers are included