 Show Posts
|
|
Pages: [1] 2 3 4
|
|
5
|
Game Development / Newbie & Debugging Questions / Re: Bayer ordered dithering
|
on: 2013-05-06 18:36:38
|
|
Yeah the threshold values range from 1-64, so presumably it breaches its respective channel fairly often which explains the artifacts, but I'm not entirely sure how to normalise the threshold value. I've tried dividing the value by 64, which is the highest value that is held in the matrix, although I'm working in whole numbers and only one instance would yield 1 and the rest would be 0.
|
|
|
|
|
6
|
Game Development / Newbie & Debugging Questions / Re: Bayer ordered dithering
|
on: 2013-05-06 16:17:30
|
|
The closest colour rounding seems to actually be working before adding the threshold. As the colour's stored as an integer it performs the division first and rounds that result and then multiplies. So the end value is actually floored to the nearest 64 in this case. For example:
140 / 64 * 64
2 * 64
= 128
So 140 becomes 128 when floored to the nearest 64. Sorry if I'm teaching you how to suck eggs, I'm just making sure.
|
|
|
|
|
8
|
Game Development / Newbie & Debugging Questions / Bayer ordered dithering
|
on: 2013-05-04 18:39:08
|
Hi all, I'm attempting to add a stylised order dithering effect on an image although I've been met with unexpected results. I have an 8 by 8 threshold matrix as follows: 1
2
3
4
5
6
7
8
| int[] dither = new int[] { 1, 49, 13, 61, 4, 52, 16, 64,
33, 17, 45, 29, 36, 20, 48, 32,
9, 57, 5, 53, 12, 60, 8, 56,
41, 25, 37, 21, 44, 28, 40, 24,
3, 51, 15, 63, 2, 50, 14, 62,
35, 19, 47, 31, 34, 18, 46, 30,
11, 59, 7, 55, 10, 58, 6, 54,
43, 27, 39, 23, 42, 26, 38, 22 }; |
I just found this on the wikipedia page for ordered dithering and have been following the explanation in order to produce this effect myself. The algorithm producing the effect from this matrix is as closely resemblant of that explained in the wikipedia page and is as follows: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| int w = image.getWidth();
int h = image.getHeight();
int bd = 64;
for(int y = 0; y < h; y++) {
for(int x = 0; x < w; x++) {
int c = pixels[y * w + x];
int d = dither[(y & 7) * 8 + (x & 7)];
int r = ((c >> 16) & 0xff) + d;
int g = ((c >> 8) & 0xff) + d;
int b = (c & 0xff) + d;
newpix[y * w + x] = 0x000000 | closestCol(r, bd) << 16 | closestCol(g, bd) << 8 | closestCol(b, bd);
}
} |
This is just the method that reduces the amount of colours available in each channel: 1
2
3
| private int closestCol(int c, int b) {
return c / b * b;
} |
The above code simply adds the corresponding value from the threshold matrix to the image data and then attempts to find the nearest colour to it after rounding. The issue is that the dither values are quite high and saturate the channel of the pixel. I've tried averaging the channel colour with the corresponding dither value but that makes the screen far darker than it should be. Is there a detail that I'm missing whereby it adds the effect without harshly altering the tone of the image? Just for reference, I've been consulting with this page: http://en.wikipedia.org/wiki/Ordered_ditheringHere's a before and after dither comparison so you can see the results: http://i.imgur.com/9SWukYS.pngThanks, Paul |
|
|
|
|
10
|
Game Development / Game Play & Game Design / Re: Trying to pixelate a section of an image
|
on: 2013-04-18 21:24:31
|
Thanks for both your replies.  I've substituted the single colour divides and used the components and it works great. I was just also wondering whether the magnification of the image is expected or whether I've glossed over another detail. :p Normally when I see pixelation the area of the image that's been pixelated is to scale with the rest of the image. |
|
|
|
|
11
|
Game Development / Game Play & Game Design / Trying to pixelate a section of an image
|
on: 2013-04-18 20:38:12
|
Hi all, I've been looking around for a premade algorithm to pixelate an image or something similar that I could expand on although I've only been able to find descriptions of the algorithm so I've attempted to make it. What it does is loops through every pixel in a BufferedImage, loaded from a 16-bit PNG image file (byte for each component) and it divides the current X and Y components by the square size . From here it performs a further nested for loop to total the pixel colours in the block that this pixel is in. It then divides by the block size, which is represented by the "pp" field, except it's squared because it samples pixels in a square along the X and Y axes. According to a few explanations I've read this should give me the average pixel colour for this block and every pixel in this block should be coloured in it. The algorithm I've written works somewhat in that the general shape of the image is preserved after the pixelation with far less detail, as is expected. The problem is that the colours are completely wrong and I'll show you how in the image below: http://i.imgur.com/Ezfp4W8.pngHere there's just a picture of a hamster I found. The algorithm magnifies the area by a sort of scale factor. Also here's the algorithm: http://www.java-gaming.org/?action=pastebin&id=544Can anyone spot why the colours aren't averaging out right? Thanks Paul |
|
|
|
|
12
|
Game Development / Game Mechanics / Re: Rotation matrices
|
on: 2013-04-04 05:46:49
|
Cheers for the reply. Yeah, I've found a few definitions through google but it's harder to find an explanation of the underlying maths. It's got such a broad definition that it's quite hard to find a clear relevant explanation. |
|
|
|
|
15
|
Game Development / Newbie & Debugging Questions / Re: Euler angles/3D rotation problem
|
on: 2013-04-04 02:18:46
|
Thanks for your reply. I've added those checks, but it seems to still glitch. I think it may be the X axis rotation that's causing the problems. If I drag the mouse down, the camera doesn't appear to move down at all and when I drag the mouse up it's very sensitive and spins around quickly and then continues to spin after I've stopped moving the mouse. |
|
|
|
|
16
|
Game Development / Newbie & Debugging Questions / Re: Euler angles/3D rotation problem
|
on: 2013-04-04 00:56:22
|
Sorry to keep posting, I've just realised something else. I've just replaced the contents of the method with this: 1
2
3
| GL11.glRotatef(xrot, 1.0f, 0.0f, 0.0f);
GL11.glRotatef(yrot, 0.0f, 1.0f, 0.0f);
GL11.glRotatef(zrot, 0.0f, 0.0f, 1.0f); |
But the problem persists, so it must not be the rotations that cause the problem. |
|
|
|
|
18
|
Game Development / Newbie & Debugging Questions / Re: Euler angles/3D rotation problem
|
on: 2013-04-03 23:18:15
|
Cheers for the reply. Yeah, I've got a few optimisation methods in mind. I'm just stumped by this unexpected transformation it's returning. It looks fairly straight forward in the article. I even double checked that all the matrix entries were being multiplied correctly. I'll give your implementation a look. Thanks. |
|
|
|
|
19
|
Game Development / Newbie & Debugging Questions / Euler angles/3D rotation problem
|
on: 2013-04-03 20:03:45
|
Hi all, I've been trying to make a 3D camera using Euler angles and I've been getting some unexpected results. I'm using LWJGL and I've plotted out a very basic flat scene to test whether the camera's working properly. I used the algorithm at the end of the FAQ question below to create and multiply the 3 rotation matrices X, Y and Z. http://www.cs.princeton.edu/~gewang/projects/darth/stuff/quat_faq.html#Q36To transform to the perspective of the rotated viewport I have the method below: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| public void transform(Player player) {
float xcos = (float) Math.cos(Math.toRadians(xrot));
float xsin = (float) Math.sin(Math.toRadians(xrot));
float ycos = (float) Math.cos(Math.toRadians(yrot));
float ysin = (float) Math.sin(Math.toRadians(yrot));
float zcos = (float) Math.cos(Math.toRadians(zrot));
float zsin = (float) Math.sin(Math.toRadians(zrot));
float[] mat = new float[16];
mat[0] = ycos * zcos;
mat[1] = -ycos * zsin;
mat[2] = ysin;
mat[4] = xsin * ysin * zcos + xcos * zsin;
mat[5] = -xsin * ysin * zsin + xcos * zcos;
mat[6] = -xsin * ycos;
mat[8] = -xcos * ysin * zcos + xsin * zsin;
mat[9] = xcos * ysin * zsin + xsin * zcos;
mat[10] = xcos * ycos;
mat[3] = mat[7] = mat[11] = mat[12] = mat[13] = mat[14] = 0.0f;
mat[15] = 1.0f;
GL11.glMultMatrix((FloatBuffer) BufferUtils.createFloatBuffer(16).put(mat).flip());
} |
With xrot, yrot and zrot being the rotation angles in degrees. I have some other methods that just add to these values to add/subtract from the angles. The results are fairly hard to describe. When I only change one rotation angle the scene seems to rotate correctly, but when I add a second the scene seems to spiral out of control. Can anyone spot any errors that I've made? Thanks |
|
|
|
|
25
|
Game Development / Game Mechanics / Re: How to project a 3D point on to a canvas
|
on: 2013-02-25 22:51:45
|
Hi all again I've still got this problem. I've attempted to change a few things, although they didn't really help. The problem remains that when the point moves behind the viewport, it reappears in the opposite corner and moves towards the point to infinity. I tried adding the Z component to this statement: 1
| if(transPos.getX() < -1 || transPos.getX() > 1 || transPos.getY() < -1 || transPos.getY() > 1) continue; |
Although it didn't seem to solve my problem, however it did clip points further out in the scene. Does anyone know of any source code where something similar has been achieved and is working (perspective projection of a 3D point on a 2D canvas)? If anyone could post a source I'd really appreciate it. I'm reading from a few different sources, although from what I'm gathering from them all collectively doesn't mention a glitch of this nature. |
|
|
|
|
26
|
Game Development / Game Mechanics / Re: How to project a 3D point on to a canvas
|
on: 2013-02-23 19:03:18
|
Thanks for the reply. Here's the code I have for rendering the points: 1
2
3
4
5
6
7
| for(int i = 0; i < vertices.length; i++) {
Point4f transPos = Point4f.multiply(Point4f.multiply(vertices[i], viewMat), projMat);
if(transPos.getX() < -1 || transPos.getX() > 1 || transPos.getY() < -1 || transPos.getY() > 1) continue;
int x = (int) (Main.WIDTH * 0.5 + transPos.getX() * Main.WIDTH * 0.5 / transPos.getZ());
int y = (int) (Main.HEIGHT * 0.5 + transPos.getY() * Main.HEIGHT * 0.5 / transPos.getZ());
screen.drawPoint(x, y, 0xffffffff);
} |
(btw Main.WIDTH and Main.HEIGHT are the viewport width and height). I thought that the if statement on the 3rd line checks whether the point is outside of the clip space, which would have eliminated points behind the camera. Could this be because the X and Y components are divided by the Z component after that check? Or is normal to just put in another check to determine whether the Z component of the point is less than the Z component of the camera? |
|
|
|
|
27
|
Game Development / Game Mechanics / Re: How to project a 3D point on to a canvas
|
on: 2013-02-23 17:06:24
|
|
Hey, thanks for the reply! I've almost got what I need now, but there's a glitch that I don't really understand the reason of. I've taken the 3D point and multiplied if by the view matrix, which I've just set as the identity. I've then multiplied this transformed point by the projection matrix shown above to get the clip space coordinates, which I then multiply by the viewport half width/height to transform it to screen coordinates and then divide both the X and Y components by the Z component for the foreshortening. The problem I've found is that when I move the point forward, it moves into the scene as you'd expect, but when I move it backwards to the point where it's behind the camera and not visible in the scene, it reappears in opposite corner.
So for example, a point that's in the bottom right hand corner, moves out of the window by the bottom right corner as its Z component deceases, but the point then reappears from the top left hand corner and moves towards the centre.
Has anyone ever heard of anything similar to this?
|
|
|
|
|
28
|
Game Development / Game Mechanics / How to project a 3D point on to a canvas
|
on: 2013-02-19 18:45:41
|
Hi everyone, the current task I've set myself is to take an array of 4 three-dimensional points and project them on to a two-dimensional canvas. I'm having a bit of trouble understanding what I've read and tried to put into practice and was wondering whether anyone could tell me where I've gone wrong. Say for example I have these 4 three-dimensional points representing the corners of a quadrilateral, with two points at Z coordinate 20 and the other two at Z coordinate 40, making up a square with its faces facing down the X axis. If I then translate this set of points 100 points down the negative X axis, I should now be able to see the back two points, which should also be rendered with perspective projection, meaning that the two furthest points appear closer together. This is the perspective projection I've used: http://msdn.microsoft.com/en-us/library/bb205351(v=vs.85).aspxIn the "Remarks" section. Now my understanding breaks down when I come to transform the points to their perspective view. From what I've gathered, the point, which can be represented with a 3-dimensional vector is multiplied by the view matrix, which I've initially set to the identity matrix. From here presumably you're meant to have a transformed point (3-dimensional vector), which you then have to multiply by the projection matrix, which in my case is in a perspective view. From that I now have a new transformed 3-dimensional vector that I can simply render to the screen as I would normal screen pixels. So in a nutshell: TransformedPoint = Point x ViewMatrix x ProjectionMatrix Is this right? This appears to just produce the same point as the original. I know I'll have to post some code up here, but could you tell if this logically isn't very sound anyway? Also, I'm rendering all this into an AWT Canvas. Thanks in advance for any help! Paul |
|
|
|
|
30
|
Game Development / Game Mechanics / Question about rotated bounding rectangles
|
on: 2013-02-05 01:52:52
|
Hi all, is it more efficient to use the separate axis theorem for 2D rotated bounding box collision checks or is it better to just rotate the 4 corners of each box, using those 4 corners to make 4 lines and then just do line-line collision checks again each rectangle side? In either case I'll have outer bounding circles to check they're in range to reduce the amount of SAT/line-line checks are performed. Also if anyone can think of any positive/negative points for using either I'd appreciate it. Thanks, Paul |
|
|
|
|
|
Add your game by posting it in the WIP section,
or publish it in Showcase.
The first screenshot will be displayed as a thumbnail.
|
|
I feel so foolish. Thanks to everybody for the help!
