Nuke

the rule of thumb is that arithmetic is free, memory is expensive, and communication is prohibitively expensive. if you can at all avoid moving the data over the pcie bus and instead use every bit of memory possible in the gpu, it will improve performance. procedural generation could stand to be even faster as you can just generate whatever data you need in the shader program. so long as generating the data every frame is faster than moving it from ram, you could save a lot of throughput for other uses. problem with procedural generation now is that most of it takes place on the cpu and thus incrus the transfer penalty, and you want to cashe it locally on the gpu to avoid that so it eats memory too. as a result you are starting to see geometry shaders that can generate geometry and textures on the fly. games run best when there is little or no bus traffic and thats why gpus have 8+ gigs of ram. where you have big open world games, keeping the bus idle frees it up for streaming in new textures and geometry for new areas as you progress. gpus are also starting to have direct access to storage to stream assets without bugging the cpu (sort of like dma for shared bus systems of olde). unfortionately i dont think gpu manufacturers are going in that direction, it seems like they are all in for ray tracing even though it is impractical at a consumer friendly price points and costs a lot of heat and power consumption.

its sort of like that scene from armagedden where the cosmonaut starts smashing the panel. "american components, russian components, all made in taiwan!" i actually have a collection of us made components that is disturbingly vintage.

the core unity engine itself is c++. c# is just the scrpiting api. its correct to say that ksp is written in c# because you can stay out of the (what modern coders call dangerous) c++ code and get the engine to do what you want. but you really want to be close to the metal at the low level where it matters.

i think the problem is you cant work on two things that interact with eachother at the same time. this is bad in situations where you need to test every object against every other object, like physics and collision detection. thats why my minecraft example skipped adjacent chunks. if you need to propagate a redstone signal from one chunk to another, you need to be able to modify the edge of the adjacent chunk. then that signal is propagated to the other blocks when that chunk is processed. the 2x2 chunk would require the chunks be organized in a way where you can modify the edge blocks on both sides without them interacting with the same memory regions (say using quadrants within the chunk). otherwise you would need to do 3x3 hunks to keep the memory areas isolated. having two threads write to the same thing at the same time, especially something that is going to change the size of the structures. you have to process nine chunks instead of four, but other threads are doing the same in adjacent chunks. you normally use semiphores and locks for this so you dont write to the same thing at the same time, but i think its possible to partition your world in a way you can multithread it without a whole lot of inter-thread communication. need not be a multiplayer only thing i suppose. even ksp1 has rendezvous. it would be nice if it could handle multiple rendezvous simultaneously, but im not sure how you would accomplish that with only one player. ksp actually runs 2 different physics simulations simultaneously. the parts within a craft, and different craft. ksp 2 might also do physics siumlation on the other craft's parts. really if you are doing something to get both those ships shaking to the point where the inter-part interactions matter, you are probibly about to have a visit from the kraken very soon. i dont think languages often used for games and game engines, namely c and c++, ever added native multithreading features. so everything needed to be handled by the programmer or 3rd party libraries. lisp on the other hand is a language for supercomputers and is built around the idea of doing the same operations on multiple data. though i doubt you will find many games written in it (freespace did have a form of lisp for its mission editor). newer languages (read: ones i dont know about, but probibly c# is a good example) will no doubt have these features built in. lua had co routines but i dont think it threads them.

cant imagine it would be too much trouble to have a high thrust but short lived srb kick motor for such emergency situations. enough to dodge an incoming projectile long enough to get the drive online. might pull a few gs for a few seconds. of course the missile will probibly have the same thing. ive made the cheetah vs gazelle analogy before. cheetah is the missile and the gazelle is the ship. if the ship can survive the initial moments of the engagement then it stands a good chance of out sustaining the missile and can win by endurance alone. one or more kick motors might enable that. i dont think wrinkles would be much of an issue in zero g.

been thinking of getting a usb microscope to make it easier to solder small components. i cant read the print on the chips any more, makes me wish id have gone with the bifocals. sometimes i wonder if other people make things. as for the samples, just have the kids catch their own bugs. or go to the pet store and buy some feeder crickets.

torch ships are cool, and the expanse is awesome for using them and laying their ships out in a way that makes sense for the technology. technically star trek's impulse drives are torch drives, but they still lay their ships out like a damn ocean liner. they have inertial dampeners and artificial gravity, so they can modify inertial frames and gravity. which begs the question why dont they use that tech for propulsion and leave the torch drive in a museum somewhere. despite this the expanse is not quite realistic in terms of thermal management. torch ships are not an irl impossibility per se, but its going to cost you some radiator mass. you could do something cool in military engagments, like target the radiators to what amounts to a missile with a flak warhead. this would cripple the engine and force a surrender. or you could cook off your engine in a vain attempt at escape, and use it to dramatic purpose in story telling. the expanse is smart in that it pushes the realism in a way normal tv watchers can understand, but omits some details. for the same reason the radiators were removed from discovery in 2001. its an added detail that most people wont understand (unless they are an automotive mechanic, a nuclear power plant technician or an hvac specialist, even a pc builder will understand waste heat). i dont like it when a story dumbs itself down for the sake of the audience, it just makes people dumb not giving them stuff to think about. i tend to think that if your story is interesting enough you really dont need to skimp on the details and the details can reinforce the story (the expanse does this, even though they might not go far enough for some, they deserve credit for what they do). one of the reasons andor does so well i think is that they actually care about the characters and the details and dont try to explain everything or obfuscate it from the audience. not every story needs to be brain off popcorn in face.

i like the idea of thermal engines which can use anything as remass, granted with a wide range of specific impulses. i think this would be best used for asteroid mining or inter-moon operations (say in the jovian system). you could use anything as propellant provided you can liquefy it/compress it and purify it, and so long as it doesnt react with parts of your engine. the heat source is irrelevant, it can be nuclear, beamed, etc. you just need enough to get you to your next destination, and harvest whatever local resource your engine will like most.

so long as its not pocahontas dances with smurffs in the story department.

minecraft is one of those games which i think would benefit from strong parallelization. it doesnt of course, not stock, and not in either java or bedrock as far as im aware (i think optifine does as well as some server side stuff). mostly by doing chunk updates in parallel. spatial partitioning is already built in to the game. i figure do not simultaneously update two directly adjacent chunks simultaneously. logically define groups of chunks (say 4, 9 or any square array of them), lets call them hunks. each thread would process a hunk, one chunk at a time (each thread would process the same chunk in their respective hunks at the same time), such that no two adjacent chunks are simultaneously updated. if you have 16 threads, you could simultaneously update a 4x4 grid of hunks. which means your ginormous redstone powered base wont lag your machine anymore. you may encounter a race condition where some chunks process faster than others, leaving a lot of cores to sit idle waiting for the signal to work on the next one. while i think this is suboptimal. but remember you are doing 16 or how many ever threds you have, minus one or two to handle things like rendering and i/o (rendering will also be sped up since you aren't handling chunks on that thread). i believe something like this is actually done in some servers, though it would be nice if it would also work in single player. still, big lost opportunity there. ksp2 will probibly have to use moving partitions to handle single craft or groups of craft interacting. a ship at jool likely has little impact in the kerbin moon system. problem is the same, as you are going to have densly populated areas with a lot of interaction as well as a bunch of loners in simple ships doing basic things. so the thread disparity is going to be a lot bigger than it is in minecraft. physics is usually a big n^2 problem, so finding some way to partition out interactions that can then be handled on other threads just dont matter to the current situation. radius checks and dot products of velocity in some agreed upon frame of reference is good enough to tell if ships have a chance of interacting at all. of course that only really applies to multiplayer. threading inter-part interactions on a ship is going to be a bigger problem and proximity will likely require it all be done on one thread.

dds is still pretty antique. they were introduced on s3 graphics cards way back in the voodoo era (voodoo cards also supported the format as well as its own inferior fxtc). there are newer formats like astc and etc that seem to see very little use on the pc (though are used heavily on smart phones and portable devices, possibly game consoles). ive always advocated storing textures in a lossless format like png. at first launch the game can query the hardware for texture capabilities then transcode and cache the textures in the best available formats, and scale them for best performance. while some games do this, i suspect the lack of uptake may be due to the fact that its better to use the most compatible format to save space as the bulk of game data is textures. also perhaps game studios don't want to leak their production quality textures.

red is the plan as both arc and 40xx series turned out to be non-starters. the arc wouldn't be an upgrade, and the 40xx is fine if you are looking to buy a really inefficient space heater. whether or not i have money when those drop is another matter.

im on a 5800x so i think im good in the cpu department for the forseeable future. i think its a good rule of thumb to skip at least 3 or 4 generations before an upgrade. and i always try to stay at the upper middle tier in terms of performance. gpu upgrade was just something that fell through when i built this rig due to the shortage, and due to lack of advancement in the more consumer friendly tiers. the 2070 super turned out to be such a good card, both in terms that it paid for itself (and half my rig) in mining and also does everything i want to as far as gaming is concerned. still id like to be able to push more pixels faster to feed my 144hz 4k monitor.

i bought six bags of candy for haloween (mostly because we couldnt stop eating it) and we got 5 trick or treaters.

my current rig can probibly handle it, but i still want to upgrade my gpu. i have cash in hand but im waiting for amd to drop their new line (i think next month). either i like their offerings or i end up getting a 30xx. arc sucks and 40xx is too big (just when i get into <12l sff builds they make all the hardware bigger) and sucks too much power for my tastes. just needs to be better than the 2070 super. cash in hand is an ephemeral thing, i always find some practical thing to spend it on and its a state that does not last forever.

i have a feeling ksp2 will be cpu bound, because physics*. so id prioritize good cpu performance over a fancy gpu. *unness its using gpu compute for that. im not talking physX, as thats nvidia only, but it should be possible to roll a compute based physics engine, it would compete with rendering so that might be a problem. a bigger problem is that consumer gpus generally have their double precision compute intentionally nerfed over workstation cards, and i think you need double precision for space math. it will still do it but not as fast.

some of these consoles are stupid expensive. you could get middle tier pc gaming hardware if you build it yourself and eschew stupid things like led lighting and water cooling.

yea i was never good at following instructions. also i picked 2.

non-planner circuit boards come to mind. use a dual head extruder to lay down conductive traces and another the substrate. be able to print capacitors and resistors in place (brownie points for 3d printed semiconductors), other components could be installed later with conductive epoxy. i mean you can get conductive filaments now, but i have a feeling there is still quite a bit of room for improvement. if the conductive filament puts out a lot of strings it might short out some connections. were still a long way from being able to do what you can do with a chem etch board, but i hope they find a way to close the gap.

coming soon to a spool of 3d printer filament near you.

yea the walking dead has been on way too long. i think it has ruined zombies for me. its like the fifth season of babylon5, but for 5 seasons, at least.

idk when i started shaving i had a rotory that worked fine. a decade or so later i got another rotory that was just terrible. my solution was to move to an alaskan fishing town so i could grow a beard without being out of place.

so the afterlife is not on kerbin. that song is in my ksp playlist for obvious reasons.

tales of the jedi was better than i expected. of course its like 6 short episodes and binged it after watching the latest episode of andor.

i once knew an engineer. he built a shop off the side of his house. because of the heat differential and near 100% humidity that comes with southeast alaska, we had to devise a drainage system for the condensation. his prediction for where the condensation line would form was spot on. we just hung a section of rain gutter, hung it from the ceiling on chains at an angle, and put a hose fitting in the end cap. the hose was then routed through the wall and out the shop. would make a cool ice formation in winter. i figure the trick was having a clean definition between the cold side and the hot side. in our case it was the point at which the roof was extended, as the shop wasn't insulated and the house was. so i figure the best bet is to put a hard split between the cold side and the hot side. hang a line between two posts, throw a tarp over it. put the hot side facing sunward, shade and insulate the cold side. angle it steeply so that the water droplets will drip down into a collection trough (this could just be a pvc pipe with a quarter cut out of it). the sides will need to be covered partially to contain the humidity gradient.