I came across the most mindfuck dense code I've ever seen at work the other day. Luckily it's not code that's run very often, but almost every single line is wrong or redundant.
Some background: The code is meant to get a list of groups that exist via an API, then update its own database by removing the groups that no longer exist. The code is written from memory and some boilerplate is omitted for clarity.
[cpp]
real_group_ids = API.GetAllGroups()
.Select(group => group.Id);
existing_groups = db.Groups
.Select(group => group.id)
.Where(id => real_group_ids.Contains(id));
groups_to_delete = db.Groups
.Where(group => !existing_groups.Contains(group.id));
foreach(var group in groups_to_delete)
{
while(group.Devices.Count() > 0)
{
group.Devices.Remove(group.Devices.Front());
while(group.Products.Count() > 0)
group.Products.Remove(group.Products.Front());
db.Groups.Remove(group);
}
}
[/cpp]
So a play-by-play here:
1) It gets all the groups from the API, all good.
2) Instead of doing a conditional select on the DB and just straight up finding all the groups that aren't in the list the API provided, it instead gets a list of all group ids that SHOULD exist.
3) Then, it uses that list of group ids that should exist, to get all the groups NOT in that list (bonus here for extracting the id in the first place and then going back to search by id to get the original group)
4) Looping over all the groups, it:
5) Not only tries to remove all the devices attached to the group one by one instead of removing them all at once, but
6) Fails to close the while-loop, meaning that for every single device in the list it:
7) Deletes the device
8) Removes all products attached to the GROUP, again one by one instead of all at once, even though after the first device is removed, not only does the group no longer exist (see #9), the products have already been removed ONE BY ONE in the previous iteration!
9) It removes the whole group from the database every time it's removed ONE device, meaning that when it comes back around for removing the second device, the group is already dead
I've been teaching my self multi-threading and implementing asynchronous processing in my world generation program and it's going mildly okay. I've managed to render my entire environment with only a few mild pixel errors on my resulting sphere map. I really need to de-OC my cpu to see if that's an issue with my latest OC changes or if it's my program, so I'll either have a massive headache or less of one here soon.
[img]http://i.imgur.com/MlNjl2I.png[/img]
note: real heightmaps are far larger than 1024x512 and doing them single thread is the single worst waste of anyone's time.
This thread makes me feel inadequate with my few small Flask sites.
Don't worry, it turns out the more threads I add to the process the worse my artifacting gets which means I've not really achieved much other than making a process worse.
I think part of the problem is that I'm working with an outdated 32bit library (that was last released in like 2011) and I have absolutely zero knowledge about writing libraries so I can't recompile it for x64, especially because that involves having to re-write an entire library which I just don't know how/want to do.
That and my threads are outputting to the exact same height map class and I have absolutely zero mutex stuff going on right now, which is generally a problem. In fact I think most of my problem may be the lack of mutex.
edit:
After implementing some mutex stuff I can safely say that it hasn't been any more helpful in reducing excess noise on my output. So fuck me.
Update: It has side-effects now.
[quote]name:
Zitizlopra®
side-effects:
nausea, blurry vision, hearing loss, tooth loss, projectile vomiting, ringing of the ears, and abnormal nail growth[/quote]
[QUOTE]name:
Truvaxide®
side-effects:
sensitivity to light and frequent urination[/QUOTE]
[QUOTE]name:
Nexviala®
side-effects:
massive stools[/QUOTE]
[QUOTE]name:
Isolammin®
side-effects:
fatigue, low blood pressure, muscle spasms, drooling, trouble breathing, acne, heartburn, abnormal hair growth, insomnia, uncontrollable laughing, headache, weight gain, trouble swallowing, uncontrollable gas, tooth loss, projectile vomiting, and itching[/QUOTE]
[QUOTE=Berkin;52143139]Update: It has side-effects now.[/QUOTE]
Reminds me of one of the responses of the priest unit in Warcraft III:
[QUOTE]Side effects may include: dry mouth, nausea, vomiting, water retention, painful rectal itch, hallucination, dementia, psychosis, coma, death, and halitosis. Magic is not for everyone. Consult your doctor before use.[/QUOTE]
i spend 4 hours last night trying to get this to work because the due date said monday the 25th of april 2016.
they updated the due date to 1st of may, i was so fucking stressed out, im so tired and its not even due for another 4 days. at least i have a proper understanding behind some swift shit that i was just using before.
[img]http://i.imgur.com/kTSWpGR.png[/img]
[editline]24th April 2017[/editline]
also i accidentally made the background black and i have no idea how to change it back to default.
I've been looking to add some basic previewing of Half-Life/Half-Life PS2/007 Nightfire (and later on Source engine) .bsp files to my multitool: [url]http://www.teamsandpit.com/#gssmt[/url]
I started playing around with OpenGL immediate mode (wrong thing, I know) today and realised I've probably got a lot of reading to do.
[QUOTE=tschumann;52143358]I've been looking to add some basic previewing of Half-Life/Half-Life PS2/007 Nightfire (and later on Source engine) .bsp files to my multitool: [url]http://www.teamsandpit.com/#gssmt[/url]
I started playing around with OpenGL immediate mode (wrong thing, I know) today and realised I've probably got a lot of reading to do.[/QUOTE]
If you're going to do a lot of reading don't waste it on immediate mode. It's not actually easier than proper Opengl it just seems that way at first but really, take a look at learnopengl.com. It'll teach you everything you need to do nifty stuff in opengl using core profile and it's very accessible.
[QUOTE=JWki;52143452]If you're going to do a lot of reading don't waste it on immediate mode. It's not actually easier than proper Opengl it just seems that way at first but really, take a look at learnopengl.com. It'll teach you everything you need to do nifty stuff in opengl using core profile and it's very accessible.[/QUOTE]
Thanks - yeah I only started with immediate mode because it's the only thing I knew anything about.
I wrote a basic little distortion/refraction shader for Unity. Really it's just a fresh rewrite (with some improvements) of an old messy shader I found on the internet that I have been meaning to do for a while. Unfortunately it does not work fully in VR but I'm looking into that right now.
[img]http://puu.sh/vuCNk.jpg[/img]
[url=https://gist.github.com/Fewes/7d0918c9822bb8e696bb0b1da4b8d3be]Code available here.[/url]
I'm working on lamps and dynamic lights and overall coziness
[video=youtube;WWdGdE8ZwIA]https://www.youtube.com/watch?v=WWdGdE8ZwIA[/video]
[QUOTE=moonmoonmoon;52144087]I'm working on lamps and dynamic lights and overall coziness
[video=youtube;WWdGdE8ZwIA]https://www.youtube.com/watch?v=WWdGdE8ZwIA[/video][/QUOTE]
That's one nice second post.
Do the lights always come in slowly on scene transitions?
I'd reserve the fade from black to larger changes in environment type, but the pause it creates is pretty nice for that.
[QUOTE=Tamschi;52144118]That's one nice second post.
Do the lights always come in slowly on scene transitions?
I'd reserve the fade from black to larger changes in environment type, but the pause it creates is pretty nice for that.[/QUOTE]
Thanks, yes I just made an account, lurked here before tho :cat:
Yeah I made them fade for every scene but what you're saying makes sense. Luckily I built a system so I can change their initial state quickly. Thanks, great tip!
[img]http://i.imgur.com/GjdzvLXl.jpg[/img]
And we're doing it boys. 100% multithreaded application that generates terrain maps, everything from normals, specularity, and terrain. It also generates a .RAW and a .TER if the resolution is right for the planet's specified circumference. Some of the settings need to be messed with so the noisemaps generate more realistic results, but that's alright I can debug that much easier. Example, for some reason that specific seed generated a lot of mountains, and their glacation happens to be very, very coastal, so we're getting some weird results here.
[QUOTE=Topgamer7;52137386]Well don't leave us hangin, what do they do?[/QUOTE]
Machine learning stuff
[QUOTE=Ac!dL3ak;52144906]Machine learning stuff[/QUOTE]
Nice! I'm also waiting on a response from a machine learning internship at the JPL, congratz
[QUOTE=F.X Clampazzo;52144898][img]http://i.imgur.com/GjdzvLXl.jpg[/img]
And we're doing it boys. 100% multithreaded application that generates terrain maps, everything from normals, specularity, and terrain. It also generates a .RAW and a .TER if the resolution is right for the planet's specified circumference. Some of the settings need to be messed with so the noisemaps generate more realistic results, but that's alright I can debug that much easier. Example, for some reason that specific seed generated a lot of mountains, and their glacation happens to be very, very coastal, so we're getting some weird results here.[/QUOTE]
did you multithread libnoise? that looks like libnoise output from the "complex planet" demo. I thought of multithreading that but ended up going with CUDA instead. If it is libnoise, you just have to get down and dirty with tuning the modules earlier in the chain that select where various types of geography appear. Some values may have been inverted, since your plains/badlands appear in the center of continents and mountains are on the edges.
[editline]24th April 2017[/editline]
I'd be really interested to see some source code, I really couldn't figure out how to get libnoise to play nice with threading and generate output images. Have you tried getting .TER files to import too? writing to that file format is really tough, I never got it working right in my CUDA library
[IMG]http://i.imgur.com/wIByZY7.gif[/IMG]
-snip-
For the longest time I thought A) was the most plausible, but the more I think about B) the less certain I am.
[QUOTE=Karmah;52145852]B. is so unintuitive though; to me the object shouldn't have that much momentum.[/QUOTE]
It's comparable to jumping on a train. From the frame of reference of the train, you're moving at the opposite vector of its velocity.
It makes more sense if you focus on the cube through the portal, your brain perceives it as a launch pad which makes more sense relative to that perspective.
im making a new moderator for my game
[t]http://i.imgur.com/feyMUJv.png[/t]
I am currently Caesar cipher decryption and encryption script in python. I'm new to programming so I thought i'd challenge myself
[QUOTE=phygon;52145868]It's comparable to jumping on a train. From the frame of reference of the train, you're moving at the opposite vector of its velocity.
It makes more sense if you focus on the cube through the portal, your brain perceives it as a launch pad which makes more sense relative to that perspective.[/QUOTE]
The cube would have to have energy imparted on it in order for it to move with that velocity, however. In your example one could also consider replacing the portals with literal doors: The cube isn't going to gain any velocity from its resting state simply because you slammed what is essentially an open door into it.
[QUOTE=Zero-Point;52146265]The cube would have to have energy imparted on it in order for it to move with that velocity, however. In your example one could also consider replacing the portals with literal doors: The cube isn't going to gain any velocity from its resting state simply because you slammed what is essentially an open door into it.[/QUOTE]
Portals are not open doors tho
If you put one on the ceiling and one on the floor and drop something in it, what do you expect to happen? When an object goes trough the floor portal and therefore exits the ceiling portal, it can be assumed the object gained some energy to be somehow transported to a location where it has a higher gravitational potential energy.
The whole idea of portals is very absurd and standard conservation of energy doesn't really apply.
[editline]25th April 2017[/editline]
B) makes the most sense.
When the cube is at rest, the cyan portal is moving from the camera frame of reference. When the cube enters the portal, stuff gets swapped around. Orange portal becomes fixed in place while the cube is now moving.
These are all good points so I'm just rating everybody agree.
[QUOTE=paindoc;52144982]did you multithread libnoise? that looks like libnoise output from the "complex planet" demo. I thought of multithreading that but ended up going with CUDA instead. If it is libnoise, you just have to get down and dirty with tuning the modules earlier in the chain that select where various types of geography appear. Some values may have been inverted, since your plains/badlands appear in the center of continents and mountains are on the edges.
[editline]24th April 2017[/editline]
I'd be really interested to see some source code, I really couldn't figure out how to get libnoise to play nice with threading and generate output images. Have you tried getting .TER files to import too? writing to that file format is really tough, I never got it working right in my CUDA library[/QUOTE]
Yeah, I've been using libnoise, and I found a guy who decided to migrate the library to x64 and I got it to compile properly after some tweaking just a moment ago so I'm now actually working on multi threading again, but now the program can run past the 32bit limits. I basically took heavily from the complex planet example and am slowly re-writing it, also I liked their colour choice so it stayed. Plus I needed a static output to compare my result to for accuracy, so I copied their noise module settings for now. I didn't see any reason to not use their settings since they were basically what I was going to do anyway lol, they just saved me the trouble of defining all the modules.
Basically I've only got the elevation grid running on multi-threading right now because I've been busy migrating it to being x64. I can upload the last .ter I generated if you want, I'm not actually sure if it loads right since I don't have the program that opens them. Basically the largest limitation with the library is that it wants to generate everything on a divisibility of 180 since it has to reference a sphere map. So multithreading is really hard since your thread count has to be a factor of 180. Meaning basically everything but a 12 or 4 core processor are suffering some less than optimal performance since they can't run perfectly hardware concurrent. HOWEVER, every piece of information I can find shows that I will almost always still see a performance increase with multiple threads, unless I do something extreme like run 180 threads on a 4-core processor. Which I did.
This 180 requirement also causes problems with map resolution and thread division because I can only have <180 threads due to what I call the 180 divisibility rule, and I have to split all work evenly per thread to generate the map correctly due to this a well. I tried it with more threads than 180 and it generated some funky shit when it doesn't divide out to a number that is fully in scope of a double, shit if it can't find work up to 180 it also makes bad images. I might return to that problem later, but for now obeying the rule of 180 is a fair solution.
I haven't quite determined the parameters that occur with each element violating that rule, but it either results in a black bar on the top of the map or a loss of some detail as the output image is a zoomed in result from the full model since the resolution is out of scope.
[code]
// The elevation grid generation chunk of the build() function
// prior to this we determine hardware concurrency to know how many threads to make, unsigned int h is the number of threads.
int chunk = m_destHeight / h; // size of each map chunk for each thread
double latChunk = 180 / h; // defining each thread's chunk of latitude
std::size_t t = h;
std::vector<std::thread> threads;
threads.reserve(t); // reserve space for threads
// giving threads something to do.
for (int i = 0; i < t; ++i) {
int Ym = i *(chunk);
int YM = (i + 1)*(chunk);
double modLat = (-90 + (i*latChunk));
threads.emplace_back(&NoiseMapBuilderSphere::buildChunk, NoiseMapBuilderSphere(), Ym, YM, std::ref(m_pDestNoiseMap), sphereModel, curLon, m_westLonBound, m_destWidth, modLat, xDelta, yDelta, i);
}
for (auto& t : threads)
{
t.join();
}
[/code]
Basically all I've done is migrate the end of the function that actually wrote the elevation map to its own function so I can use it to write chunks:
[code]
void NoiseMapBuilderSphere::buildChunk(int Ym, int YM, NoiseMap* m_pDestNoiseMap, noise::model::Sphere sphereModel, double curLon, double m_westLonBound, int m_destWidth, double curLat, double xDelta, double yDelta, int ID)
{
double curLonb = curLon;
double curLatb = curLat;
for (int y =Ym; y < YM; y++) {
float* pDest = m_pDestNoiseMap->GetSlabPtr(y);
curLonb = m_westLonBound;
for (int x = 0; x < m_destWidth; x++) {
sphereLock.lock(); // we have to mutex the getvalue() from the sphere model because otherwise the threads had been shown to sometimes take each-other's returns.
float curValue = (float)sphereModel.GetValue(curLatb, curLonb);
sphereLock.unlock(); // we unlock the mutex after because writing to the destination noise map is something that they're able to share doing as they're not accessing any of the same locations in memory.
*pDest++ = curValue;
curLonb += xDelta;
}
curLatb += yDelta;
if (m_pCallback != NULL) {
m_pCallback(y);
}
}
std::cout << "Thread " << ID << " is done with their heightmap chunk." << std::endl; // this actually could use a mutex if I cared that much about the console printout being perfect, but it's non critical so whatever
}
[/code]
I pulled the curlon and curlat to their own in function variables because referencing in-function is faster iirc, but otherwise this is basically the same code that was used by the build() function to build the elevation map.
I should probably pull xdelta and ydelta too but I haven't seen the need really, I honestly probably didn't need to pull the other 2.
The way this works is essentially we only have to mutex anything that the stupid threads can use to steal returns. I might decide to mutex the slabptr call but it hasn't caused any problems yet even with 180 threads so idk, I'll see if it's relevant later.
Basically the single largest sink of time is building the elevation grid and model, second to that is the output files but I think I can just push those into their own functions for each file and thread them, probably 1 thread per since honestly, writing files is peanuts in comparsion. Generating all the noise modules takes like, maybe a second at worst.
[QUOTE=cartman300;52146439]Portals are not open doors tho
If you put one on the ceiling and one on the floor and drop something in it, what do you expect to happen? When an object goes trough the floor portal and therefore exits the ceiling portal, it can be assumed the object gained some energy to be somehow transported to a location where it has a higher gravitational potential energy.
The whole idea of portals is very absurd and standard conservation of energy doesn't really apply.
[editline]25th April 2017[/editline]
B) makes the most sense.
When the cube is at rest, the cyan portal is moving from the camera frame of reference. When the cube enters the portal, stuff gets swapped around. Orange portal becomes fixed in place while the cube is now moving.[/QUOTE]
That's because you're going from a position where gravity has more of an affect (where gravity can pull down on the cube. In your example video however, there can be no downwards force, as the exit portal is angled upwards, not downwards as in your ceiling example.
[QUOTE=phygon;52145769][IMG]http://i.imgur.com/wIByZY7.gif[/IMG][/QUOTE]
While I instinctively feel like B makes sense, I think a good thought experiment is asking what happens if the piston doesn't go down all the way, but only covers the top 10% of the cube maybe. Does it still get launched?
[QUOTE=Zero-Point;52146812]That's because you're going from a position where gravity has more of an affect (where gravity can pull down on the cube. In your example video however, there can be no downwards force, as the exit portal is angled upwards, not downwards as in your ceiling example.[/QUOTE]
That doesn't matter though. Momentum should be conserved, so the instantaneous velocity should not change when the box goes through the portal.
The only way to have the box come out at a different velocity would be to have the cube being compressed or stretched to compensate, which makes no sense. Ignoring rotation, if one side of the cube is moving at some speed, the other side of the cube has to be moving at that same speed.
[editline]24th April 2017[/editline]
[QUOTE=Dr Magnusson;52146993]While I instinctively feel like B makes sense, I think a good thought experiment is asking what happens if the piston doesn't go down all the way, but only covers the top 10% of the cube maybe. Does it still get launched?[/QUOTE]
10% of the mass would have the non-zero momentum while the rest would have 0 momentum? so it would feel an impulse upwards into the piston portal? :v: idk
Sorry, you need to Log In to post a reply to this thread.
What are you working on? v67 - March 2017
