• 14 Posts
  • 587 Comments
Joined 1 year ago
cake
Cake day: June 10th, 2023

help-circle

  • I liked the previous system more than this. I think they could easily have the best of both worlds by making each pipe its own segment that pulls fluid from segments that have less fluid in them proportional to how much fluid that segment has. That way there’s both a propagation lag (and closer buildings getting more throughput than farther ones) like the current system and high throughout if the entire pipe is filled like the new system. This even opens up the possibility of higher quality pipes forming larger segments to increase throughout when the pipe isn’t fully filled.

    This would cause sloshing, but that can be fixed by each segment checking if the segment they’re pulling from pulled from them last tick and if so temporarily combining into a single segment for the next tick.

    The evaluation order feels tricky for this to work and the fill amounts of the segments would need to be updated right after evaluation instead of at the end of the tick for full throughput, but I think that can be figured out








  • It’s not what the trailer shows, it’s how it’s showing it. It’s just a slide show of things happening. Fade transitions. Awkward cuts between shots. Almost nothing in sync with the music. The release date is stitched to the end as another clip. The villain’s theme just starts playing while the music is still going. Shows the date and location in the beginning as if it’s going to be story related, then just shows gameplay until the end…





  • No? Afaik vsync prevents the gpu from sending half drawn frames to the monitor, not the monitor from displaying them. The tearing happens in the gpu buffer Edit: read the edit

    Though I’m not sure how valid the part about latency is. In the worst case scenario (transfer of a frame taking the whole previous frame), the latency of an lcd can only be double that of a crt at the same refresh rate, which 120+ hz already compensates for. And for the inherent latency of the screen, most gaming lcd monitors have less than 5 ms of input lag while a crt on average takes half the frame time to display a pixel, so 8 ms.

    Edit: thought this over again. On crt those 2 happen simultaneously so the total latency is 8ms + pixel response time (which I don’t know the value of). On lcds, the transfer time should be (video stream bandwidth / cable bandwidth) * frame time. And that runs consecutively with the time to display it, which is frame time / 2 + pixel response time. Which could exceed the crt’s latency

    BUT I took the input lag number from my monitor’s rtings page and looking into how they get it, it seems it includes both the transfer time and frame time / 2 and it’s somehow still below 5 ms? That’s weird to me since for that the transfer either needs to happen within <1 ms (impossible) or the entire premise was wrong and lcds do start drawing before the entire frame reaches them

    Although pretty sure that’s still not the cause of tearing, which happens due to a frame being progressively rendered and written to the buffer, not because it’s progressively transferred or displayed