Ashedragon
|
 |
«
Reply #1740 - Posted
2015-02-17 04:09:20 » |
|
I spent the majority of the day redesigning Fragile Soul's menu: <![CDATA[<a href="http://www.youtube.com/v/aOgWwiMn9XU?version=3&hl=en_US&start=" target="_blank">http://www.youtube.com/v/aOgWwiMn9XU?version=3&hl=en_US&start=</a>]]> |
boo
|
|
|
|
cylab
|
|
«
Reply #1741 - Posted
2015-02-17 06:56:04 » |
|
Parallax scrolling is the <marquee> of 2012-2015  Meh. I think it looks great! |
Mathias - I Know What [you] Did Last Summer!
|
|
|
|
Mike
|
|
«
Reply #1742 - Posted
2015-02-17 06:58:38 » |
|
@Mike: The number one rule of web design (and pretty much all digital content creation): Don't do something just because you can. Parallax scrolling is the <marquee> of 2012-2015 - Jev I couldn't, that's why I did it  I think it'll look great with the additional menu to quickly go to a section. The good thing about the current layout is that the graphics get a very large attention on the page, which is the only thing the game has going for it at the moment. I don't think we should put any more into this thread as it isn't about web design. Once I change it down the line I'll put in another "What I did today". Mike EDIT: I added the navigation as suggested. As it was only a few minutes of work I thought it was silly not to do it |
|
|
|
Games published by our own members! Check 'em out!
|
|
|
theagentd
|
|
«
Reply #1743 - Posted
2015-02-17 15:49:19 » |
|
I found some nice optimizations for bounds testing in shaders. Basically my motion blur was blurring over the edge of the screen, resulting in either black color if I used texelFetch() which gave a dark aura around the screen when in motion, or being clamped to the edge pixel if I used texture() which inflated the weights of the edge pixels. Neither of these looked very good, so I decided to simply remove the samples that fell outside the screen. However, detecting these scenarios was expensive. Simply using an if-statement to test whether the coordinates are inside the screen was dead slow as this was compiled to 1 branch per sample. 1
2
3
| if(texCoords.x >= 0 && texCoords.y >= 0 && texCoords.x < resolution.x && texCoords.y < resolution.y){
samples += 1.0;
} |
However, there's a trick you can use. By casting the resulting boolean to a float, we can convert the boolean to 1.0 if it's true and 0.0 if it's false! Exactly what we want! 1
| samples += float(texCoords.x >= 0 && texCoords.y >= 0 && texCoords.x < resolution.x && texCoords.y < resolution.y); |
Sadly, this still compiles to the same thing as the if-statement. That's weird since I know that GPUs have specific instructions to set the value of a register based on a simple comparison. As an example, this line: 1
| float x = float(someValue < 1); |
compiles to this instruction: 1
| x: SETGT R0.x, 1.0f, PV0.x |
It would seem that the boolean &&-operators are messing this up, causing it to revert to branches. Let's try casting the result of each comparison to floats and then use a simple float multiply between them to effectively and them together. 1
| samples += float(texCoords.x >= 0)*float(texCoords.y >= 0)*float(texCoords.x < resolution.x)*float(texCoords.y < resolution.y); |
Bam! The comparison compiles to 2 SETGE (greater-equals) instructions, 2 SETGT (greater-than) instructions and 3 multiplies. I need to do this 16 times per pixel, once for each sample, so this saves a load of work! There is one final optimization we can make to improve this code on AMD's vector GPUs. AMD's older GPUs are a bit funny in that they run each shader on 4 or 5 different cores at the same time, trying to do as much as possible at the same time. This code: 1
| float x = a + b + c + d; |
would fit this extremely badly. GLSL requires the GPUs to enforce the order of the operations, so none of these instructions can be run in parallel. First we do a+b, then (a+b)+c, then finally ((a+b)+c)+d, which requires 3 cycles. If we add some "unnecessary" parenthesises, we can encourage vector GPUs to do these additions in parallel without affecting the performance of scalar GPUs that don't have this problem: 1
| float x = (a + b) + (c + d) |
This only takes 2 cycles, as a+b and c+d can both be calculated in the first cycle, and then (a+b)+(c+d) can be calculated in the second cycle, making this chain of addition 50% faster. Doing this for the bounds testing gives this code: 1
| samples += (float(texCoords.x >= 0)*float(texCoords.y >= 0))*(float(texCoords.x < resolution.x)*float(texCoords.y < resolution.y)); |
Theoretical performance of the 4 versions of bounds checking done for 16 samples on a Radeon HD 6870: 1. 2.04 pixels per second 2. 2.02 pixels per second 3. 11.20 pixels per second 4. 11.79 pixels per second All in all, that's a 5.78x improvement compared to a naive if-statement. |
Myomyomyo.
|
|
|
|
BurntPizza
|
|
«
Reply #1744 - Posted
2015-02-17 15:59:23 » |
|
Nice. There needs to be something like Souper but for shader code, although it would probably be more effective on pre-compiled shaders. |
|
|
|
|
|
Roquen
|
|
«
Reply #1745 - Posted
2015-02-17 16:35:54 » |
|
Manipulation of sign bits is handy on the CPU as well (both float and integers). Have I ever mentioned that GL compiling GLSL from source in the driver was a really terrible idea?? |
|
|
|
|
|
Riven
|
|
«
Reply #1746 - Posted
2015-02-17 16:36:02 » |
|
1
| samples += float(texCoords.x >= 0 && texCoords.y >= 0 && texCoords.x < resolution.x && texCoords.y < resolution.y); |
Sadly, this still compiles to the same thing as the if-statement. That's weird since I know that GPUs have specific instructions to set the value of a register based on a simple comparison. It's not that weird, because this statement: 1
| b = texCoords.x >= 0 && texCoords.y >= 0 && texCoords.x < resolution.x && texCoords.y < resolution.y |
is roughly equal to: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| init: if(texCoords.x >= 0)
if(texCoords.y >= 0)
if(texCoords.x < resolution.x) {
b = (texCoords.y < resolution.y);
goto end;
}
else
goto lab;
else
goto lab;
else
goto lab;
lab: b = false;
end: |
The early-out (what's the name...) of '&&' causes a lot of branches. |
Hi, appreciate more people! Σ ♥ = ¾ Learn how to award medals... and work your way up the social rankings! |
|
|
|
BurntPizza
|
|
«
Reply #1747 - Posted
2015-02-17 16:39:31 » |
|
The early-out (what's the name...)
Short-circuiting And yeah, I'm curious how non-ss comparisons perform: samples += float(texCoords.x >= 0 & texCoords.y >= 0 & texCoords.x < resolution.x & texCoords.y < resolution.y); |
|
|
|
|
|
|
Roquen
|
|
«
Reply #1748 - Posted
2015-02-17 16:55:06 » |
|
Nice. There needs to be something like Souper but for shader code, although it would probably be more effective on pre-compiled shaders. Super optimizers are an interesting toy thing to do, but they're insanely slow. Also this page's results aren't too encouraging. 31*i no result? Constant multipliers and divisors over integer -> addition chains. |
|
|
|
|
|
pitbuller
|
|
«
Reply #1749 - Posted
2015-02-17 18:11:25 » |
|
I found some nice optimizations for bounds testing in shaders. Basically my motion blur was blurring over the edge of the screen, resulting in either black color if I used texelFetch() which gave a dark aura around the screen when in motion, or being clamped to the edge pixel if I used texture() which inflated the weights of the edge pixels. Neither of these looked very good, so I decided to simply remove the samples that fell outside the screen. However, detecting these scenarios was expensive.
...
I have seen this kind of pattern multiple times. Its hlsl but maps well to hardware. 1
2
| if (dot(1.0, saturate(texCoords) - texCoords) != 0.0)
samples += 1.0; |
|
|
|
|
|
Games published by our own members! Check 'em out!
|
|
|
theagentd
|
|
«
Reply #1750 - Posted
2015-02-17 19:24:31 » |
|
I found some nice optimizations for bounds testing in shaders. Basically my motion blur was blurring over the edge of the screen, resulting in either black color if I used texelFetch() which gave a dark aura around the screen when in motion, or being clamped to the edge pixel if I used texture() which inflated the weights of the edge pixels. Neither of these looked very good, so I decided to simply remove the samples that fell outside the screen. However, detecting these scenarios was expensive.
...
I have seen this kind of pattern multiple times. Its hlsl but maps well to hardware. 1
2
| if (dot(1.0, saturate(texCoords) - texCoords) != 0.0)
samples += 1.0; |
I tried a similar version too: 1
| samples += float(texCoords == clamp(texCoords, vec2(0), resolution)); |
8.30 pixels per second. EDIT: If your coordinates are normalized and you use clamp(<value>, 0.0, 1.0), the clamp becomes free, in which case this one is ALMOST as fast as the float multiplied version (version 4). EDIT2: Turns out that clamp DIDN'T become free. Since the texture coordinate varying input is never modified, there is no previous instruction that clamp can piggyback on, so it needs to add a MOV instruction with CLAMP to get the same result. It's faster than a MIN and a MAX, but still slower than the optimized float multiplied thingy. |
Myomyomyo.
|
|
|
|
wessles
|
|
«
Reply #1751 - Posted
2015-02-17 21:46:47 » |
|
I made a shader mod for Luftrausers. It is supposed to imitate old CRT arcade monitors, complete with warping and scan-lines. I have been trying to make a shader like this for a whole year, and I finally made it when messing with modding. Now to find a game of my own to put it in  ... <![CDATA[<a href="http://www.youtube.com/v/2ZZl2GHT02A?version=3&hl=en_US&start=" target="_blank">http://www.youtube.com/v/2ZZl2GHT02A?version=3&hl=en_US&start=</a>]]> |
|
|
|
|
|
|
|
SHC
|
|
«
Reply #1753 - Posted
2015-02-18 06:31:56 » |
|
Started on my 3D platformer using SilenceEngine.  Got gravity, lighting, and also controller input using Generic/XBOX controllers done. Still need to load levels from file, and also add a nice story around it. |
|
|
|
|
kingroka123
|
|
«
Reply #1754 - Posted
2015-02-18 18:04:10 » |
|
Made a twitchy shooter yesterday. *1.8mb gif* |
|
|
|
|
|
|
|
|
|
pitbuller
|
|
«
Reply #1757 - Posted
2015-02-18 22:08:24 » |
|
I coded a simple camera frustum to ground plane clipping algorithm. It does help a ton for calculating minimum shadow frusta.
Ground plane is calculated dynamically from minimal height of heightmap that intersect the current camera split per cascade.
Up to 2Millions triangle savings with improved effective resolution.
|
|
|
|
|
|
Slyth2727
|
|
«
Reply #1758 - Posted
2015-02-18 22:54:24 » |
|
Dynamic, penumbra'd (yes that's now a word), multisource shadows with blending. Oh, and some fake normal mapping. I also implemented map creation from lua files, like you see in the top left. Based off of davedes article! Edit: I also have the solving of a rubiks cube completely memorized and can do it all without looking at a reference   |
|
|
|
|
|
matanui159
|
|
«
Reply #1759 - Posted
2015-02-19 06:13:12 » |
|
This is more of: 'what I'm doing today' or 'what I'm doing at the moment'
But, I'm setting up Ubuntu on a virtual machine... I was extremely bored today so I thought... What the heck... I'll see what all the fuss is over...
|
Is it sad that I still get a fright when the computer beeps at me...
|
|
|
|
LiquidNitrogen
|
|
«
Reply #1760 - Posted
2015-02-19 10:07:51 » |
|
Finally picking up work speed again I've drawn 6 animated characters now: Rookie, Engineer, Scientist, Guard, Captain and a Lizard Alien. |
|
|
|
|
|
kevglass
|
|
«
Reply #1761 - Posted
2015-02-19 10:12:39 » |
|
Love your art work sooooo much!
Kev
|
|
|
|
MrPizzaCake
Senior Devvie  Medals: 8Exp: 3 years
Hello, another wonderful human being :)
|
|
«
Reply #1762 - Posted
2015-02-19 10:17:10 » |
|
@LiquidNitrogen How the heck are you so awesome?! Seriously though, you're sooooo great at pixel art. Like, really great.
|
How am I? Tough question, since emotions are confusing as heck  |
|
|
|
LiquidNitrogen
|
|
«
Reply #1763 - Posted
2015-02-19 10:25:14 » |
|
Thanks, ive kinda been doing it for 20 years, but extremely amateurish.. I guess sometime last year I just decided to try harder lol.
|
|
|
|
|
|
lcass
|
|
«
Reply #1764 - Posted
2015-02-19 11:30:08 » |
|
finally got around to making sprites rotate on the GUI , makes building a lot easier. |
|
|
|
|
|
kevglass
|
|
«
Reply #1765 - Posted
2015-02-19 13:41:47 » |
|
1
2
3
4
5
6
| ....................
TEST RUN COMPLETED 'The Trial' (campaign1/quest1.tmx)
QUESTS PLAYED: 20
QUESTS WON: 8 (40%)
QUESTS LOST: 12 (60%)
AVERAGE HERO SURVIVAL: 2 (of 4) |
Even having improved the AI for players considerably, the first challenge isn't going to be easy. Cheers, Kev |
|
|
|
|
CodeHead
|
|
«
Reply #1766 - Posted
2015-02-19 16:53:34 » |
|
Working on creating a custom control for one of the guys in our transportation division. (Warning: 2.3mb gif file.) When it's finished, it will be used to provide a visual representation of curent shipment locations using tracking information provided by the shipping companies. Unfortunately, I'm still waiting for them to get back to me with some details. For now it's pretty much eye candy. Its looks can be customized and it supports auto rotation/rotation via mouse drag. Built using "old school" visual trickery in Java2D mostly to prove to a manager that it could be done. Not a 100% perfect effect, but good enough for its intended purpose. Since it's a slow day at the office I think I'll tie it to a METAR parser I've been developing and turn it into a weather widget while I have some idle time. I love my job most days.  |
Arthur: Are all men from the future loud-mouthed braggarts?
Ash: Nope. Just me baby...Just me.
|
|
|
|
Slyth2727
|
|
«
Reply #1767 - Posted
2015-02-19 19:18:37 » |
|
Some correction in coloring and normal mapping. Currently I'm trying to figure out a rendering scheme that places the characters on top of the shadows, but still affects them with the lights. Hm...  |
|
|
|
|
|
pitbuller
|
|
«
Reply #1768 - Posted
2015-02-19 19:58:56 » |
|
Some correction in coloring and normal mapping. Currently I'm trying to figure out a rendering scheme that places the characters on top of the shadows, but still affects them with the lights. Hm...
Everything in that screenshot just screams DITHERING. http://loopit.dk/banding_in_games.pdf |
|
|
|
|
|
Slyth2727
|
|
«
Reply #1769 - Posted
2015-02-19 20:42:31 » |
|
Haha I know, it wasn't really something I had thought about while making it. Will fix! Thanks |
|
|
|
|
|
