Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

  • Days Won


Green_Baron last won the day on October 1

Green_Baron had the most liked content!

Community Reputation

158 Neutral

1 Follower

About Green_Baron

  • Rank

Personal Information

  • Role
    Amateur / Hobbyist
  • Interests


  • Github

Recent Profile Visitors

5363 profile views
  1. Green_Baron

    C++ C++ size_t for everything?

    Sorry if i sounded disrepectful, wasn't meant so. What i meant was that the discussion just shows the possible confusion. You have my respect. ------ After leaving the loop the unsigned counter would still be wrapped around. No problem if it's defined local in the loop. But if it lives outside for later use or so one should keep that in mind ... i would arguably regard -1 as being more intuitive than the maximum of the size type ....
  2. Green_Baron

    C++ C++ size_t for everything?

    Haha, now, if that discussion is not an argument pro signed integers in loops, just to avoid confusions, then i don't know what ... Just trying to be funny๐Ÿคก p.s.: have you tried it, with a std::array and the range checking at(), counting down ?
  3. Green_Baron

    C++ C++ size_t for everything?

    Dunno, some if not many situations need operations on the indices, that include comparisons with signed variables, subtractions, counting in a loop by steps !=1, etc., so many opportunties to miss the 0, wrap around, narrow ranges, hide things behind work-arounds and casts if sticking to unsigned too long. This may be qualitative, semantic, relative, whatever, but i don't see it so strictly. One could even question the stl guys' decision to choose unsigned integers for indexing. It is narrowing. But so it is. Yet signed integers have their place. Just because they could make off by one errors less catastrophical :-)
  4. Green_Baron

    Where to find resources about physics simulation?

    Hi, since you haven't specified, may i ask are you looking for the basics ? There are quite a few implementations and books, if you search "real time collision detection" or "game physics". Or is it about specific work on a specific subject, as you mentioned research papers ? In this case it might be good to know that subject and how realistic "somewhat realistic" means ๐Ÿ™‚
  5. Looks nice, thanks for sharing.
  6. Well, it depends a bit on what "Newtonian" and physics here means. I first thought (also because of the mentioning of KSP which basically implements newtonian physics) that it is about movement in space around a body. Since these are allways in an orbit forced by gravity (in game simplified as conic sections), there is no strafing or flying towards, these things simply don't exist under newtonian physics. In order to meet with another one would have to align orbital planes (via manoeuvers in the ascending/descending nodes) and raise or lower apses (via manoeuvers on the opposite side) in order to fall behind or to catch up. You couldn't even fire a missile any time you like because that'll be bound to its orbit, too. For a space shooter that is of course pretty boring if not irritating, but would surely have its own appeal. A UI for this would surely be fascinating. Orbiter as well as FlightGear have both implementations of the Shuttle orbital manoeuvering systems and controls. Seems like i was a little mislead and as usual far too much entangled in (pseudo-)realism, because if it is the classical linear movement that counts here (like in the X series of space games), then of course things are easier.
  7. Green_Baron

    C++ C++ size_t for everything?

    Ha ๐Ÿ™‚, since everyone is riding that wave: sure, i am aware of a bunch of solutions to the "problem". But i have just recently commited such an error, as a result of a refactoring i overlooked a comparison and the respective compiler warning ๐Ÿ˜ณ So, apparently i am in no position to offer a general statement on do or don't use this or that datatype. Personally, i prefer one of the intx_t/uintx_t types and size_t when that type is expected/returned. I don't use it generally.
  8. Green_Baron

    Most innovate games of the last decade?

    Factorio is really nice. I found the space games that introduced realism into gaming quite innovative, namely Orbiter and Kerbal Space Program. Both aren't the most graphics intensive games, but nevertheless quite time absorbing. But of course, like any game, one day we've had enough ...
  9. Green_Baron

    C++ C++ size_t for everything?

    A semantic question, isn't it ๐Ÿ™‚ ? OpenGL sometimes uses signed integers where i'd intuitively would choose an unsigned, so to avoid warnings or casting we might want to submit to the circumstances and use an int, too ? When looping around to fill arrays or buffers and the like we sometimes count down to >=0, an unsigned would be suboptimal then ... What about choosing the datatype for a situation that avoids demands the least type casting ? Dunno ... i'd say no, not for everything. But for sizes, yes. Imagine: 10 "guidance is internal" .. 8 .. (and so on) .. 1 .. 0 .. 65535 .. 65534 ...
  10. A PID controller comes to my mind ... But maybe we can try to specify a graphical solution, and pls. somebody interrupt me if i talk nonsense. So, initially our ship moves linearly, in a straight line with known speed and mass. The thrust its engine can produce is constant, with known force. For simplicity mass doesn't change because of fuel burn ("infinite fuel"). Let's assume that we allways burn right-angled to the course line for a change in direction. Then the rate of change per time can easily be calculated (a simple vector addition of course- and thrust vector) and the plotted resulting courseline over a longer time under thrust would ba a circle segment, right ? Now there is a point away from the course line that we want to cross. A line through that point that cuts our straight courseline some time ahead would be the new course line that we want to achieve in a finite time. Now, to calculate the start of the burn, we "simply" must put our circle segment ahead so that the entry lies on our course and the exit on the new courseline. For that we must have the radius of the circle and the position of the center. The latter is in the same plane as the two course lines, i let someone figure it out, shouldn't be too complicado. Now, this must be done for every such future change. Allways leaving enough space and time between changes to actually get on the new courseline.
  11. Real time in space can be boring ... ๐Ÿ™‚ Question: are you looking for the physics ? First, the force is produced by thrust, not dV. dV describes the ability of a ship to perform a change in velocity over time. It is a simple calculation, based on the ship's mass at the beginning, mass at the end of the manoeuver and exhaust velocity of propellant (Ziolkovsky, rocket equation and all that ...). You can release that dV in a short time with a high thrust (e.g. chemical), or over a long time with low thrust (e.g. electric). The resulting change in orbital trajectory is very different, though the same dV has been released. Or is it more about the UI to actually set up a manoeuver ? I found the ksp mechanics far too fiddly and very inexact. It was barely okay for the toy planets. There was an addon to help setting up an exact manoeuver by typing in the numbers for the 6 movement vectors (trivial 2-body, ship/planet relative: prograde, retrograde, normal, antinormal, radial, antiradial). I would do that in conjunction with an orbital calculator that precomputes the values based on the current trajectory and a chosen point/time combination where my ship should go to. Like, i want to intercept that other planet/ship/'Oumuamua at a given time, show me when to burn, but pls. take into account for ship's mass change and burn time. KSP never was able to do that when i played it ... Orbiter had an addon, i think ... Does that make sense ? Sorry if not ... but i am interested in these things as well.
  12. Green_Baron

    asteroids ship movement

    I believe this keeps you running in circles. You will not find anything new in your old threads. I did a brief search and found this that appears to me as being close enough to your setup (it is one of a series that explains the "historic" opengl and uses glut). Don't necessarily program things, just read and understand. And you must be able to do the abstraction from a toturial that shows you how a specific thing works to actually implementing it in your use case. That is an ability no tutorial or online help can convey and comes after understanding the technique. First understand how it works (rotation martix, axis rotation and all that), then how to apply it to your ship. And when you're thorugh with these, then the real problems show up. But that must yet be seen.
  13. Green_Baron

    asteroids ship movement

    How long shall it go on like this ? You post the same lines of codes and the same questions over and again with no sign of actual understanding. You must learn to solve your problems by yourself and not demand help every time you stumble upon a step like a boolean won't flip or a comparison goes wrong. There are more than enough tutorials on opengl 1 and 2, with extensive examples and pages after pages of explanations of how these things work. We can't do better than these. Well, i can't ...
  14. Exactly, it is derived from lat/lon positions on an ellipsoid and a distance between posts expressed in degrees. Just another planet renderer (yawn). Correct in the first part, but the lodding is not done via mipmaps, it is a cdlod clone i use. Edit/Correction: not one large height texture, it is far too large and may have white spots, but stitch together individual tiles based on their position.
  15. Hope i don't confuse things, have spoent the afternoon constructing related textures but with different content ... Well, it is not that the distance between texels directly corresponds to world positions. A texel is just a height value, it's world position comes from other sources and is calculated. But i don't want to go deeper into the LOD algorithm, will do that in my blog one day soon(tm). A rectangle texture might only have advantages if it is faster than a full blown 2d texture, but i'd consider tackling and comparing this to be premature optimization at the current state of program. A vertex (world position) has one corresponding height value (a pixel if you so want, i'd prefer heightmap texel here). I calculate surface normals (vertex normals) in the vertexshader by sampling around the current position and crossing the resulting vectors, or by using a weighted matrix on the surrounding positions. Since a position and a texel correspond, i can do so easily. But there is a problem at the borders because texture positions are missing there. The resulting error is visible. That's why i need a texture of 2^n +1 or +2 depending on the normal calculation method. Nope, the resulting world positions are mangled so that they fit an ellipsoid. I am currently doing that. Simple texture lookups. Example (simplified): vec3 computeNormalCentralDifference( vec3 pos ) { float leftHeight = texture( heightMap, vec2( pos.x - 1.0, pos.z ) ); vec3 left = vec3( pos.x - 1.0, leftHeight, pos.z ); float rightHeight = texture( heightMap, vec2( pos.x + 1.0, pos.z ); vec3 right = vec3( pos.x + 1.0, rightHeight, pos.z ); float bottomHeight = texture( heightMap, vec2( pos.x, pos.z - 1.0 ); vec3 bottom = vec3( pos.x, bottomHeight, pos.z - 1.0 ); float topHeight = texture( heightMap, vec2( pos.x, pos.z + 1.0 ); vec3 top = vec3( pos.x, topHeight, pos.z + 1.0 ); return cross( right - left, top - bottom ); } Mipmapping is disabled for the heightmap textures. Otherwise i'd have to call textureLod()s with another degree of complexity ... i am a stupid guy and would get lost ๐Ÿ™‚ And i wasn't exactly honest, a number of vertices can actually share adjacent heightmap values (faking resolution), and then interpolation takes place. But that is an independent thing. I need extra pixels or texels at the border simply because for the shading i want to sample around the current position (like in the example) and the underlying lod algorithm needs a power of 2 heightmap. Thus i must add the mentioned overlap of 1, either at one side and top, or at both sides, depending on the sampling technique. That's all. I will simply go the way. If "unintended consequences" show up, i'll post them. Thanks for sharing thoughts !
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net isย your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!