jheriko

you clearly haven't played a modern game :P

cpu timings taken care around by developers is 10-15 years out of date. most of them these days dont even know what a dot product is, how to find the distance to a point or a straight line in-between two... and the people they rely on to do this for them make horrendous meals of it.

but yeah, sure, cpu instruction timings matter.

; set max speed so small entities are not skipped by projectiles ; could set faster than max-speed if I just do multiple smaller movement steps in one frame

jesus wept. sweep. c'mon.

so normalised dot product.

the notation here is bad. the bottom of the division looks like a cross product

as a games and graphics programmer i find it amazing that this would be a mystery... understanding the dot product is utterly foundational, and is some high-school level basics.

this fits... i'm constantly amazed by how bad most programmers are at maths and problem solving, and how few of them do anything in their own time to improve their skills.

just never use pipes. they are some weird archaism that need to die :P

the only time ive used them is external constraints. they are just not useful.

its interesting... but i do wonder how we went from planet scale and infinite terrains in the earlier 2000s and late 90s down to "lets just do one little square". granted this looks a lot prettier...

i did a quick code review. this mountain of code has the same error and the same precision with identifying phases.

thats a fair cop

tbh the small error can be very easily fixed. its close to the difference between a sine wave and its linear piecewise approximation from tip to tip, hence the very high accuracy on the quarters

you could go even further and remove the error from path being nearly a precessing ellipse...

in both cases what you will get is nothing that you would detect by eye or even with a telescope.

for the stated purpose this algorithm does fine in almost every use case including astronomical ones.

downvote me. im tired of masses of bloat and excessive code

nice spot

this looks incredibly bad from the implementation. there is a much simpler algorithm that works for hundreds of years in either direction of the present...

by comparison this is an absolute mountain of code. here is a good one - but note that it is only so accurate for each quarter phase (...and not sure why it destroys the formatting):

function approximateMoonPhase(julianDay)

{

    // from Meeus p.319

    // JDE = 2451 550.09765 + 29.530 588 853 k

    // + 0.000 1337 T2

    // - 0.000 000 150 T3

    // + 0.000 000 000 73 T4

    const t = toJulianCenturiesSinceJ2000(julianDay);

    const lhs = julianDay - 2451550.09765 + (-0.0001337 + (0.00000015 - 0.00000000073 * t) * t) * t * t;

    return lhs / 29.530588853;

}

enjoy. its from the same source as your work appears to use...

which, as someone who as implemented a ton of this stuff. its kind of a damning sentiment that we still refer to such an old book instead of learning the problem space and making better solutions... i have a whole book in me about this at some point.

no mention of the BOM... tragic.

Fuck me it's 2024

2014 me shaking his head in ways 2004 me saw coming in 1994.

Im only 40.

FUCK

just use numbers and crossbar your 7s - problem gone.

if someone's writing is incompetent tell them. if you can't then they ruined it for themselves by being shit at writing the number 7.

step 1: register a british company step 2: done...

the story is fun, but i can't help but notice the justification for the cassette to being with is nonsense - solving a problem nobody ever had.

who the fuck has to measure out a dishwasher tablet? nobody is who

i like the story, but i cant help but notice that the "cassette" is solving a non-existent problem

who the fuck has to measure a dishwasher tablet?

i am a gamedev. i never encountered this until unity became popular, and even then it was always looked down on as a shitty and hacky approach to a well solved class of problem.

10 years after this, its still about the same... which is probably why an article like this has any controversy about it instead of being run-of-the-mill.

i tire of IM vs retained discussions. the difference is academic up-to tools and code-gen in my experience. you can make one with the other up-to a point of usability. the classic point of split i find is if a UI designer wants to insert intermediate "for-show" elements, e.g. for animation. in that space imgui is, in practice, just going to disable your ui designers vs a retained mode solution using well established tools for defining and animating ui in standard ways. sure you can undo that problem, but thats code work, code work that blocks your ui people from doing their job until its done, and more points of failure for bugs to creep in...

the arguments i hear about debuggability seem brain-dead, but on reflection that might be the utility here. "make things easier to debug, shittier programmers can do work"... and that is not to be taken lightly or dismissively when it has real world weight.

retained mode most often exists in the backend, e.g. Win32, although some of it may use IM style interfaces, e.g. MessageBox, and so a lot of im gui tools will still use something retained under the hood, and have to go to some lengths to be able to identify "dynamically created" things. yes it can be worked around, but its another headache and bug vector...

ive honestly never seen IM GUI as a great approach, most often i implement it due to demand, and with some frustration at the brain dead arguments levelled for it. it solves a problem of programmer burden, which is not that useful in real world projects in my experience, and since the interfaces are interchangeable, its not really a fundamental decision to be making either until someone else forces it.

EDIT: to be clear, imagine trying to debug your data-defined if-statement. really think it through and implement it.

laughs in "never needed any of these weird mechanisms to manage my own memory"

calling your kid 'Dash'???

make things. the end.

how in the hell does uber need engineering problems solved?

mad

A good, solid and old argument...

https://www.ucl.ac.uk/museums-static/digitalegypt/literature...

i found my first compiler bug in my first job in my first few weeks... nobody was keen to believe me except the ms support guy i eventually got in touch with - who was kindly able to tell me that it was caught and fixed in a later version of the compiler that we couldn't use, but then at least gave me the clout to get the issue worked around instead of ignored as the fantasy of a junior programmer.

HEAD - something you only need to know about when easily fixed usability bugs in git make your life a misery

banks have low requirements with no technical challenges...

im honestly amazed how bad almost every bank service is with their tech usage... and this has been true for all of my living memory.

i might have to look into these guys... maybe i can have a service thats only millions of times worse than i expected as a child, instead of trillions of times worse

interesting, i got a few of the trickier ones a littler off...

I was 95% accurate! ⬜⬜

over a few days is pretty good. not sure you are onto a winner here given that every junior game programmer should be able to make something like this in a day or less.

ask yourself that question and answer it.

just what in the hell are you thinking?