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...
Show What You Can Do
When looking to start or join a team online, people are always interested in seeing what work you've produced beforehand. The work doesn't necessarily have to be done in a game, but it should showcase your ability to create game quality assets.
Talk About What You Want To Do
If you're looking to recruit people for a team, talk about ...
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.
There are various scaling algorithms that are specifically crafted for enlarging pixel art for modern displays. They usually work with factors 2x or 3x and produce nice non-blurred and non-blocky results.
Take a look at this Wikipedia article, which has many examples.
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 ...
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 ...
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 ...
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 ...
From your link:
Next, we're calculating the line offset. We're dividing the pitch by
4; the pitch value is in bytes, but we're moving four bytes at a time.
It should be:
void putpixels(int x, int y, int color)
unsigned int *ptr = (unsigned int*)Screen->pixels;
int lineoffset = y * (Screen->pitch / sizeof( unsigned int ) );
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 ...
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.
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, ...
I found this code which seems to do what you want :
With the nearest algorithm, we fill each pixel of the scaled image using the nearest pixel from the source image. This leads to many possible artifacts.
With the linear algorithm, the goal is to look for each pixel of the scaled image where we are in ...