| wareya |
Posted on 19-05-19, 06:51 in I have yet to have never seen it all.
|
 Post: #61 of 100 Since: 10-30-18 Last post: 1784 days Last view: 1349 days |
The tiny texture cache basically only affects how big of a texture you can stuff into the rasterizer at once. It's not VRAM. Sure, 4KB was too tiny, but something like 16KB would have been fine too. Remember that the N64 had a shared rambus. |
| wareya |
Posted on 19-05-20, 12:14 in Mozilla, *sigh* (revision 1)
|
|
Post: #62 of 100 Since: 10-30-18 Last post: 1784 days Last view: 1349 days |
Advertising through untrustworthy middlemen is inherently wrong, not just because of quality control problems, but also because like was mentioned, it needs to be invasive (read: kill users' privacy and target them based on tracking heuristics) to be truly profitable. Some things are just wrong. Nothing wrong with direct sponsorships though, as long as you're not shilling something without saying so, even though being honest about it makes it look like you sold out. |
| wareya |
Posted on 19-05-20, 13:38 in Mozilla, *sigh*
|
|
Post: #63 of 100 Since: 10-30-18 Last post: 1784 days Last view: 1349 days |
>Sponsorship isn't feasible for small/controversial/broad websites. Okay. >small You got me there, but you're not going to make much money off of ads on a small site anyway. Start a patreon or gumroad or something. Or run the site out of pocket. >controversial If you're too "controversial" to find sponsors, then you're "controversial" in a very bad way. >broad I don't see this being a problem. Surely you could sponsor specific publications if you're big enough, like big youtubers do. |
| wareya |
Posted on 19-05-26, 18:50 in Something about cheese!
|
|
Post: #64 of 100 Since: 10-30-18 Last post: 1784 days Last view: 1349 days |
Posted by sureanem 1) Run by a not-for-profit. 2) Being run by non-profit or not-for-profit organizations is completely meaningless. In fact you can assume that if something like this is run by a not-for-profit or non-profit organization, then it's going to be more corrupt than if it were privately- or government- run. https://en.wikipedia.org/wiki/College_Board#Sale_of_student_data https://en.wikipedia.org/wiki/Educational_Testing_Service#Criticism |
| wareya |
Posted on 19-06-02, 00:50 in Mozilla, *sigh*
|
|
Post: #65 of 100 Since: 10-30-18 Last post: 1784 days Last view: 1349 days |
"toxically masculine" is actually just grammatical gymnastics for "regarding the toxic behavior that tends to occur when someone misunderstands values that are traditionally masculine". It doesn't have anything to do with masculinity itself. The situation you described is actually a perfect example of something that stems from this particular kind of toxicity. |
| wareya |
Posted on 19-06-02, 00:51 in I still HATE smartdevices
|
|
Post: #66 of 100 Since: 10-30-18 Last post: 1784 days Last view: 1349 days |
The ideal album organization is obviously how TLMC does things where you have tagless files representing entire albums as a single waveform and then all the metadata is specified in a single cue file. |
| wareya |
Posted on 19-06-07, 07:33 in Something about cheese!
|
|
Post: #67 of 100 Since: 10-30-18 Last post: 1784 days Last view: 1349 days |
That's some grade A classist bullshit right there. |
| wareya |
Posted on 19-06-11, 01:35 in Something about cheese! (revision 2)
|
|
Post: #68 of 100 Since: 10-30-18 Last post: 1784 days Last view: 1349 days |
General intelligence is a joke. Hi, I'm autistic, I'm unbelievably intelligent in some ways and fucking retarded in others. I even out to being mildly intelligent on general intelligence tests, but that doesn't mean I'm going to function like I'm intelligent all the time. If someone gives me elaborate verbal instructions? Nuh-uh, not gonna happen. My verbal working memory is literally retarded. Have this game engine or programming language I hacked together for fun instead. People tend to have have more variance between their own personal skills than there tends to be between random people, or even random demographics. |
| wareya |
Posted on 19-06-21, 18:45 in Why is ROM translation so (technologically) hard?
|
|
Post: #69 of 100 Since: 10-30-18 Last post: 1784 days Last view: 1349 days |
love 2 unironically write the string of text "discrete kanji logogram" |
| wareya |
Posted on 19-06-22, 08:29 in Why is ROM translation so (technologically) hard?
|
|
Post: #70 of 100 Since: 10-30-18 Last post: 1784 days Last view: 1349 days |
formally numberless conceptual-morphemic orthographical unit of the middle empire |
| wareya |
Posted on 19-07-16, 00:05 in Leaked Super Mario 64 Decompiled Source
|
|
Post: #71 of 100 Since: 10-30-18 Last post: 1784 days Last view: 1349 days |
>and have room over for input prediction and other book-keeping Dude, input-based emulator netplay isn't capable of input prediction. What are you talking about? |
| wareya |
Posted on 19-07-16, 00:08 in Games You Played Today REVENGEANCE
|
|
Post: #72 of 100 Since: 10-30-18 Last post: 1784 days Last view: 1349 days |
Posted by sureanem "n64 emulation is reclining" "<links accurate n64 eumlation thing>" "it's really slow so it doesn't count" Emulating things accurately hurts performance. Who knew? |
| wareya |
Posted on 19-07-17, 03:09 in Leaked Super Mario 64 Decompiled Source (revision 1)
|
|
Post: #73 of 100 Since: 10-30-18 Last post: 1784 days Last view: 1349 days |
That's not input prediction, that's rollback. Input prediction is a term of art with a specific meaning. It only applies to the local player's own motions. |
| wareya |
Posted on 19-07-18, 01:31 in Leaked Super Mario 64 Decompiled Source
|
|
Post: #74 of 100 Since: 10-30-18 Last post: 1784 days Last view: 1349 days |
Game state prediction and input prediction are different things and the former is not called the latter. Nobody calls what fighting games with rollback do "input prediction", because it's not. |
| wareya |
Posted on 19-07-18, 09:07 in Leaked Super Mario 64 Decompiled Source (revision 1)
|
|
Post: #75 of 100 Since: 10-30-18 Last post: 1784 days Last view: 1349 days |
The current best HLE graphics plugin is actually GL-native, GLideN64. Not to be confused with Glide64. |
| wareya |
Posted on 19-07-25, 08:02 in What is input prediction? (revision 5)
|
|
Post: #76 of 100 Since: 10-30-18 Last post: 1784 days Last view: 1349 days |
Input prediction is the prediction of the direct effects of a client's inputs on the client's own gamestate without fast-forwarding the rest of the gamestate. For example, assume you're playing a FPS and you have 500 milliseconds (half a second) of ping, and the server is looking at Time=102seconds. Let's assume that there is no input prediction. When you, the player, see the entire game world at Time=101.5 seconds, that includes your own character's position. And there's going to be a 500ms round trip on your client sending its inputs commands to the server and having the server finish simulating the gamestate up to that point and return them back to you. Let's assume that you're using some sort of rollback or fast forwarding for the entire gamestate, taking into account all the inputs that you have sent to the server but your client has not yet seen the server acknowledge. If you do this, then you're going to have to re-fast-forward the entire gamestate whenever an input that is not your own changes. This is fine for fighting games because it's very important for everything to have consistent relative positioning, which we will see that input prediction does not ensure. Fighting games can add buffer frames to reduce the appearance of "oh, he died but then it rewound and turned out he didn't get hit" glitches and so on. Let's assume that there is input prediction. When you, the player, see the game world at Time=101.5 seconds, your client will fast forward its own movements and actions only to Time=102. This eliminates the network-induced input lag, without causing the gamestate as a whole to ever need to rewind. The only thing that will ever be re-fastforwarded is the player's own motions, which the client is almost always going to get almost completely correct. This causes problems for things like attacks, because now the player isn't seeing exactly what the game server sees. This is why in games like Quake 1, Quake 2, and vanilla Quake 3, you need to shoot ahead of moving players to hit them. If you aim directly at someone, you're aiming from a fast-forwarded point in time to a time in the past, so once the attack registers, the opponent will have moved out from under the line of sight your crosshair was aiming down at the time you saw the attack on your screen. This is what "lag compensation" is for. There are several approaches to lag compensation. I will describe two of them. The first one is a limited form of fast forwarding applied to individual entities rather than to the gamestate as a whole. This fast-forwards the client's view of certain aspects of the gameworld (specifically, other players' positions) so that their own "fast forwarded" position is no longer out of sync with them. This has similar problems to fast forwarding the entire gamestate (rollback), but it's much cheaper, and you can "cheat" as a developer and add things like position smoothing to hide erraneous extrapolations. Things like damage events and deaths are only applied when the server says to do so. This is what Quake 3 CPMA uses. The second is good old "backwards reconciliation". In short, the server keeps a log of old gamestates and looks for the one that the player was looking at when their input events fired when doing things like calculating hitscan attacks. When it receives an input at Time=102seconds from a player with 500ms (0.5 seconds) of latency, it will compute certain effects of the player's inputs (namely hitscan attacks) based on a gamestate from Time=101.5seconds, in order to make up for the fact that the player was looking that far into the past at the time that the input was triggered. This is what is used by Quake 3 Unlagged and every Valve game. Backwards reconciliation is a perfect match for input prediction as FPS games know it. But as you can see, you have to be able to selectively ignore the side effects of the player's own actions when they shoot weapons, and only actually put them into effect after the server checks your inputs and calculates the effect itself (with or without backwards reconciliation, depending on the game). This means that if you have 500ms ping, you won't see someone take damage from your attacks until 500ms later, but that will be the only inconsistency. This is what makes it "input prediction". It only predicts the direct effects of your inputs like your movements and weapon animations, not the effects that those predictions have on the game world. |
| wareya |
Posted on 19-08-06, 08:28 in Gammakit and Magmakit - an insane language and a game engine (revision 2)
|
|
Post: #77 of 100 Since: 10-30-18 Last post: 1784 days Last view: 1349 days |
Magmakit's current "demo" is a trivial platformer with tiles where all collision is implemented using AABB sweep-distance-normal tracing and a continuous contact solver. It's very slow. Runs at a decent framerate with only a dozen or so tiles, but very slow. One of the unspoken design principles behind magmakit is that if a developer really needs to do something performance sensitive they should hack at the engine itself (magmakit) instead of doing it in gammakit code (which is slow) and hoping for the best. I began constructing the skeleton for a Real, Proper collision detection system, which, naturally, being the masochist I am, I started at the broadphase instead of just looping through every single static and dynamic object and laughing at how much faster Rust is than Gammakit, because I figured I might as well do some "hard" programming to remind myself how much it sucks and make myself play more video games or something (which I haven't been doing enough of lately). I decided to implement a BVH system with AABBs (so, a dynamic AABB tree), because querying a quadtree or grid requires keeping a hashset/btreeset of all known potentially-hit objects, and I figure BVHs are better because they don't have that problem (this is the full extent of the thought I put into it; I really just wanted to do something I haven't done before, and I've made quadtrees and grids before). Again, people seem to call the type of BVH I'm implemented a "dynamic AABB tree". The most straightforward explanation of dynamic AABB trees I could find is this blog post here: https://www.randygaul.net/2013/08/06/dynamic-aabb-tree/ - it's a bit skimpy on some of the details, so I'm not sure I'm going to implement everything properly (no, I'm sure that I won't), but it's concise and seems straightforward enough. After a couple hours of bashing on my keyboard, I have a working insert-only BVH system, or at least I think I do, there isn't really a formal specification of what BVHs really function like for me to check or anything like that. It turns out that BVH systems are very strongly heuristic-based, and changing things slightly can have a huge impact on the resulting arrangement of bounding volumes. I have an album of how my BVH grows as I add more tiles to it here: https://imgur.com/a/4cT4vTw It seems that building a BVH gradually will inevitably result in strange obviously non-optimal collections of bounding volumes, as wikipedia puts it "BVHs also naturally support inserting and removing objects without full rebuild, but with resulting BVH having usually worse query performance compared to full rebuild". It seems that the right way to avoid this is to completely rebuild the entire hierarchy after a while if the tree is too inefficient, but I'm not really interested yet. Maybe once everything else is in place. |
| wareya |
Posted on 19-08-13, 08:22 in Retroarch's (controller) interface is an bad abstraction
|
|
Post: #78 of 100 Since: 10-30-18 Last post: 1784 days Last view: 1349 days |
The sony design is actually BETTER than the nintendo design, because the lack of "button" in the middle and round edges of the "buttons" makes it more comfortable to lay your thumb on for extended periods of time, and the (slight) flexibility of the underlying cross makes it easier to snap suddenly between two different diagonals, without making it too easy to accidentally press on a diagonal when trying to press a single straight direction. (Nintendo dpads are too easy to press diagonally when trying to press straight when they're not worn-out yet, and once they're worn-out they stop being snappy. The sony design's flexibility avoids this tradeoff.) "Floating disk" dpads are no better than the godawful dpad emulation you get with a steam controller, aside from a more realistic tactile response for depressing buttons. |
| wareya |
Posted on 19-08-19, 09:51 in Typesetter.css, make semantic HTML readable
|
|
Post: #79 of 100 Since: 10-30-18 Last post: 1784 days Last view: 1349 days |
Blank line plus REVERSE indentation. Fight me. |
| wareya |
Posted on 19-09-12, 11:35 in N64 emulators vs. "PJ64 v1.x" emulators
|
|
Post: #80 of 100 Since: 10-30-18 Last post: 1784 days Last view: 1349 days |
On a completely unrelated note, I recently realized that bizhawk (yes) is the simplest way to get a working, up-to-date n64 emulation package. Jeez. |
