I enjoy the general structure of Metroidvanias but most of them rely on combat mechanics for the micro-challenges in each room or boss. I like the exploration, backtracking, progression and unlocking previously inaccessible area.
But combat isn't the only mechanic that could be present there. There are examples like Ori and Toki where combat is de-emphasized in favor of movement/puzzles, but they're still 2D platformers.
I want to see a metroidvania game based on racing. I enjoy driving/racing games and would like to see those mechanics provide the micro-challenges for a metroidvania. Boss fights would be setpiece races, earning XP would be small things like a time trials, stunts, or precision driving. Unlocks like drifts, speed boosts, etc.
but... you had to go looking for that one, skipping over the part where you saw a bunch of waist-up pictures of a cartoon canine and got too hot and bothered to continue reading? it's not linked from the original article
> Transmeta usually steers the conversation toward performance on DES algorithms or MPEG loops, tasks that play into Crusoe's (and Efficeon's) strengths.
'MPEG loops' got a lot more important in the intervening years
transmeta was right. their approach was better, it should have won.
I don't think the project is putting their best presentation forward, but the second image on the intro makes it pretty clear there's a .v/.sdc/.def file kicking around. Without any relevant tooling to develop, debug, or modify them, but it's clear the python is just shuffling deck chairs.
It's impressive but in practice, as a guide, it's very difficult to use. There is one path to follow with no overall map or routing to skip things. So to use it to figure out one tricky section often means reading 4 extra paragraphs just to find a landmark and trace from there to where you're stuck before you can follow along.
You're not a billionaire, why are you spending your precious time on this earth trying to lump them together with "middle class Joes" as if that absolves them of their history?
Perhaps Buffett doesn't have a singular genius for applying his wealth to charity. It's anti-democratic on its face to just surrender control of "what problems are solved" to a single person, regardless of the decision metric. Is it truly better for one person to control all of that on a whim? Even assuming the best of intentions, he may pick a disease charity based on a close association with a victim rather than any broad rational analysis. You're just hopping right on board with his unquestioned assertion "I'm better at picking," did you give that one any pause or just hopped right up to carry that water?
What are the problems that governments are 'often' poorly suited to solve? Would governments be more or less suited to deal with these issues if they hadn't been defunded to support the personal wealth and charitable whims of billionaires?
that may have been what they wanted to write. unfortunately they wrote something wrong and misleading instead. i understood what they wrote perfectly well and the implication therein isn't, somehow, my fault
in addition to the complexities they add to every layer of the stack that ajross and alain94040 brought up, they're not all that useful in practice. i seem to recall that they'd rarely be over 50% utilized and the majority of instructions in the delay slot were nops
you sure about that link? he's talking about a core that didn't have SMT and is ranting, in general, about errata existing and wildly misrepresenting their impact
never mind that most errata are conditional until the ucode patch load, but that particular rant has nothing to do with HT
I fail to see how a dev talking about a wholly unrelated implementation from an entirely different vendor has anything to bear on this conversation unless you're just maliciously spreading FUD around the entire concept of random numbers.
Do you actually know if the instruction is faulting or delivering back non-random data ("sure it does...")? Is the non-random data 0's or something with a pattern like 0x9090? Does that match the Intel implementation's behavior exactly?
right, labor law is aware of "constructive dismissal," been a part of the law since, gosh, 1964?
oh right but this is ~google~ in the ~silicon valley tech industry~ so stodgy old concepts like "long settled labor law" still appear to be wholly unheard of by the average techie bootlicker
how is MESI "an abstraction"? why is it the only model proffered instead of MESIF/MOESI?
and "the top 16-bits are basically ignored" is a funny way to spell "general protection exception on linear memory reference in non-canonical space" but sure, guess we're just handwaving here
i legit don't know what you're expecting? your lie was central to the technical discussion and at no point did you acknowledge the error.
if you can't handle being called out for providing false technical information... don't hand out false technical information? seems easy. it's not, as you so desperately want, a personal attack to identify areas where you're misrepresenting the technology.
im curious, how did you want this to go? DT, incorrectly:"fences are required" jv6:"ah, well, hm, er, here's section 8.1.3 which doesn't mention fences at all and specifies two methods (neither of which is a fence) that ARE required to ensure correct operation" like can i even tell people the truth? or must your egregious misrepresentation stand without question for you to find the "tone" acceptable?
im sad i missed your edit, apparently filled with unhinged personal attacks, but ive limited my commentary to the technical details and it's amazing that you still claim some higher ground while steadfastly ignoring the subject matter, on which you are incorrect and misinforming others.
im not claiming to be a "better assembler programmer" im literally quoting the only relevant documentation on a tricky area where you were spreading lies charitably dressed up as half-guesses. if you hadn't barged in with some grossly incorrect theory about fences we wouldn't be talking at all. i still think lying and misleading while putting on airs of educating folks is worse than, uh, quoting documentation? are you thinking the documentation is being too harsh on your pet theory?
will you at least agree to stop spreading this dangerous misinformation? neither fence is serializing (like... you wouldn't want them to be...) and someone building a JIT around your guessing is heading towards an erroneous implementation.