K^2

Members
  • Content count

    3,794
  • Joined

  • Last visited

Community Reputation

1,329 Excellent

2 Followers

About K^2

  • Rank
    Particle Theory ABD

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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?
  2. K^2

    Best C Library for 2D Games?

    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.
  3. 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.
  4. 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)
  5. K^2

    Best C Library for 2D Games?

    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.
  6. K^2

    Metal rich planetoid thought experiment

    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.
  7. K^2

    Making your own code

    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.
  8. K^2

    Metal rich planetoid thought experiment

    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.
  9. K^2

    Making your own code

    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.
  10. K^2

    Making your own code

    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.
  11. K^2

    Future of game visuals!!

    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.
  12. K^2

    Making your own code

    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.
  13. K^2

    "Rokkit Syense" in CW's "The 100"

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

    Bullroarer

    If we think of it as an airfoil, definitely pitch.
  15. K^2

    "Rokkit Syense" in CW's "The 100"

    *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.