What Are You Working On? - December 2014

[Fourier]

[QUOTE=Darwin226;46796993]If you're interested. I recommend starting with Haskell here [url]http://learnyouahaskell.com/chapters[/url]
As a tip, try and forget everything you know.[/QUOTE]

The forgetting part is harder than you think.

[Darwin226]

[QUOTE=Fourier;46797312]The forgetting part is harder than you think.[/QUOTE]

I've been through it. It's exactly as hard as I think.
The idea isn't to actually forget anything. Just don't go in with the attitude "This usually isn't done like that, so it obviously isn't done right". 99% of everything has a very good reason behind it. Something you can't really say for many other languages.

[WillKirkby]

[QUOTE=Berkin;46796914]That reminded me of the [URL="https://twitter.com/gameideamachine"]Game Idea Machine[/URL] Twitter bot. A Rant remake of this would be... interesting.[/QUOTE]

How about a Rant remake of [url=http://will.kirk.by/labs/extremesportgenerator/]this silly little thing[/url]?

[reevezy67]

Wrote a thing that grabs things for a thing from a thing.
[URL]https://github.com/EReeves/OGSGFGet[/URL]

[Aluminum Ken]

I don't know is anyone here still doing stuff for Source, but I did this today:

[IMG]http://i.imgur.com/xNjZ6C8.png[/IMG]
A more up-to-date shadercompile.exe, with new features like:
1. Multi-Threaded workflow!

2. Updated compiling messsages. It also tells you is a shader compile failed via printing "Removing failed" instead of "Writing".

3. When the compile finishes and printing errors, it will also saved in buildshaders.log, so you don't need to worry about compiling again just to see the errors.

[Tamschi]

[QUOTE=elevate;46796347]Posts like these test my ability to actually articulate what my program is doing, but I'm using lists for Doom lump handling.

In the Doom engine, all lumps are loaded into an array even if they are from different wads. Also, certain lumps are delimited by markers. I want to extract all these delimited lumps into a new object. However, I also want each lump in the object to refer to its position in the lump array so I can then refer to lumps relative to that position. My solution for this was to give this new object iterators instead of lumps.

If I were to use a vector of wads, with each wad implemented as a vector, then my iterators would not be invalidated but they wouldn't obey the Doom engine behavior of all lumps being in the same array. For instance, you cannot iterate to one vector from another vector. If I were to use a vector of lumps, then each time I loaded a new wad, my iterators would be invalidated because there is the possibility my vector gets reallocated. I could also have two vectors, one with the lumps and one with positions of the lumps, but I don't think this solution is very elegant, so I went with lists.

However, I could do without the list entirely if I don't require that I return new objects with lumps in them, and instead iterate through the lump array directly. I'm not for sure how I would implement this yet though.[/QUOTE]

Oh, good. That makes a lot more sense than what your previous post was suggesting.

[editline]26th December 2014[/editline]

[QUOTE=WillKirkby;46797396]How about a Rant remake of [url=http://will.kirk.by/labs/extremesportgenerator/]this silly little thing[/url]?[/QUOTE]

[quote]Ironing In Shark-Infested Waters[/quote]

[I]Iron[/I]ically enough this would be relatively safe due to the high current of the iron producing magnetic fields that deter sharks.

[20k]

Smoke upscaling is going well. The actual smoke rendering is incorrect because its a quick hack which means that for the upscaled versions, the edge of the smoke is 'thicker'. None the less, you can see that the upscaled version has high frequency noise along the edge

Default 100x100x100

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

Upscaled 100x100x100 with low noise contribution

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

Upscaled 100x100x100 with higher noise contribution

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

The upscaled versions are scaled to 200x200x200, which costs 1ms, for a total smoke time of 2.5ms. In contrast, actually simulating 200x200x200 costs 8ms!

The noise is wavelet noise. I can alter some random band properties which i think essentially allow me to control the noise frequency, though the paper im working with leaves out a few details so im not 100% sure. After I apply the noise to the smoke velocity, i advect the smoke by the upscaled velocity. This gets done in the same kernel as the upscaling, so I don't have to pay a massive bandwidth penalty for saving the higher resolution velocities

Next up is making the smoke rendering look nice, so i can visualise the high frequency noise. Hopefully with a high grid density it should look turbulent along the edge and like a much higher detail simulation

[Cold]

[QUOTE=Icedshot;46800296]Smoke upscaling is going well. The actual smoke rendering is incorrect because its a quick hack which means that for the upscaled versions, the edge of the smoke is 'thicker'. None the less, you can see that the upscaled version has high frequency noise along the edge

The upscaled versions are scaled to 200x200x200, which costs 1ms, for a total smoke time of 2.5ms. In contrast, actually simulating 200x200x200 costs 8ms!

The noise is wavelet noise. I can alter some random band properties which i think essentially allow me to control the noise frequency, though the paper im working with leaves out a few details so im not 100% sure. After I apply the noise to the smoke velocity, i advect the smoke by the upscaled velocity. This gets done in the same kernel as the upscaling, so I don't have to pay a massive bandwidth penalty for saving the higher resolution velocities

Next up is making the smoke rendering look nice, so i can visualise the high frequency noise. Hopefully with a high grid density it should look turbulent along the edge and like a much higher detail simulation[/QUOTE]

So what do you use for solving the smoke? Most 3d fluid solvers that i have used are soo unstable that it seems redundant to apply noise to it.

An even if you want more noise/randomness to a fluid, all you need to do is mess with the velocity or pressure field, and going all the way to wavlet noise seems like such an overkill.

[20k]

[QUOTE=Cold;46800625]So what do you use for solving the smoke? Most 3d fluid solvers that i have used are soo unstable that it seems redundant to apply noise to it.

An even if you want more noise/randomness to a fluid, all you need to do is mess with the velocity or pressure field, and going all the way to wavlet noise seems like such an overkill.[/QUOTE]

Im using a stable solver. My diffusion step is numerically stable (but physically inaccurate, i'm just averaging neighbouring cells), and my advection step is purloined from the paper [url=http://www.autodeskresearch.com/pdf/GDC03.pdf]realtime fluid simulation for games[/url]. It seems stable enough so far (and is meant to be stable), though I haven't tested it on complex flow. There isn't any pressure simulation, there doesn't seem like any point to having that

I'm fuzzy on the exact details, but wavelet noise is seemingly used because it is band limited and can be used to approximate kolmogorov theory. This means that the results (i think) are physically accurate. I do agree with you though that it doesn't seem 100% important and that I could probably use regular noise. I could also probably substitute for perlin, but that isn't band limited and can/could produce aliasing.

It makes no difference either way really. For reference, I *am* essentially just messing with the velocity field, though the upscaled velocity + noise is not reinjected into the simulation

The idea behind this is that I can use a *very* low resolution grid to simulate the smoke, and then upscale it to a higher resolution, adding in turbulence to make it look less boring. It doesn't really matter how unstable the underlying simulation is then, im doing it purely for visual effect (the end result is something applicable to videogames)

[url=http://www.cs.cornell.edu/~tedkim/wturb/wavelet_turbulence.pdf]this[/url] is the source paper im referencing from

Edit:

I'm quite interested on all this, feel free to badger me about the minor points or the implementation etc

[Rohan]

I'm adding syntax highlighting to Mond's REPL:
[img]https://dl.dropboxusercontent.com/u/675786/ShareX/2014-12/26_20-30-52.png[/img]

It looks way nicer in OSX:
[img]http://a.pomf.se/phwzqy.png[/img]

And looks terrible in cmd:
[img]https://dl.dropboxusercontent.com/u/675786/ShareX/2014-12/27_00-32-55.png[/img]

If you want to try it here's an exe: [url=https://dl.dropboxusercontent.com/u/675786/mond.exe]linky[/url]

[Dilbert]

[QUOTE=Tamschi;46798546]Oh, good. That makes a lot more sense than what your previous post was suggesting.[/QUOTE]

I tried my best! Pretty much I just want to take advantage of list's allocation scheme. I'll put iterators to each lump I want in a vector or hash table so I can still quickly iterate through them.

Also going over what I was doing helped me make more sense of it. Rubber duck debugging and all.

[reevezy67]

Thanks.

Why are all the mono libraries segregated on Debian, makes it a pain in the ass to deploy when you have to tell the client to download them.

I understand things like winforms but stuff like system.core for 4.0 should be included in the base package.

[Tamschi]

[QUOTE=reevezy67;46803578]Thanks.

Why are all the mono libraries segregated on Debian, makes it a pain in the ass to deploy when you have to tell the client to download them.

I understand things like winforms but stuff like system.core for 4.0 should be included in the base package.[/QUOTE]

Hopefully that's going to be fixed once Microsoft figures out .NET Core deployment and updating.

[Trumple]

[QUOTE=reevezy67;46803578]Thanks.

Why are all the mono libraries segregated on Debian, makes it a pain in the ass to deploy when you have to tell the client to download them.

I understand things like winforms but stuff like system.core for 4.0 should be included in the base package.[/QUOTE]

Why not bundle mono inside your application and distribute it as one tidy binary?
See 'Bundles' on this page: [url]http://www.mono-project.com/archived/guiderunning_mono_applications/[/url]

[Tamschi]

[QUOTE=Trumple;46803665]Why not bundle mono inside your application and distribute it as one tidy binary?
See 'Bundles' on this page: [url]http://www.mono-project.com/archived/guiderunning_mono_applications/[/url][/QUOTE]

The disadvantage is that you have to keep up with all Mono security updates manually, and likely increase the update downloads for users of your software.

[Trumple]

[QUOTE=Tamschi;46803809]The disadvantage is that you have to keep up with all Mono security updates manually, and likely increase the update downloads for users of your software.[/QUOTE]

While that's true, might it be easier to supply an update than get users to update Mono on every platform? Might be easy for Linux users, what with the package management tools, but Windows users would probably just ignore your request, whereas they might be more inclined if you just package it as an isolated update

[Cold]

[QUOTE=Icedshot;46800737]Im using a stable solver. My diffusion step is numerically stable (but physically inaccurate, i'm just averaging neighbouring cells), and my advection step is purloined from the paper [url=http://www.autodeskresearch.com/pdf/GDC03.pdf]realtime fluid simulation for games[/url]. It seems stable enough so far (and is meant to be stable), though I haven't tested it on complex flow. There isn't any pressure simulation, there doesn't seem like any point to having that

I'm fuzzy on the exact details, but wavelet noise is seemingly used because it is band limited and can be used to approximate kolmogorov theory. This means that the results (i think) are physically accurate. I do agree with you though that it doesn't seem 100% important and that I could probably use regular noise. I could also probably substitute for perlin, but that isn't band limited and can/could produce aliasing.

It makes no difference either way really. For reference, I *am* essentially just messing with the velocity field, though the upscaled velocity + noise is not reinjected into the simulation

The idea behind this is that I can use a *very* low resolution grid to simulate the smoke, and then upscale it to a higher resolution, adding in turbulence to make it look less boring. It doesn't really matter how unstable the underlying simulation is then, im doing it purely for visual effect (the end result is something applicable to videogames)

[url=http://www.cs.cornell.edu/~tedkim/wturb/wavelet_turbulence.pdf]this[/url] is the source paper im referencing from

Edit:

I'm quite interested on all this, feel free to badger me about the minor points or the implementation etc[/QUOTE]

So how are you planning to lit and render the volume.

The normal approach of raycasting would have a pretty significant overhead, when you upscale the volume.

[Gmod4ever]

[QUOTE=Handsome Matt;46804827][img]http://i.imgur.com/LKFB7tg.png[/img]

forked a hex editor and added the inspector tool window, haven't been able to find a freeware hex editor that has such a thing, so I made one c:[/QUOTE]

If you can add a sliding-window struct view, I would love you [b]forever[/b].

By a sliding-view struct view I mean that you design a struct template, and then you can set (maybe with ctrl-click) the first byte of the struct in the hex editor, and the inspector fills out the struct from that first byte. The sliding comes from the fact you can move the first byte around (maybe with the arrow keys / AD keys), and then all the struct values update accordingly.

There have been cases where I've had access to (or a pretty good idea about) how a particular file is structured, but was not exactly sure where it began.

And then other times, for my own programs, I have it write in a particular structure (especially serializing), but somewhere in the save/load process something gets skewed, and so the first n objects are loaded correctly, and then the rest just becomes fucked beyond all recognition - a sliding-window struct view would make it [b]so[/b] much easier to debug such things, find out exactly where everything starts going wrong.

[Tamschi]

[QUOTE=Trumple;46804215]While that's true, might it be easier to supply an update than get users to update Mono on every platform? Might be easy for Linux users, what with the package management tools, but Windows users would probably just ignore your request, whereas they might be more inclined if you just package it as an isolated update[/QUOTE]

On Windows it would be a better idea to just use .NET, considering that's updated through Windows Update (or at least Microsoft Update).

[Gmod4ever]

Oh, another thing that would be really, [b]really[/b] nice, Matt, is if you could set in the view-pane boundaries.

For both the struct-view and the general view (or you can consider a "general" view to be a struct of only one element).

By boundaries I mean something like, the first byte of each "struct" iteration has a yellow background, and then the first byte of each "struct" element has a blue background (unless it's the first byte of the whole struct). The colors themselves are just an example. Maybe make it so each element can be assigned its own color.

By this, I mean something like...

[t]http://a.pomf.se/lhkhdx.png[/t]

I think that would also be very neat, because sometimes I get lost maintaining the mental structure when just staring at monospaced square grids of characters. Something like this would be easy to identify struct misalignments, especially if a specific character is used as a sort of "header" for each struct, be it like a type or an actual magic number (perhaps introduced for debugging).

Sorry if I'm basically back-seat programming right now. This is just something I've been wanting to do for a long time, but without the hassle of making a hex editor. I've never forked someone else's work before, so, yeah. :v:

[icantread49]

Currently working on porting from GLES 1.1 to GLES 2.x. It's a huge pain so far, but the benefits will be worth it.

[Darwin226]

[QUOTE=icantread49;46805176]Currently working on porting from GLES 1.1 to GLES 2.x. It's a huge pain so far, but the benefits will be worth it.[/QUOTE]

Is GLES 1.1 fixed-pipeline stuff?

[Fourier]

Sometimes I feel so sad.. I am just a video game developer, but I want to be everything, an epic mathematician, epic medical engineer, epic tesla coil genius, epic autonomous quadcopter engineer, robotics guy,.. so many thing to do yet so little time..

fuck you god, why didn't you gave me 10000 years to live you fucking asshole

[mastersrp]

Just ordered a Banana Pi + transp case + 5v2a microusb charger for it. Gonna see how the heat turns up, and if I even need some heatsink shit for it. Probably do. But for the coming months, I'm hoping that it'll be my primary work station. Which is pretty cool, going from a theoretical max of 400W power usage to a theoretical max of 10W, with only slightly less functionality.

I'll still power up the "power hungry" PC for gaming though.

[editline]27th December 2014[/editline]

I'm not sure why I posted this here. I am not "working on" ordering it, I already did that. Oh well.

Anyway, I did this a few days ago, gonna get some work done on getting it a bit more comformant (it's pretty shit right now but took like 2 minutes to write so whatever)

#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <sys/types.h>
#include <unistd.h>

int
main( int argc, char **argv ) {
	if( argc == 1 ) {
		printf( "%s: [file]\n", argv[0] );
		return EXIT_SUCCESS;
	}
	int file = open( argv[1], 'r' );
	size_t size = lseek( file, 0, SEEK_END );
	lseek( file, 0, SEEK_SET );
	if( size == -1 ) {
		perror( argv[0] );
		return EXIT_FAILURE;
	}
	char *contents = malloc( size );
	read( file, contents, size );
	close( file );
	printf( "%s\n", contents );
	fflush( stdout );
	return EXIT_SUCCESS;
}

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <dirent.h>

int main( int argc, char ** argv ) {
	if( argc == 1 ) {
		printf( "%s: [directory]\n", argv[0] );
		return EXIT_SUCCESS;
	}
	DIR *dp;
	struct dirent *de;

	dp = opendir( argv[1] );
	if( !dp ) {
		perror( argv[0] );
		return EXIT_FAILURE;
	}
	while( ( de = readdir( dp ) ) ) {
		printf( "%s\n", de->d_name );
	}
	closedir( dp );
	return EXIT_SUCCESS;
}

cat + ls

did them for fun, and also to see how far i could go with writing shit that is just C scripts and how far a system can actually go with being just scripts of C and not actually any binary files (except a few obviously like base utilities as an initramfs shell and some compiler of sorts to launch the initial login shell).

[voodooattack]

I'm going to post a vague screenshot, and a very vague string of text, then I'll disappear again.

[img]https://dl.dropboxusercontent.com/u/27714141/cilium1.png[/img]

CUTTCCATGTCAGTACGTCAGCCTGAGGAGTCGGTTGAUTGGUUGGACTTUGUGCAUAA
AAATTCUGGATUTAGAUGGCCAUTGTCAGTUGCGUGGACCCUAUGTAUCTGCGAUACCC
UATUUTATUCCTCATCCCAUCACGAAUUTAUGGCTCGUGCATAGGGTUAUACCGAGAGT
CTAAUUCUCCUGGTTGUCAAGUGCATTGTUCTAUUGUCAACTCGUGACTUUGTTGAAUC
AGUUATCCUTTGCGUGCGCACGUUAUTGCTGGTCUAGUGTGATACAGGTAACAUUCGGA
....

[Fourier]

Banana PI is pretty cool thing, packs a bunch of power for processing in small box :).

[editline]27th December 2014[/editline]

[QUOTE=voodooattack;46805612]I'm going to post a vague screenshot, and a very vague string of text, then I'll disappear again.

[img]https://dl.dropboxusercontent.com/u/27714141/cilium1.png[/img]

CUTTCCATGTCAGTACGTCAGCCTGAGGAGTCGGTTGAUTGGUUGGACTTUGUGCAUAA
AAATTCUGGATUTAGAUGGCCAUTGTCAGTUGCGUGGACCCUAUGTAUCTGCGAUACCC
UATUUTATUCCTCATCCCAUCACGAAUUTAUGGCTCGUGCATAGGGTUAUACCGAGAGT
CTAAUUCUCCUGGTTGUCAAGUGCATTGTUCTAUUGUCAACTCGUGACTUUGTTGAAUC
AGUUATCCUTTGCGUGCGCACGUUAUTGCTGGTCUAGUGTGATACAGGTAACAUUCGGA
....

[/QUOTE]

Genetic algorithm? The string here is "DNK"?

[voodooattack]

[QUOTE=Fourier;46805622]Genetic algorithm? The string here is "DNK"?[/QUOTE]

Aww man, and I thought I was being vague..

[mastersrp]

[QUOTE=Fourier;46805622]Banana PI is pretty cool thing, packs a bunch of power for processing in small box :)[/QUOTE]

Pretty much my thoughts. Gonna see what I can make the thing do, both in terms of raw performance, but also how the GPU can be utilized. Also fuck proprietary drivers :( They suck.

[Ott]

[QUOTE=voodooattack;46805612]I'm going to post a vague screenshot, and a very vague string of text, then I'll disappear again.

[img]https://dl.dropboxusercontent.com/u/27714141/cilium1.png[/img]

CUTTCCATGTCAGTACGTCAGCCTGAGGAGTCGGTTGAUTGGUUGGACTTUGUGCAUAA
AAATTCUGGATUTAGAUGGCCAUTGTCAGTUGCGUGGACCCUAUGTAUCTGCGAUACCC
UATUUTATUCCTCATCCCAUCACGAAUUTAUGGCTCGUGCATAGGGTUAUACCGAGAGT
CTAAUUCUCCUGGTTGUCAAGUGCATTGTUCTAUUGUCAACTCGUGACTUUGTTGAAUC
AGUUATCCUTTGCGUGCGCACGUUAUTGCTGGTCUAGUGTGATACAGGTAACAUUCGGA
....

[/QUOTE]

I was wondering what happened to your cell simulator.

[voodooattack]

[QUOTE=Ott;46805792]I was wondering what happened to your cell simulator.[/QUOTE]

It was too CPU intensive, even on my i7. I abandoned the idea for now. I'll wait for quantum computers before trying to model organelles. :v:

This is a new one entirely. It's much simpler in ways, but also hopefully complex in emergent behaviour.