K^2

This is incomplete. Radial burn isn't inherently inefficient. Energy-efficiency of the burn is proportional to cosine of the angle between your prograde direction and direction of the burn. If you're in circular orbit, instantaneous efficiency of radial burn is zero. Of course, as soon as you start burning, the orbit stops being circular, and things start improving, but you'll never have that 100% energy efficiency that you would with a prograde burn. Vertical ascent to altitude is a prograde burn, even though it's also radial. That bit is as efficient as it can be. Circularization will now take a lot of fuel, because you start from stand-still, but if you have no intention of making orbit, that's irrelevant. This is further complicated by the fact that have you had very high TWR and started from a vacuum world, burning straight up would be the best way to gain altitude. Again, given that you do not plan to establish orbit. It's when your TWR is comparable to 1 that you start getting benefits of gravity turn when shooting for altitude. So it's not that simple.

I'm not sure what you're trying to refute. This has been established several posts ago. You specifically asked if dV results in same velocity difference in inclination change. THEN you brought up energy and angular momentum. The only claim so far has been that application of same amount of dV as an instantaneous impulse always produces the same change in velocity.

So? We're just talking about the fact that dV applied as an impulse is always the same change in velocity. Velocity being a vector is the only bit that applies. How all other quantities transform is up to details. Inclination change produces zero change in energy. But it's still the same velocity change for the dV applied. Whereas prograde burn will increase energy. Angular momentum is a lot more like velocity here. An inclination change produces the vector change in angular momentum that has the same magnitude as increase in angular momentum due to prograde burn. In fact, dL/m = r x dV, so only a radial burn will produce no change in angular momentum. (But is still the same change in velocity!)

You're basically on track for resolving your conceptualization problem. Same amount of fuel burned by the same rocket should give it the same change in velocity. Yet rocket gains more energy if it goes from 100m/s to 200m/s than if it goes from rest to 100m/s. Where does extra energy for this come from? Well, how does kinetic energy of fuel/exhaust change in both of these scenarios?

On smaller projects, it's sometimes fun to do things the most challenging way. But it rarely pays off on larger ones. Just because you can make headway with the wrong tool, doesn't mean you should if you can get more done with less time spent. In this particular case, you can probably write the whole thing in C and not have to sacrifice much. Although, you will probably already be writing hacks. I used to work in a game studio that had an in-house C engine. One of the things that stuck in my mind is the way UI widgets worked. There was a struct Widget. And then a UI component that was also a widget, would include it. struct Button { struct Widget widget; // ... }; Now you can pass pointer to Button to a generic function that handles any Widget by simply type-casting the pointer. Yes, that is basically an inherited member function call implemented entirely in C. (Indeed, that's how inheritance actually works in C++) The peak of insanity was character movement code, however, which had something not entirely unlike virtual functions implemented for different movement types. Back when that code base was started, about 15 years ago, there was a very good reason to stick with C. C++03 was a new thing back then, and even with these improvements, it was a clunky language that took forever to compile and brought loss of performance with it. If you wanted a high performance engine that was easy to work with, you wrote it in C. At least, the heavily used portions. But C++ isn't the same anymore. Compilers and optimizers got a lot better, and the standard enforces many good practices. Today, if you are finding yourself hacking in inheritance, virtuals, lambdas, or templates into C code, it's a sure sign that you should be writing in C++. Big part of working with the write language is not whether it makes it easier to solve problems or not. Where it really counts is when you have to revisit code you wrote months back. C code gets really hard to follow once it gets sufficiently complex. C++ can get worse if you write bad code, but it gives you many opportunities to make it very easy to follow if you do it right.

Yes, because velocity is a vector. delta-V isn't change in speed. It's the magnitude of difference in velocities. I believe, you mean energy here. This can mean more velocity elsewhere in the orbit, but instantaneous change will be exactly the same dV, just as you explain above.

This equation is correct for circular orbits only. It is not correct for apsides of the elliptical orbit. Also, be careful with units. The 9.8 in this equation is surface gravity in m/s2, which locks you into using meters for body radius and altitude. Note also that this is equivalent to a more conventional form v = sqrt(GM/r)

If you want to do C, just do OpenGL, honestly. It has C bindings, and while it can do fancy stuff with extensions, you don't have to dive head-deep. You can do easy 2D stuff with minimal setup. C++20 might get standardized 2D graphics via io2d library. There is a proposal for it, but it's in a very uncertain state at the moment. That said, if you want to take a deep dive into the world of modern C++, three is a reference implementation of io2d that you can use in your engine and replace with standard C++ if and when that gets released. Edit: Looks like graphics TS has been deferred, meaning definitely not C++20. They're still working on it, so it still has a chance of being a C++23 or later feature. The reference implementation is still maintained, however, so the option of using it in your project is open.

I don't see where symmetry breaking for magnetization would come from. Rotation due to tidal lock just isn't going to be great enough without liquid core. I suppose, some asymmetry in metallicity could do it, but idk. If magnetic field forms, it changes things dramatically, but that's above my pay grade. Otherwise, that first image seems like it'd be in the ballpark. Not to scale, of course.

If you mean, C is easier to learn and use efficiently for somebody who's new to programming in general, with a goal of writing a simple command interpreter, then yes, I agree. What I was saying is that reason that existing interpreters, ones that were written by people you can't call amateurs by any measure, were written in C are largely outdated. I guess, we were talking about different things. C will result in a whole lot of repetitive code that can be minimized with templates. Consider a task of writing a 6507 VM for an Atari emulator. It has a 1 byte instructions, so short of transpiling or JITing, your best bet for good performance is to simply have a 256 instruction lookup table filled with function pointers. But a lot of the instructions in the table are going to be essentially the same code, with variations on which registers it operates on. Each instruction that operates on memory, for example, will have a version that operates on the zero page. And while you can write each operation function to include conditionals based on specific op code, that results in a lot of unnecessary thrashing on every single byte of code. In practice, what you want is to have each entry in your instruction map to point to a simple, linear code. That results in very good prediction performance. The C solution is to either write a separate function for each instruction, which takes a lot of time, hard to read, and hard to debug. Or you can write macros, which will take longer to write, be harder to read, and even harder to debug. Or you just byte the bullet, write messy switch for each instruction, and hope that performance just won't matter for such a project. (Which is probably true, but it still stings.) Your other option is to write templated code in C++. In this case, you can pull all of your register and memory code into common templated structs with getters and setters, which, being templated statics, will get inlined in each version of your operation. And now you write just one version of ADD instruction, templatized on memory/register type, that uses the same getters/setters as every other instruction. You end up with clean, readable code that is very cache and pipeline friendly, and performs as well as if you've written the interpreter in assembly. Of course, if you're making your own scripting language, you can design its features around being friendly to simple C code. Whether or not that's a limitation in any particular case will depend. But there are definitely good reasons to bring out heavy guns for interpreter if you aren't squeamish about templates. The C++20 concepts will make this even better.

I'm not a layer plasma physicist, but I have two insights. First, solar wind is at least partially a plasma flow. Without a significant magnetic field, any charge build-up will be self-correcting. I expect such an object to be neutral unless there is some weird dynamo effect going on, but I can't think of any reason why there would be, because of insight two. Reynolds number for Ceres-sized object inside of Mercury's orbit is going to be a lot less than 1, unless it's close enough to the Sun to be evaporated. Consequently, the flow of solar wind around such an object can best be classified as boring. There's still going to be a shock, and a bow wave is going to form a very narrow cone behind the object with low plasma velocity inside the cone. But at Re << 1, the plasma flow inside this boundary will gently hug the surface without any turbulence. Boring. I'll happily stand corrected if I missed anything, because as I've pointed out, plasma flows were never my speciality.

This is a somewhat dated view. Compilers got a lot better, and standard enforces some good rules that lead to better optimization now. There isn't a reason to chose C over C++ for performance anymore. Of course, you have to know how to write in C++ without relying on standard libraries if you're going to writer drivers or OS code, and when writing for performance, know which standard library calls do expensive error checking.

No thank you. But JS front and back is completely fine, so long as you use modern frameworks and keep in mind limitations of JS backend. I'd even say QBasic. But I was learning to code on MSX BASIC. I didn't know how to use loops and subroutines until I switched to C. Fortunately, that happened very early.

These kinds of effects have been simulated in games for quite a while. It's not hard to apply motion blur based on velocity differences. This is more commonly done with respect to vehicle wheels and propellers, but it's the same exact principle. And computationally, way cheaper than high frame rate. Suppose, you had a screen that can support very high frame rate, and a beefy graphics card that can keep up. Would you rather run the game at hundreds of FPS, or cap it at 60 or 90, apply effects to get all motion blurs looking exactly as they would at high frame rate, and then use the spare computational power to crank up draw distances, detail, environment lighting, etc. to the max? I can tell you which one the development team is going to go with.

I've hit the same rock on my path. I've heard CS professors say, "It's alright if you've never programmed before. It's much worse if you know BASIC." Picked up some bad programming habits that it took me years to get rid of.

Eh. That's basically Apollo XIII in a nutshell, so I let that slide.

If we think of it as an airfoil, definitely pitch.

*snort* I can already picture a space-themed sci-fi show that hired a bunch of KSP players to consult, none of whom have any other science/industry experience. Asparagus stages and drop tanks. Struts everywhere. I think I want to watch that.

What possible new things can you get out of not seeing something another way? Absolutely anything that's game-play relevant can be simulated by selectively rendering or not rendering. Even if you want to do a one-frame quick flash of something, and the frame rate isn't high enough, you can render it with low opacity, and it will look exactly like it flashed for a fraction of a frame.

Why do you need things moving really fast to make them invisible, when you can just not render them in the first place? While there are some limitations, when you are writing a game engine, you basically make the rules for the world you are creating. It's like having a personal Gandalf. Need eagles? Bam! Eagles. You don't need to worry about things like, "How do I make it so that the object is there, but you can't see it?" You simply set it to participate in game logic and physics, but not in rendering. And that's it. It's there, and invisible. No need to try and hack your way around it when you have all the controls.

Probably a switch wrapped in a loop. Just a guess, though. The only way I can think to test it is to write a program with gotos in C, compile it to WASM with LLVM tools, and then disassemble the output. P.S. Depending on what the optimizer does, WASM switches might avoid a lot of the worst-case problems that show up in JS, so you might gain some performance in this instance. But I haven't seen any benchmarks for this. Benchmarks I've seen are for fairly generic code.

Yeah, that gap takes an effort to close, but basically everyone who works with assembly professionally ends up using instruction references, so that's the only material available. It gets worse if you have to write machine code by hand, because documentation on which bits mean what within the instruction are extremely cryptic, and basically follow some sort of an Intel shorthand from decades and decades ago that I have to track down explanations for every time. Why can't everything be like MIPS? (Don't answer that, I know why, just complaining out loud.)

Don't get me started on The 100. I enjoy the show, though I couldn't tell you why, but absolutely everything involving any kind of science makes me cringe. Pointing a rocket towards the ground and firing the engines is not how you make it re-enter... That's probably the biggest and earliest cringe, which they've done multiple times afterwards. But it just does not get better. I don't normally complain about things like this, but the show is obviously trying to be hard sci-fi. And it does it completely and utterly wrong.

I don't think this is a thing that's even done anymore. People write assembly inserts. Especially if you're a driver dev. And people need x64 assembly for debugging and otherwise messing with compiled code. But I'm not sure you'll find modern books on straight up programming in x64. If somebody wants to prove me wrong, I'd be curious. I would take a more practical approach. If you are more interested in actually writing entire code in assembly, this is still something that's done for MCUs some times. I'd pick up something on, perhaps, PIC MCU, and either an actual chip with a USB dev board or an emulator, and just play with it. Alternatively, there is a lot of good material on disassembly and debugging, which involves learning a lot of modern assembly. This is in case you are specifically interested in x64 and what compiled code looks like after optimizer had a go at it. For this, you'll want ability to compile your own code from C/C++ and be able to use debugger. gcc/g++ and gdb will do. Though, personally, I prefer the clang/clang++ and lldb combination for this. Unfortunately, all of the books I have on the subject are hopelessly outdated. So I can't recommend anything specific. But if you search for something on security and disassembly, you'll probably find something.

To be fair, a lot of that is from density variations in the upper atmosphere. If you're shining light through atmo at sea level, you can probably do a little better. Still, having that as the worst case scenario and vacuum as best already puts some constraints on the question.