What Are You Working On? - December 2014

[cartman300]

[QUOTE=war_man333;46811317]I don't know how to get the appTime? I have 1 clock I use for everything, so essentially that's appTime, I guess?

It works pretty well right now, not sure how to capture it at 60 fps though.[/QUOTE]

If you don't restart the clock after you start it for the first time when the application starts, then yes.

[icantread49]

[QUOTE=cartman300;46811277]Don't.
Imagine if you didn't use vsync or FPS caps and had quite a great performance. Delta time can be 0 in such cases and as a result your enemy would be pushed forever. I encountered that before in my apps.
And in most cases it would not be accurate at all because of float losses.

I recommend you use global game time and manually calculate deltas each frame like this

pushTime = appTime - pushStartTime;

[/QUOTE]

Calculating time deltas like that for every game object would quickly get out of hand.

There's nothing wrong with using a delta time variable. The only case where you might run into an issue is if you have a blank screen pushing over a thousand frames per second, in which case a millisecond-based delta time would become 0.

[cartman300]

[QUOTE=icantread49;46811375]Calculating time deltas like that for every game object would quickly get out of hand.[/QUOTE]

How exactly can one subtraction that fixes a couple of potential bugs compared to one addition gonna get out of hand quickly?

[awcmon]

[QUOTE=CloseShave113;46810801]Currently working on MLG Pong / MLG Brick Breakers, it's 0% original and everyone will hate it, but hey, I've got spare time and I'm enjoying adding silly elements to it.
Video here:

[url]https://www.youtube.com/watch?v=Bmk-l0GGZBI[/url]

Download it here it you want:
[url]https://www.dropbox.com/sh/7qadc34n1u6wc7d/AABa_eWDciXVbjHOjzExPu6Ta?dl=0[/url][/QUOTE]

wtf the ball went through the paddle

[icantread49]

[QUOTE=cartman300;46811434]How exactly can one subtraction that fixes a couple of potential bugs compared to one addition gonna get out of hand quickly?[/QUOTE]

ballX += ballDir * speed * dt;
if (ballX < 0 || ballX > 800)
    ballDir *= -1;

Try rewriting that using an absolute time calculation (nowTime - startTime).

[cartman300]

[QUOTE=icantread49;46811472]

ballX += ballDir * speed * dt;
if (ballX < 0 || ballX > 800)
    ballDir *= -1;

Try rewriting that using an absolute time calculation (nowTime - startTime).[/QUOTE]

This isn't relevant because all i was saying time measurement using frame deltas is not okay, it can go off quite a lot and that is not okay.

[xThaWolfx]

[QUOTE=Contron;46810962]I am assuming you're using C# here, so here goes.

It's funny you mentioned this, because I encountered the same problem when implementing multithreading into my ray tracer (for reference, issues such as [URL="http://puu.sh/dumwu/ecd45105c3.jpg"]this[/URL]). Want to know why it works when you remove the multithreading? I imagine it's because you're using the same Random instance between threads. [B]Random is not thread-safe,[/B] and using the same one across threads will often corrupt it and return bogus results. The solution would be to create a separate Random instance for each thread and use that - it's how I overcame the issue.[/QUOTE]

This is indeed the case, thank you so much. I'll go and fix that now, I'll report back later!

[editline]derp[/editline]
It works! Seriously, I can't thank you enough, this would've probably been an issue I'd be spending hours upon hours to figure out.

[Tamschi]

[QUOTE=Cold;46808536]Well when you'd for example slap your camera right into the smoke that it covers your whole screen, in a raytrace worst case scenario you'd be doing fairly simple logic, but you'd be accessing the data ~400 times(depth of the voxel data) for every single pixel on the screen.

Yet afaik its pretty much your only option, extracting an isosurface would still require you raytrace the contents to get transparancy and lightning. Slicing would probably have worse performance, and Splatting and Shear warping have such significant visual issues that i am not sure if you can fix them.[/QUOTE]

There are methods to work around some limitations when rendering volumetric or transparent objects from surfaces, like [URL="https://en.wikipedia.org/wiki/Depth_peeling"]depth peeling[/URL] (which apparently can be done in a single pass when not using conventional shaders).
[URL="https://en.wikipedia.org/wiki/Order-independent_transparency"]Otherwise there are also a few other methods[/URL] but those may be inaccurate or somewhere near the complexity of raytracing the original volumetric data.

[adnzzzzZ]

[QUOTE=war_man333;46811030]how terrible is this on a scale from 1 to 10?

void Enemy::push(float dt)
{
	if(beingPushed == true)
	{
		pushTime += dt;
		if(pushTime < 0.45)
		{
			float speed = 256*exp(-9.467f*pushTime)*dt; //fancy math bitch
			cout << speed << endl;
			if(pushDirection=="right")
				x+=speed;
			if(pushDirection=="up")
				y+=-speed;
			if(pushDirection=="left")
				x+=-speed;
			if(pushDirection=="down")
				y+=speed;
		}
		else
		{
			beingPushed = false;
			pushTime = 0;
		}
	}
}

it's the method for pushing things (enemies) around after they get hit.
wish I could show it, but I don't know how to .gif/.webm easily[/QUOTE]

This is fine. Some of my push code is kinda similar using timers too and fancy math:

function MovableTopDown:movablePush(fx, fy)
    local t1 = (-self.v_z + math.sqrt(self.v_z*self.v_z + 2*mg.gravity_z*self.z))/mg.gravity_z
    local t2 = (-self.v_z - math.sqrt(self.v_z*self.v_z + 2*mg.gravity_z*self.z))/mg.gravity_z
    local t = math.max(t1, t2)
    self.timer:during('pushing', t, function() self.push_v.x = fx; self.push_v.y = fy end)
    self.timer:after('pushing_after', t, function()
        self.push_v_damping = true
        self.timer:after('pushing_damp', 1, function() 
            self.push_v_damping = false 
            self.push_v.x = 0
            self.push_v.y = 0
        end)
    end)
end

[Contron]

[QUOTE=xThaWolfx;46811583]This is indeed the case, thank you so much. I'll go and fix that now, I'll report back later!

[editline]derp[/editline]
It works! Seriously, I can't thank you enough, this would've probably been an issue I'd be spending hours upon hours to figure out.[/QUOTE]

No problem, glad I could help!

[Topgamer7]

[QUOTE=JohnnyOnFlame;46809932]So, I bought a router to do some trials on how well it fares up as a low spec, low consumption file server.

Knowing that for this application I needed storage, I opted for [url=http://wiki.openwrt.org/toh/tp-link/tl-wr842nd]this one[/url] because of it's USB capabilities. I'm using the v2.0 model.

First things first, the default software is terrible, so...

[img]http://i.imgur.com/lSY2fx7.png[/img]

Not too shabby! Process was painless, there was a trunk image ready for it, just needed to flash it using the default tp-link software's upgrade facilities.
I decided to do a performance test, so I configured OPL on my PS2 and a samba daemon on my router, a few taps on my controller and...

[img]http://i.imgur.com/7CwUFv1.png[/img]

ISO Backups of PS2 games being streamed from the USB thumbdrive connected on the router, 30% CPU usage when streaming FMVs. Also stutters less than my notebook-as-network setup when doing so.

This is the internal memory after installing nearly all packages I'm going to use (git, ssh, sftp, smb, rsync, etc, only missing the irc bouncer)

root@OpenWrt:~# df -k
Filesystem           1K-blocks      Used Available Use% Mounted on
rootfs                    4928      3460      1468  70% /
/dev/root                 2048      2048         0 100% /rom
tmpfs                    14336       584     13752   4% /tmp
/dev/mtdblock3            4928      3460      1468  70% /overlay
overlayfs:/overlay        4928      3460      1468  70% /
tmpfs                      512         0       512   0% /dev

Early conclusion: OpenWRT is awesome, and its entirely possible to use one of these to host files and stuff if you don't need too much speed. The USB is capable of delivering ~900mA and seems to be ok with delivering constant 700mA, should be enough to power an external usb hdd I guess. Did not test rsync performance yet, and did not test performance with an external hdd drive yet.[/QUOTE]

TimeSplitters what whaaat!

[NoRegard]

[QUOTE=adnzzzzZ;46811834]This is fine. Some of my push code is kinda similar using timers too and fancy math:

function MovableTopDown:movablePush(fx, fy)
    local t1 = (-self.v_z + math.sqrt(self.v_z*self.v_z + 2*mg.gravity_z*self.z))/mg.gravity_z
    local t2 = (-self.v_z - math.sqrt(self.v_z*self.v_z + 2*mg.gravity_z*self.z))/mg.gravity_z
    local t = math.max(t1, t2)
    self.timer:during('pushing', t, function() self.push_v.x = fx; self.push_v.y = fy end)
    self.timer:after('pushing_after', t, function()
        self.push_v_damping = true
        self.timer:after('pushing_damp', 1, function() 
            self.push_v_damping = false 
            self.push_v.x = 0
            self.push_v.y = 0
        end)
    end)
end

[/QUOTE]

awesome, great to hear :~)

Sometimes when I write code, I'm not sure if I'm doing it in a retarded fashion, or I just actually need all those lines of code.

[QUOTE=DarKSunrise;46811321]this sounds like a really unlikely problem

maybe just use doubles for dt then instead[/QUOTE]

switched to double

[Rohan]

[video=youtube;q8GjsS6gkmw]http://www.youtube.com/watch?v=q8GjsS6gkmw[/video]

I made a Mond REPL that takes keyboard input from anywhere (SetWindowsHookEx) and sends output as key strokes with [url=http://msdn.microsoft.com/en-us/library/system.windows.forms.sendkeys.send(v=vs.110).aspx]SendKeys[/url].

That's notepad, by the way. It also works in Chrome and Steam.

[20k]

[QUOTE=Cold;46810491]Well you can prematurely end the raytrace when certain conditions have been met, such as the density being so high that continuing would have no impact.

But worst case scenario(grid empty(with no optimization), or filled with a very low density smoke) you'll have to trace the whole thing.[/QUOTE]

Oh right, I see what you mean

The smoke should be reasonably temporally coherent so I'm about 98% sure there's something interesting I can do with that. Its also possible to detect a subset of cells that are close to the boundary of the smoke shape, it might be possible to start the raytracing at the closest cell to the camera, or generally do something with that

In terms of very low density fog, I'm not sure how to deal with that currently as it necessarily requires summing all the values. I guess I might be able to make the sampling frequency for the ray tracing adaptive, depending on how much smoke there is. At the moment I'm only planning to render smoke a few samples after a ray intersects the surface to make a proxy for the overall value, but obviously that doesn't deal well with non uniform fluids and could lead to some pretty odd looking things

[Ott]

[QUOTE=xThaWolfx;46810626]Yeah, I had the same thought. It's still nice to play around with, even on one thread:
[thumb]http://i.imgur.com/4FZqccB.jpg[/thumb][/QUOTE]

Is the ambient occlusion because the corners are statistically harder to hit, or are you emulating light rays [i]that[/i] well?

[xThaWolfx]

[QUOTE=Ott;46812591]Is the ambient occlusion because the corners are statistically harder to hit, or are you emulating light rays [i]that[/i] well?[/QUOTE]

I think it's just the statistically harder to hit corners, but it is something that automatically happens with path tracing.

Also, increasing the samples and depth will make it less noticeable:
[thumb]http://i.imgur.com/RCwAdny.jpg[/thumb]

[Trumple]

[IMG]http://orbit.bitnode.co.uk:53372/stream[/IMG]

^ this is being live streamed via my latest side-project, [B]mjpeg-relay[/B]. It's an MJPEG stream, sourced live from my Raspberry Pi's camera (pointed at my clock), which is being relayed via my VPS using mjpeg-relay

[IMG]https://dl.dropboxusercontent.com/u/10518681/Screenshots/2014-12-29_01-30-08.png[/IMG]

I made this because I had some issues getting common video streaming solutions such as VLC, ffmpeg/avconv to work at an acceptable standard on my Raspberry Pi (and also on my server). Either they crashed on startup (or at some point shortly after), were too resource hungry for my Raspberry Pi, didn't send the correct headers for MJPEG streaming, or introduced an unacceptable lag on the stream. After hours of trying, I gave up and made my own. It's dead simple, transparent, low-resource, and doesn't introduce unacceptable lag. I can only hope it works! Please rate disagree if you can't see it. I'll assume any other rating means you can see it.

Source code: [URL]https://github.com/OliverF/mjpeg-relay[/URL]

e: I know IE doesn't support mjpeg streaming so you're out of luck if that's what you're using, sorry!

e:
[IMG]https://dl.dropboxusercontent.com/u/10518681/Screenshots/2014-12-29_02-44-08.png[/IMG]

whooooaarr :~)

[esalaka]

[QUOTE=Trumple;46813084]e: I know IE doesn't support mjpeg streaming so you're out of luck if that's what you're using, sorry![/QUOTE]

Is that why one of the viewers is sad

[Trumple]

[QUOTE=esalaka;46813147]Is that why one of the viewers is sad[/QUOTE]

No that's me every time I try to make a cross-platform web solution

[icantread49]

[QUOTE=Ott;46812591]Is the ambient occlusion because the corners are statistically harder to hit, or are you emulating light rays [i]that[/i] well?[/QUOTE]

Path tracing is basically a simulation of light rays, unlike traditional ray tracing. Since occluded areas (like corners) tend to trap more rays than open areas, they look darker, and things like ambient occlusion Just Work.

[20k]

Somewhere in the process of doing raytracing, I accidentally created cubemapping

[IMG]https://dl.dropboxusercontent.com/u/9317774/cubemapping.PNG[/IMG]

This is uuh... useful, I guess? :v:

Hopefully I should have some real results soon

Edit:

I got a 0/10 would not bang raycaster working. Rays are cast straight into the structure with literally no optimisation whatsoever. They collide against all 12 triangles (per pixel) to find the closest and furthest away t values for the ray, then steps between the minimum and maximum t values, sampling the cube as it goes

[IMG]https://dl.dropboxusercontent.com/u/9317774/smoke.PNG[/IMG]

It only costs 2ms which is not exactly terrible for an extremely brute force approach. Its a tad buggy currently, but at least the performance isn't too atrocious

Edit 2:

More bugfixing, a direct comparison between the two rendering methods (they should be drawing on top of each other, but the specific positions are bugged)

[IMG]https://dl.dropboxusercontent.com/u/9317774/comparison.PNG[/IMG]

[Fourier]

[QUOTE=Contron;46810962]I am assuming you're using C# here, so here goes.

It's funny you mentioned this, because I encountered the same problem when implementing multithreading into my ray tracer (for reference, issues such as [URL="http://puu.sh/dumwu/ecd45105c3.jpg"]this[/URL]). Want to know why it works when you remove the multithreading? I imagine it's because you're using the same Random instance between threads. [B]Random is not thread-safe,[/B] and using the same one across threads will often corrupt it and return bogus results. The solution would be to create a separate Random instance for each thread and use that - it's how I overcame the issue.[/QUOTE]

What the hell, good to know! Also it makes sense now.

[Ac!dL3ak]

Shouldn't that be in the documentation?

[robmaister12]

[QUOTE=Ac!dL3ak;46814904]Shouldn't that be in the documentation?[/QUOTE]

It is. [url]http://msdn.microsoft.com/en-us/library/system.random%28v=vs.110%29.aspx#ThreadSafety[/url]

[editline]29th December 2014[/editline]

I should probably include some content. A few days ago I launched [url=http://100daysofhacking.com/]100 Days of Hacking[/url] and have been making daily posts about some progress I've made in that day.

For those who prefer Medium: [url]https://medium.com/100-days-of-hacking[/url]

So far it's been pretty good, I'm actually making progress on pinpointing a bug that's been in SharpNav for over a year now and should be able to get it mostly fixed tomorrow.

[Tamschi]

[QUOTE=war_man333;46811939][...]

switched to double[/QUOTE]

Probably doesn't make too much difference, since the precision is a few orders of magnitude over what you can reasonably expect at frame times at delays of reasonable size.
(It probably would still work reliably if you delay something by an hour, but I haven't calculated it precisely.)

[voodooattack]

God damn evolution. The organisms are exploiting some kind of bug to assign NaN as their energy value so that they live forever.

[Fourier]

[QUOTE=robmaister12;46815028]It is. [url]http://msdn.microsoft.com/en-us/library/system.random%28v=vs.110%29.aspx#ThreadSafety[/url]

[editline]29th December 2014[/editline]

I should probably include some content. A few days ago I launched [url=http://100daysofhacking.com/]100 Days of Hacking[/url] and have been making daily posts about some progress I've made in that day.

For those who prefer Medium: [url]https://medium.com/100-days-of-hacking[/url]

So far it's been pretty good, I'm actually making progress on pinpointing a bug that's been in SharpNav for over a year now and should be able to get it mostly fixed tomorrow.[/QUOTE]

But using only one instance of Random sucks because then you need to lock stuff and.. meh.

Isn't it better to create multiple instances of Random, with different seed for each one?

[Darwin226]

[QUOTE=voodooattack;46815089]God damn evolution. The organisms are exploiting some kind of bug to assign NaN as their energy value so that they live forever.[/QUOTE]

That's actually the most common behavior in these evolutionary simulations.
If you have a bug that allows them to cheat, they will cheat.

[Fourier]

[QUOTE=voodooattack;46815089]God damn evolution. The organisms are exploiting some kind of bug to assign NaN as their energy value so that they live forever.[/QUOTE]

Maybe it is just one of the math functions assigning NaN to them:

- Division by zero
- Tan function
- Normalizing zero vector (division by zero again)

This is all I can remember.

[Trumple]

My clock is apparently very interesting:
[IMG]https://dl.dropboxusercontent.com/u/10518681/Screenshots/2014-12-29_02-44-08.png[/IMG]

[editline]29th December 2014[/editline]

I'll pretend that's the reason why, and not just because it automatically loads when someone looks at the page