So here I was thinking I could fix the artifacting program if I was able to pull a copy of the module the libnoise was using to determine the value for each pixel on world build, but it's just 6 nested pointers into obscurity and I'm getting really tired of it. I can't even mutex the lower function on the sphere model its self. I've tried making a direct copy of the sphere model, but that doesn't work since it's still using the same pointer to the same module. I've tried creating a new module and assigning it the values inside the other module but it's an abstract class and I haven't quite figured out 100% what's happening yet. If I can implement copies of the noisemap or whatever this shit is calling to, I'll be able to build a map in roughly 70 seconds.
I think I might be able to just push the module::cache into the build function and then transfer it from there same style. Maybe.
[QUOTE=F.X Clampazzo;52155384]So here I was thinking I could fix the artifacting program if I was able to pull a copy of the module the libnoise was using to determine the value for each pixel on world build, but it's just 6 nested pointers into obscurity and I'm getting really tired of it. I can't even mutex the lower function on the sphere model its self. I've tried making a direct copy of the sphere model, but that doesn't work since it's still using the same pointer to the same module. I've tried creating a new module and assigning it the values inside the other module but it's an abstract class and I haven't quite figured out 100% what's happening yet. If I can implement copies of the noisemap or whatever this shit is calling to, I'll be able to build a map in roughly 70 seconds.
I think I might be able to just push the module::cache into the build function and then transfer it from there same style. Maybe.[/QUOTE]
what module is the one thats really giving you trouble? I can try to help more if you can specify which module is the issue, I had to get pretty familiar with how some of them worked to get them to work on GPU architecture.
[QUOTE=paindoc;52155480]what module is the one thats really giving you trouble? I can try to help more if you can specify which module is the issue, I had to get pretty familiar with how some of them worked to get them to work on GPU architecture.[/QUOTE]
Well, I was thinking that since Module::Cache FinalPlanet (whatever the capitals are) was the source module that each pixel's float value was called from. BUT, it turns out this isn't true either I guess, since I was able to create multiple sphere models using it and the same problem happened, so I thought, hey maybe if I just created a vector of NoiseMapBuilderSphere, I can just make each one output to the same elevation grid and just only do its own tiny bit as a thread. Which would have worked in theory, but I can't create multiple instances of an abstract class.
My next option I think is to just build my own implementation of the NoiseMapBuilderSphere and sphere model that aren't abstract classes so I can make the call for each pixel's float value from as many copies of the source noise module as I want. I believe this to be the problem since mutexing the write call to the elevation grid doesn't actually do anything since it works on pointers.
This final idea might be over-kill but it should work I'd think. idk. At this point, I'm amazed I got threading to work in the first place, even if it wasn't more than a few seconds faster on average due to the very sub-optimal mutex.
[QUOTE=F.X Clampazzo;52155745]Well, I was thinking that since Module::Cache FinalPlanet (whatever the capitals are) was the source module that each pixel's float value was called from. BUT, it turns out this isn't true either I guess, since I was able to create multiple sphere models using it and the same problem happened, so I thought, hey maybe if I just created a vector of NoiseMapBuilderSphere, I can just make each one output to the same elevation grid and just only do its own tiny bit as a thread. Which would have worked in theory, but I can't create multiple instances of an abstract class.
My next option I think is to just build my own implementation of the NoiseMapBuilderSphere and sphere model that aren't abstract classes so I can make the call for each pixel's float value from as many copies of the source noise module as I want. I believe this to be the problem since mutexing the write call to the elevation grid doesn't actually do anything since it works on pointers.
This final idea might be over-kill but it should work I'd think. idk. At this point, I'm amazed I got threading to work in the first place, even if it wasn't more than a few seconds faster on average due to the very sub-optimal mutex.[/QUOTE]
At this point, I'd say just dive into the source code of libnoise itself. There's not a lot of changes you'd have to make to get it to compile for 64 bit (if any, tbh, i'm not sure why you needed them in the first place).
When you try to create multiple models fed from the singular module chain, im not sure wtf would happen. I'm not surprised you get artifacting though. Whenever you see a call to "GetValue(x,y,z)" that just recurses through the list of modules until it gets to the first module, retrieves a noise value, then takes that value up the chain feeding it through the modules as it goes. Using this on threads shouldn't cause too many issues, I guess, since the only time you'll be possibly sharing resources should be in the base generator modules.
I imagine outputting to the same destination elevation grid also won't work. you're probably aware, but the grid size sets the resolution or number of sampling points and the parameters fed to the NoiseMapBuilderSphere class set the lattitude and longitude bounds that the sampling points stay within. So why not create separate heightfields that are "chunks" of your final heightfield, and change the lattitude/longitude bounds of each NoiseMapBuilderSphere appropriately? then each builder/heightfield could be on its own thread, and you can merge the data later maybe?
Without using the cheatsheets on the bottom, can you guess which is faster? buildb() or buildman()?
[url]https://gist.github.com/JohnnyonFlame/21f6230e518c680dcec1a2803be43dda[/url]
(Code is messy as hell, it's not production ready. It's just experimentation for now)
[QUOTE=Tamschi;52132803]You can probably tell the TypeScript compiler to use a newer ES version to make it emit it directly.[/QUOTE]
Just want to confirm that config directive below preseved async\await
"target": "es2017"
also realised how retarded the building of this typescript project was since long time ago, and I finally made it better for myself.
it was so bad I don't even want to go into details, I'll just let you know that it also consisted of a gulp task that copied node_modules to a separate directory
[QUOTE=paindoc;52155795]At this point, I'd say just dive into the source code of libnoise itself. There's not a lot of changes you'd have to make to get it to compile for 64 bit (if any, tbh, i'm not sure why you needed them in the first place).
When you try to create multiple models fed from the singular module chain, im not sure wtf would happen. I'm not surprised you get artifacting though. Whenever you see a call to "GetValue(x,y,z)" that just recurses through the list of modules until it gets to the first module, retrieves a noise value, then takes that value up the chain feeding it through the modules as it goes. Using this on threads shouldn't cause too many issues, I guess, since the only time you'll be possibly sharing resources should be in the base generator modules.
I imagine outputting to the same destination elevation grid also won't work. you're probably aware, but the grid size sets the resolution or number of sampling points and the parameters fed to the NoiseMapBuilderSphere class set the lattitude and longitude bounds that the sampling points stay within. So why not create separate heightfields that are "chunks" of your final heightfield, and change the lattitude/longitude bounds of each NoiseMapBuilderSphere appropriately? then each builder/heightfield could be on its own thread, and you can merge the data later maybe?[/QUOTE]
I was thinking about that, I've been working within the library already since I was modifying the sphere model to see if I could split the entire build process into smaller sets as you mentioned trying.
Im wondering if maybe chunking out the output would solve the issue but idk. If I combine them later idk if I'll see any benefit. I could implement futures and have an elevation grid be entirely made of futures filled by the threads, which might prevent any weird cross talk by the threads.
Edit: Nah, it looks like the issue is literally just within the line
[code]
//noiseutils.cpp
//classically found in NoiseMapBuilderSphere::Build();
float curValue = (float)sphereModel.GetValue(curLatb, curLonb);
[/code]
Mutexing around that single line stops the artifacting, but mutexing around the output:
[code]
*pDest++ = curValue
[/code]
doesn't do anything.
So to me, this seems like an issue with threads snagging the return float value from the sphere model that belongs to other threads? The sphere model's source module winds its way back to the previous source module, which I think ends at Module::Cache FinalPlanet in their program. I'm not sure though.
[QUOTE=suXin;52156408]Just want to confirm that config directive below preseved async\await
"target": "es2017"
also realised how retarded the building of this typescript project was since long time ago, and I finally made it better for myself.
it was so bad I don't even want to go into details, I'll just let you know that it also consisted of a gulp task that copied node_modules to a separate directory[/QUOTE]
I still have no clue about the build tools at all, so I use a (gutted) Vue.js community(?) template (Webpack with some minifier, I think).
In the process of porting my sprite lighting system to Unity:
[img]http://puu.sh/vyexU.jpg[/img]
[img_thumb]http://i.imgur.com/14mzZuI.png[/img_thumb]
Since my last post I added colored blocks and started work on networking the thing
Also changed my meshing algorithm to be more optimized and cute (thanks layla)
[QUOTE=fewes;52158070]In the process of porting my sprite lighting system to Unity:
[IMG]http://puu.sh/vyexU.jpg[/IMG][/QUOTE]
Aw yess
I loved your graphics work in the past; it's been awhile since I've seen this stuff.
Nothing spectacular. Working on a final project for a computing class I'm taking and for said project I decided to make a twitter bot. Reads CNN/CBS/NBC/FOX news tweets and forms opinions of sorts on them. Pardon the canned response lines, they do actually vaguely represent the severity of the bot's opinions on the matter. Will replace later with generated ones. It's all over the place though and has a number of hiccup spots so far.
Also, a side note, it's setup to "remember" certain topics so that if it comes across them later it will develop it's opinion further with respect to those previous events.
Themed on a 90's emperor caligula: [url]https://twitter.com/CaligulaBot[/url]
Highlights:
(Click the tweets for the normal tweet view (includes caption). Will make more sense that way.)
[media]https://twitter.com/CaligulaBot/status/857748122386264066[/media]
[media]https://twitter.com/CaligulaBot/status/857736799355064328[/media]
[media]https://twitter.com/CaligulaBot/status/857725514240405504[/media]
edit:
Also, I really gotta get cracking on those randomly generated response things because it keeps choosing the same few for some reason.
[QUOTE=Cow Muffins;52154976]I dig this one. I could see it being useful as a mobile app.
Getting notifications when the Jimmy Johns guy is handing out free samples would be killer.
Plus, college campuses, inevitably have some legends that would be cool to read about.[/QUOTE]
I'd love to do something like that but without anyone getting interested in it I can't get motivated to create such a thing
Anyone have any ideas for multiplayer games that I could make bots to play against each other in?
I've been running some Hockey? bot matches, which works well because there's no cheat protection, so the bots can work via memory editing, and everything is physics driven so you can't make a super overpowered aimbot or anything like that. Racing games might be another possibility. I know TORCS has bot racing leagues
[QUOTE=laserpanda;52159848]Anyone have any ideas for multiplayer games that I could make bots to play against each other in?
I've been running some Hockey? bot matches, which works well because there's no cheat protection, so the bots can work via memory editing, and everything is physics driven so you can't make a super overpowered aimbot or anything like that. Racing games might be another possibility. I know TORCS has bot racing leagues[/QUOTE]
I think good old [URL="https://sourceforge.net/projects/blobby/"]blobby volley[/URL] could be something fun to look at. Not sure if runs on recent Windows tho.
I've been reworking a lot of my game's code so it works properly at different frame rates. Before the game was locked at 60 and if the fps dropped, it would go slow motion (which could cause sync issues when playing online). The game is now using a variable time-step and has frame rate cap slider in the options.
[IMG]http://i.imgur.com/33Te8os.gif[/IMG]
Having the game a different frame rates causes a number of problems. The main problem was my animations not working correctly. There's a lot of checks to see if animations have reached a certain frame and that doesn't work if frames are skipped or are stayed on for multiple logic frames. I've reworked it so that kind of game code happens when animations change frame rather than in the normal game update loop.
Another problem is physics not working reliably at variable frame rates. The good thing is the game only has simplistic physics like a gibs or coins bouncing on the ground. I just had to tweak that a bit to prevent endless bouncing. For collision I use Separating Axis Theorem, it generally seems to be behaving at different frame rates. Though if I limit it to 30fps and I do a sudden fast movement like a leap, I can go through smaller collision boxes. There aren't many of those though and it doesn't break the game or anything if you do manage to jump through them.
There are also places where I use linear interpolation that end up working differently at different frame rates. For a weapon reload animation I made the player's arm move down to the belt, up to the gun then back to the resting position. Playing the game at 30fps made reload animations faster and playing at 300fps made them slower. To fix this I decided to make the reload animations animate based on time. Making it all based on time instead of waiting for the arm to reach it's current target before moving on to the next makes should make it work for any fps. For example; the whole animation for one gun takes 0.7 seconds, I then calculate the percentage of the total time past each update. Once 30% of the 0.7 seconds has past it moves on to the next part of the animation, then once another 0.14% has past it goes to the next one. The time and percentages I would need to figure out for each weapon reload animation.
Any java devs (familiar with processing) around with Steam/Discord who feel like adding me and helping me with some code? It's a space invaders game (pre warning, it's messy and patched together)
I keep getting a null pointer exception, my deadlines in a few hours and I just need to get these damn aliens to disappear when they get shot, i'm using them in an array (same with the lasers i'm shooting) but when i try to null the invader the game crashes.
Sorry if this is the wrong place, I just found the thread with the most people active in hopes of somebody seeing this and adding me :v:
'member how easy creating textures in OpenGL is/was?
[cpp]
// assume I've loaded image data from file into uint8_t* "image_data"
GLuint texture;
glGenTextures(1, &texture);
glBindTexture(GL_TEXTURE_2D, texture);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, width, height, 0, GL_RGB, GL_UNSIGNED_BYTE, image_data);
glGenerateMipmap(GL_TEXTURE_2D);
[/cpp]
Well, Vulkan being what is if (ofc), really shows off how verbose it can get when it comes to the [URL="https://gist.github.com/fuchstraumer/0ec1ae57a6210036963916088d8471fc"]nearly 200 lines required to create a Vulkan Image (texture objects in vulkan) from a file[/URL]. This also doesn't include the ~40 lines of code that creates/sets the image layouts and memory barriers for helping copy data to the GPU. The first "if" statement is just using a staging buffer if it makes sense to use one, which apparently can really help performance. Its still kind of weird though, because this doesn't feel entirely foreign to me after CUDA but its still so much more detailed and powerful than that was. And the API may be verbose and full of silly "CreateInfo" structs, but at least its in a decent shape and isn't as retarded as CUDA's API can be. Also, somehow the VulkanExamples I found weren't the cool as fuck (and more thoroughly recommended) VulkanExamples [URL="https://github.com/SaschaWillems/Vulkan"]here[/URL], which is where I'm lifting most of the code from. I can't claim any originality here (I usually can't claim much anywhere), but I'm mostly just trying to transcribe the code to pick up what I can about the monolithic-feeling API that is Vulkan.
On another note, past roommate sent me this great little thing he found at work:
[quote]
"Came across this beauty: hphplbl = vpprglbl->hrghplbl"
"Huge pointer to a huge pointer of labels = global pointer to pointer of labels-> handle of array of huge pointers to labels. At least I think that's the Hungarian translation"
[/quote]
For extra fun, try to pronounce it. poor sap also found a macro checking for Windows 3.1 support today :v:
[editline]28th April 2017[/editline]
also despite how easy it is to create textures in OpenGL debugging them is a tremendous pain in the ass, and I'm pretty sure that Vulkan has a debug layer that covers possible texture issues really well so hopefully that'll be less awful (pls). The standard validation layer set is a superset of all of the currently released ones, and it already makes it really easy to catch errors. You don't even need to worry about specifically calling a function to get an error - so long as you bound the debug callbacks to your instance upon creation and have the validation layers enabled, any detected error gets printed to the console. And the errors are concise and easy to figure out too. I'm honestly tremendously impressed with that aspect of Vulkan already, which is great given how much work it is to just get simple things written due to all the boilerplate code.
I maybe, MAYBE, may have finally got multi-threading working for this program.
It's building again anyway, I'll have to do some tests to see if it's actually faster, but whatever. If I get the right map on the output it'll be time to make the image renderers write from a vector of noisemaps instead of a single mutexed one and bam, suddenly it's fully multi-threaded sans the image renderers I suppose, but I can always make copies of the noisemap vectors and pass by value if I was really that dedicated to multi-threading the whole thing.
edit:
Well, it works, but it's still artifacting [I]some[/I]. Maybe if I just make my source module into an array of source modules and each builder gets its own identical source map too... Eliminate literally every single way they can steal each-other's shit.
[QUOTE=paindoc;52161913]'member how easy creating textures in OpenGL is/was?
[cpp]
// assume I've loaded image data from file into uint8_t* "image_data"
GLuint texture;
glGenTextures(1, &texture);
glBindTexture(GL_TEXTURE_2D, texture);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, width, height, 0, GL_RGB, GL_UNSIGNED_BYTE, image_data);
glGenerateMipmap(GL_TEXTURE_2D);
[/cpp]
Well, Vulkan being what is if (ofc), really shows off how verbose it can get when it comes to the [URL="https://gist.github.com/fuchstraumer/0ec1ae57a6210036963916088d8471fc"]nearly 200 lines required to create a Vulkan Image (texture objects in vulkan) from a file[/URL]. This also doesn't include the ~40 lines of code that creates/sets the image layouts and memory barriers for helping copy data to the GPU. The first "if" statement is just using a staging buffer if it makes sense to use one, which apparently can really help performance. Its still kind of weird though, because this doesn't feel entirely foreign to me after CUDA but its still so much more detailed and powerful than that was. And the API may be verbose and full of silly "CreateInfo" structs, but at least its in a decent shape and isn't as retarded as CUDA's API can be. Also, somehow the VulkanExamples I found weren't the cool as fuck (and more thoroughly recommended) VulkanExamples [URL="https://github.com/SaschaWillems/Vulkan"]here[/URL], which is where I'm lifting most of the code from. I can't claim any originality here (I usually can't claim much anywhere), but I'm mostly just trying to transcribe the code to pick up what I can about the monolithic-feeling API that is Vulkan.
On another note, past roommate sent me this great little thing he found at work:
For extra fun, try to pronounce it. poor sap also found a macro checking for Windows 3.1 support today :v:
[editline]28th April 2017[/editline]
also despite how easy it is to create textures in OpenGL debugging them is a tremendous pain in the ass, and I'm pretty sure that Vulkan has a debug layer that covers possible texture issues really well so hopefully that'll be less awful (pls). The standard validation layer set is a superset of all of the currently released ones, and it already makes it really easy to catch errors. You don't even need to worry about specifically calling a function to get an error - so long as you bound the debug callbacks to your instance upon creation and have the validation layers enabled, any detected error gets printed to the console. And the errors are concise and easy to figure out too. I'm honestly tremendously impressed with that aspect of Vulkan already, which is great given how much work it is to just get simple things written due to all the boilerplate code.[/QUOTE]
Every time I see theses posts my willingness to try vulkan decreases 10-fold.
[editline]29th April 2017[/editline]
I'm starting to lose sight of how it can be a better API than the alternatives given that the difference in time spent just to get trivial things done is like 1000% longer.
Golly gee do I love writing over 150 lists because I can't use maps because fuck me I guess? The real kicker here will be if lists don't work here either.
Oh I could have used an array, but I'm a fucking moron who wanted to make things more dynamic.:dig:
[QUOTE=Karmah;52163650]Every time I see theses posts my willingness to try vulkan decreases 10-fold.
[editline]29th April 2017[/editline]
I'm starting to lose sight of how it can be a better API than the alternatives given that the difference in time spent just to get trivial things done is like 1000% longer.[/QUOTE]
The difference is that there are no gotchas in vulkan, and that entire function can be broken down into lots of tiny fragments that are easy to reason about, rather than trying to create, copy, manage, setup, load and push image data to the graphics card all in one big function.
It's like saying that COBOL is better than assembly, because you haven't built the C compiler to put on top of it yet.
[QUOTE=Dr Magnusson;52163749]The difference is that there are no gotchas in vulkan, and that entire function can be broken down into lots of tiny fragments that are easy to reason about, rather than trying to create, copy, manage, setup, load and push image data to the graphics card all in one big function.
It's like saying that COBOL is better than assembly, because you haven't built the C compiler to put on top of it yet.[/QUOTE]
Exactly. I much prefer Vulkan over OpenGL even if the verbosity gets daunting sometimes. But that's why you built your own abstraction on top.
Also, regarding the it takes longer to do trivial things issue, that just shows how these things aren't necessarily trivial actually, they were just hidden away before.
[QUOTE=Karmah;52163650]Every time I see theses posts my willingness to try vulkan decreases 10-fold.
[editline]29th April 2017[/editline]
I'm starting to lose sight of how it can be a better API than the alternatives given that the difference in time spent just to get trivial things done is like 1000% longer.[/QUOTE]
As pointed out, there's a reason things take so long. The transfer of texture data is an operation that I enjoy having control over, tbh.
Dr. Magnusson had a good point. I'm still building the wrappers in many ways, so it all still looks pretty gross. OpenGL has to make assumptions about the layout of your texture data and the type of gpu its loading data onto, but Vulkan lets you choose a loading method and image layout that is optimized for hardware you're using. With OpenGL, that's probably left to the driver.
I also feel I'm probably bitching too much. My posts aren't meant as "wow fuck Vulkan", but really are just me expressing surprise at the depth of the API and the level of control it offers. I was also a bit salty because of some particularly awful code I found at work :v:
[editline]29th April 2017[/editline]
The Vulkan tutorial also states something important: if you're interested in graphics programming and gpu programming and want to get into the nitty-gritty of those things, Vulkan may be the API for you. Same if you really want every ounce of performance you can get.
But, if you're more interested in gamedev and the bigger picture, OpenGL is probably still your ticket.
[editline]29th April 2017[/editline]
[URL="https://github.com/prusa3d/Slic3r/blob/master/xs/src/libslic3r/TriangleMesh.cpp#L956"]this is the code that made me salty btw[/URL]. Highlights include:
- CYCLE: while(1), because this is a great use of goto
- for(;;)
- brackets missing errywhere
- nasty pointer business
- and more! yay!
[I]Reconfiguration of LibNoise to work in a 64-bit, Multi-threaded Environment[/I]
[I]we'll start with the results first:[/I]
5400x2700 lit, coloured map. Generated by the program.
[t]http://img12.deviantart.net/a6db/i/2017/119/a/5/terrain_by_johnpugsman-db7juas.jpg[/t]
[img]http://i.imgur.com/OTCVriVl.png[/img]
So, I only have one processor's worth of data right now, and it's a stock FX-4350 because it's the weakest processor I'm willing to drag out, and it's not insanely old. Otherwise I'd have maybe ran a test on one of the Athlon 64 X2 3800+'s I have kicking about in storage somewhere. Anyway. The findings were pretty astonishing to say the least. One would initially expect that you'd run into your best performance when closest to hardware concurrency in a multi-threaded program but I've apparently found that there's no best setting other than as many thread as possible, in this case that's 90 threads. You'd think we could do 180 in theory, but the program crashes when it tries to init180 planet containers. No idea why, probably a memory thing. There's a few things I could do to optimise the code but right now it works and that's about all that matters.
[I]How does this actually work:[/I]
Basically I started with how the map builds each elevation map. Critically it boils down to NoiseMapBuilderSphere, specifically the build() function. It can be found in noiseutils.
[code]
// we modified only 2 lines, the for statement for Y, and the declaration of curLat, which we set to latLow, the lower latitude for the chunk assigned to our thread.
// otherwise all we have to introduce is the mutex that locks the output part of our function.
double curLat = latLow;
for (int y = boundLow; y < boundHigh; y++) {
float* pDest = m_pDestNoiseMap->GetSlabPtr (y);
curLon = m_westLonBound;
for (int x = 0; x < m_destWidth; x++) {
float curValue = (float)sphereModel.GetValue (curLat, curLon);
OutLock->lock();
*pDest++ = curValue;
OutLock->unlock();
curLon += xDelta;
}
curLat += yDelta;
if (m_pCallback != NULL) {
m_pCallback (y);
}
}
[/code]
We also introduce a new function, giveChunk, this function passes the chunk information and the pointer to the output mutex.
BoundLow is the point in our output noisemap where the chunk begins, and BoundHigh is the top of it. LatLow is the latitude where the chunk starts.
[code]
void NoiseMapBuilderSphere::giveChunk(int BoundLow, int BoundHigh, int LatLow, std::mutex* mutex)
{
// assigns the boundries for each thread chunk
boundLow = BoundLow;
boundHigh = BoundHigh;
latLow = LatLow;
OutMutex = mutex;
}
[/code]
from there I had to work backwards to get each thread its own BuilderSphere to work from, and since this entire library works like a giant reference passing clusterfuck, I couldn't just create a vector of anything. It also can't be done with a list, though maybe it can be done with maps, due to the fact the library wants to send the elements of our container around like spam mail just to borrow their memory address. But first I set up the thread execution for each chunk.
[code]
// creates the spherical noisemap builders and elevation grid
utils::NoiseMapBuilderSphere buffer; // Builder Buffer
utils::NoiseMap elevGrid; // output NoiseMap
// the following are constants for each builder sphere
buffer.SetDestNoiseMap(elevGrid);
buffer.SetBounds(SOUTH_COORD, NORTH_COORD, WEST_COORD, EAST_COORD);
buffer.SetDestSize(GRID_WIDTH, GRID_HEIGHT);
// now creating vector of threads
std::vector<std::thread> threads;
threads.reserve(t); // reserve space for number of threads, t is defined at the top;
// determining the size of each chunk, thread total and output image height must be a factor of 180
unsigned int chunk = (GRID_HEIGHT / h);
int latchunk = 180 / h;
for (int i = 0; i < h; i++)
{
boundLow[i] = i*chunk;
boundHigh[i] = ((i*chunk) + chunk);
latLow[i] = -90 + (i*latchunk);
buffer.giveChunk(boundLow[i], boundHigh[i], latLow[i], &writeLock);
buffer.SetSourceModule(Planet[i].finalPlanet);
planets[i] = buffer;
}
for (int i = 0; i < h; i++)
{
threads.push_back(std::thread(&GenPlanet::ChunkBuild, this, i));
}
for (auto& t : threads)
{
t.join();
}
// image output code goes here.
}
// This stupid function only exists because I couldn't get each thread to execute the function for each planet[i]
// don't know why, don't care to find out rn, this works just as well.
void GenPlanet::ChunkBuild(int ID)
{
planets[ID].Build();
}
[/code]
From there all I had to do was create enough noise sources so my threads could work without fucking stealing each other's values from the sphere model. Since the seeds and values of the source are static and based on a config file I write, it's as simple as removing all the module generation from my planet generation class to its own class, PlanetContainer, which is named for the fact that all it does is create and store a planet. This meant moving literally all 128 or so modules needed to the header of PlanetContainer.h, and moving all the generation code to init in PlanetContainer.cpp.
From there I create an array of PlanetContainers and generate a planet using the init function, which passes all the variables defined by the config file to each planet.
I could probably use maps for more dynamic container storage to minimise memory space if I cared about running close to hardware concurrency, but tbh based on my initial run-time data, running a full 90 threads is seemingly most efficient anyway. I could probably also call for the destruction of each PlanetContainer as each thread finishes, but again, I really don't see the point when the program doesn't really need me to care that much about memory management right now.
My original computational time using the 32-bit library and only a single thread was something around 166+ seconds for the same size map, meaning I've been able to achieve a near 200% increase in program speed.
I'm going to spend this next few days/week cleaning up the code and adding comments then I'll be releasing the final source code whenever that's done. This depends on if I take a jab at multi-threading the image outputs as well, as that's the second largest time-sink in the program.
[QUOTE=tschumann;52147228]I saw this a few weeks ago and my first instinct was A, but as people pointed out, it has to be B because of conservation of momentum. But as cartman300 says, the idea portals is very absurd and I felt like A might be what actually happens in-game in spite of the laws of physics. But I guess I was wrong.[/QUOTE]
Portals themselves violate conservation of momentum if they aren't facing in opposing directions anyway, so arguing with that is moot.
[QUOTE=DrDevil;52166372]Portals themselves violate conservation of momentum if they aren't facing in opposing directions anyway, so arguing with that is moot.[/QUOTE]
Not necessarily, there are a few solutions to that that have already been mentioned here.
Portal portals very clearly violate conservation of momentum though, except in simply connected subsets of the world they exist in. That's definitely still a weaker guarantee, but it preserves all physics aside from that one theorem.
Implemented undo and redo into my shader node thing
[media]https://www.youtube.com/watch?v=WNOazZ-SA9c[/media]
[QUOTE=DrDevil;52166493]Implemented undo and redo into my shader node thing
[media]https://www.youtube.com/watch?v=WNOazZ-SA9c[/media][/QUOTE]
Seeing other people using PyCharm makes me so happy. I love using it so much.
[QUOTE=Tamschi;52166437]Not necessarily, there are a few solutions to that that have already been mentioned here.
Portal portals very clearly violate conservation of momentum though, except in simply connected subsets of the world they exist in. That's definitely still a weaker guarantee, but it preserves all physics aside from that one theorem.[/QUOTE]
Is there an established physics model that says what's possible if you just "turn off" conservation of momentum? Seems like it would make the whole thing very inconsistent.
Sorry, you need to Log In to post a reply to this thread.
What are you working on? v67 - March 2017
