The attenuation function you've got,
att = 1.0 / (1.0 + 0.1*dist + 0.01*dist*dist)
is a fairly common one in computer graphics - or, more generally, 1.0 / (1.0 + a*dist + b*dist*dist)) for some tweakable parameters a and b. To understand how this curve works it's helpful to play with the parameters interactively. This curve is nice because it approaches ...
Your problem isn't moving the camera in full-pixel increments. It's that your texel-to-pixel ratio is slightly non-integer. I'll borrow some examples from this similar question I answered on StackExchange.
Here's two copies of Mario - both are moving across the screen at the same rate (either by the sprites moving right in the world, or the camera moving ...
This article gives some useful explainations, even if that's before 4.3 came out:
If you’re going for the “pixel art” look then the camera’s
orthographic size is of critical importance; this is the trickiest
part of nailing 2D in Unity.
The orthographic size expresses how many world units are contained in
the top half of the camera projection. ...
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 if ...
I'm currently making a game that has to run on a wide variety of display sizes and aspect ratios, and it hasn't been a very easy process. In addition, if you're making things in pixel art, and you want to keep the pixel art feeling while supporting many resolutions, you're walking into a world of pain, so be prepared.
In my opinion, there are several things ...
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, ...
Found a solution from some resource. Go to Global Game Settings, then go to any platform spoiler(for example "Windows" or "Android"), there choose the spoiler titled "Graphics" and toggle "Interpolate colors between pixels" off. Have fun :)
The quick-and-dirty solution would be to use a camera filter effect. The color correction curves filter might do what you want. Move the end-points of the R, G and B curve down, but the blue-curve a bit less. If you don't want it to affect some objects (like your GUI, for example), render them with a different camera.
But the problem with this is that you ...
Talking about the "best choice" is always difficult, as long as you did not specify the task that you intend to perform in all detail.
But here are several aspects to consider. First of all: Java is not C. The memory management is completely different, so one has to be very careful when trying to apply insights from one programming environment to another.
Consider actually generating the scaled down versions at development time, and including them directly in the game as a resource. Do this with Photoshop or whatever tool you find creates what you like. Then have the game dynamically select the right art set appropriate to the current resolution.
Here are a couple of reasons you might do this...
This is called mipmaping, It looks like you are missing out on mipmaping for your textures. this causes a huge impact on visuals. And when it comes to mipmaping Normals, Specular and other "information" textures, it gets quite tricky.
the reason for this is that when objects gets further away, the gpu has to take this into account and calculate the ...
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 ...
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 ...
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.
Nobody wants to deal with having to manually scale up every sprite; not only is it a sloppy workspace but it yields to be very unprofessional. I found a solution when turning off interpolation in global game settings didn't work.
:) I hope this helps you in your future endeavors.
When the sprite is obscured by an object, you could make that object transparent:
You can make a sprite transparent in Unity by setting the alpha-value of the sprite color.
Color tmp = sprite.GetComponent<SpriteRenderer>().color;
tmp.a = 0.5f;
tmp.GetComponent<SpriteRenderer>().color = tmp;
Another option is to just draw the outlines when the ...
You're not working with bitmaps here. The graphics object you're using uses vector graphics. So basically you're painting a lot of rectangles to your mask...
The only reasonable way to determine whether or not your mask is entirely filled would be to render it to a BitmapData (using BitmapData.draw) and then iterate through the pixels until you hit a ...
These are all good answers but nobody explained the reason why you need to access the pixels in the way you do. The pixel data is a one dimensional array. For a 10x10 screen, the following is how you can visualize the data being set up.
// This is how it is actually setup
unsigned int data;
// This is how people envision it being setup
unsigned int ...
In the pixel shader you could pass in a 256x256 Texture2D with the pallet colors all lined up horizontally in a row. Then your NES textures would be converted to direct3D Texture2Ds with ever pixel converted to a 0-255 index value. There is a texture format that only uses the red value in D3D9. So the texture would only take up 8bits per pixel, but the ...
Textures mapped onto the surfaces of 3D geometry were developed to represent, well, surface texture. This type of detail usually doesn't align precisely with the grid of screen pixels, due to varying object sizes, distances, orientations, and camera perspectives, so it doesn't include any built-in features to snap the sampled texels to screen pixels. In fact,...
It seems like you have 2 questions here: 1. Why doesn't this code change the surface? 2. Is there a way to do this faster?
Why doesn't this code work?
For me, opening a window, grabbing the screen surface, and writing to the pixels with the function you have there works perfectly fine, so the problem is likely not in your SetPixels function. Instead, it's ...
If you want to draw a line "by hand" then you can use Bresenham's Algorithm.
The algorythm take two 2d points and draws a line.
So given point A and a length L , here is how you compute point B to draw the line from A to B (depending on the axis: x from left to right, y from down to up)
B.x = cos(Angle) * L + A.x;
B.y = sin(Angle) * L + A.y;
First, I would like to point out that doing rotation for a bitmap image is slightly different from doing it in OpenGL or DirectX because the rendering API will usually take care of a lot of the details. Two reasons why this is the case
Using a rotation matrix that have a sin/cos will often result in fractions
that cannot be indexed directly in the buffer. ...
If you don't really care about texture memory usage (and the idea of blowing an insane amount of texture memory to achieve a retro look has a kind of perverse appeal) you could build a 256x256x256 3d texture mapping all RGB combinations to your selected palette. Then in your shader it just becomes one line of code at the end:
return tex3d (paletteMap, ...
In one of my voxel engines, the voxel block explosion was done by creating a defined amount of minature blocks at the explosion point, and applying physical properties to them, eg velocity and gravity. Then, set them at random directions, and draw them. So, the actual voxel model wasnt really being disintegrated, but the voxel particles gave that impression.
In your main ApplicationListener where you create a camera object there will also be a resize method. If not override/implement it. It takes two arguments and when the window is resized these will be the dimensions of the newly resized window. Just set the cameras size to the new window size and call camera.update(); Should sort it! (I assume you are using ...
Sure. Figure out which portions of the screen you want to render at what resolutions, and render them into FBOs of appropriate sizes.
Once you have your different elements rendered into separate FBOs, you can then composite them together into the main framebuffer using glBlitFramebuffer().
Or alternately, if you don't want to composite them together as ...