I prefer to slow down and actually just say hello to them, they'll usually say sorry and I'm back on my way again. Just ringing a bell, or worse a horn, scares them and they need to turn round to figure out where you are and whether you're about to squash them. I don't feel I have the right to do that to someone just out enjoying a peaceful walk.
On the other hand, I've been angered by dog owners when running who just take up the entire pavement. A couple of weeks ago, I had one guy coming towards me force me to come to a complete stop when I was running flat out, because he couldn't be bothered to control his dogs. He was in the centre of the pavement, and the 2 dogs were at the extreme edges with tight enough leads between him and the dogs, so it'd have tripped me up if I'd tried to jump them. He knew full well I was heading that way, but in the 10 seconds since we had made eye contact, he was clearly determined not to reign his dogs in, and it was only when I was stopped and so he had to reign them in to continuing walking past that I was able to keep using the pavement.
>Just ringing a bell, or worse a horn, scares them and they need to turn round to figure out where you are and whether you're about to squash them. I don't feel I have the right to do that to someone just out enjoying a peaceful walk.
Yes, it's very context-dependent. I'm going to behave very differently in an area where there are hundreds of cyclists every hour compared to a place where there might be one or fewer.
The real trick with bell ringing is to try to get the distance right. Too far away and they won't hear. Too close and it might startle them, and they won't have enough time to react properly.
I was about to rush to the defence of Windows 11, thinking it couldn't possibly be that bad, and just checked mine. I booted a couple of hours ago and have done nothing apart from running Chrome and putty, and whatever runs on startup.
Apparently 13.6GB is in use (out of 64GB), and of that 4.7GB is Chrome. Yeah, I'm glad I'm not running this on an 8GB machine!
That's a good point. Good quality food like meat might be much harder to obtain, you'd need weapons and maybe organised into a group to catch anything large, but the flip side is that subsisting on fruit and berries is much easier when there's literally nothing to stop you gathering and eating what you want.
In a sense, simple existence is easier when you don't have to worry about money, or who owns what land, assuming of course that you're fit enough and able to spend a lot of time gathering food.
Is there any research about why Sub-Saharan Africa doesn't have Neanderthal DNA?
Is the argument that the tribe of humans from Africa was good at repelling outside invaders, but themselves expanded outwards and assimilated (and then outnumbered) the other populations, or something else?
It just seems a bit bizarre given that all humans elsewhere have relatively similar amounts (but quite a low amount) of Neanderthal DNA, which seems to suggest a reasonable amount of migration, interaction and interbreeding between populations everywhere except Africa.
There were multiple waves out of Africa but Most early anatomical human groups never left Africa as a result, there’s more DNA diversity within the continent than outside Africa
Its confusing because the non-african group grew exponentially while the intra-African continent continued to mature
The anatomically modern humans that left Africa spread rapidly and aggressively across the world basically absorbing and destroying every proto-human group and ecological niche and
now the world is ruled by the aggressive narcissistic chimeral hybrid of human (African) Neanderthal (European proto human) and denisovian (Peking man) that survived the exit snd expansion
I think this graph is a great illustration about how anonymising data is hard. It's very easy to isolate individual authors from this list, because there are clear diagonal lines because the year and age are increasing in lockstep. This also suggests there aren't actually that many authors in this collection, because of these strong diagonals everywhere.
There's probably also some erroneous data here with a bunch of points representing material written by people at age 34 between about 1920 and 1940 (an obvious horizontal line) when most of the rest of the graph doesn't show any strong horizontal bias for a specific age.
I remember back in the 80s writing a CGA text-mode game (they were quite in vogue at the time), and (as I assume most programmers did) I used the video memory directly as the source of truth about the current state of the level.
OP's distinction about video being a raster-based signal that you feed into a regular TV-like device, rather than being vector based or hard wired lights seems sensible. As to how that video signal is generated is kind of irrelevant.
The manchester mark 1 had a teleprinter as its output, and used a Williams tube as ram (https://en.wikipedia.org/wiki/Williams_tube). If the image on wikipedia is accurate, the checkers game only "displayed" itself incidentally, on the Williams tube, rather than actually outputting to the teleprinter. In your game, it would be like writing the current level to internal ram, rather than to the actual video memory. The Williams tube isn't really a TV-like device. It stores data on a CRT, but that CRT isn't visible to the user in general operation, as the read plate covers the "screen". Again, "first video game" is up to a lot of interpretation.
Also, saying that vector based video makes it not a video game is a little strange, given how common vector graphics were in arcades (eg Asteroids, Tempest, Missile Command) and the Vectrex
I'm not necessarily making the point that vector graphics based games aren't video games, just arguing against the parent comment against the claim that it wasn't a video game because it was stored in RAM.
I agree with the assertion that this was a video game because it was using a raster-based CRT for the display, even though the primary purpose of that display was for data storage not display.
Unlike the article, I'd assume it's hardware related rather than software.
Assuming the article is correct and the hardware can do 7680x4320 @60, which requires 8GB/s memory bandwidth, in theory it should be able to do the same to read the same memory and interleave every other line for the down-sampling. However, it's possible that the new memory controller can't support 2 simultaneous burst streams (because the 2 lines are 30KB apart in memory), or if it's doing a single burst and buffering the first line until the second line is available, then maybe the cache is smaller than 30KB.
Another possibility is that previously the scale averaged pairs of pixel horizontally and cached them until the next line was available to average with that, and for some reason it was changed to average all 4 at the same time and so the cache isn't sufficient (although it'd be weird as 25.25KB is a fairly weird size to limit the cache to)
Alternatively, looking at clock rates needed for the sampler, 3360x1890 @60 is 381MHz, 3840x2160 @60 is 497MHz. It's quite possible that they've lowered the base clock on some hardware and not considered that it'd impact the maximum effect on the scaler.
But whatever IMHO, it's unlikely to be a software bug with an easy fix.
The 4 values in MaxSrcRectWidthForPipe are sub-pipes within each display controller, not separate display outputs. Every external display controller on the M5 Max has the same pattern: sub-pipe 0 = 6720, sub-pipes 1-3 = 7680. A single-stream 4K display only uses sub-pipe 0. Sub-pipes 1-3 are for multi-pipe configurations (8K displays use 2 sub-pipes, which is why an 8K EDID causes the DCP to assign PipeIDs=(0,2) with MaxPipes=2).
Your scaler clock theory could be right: the single-stream scaler path may genuinely have a lower throughput limit than the multi-pipe path.
Interestingly, the M2 Max uses a completely different IOMFBMaxSrcPixels structure. Instead of per-sub-pipe arrays, it has a flat MaxSrcRectWidth=7680 and MaxSrcRectTotal=33177600 (exactly 7680x4320) per controller. Every external display controller gets the full 7680 budget. Apple seems to have restructured the display controller architecture between M2 and M4/M5 to per-sub-pipe budgets, and the single-stream sub-pipe got a reduced allocation (6720 vs 7680) in the process. Whether that's a hardware change in the scaler or a firmware allocation policy is hard to say without Apple's documentation.
Seems nice, but beyond 6 points the polygons are hard to distinguish easily. Certainly not something you can quickly glance at in a rush. I'd say sticking to 5 maximum would be best.
I don't think empty for 0 necessarily makes the best sense. You wouldn't easily be able to see where the gaps are at a distance.
Using base 60 and encoding digits doesn't necessarily make the most sense.
For instance hours, it might make sense to use 2x times base 5, probably with no 0 encoded so that there's always something in the hours column.
Or, of course you could do an encoding with a base 4 and a base 6, which is mentally easy to convert back to to a regular 24 hour clock. TBH I'd probably encode that as maybe a square where there's 1-4 sides enclosing a polygon of 0-5 points.
Maybe I'd encode half-minutes with 3 base 5 encodings and some encodings unused, or a base 3, base 4 and a base 5 encoding for minutes.
I would probably also then group them into functional groups that touch each other within the group, so you can easily see the groups, but tell them apart easily.
Actually, I was going to completely edit this comment with a different suggestion, but decided to leave that to show the thought process.
Thinking more about the hours, I like the circle progressing round, but also maybe you could do it as a box with 1-4 sides present enclosing a polygon of 0-5 points. It's easy to mentally convert that to both 12 and 24 hour clock format.
For the minutes, I'd be tempted to do something like the current hours, done as a fraction of the circle arc with an additional polygon of 0-5 points for the minute. It's relatively easy to eyeball the size of the 5 minute segment, and the polygon just refines that a bit. You could locate the polygon so it touches the arc at the 1/12 of the circle corresponding to the base, which would help with estimating the arc length too.
Either way, I wouldn't make the encoding rely on colours, especially colours that look very similar.
On the other hand, I've been angered by dog owners when running who just take up the entire pavement. A couple of weeks ago, I had one guy coming towards me force me to come to a complete stop when I was running flat out, because he couldn't be bothered to control his dogs. He was in the centre of the pavement, and the 2 dogs were at the extreme edges with tight enough leads between him and the dogs, so it'd have tripped me up if I'd tried to jump them. He knew full well I was heading that way, but in the 10 seconds since we had made eye contact, he was clearly determined not to reign his dogs in, and it was only when I was stopped and so he had to reign them in to continuing walking past that I was able to keep using the pavement.
reply