| feedbot: | http://ossasepia.com/2020/01/16/crystalspace-creating-factories-and-meshes-setting-the-client-down/ << Ossa Sepia -- CrystalSpace: Creating Factories and Meshes, Setting the Client Down | [10:26] |
| mircea_popescu: | ^ Pretty great list of accomplishments, really. | [11:25] |
| mircea_popescu: | diana_coman, reading all this all over again, it makes regret quite palpable. | [11:26] |
| mircea_popescu: | can't avoid revisiting the logic that lead there. | [11:29] |
| diana_coman: | mircea_popescu: thanks; there is at least some weight lifted as I could finally clear up and archive the lot of it. | [11:31] |
| diana_coman: | feels more like the start of a new year than 1st of jan did tbh. | [11:31] |
| mircea_popescu: | http://logs.ossasepia.com/log/trilema/2019-12-30#1956382 which lead to took us to http://logs.ossasepia.com/log/trilema/2019-12-30#1956451 which then two weeks later, as the dilemma wasn't resolving, yielded http://ossasepia.com/2020/01/10/eulora-logs-for-10-Jan-2020#1001227 | [11:32] |
| ossabot: | (trilema) 2019-12-30 mircea_popescu: diana_coman, let's restate this, so currently work on nailing down the comms protocol is stalled on a definitive universal data model, which is stalled on graphical use in the client, that about it ? | [11:32] |
| ossabot: | (trilema) 2019-12-30 mircea_popescu: diana_coman, the way this coming to a head is working out in my head is as follows : you have practically speaking the option to either a) go trawl the entire internet, drag out ~everything~ that's conceivably useful (submit expenses report for stuff that's behind reasonable paywalls i guess) and then we systematize the pile ; or else write a possible-lifeform-generation machine and see what you want it to save. | [11:32] |
| ossabot: | Logged on 2020-01-10 08:13:29 mircea_popescu: so it seems to me the situation can be rather summarized like this : for a while i was in costa rica, and played eulora daily. for that while we focused on short term, clear payoff, necessarily smaller changes, which reliably drove small but visible improvement to the game. | [11:32] |
| mircea_popescu: | diana_coman, haha, i bet it was a larger new year-ing than the arbitrary timedateline thing | [11:33] |
| diana_coman: | aha; well, on occasion I manage to sync with the arbitrary timedateline thing too but it doesn't happen all that often so not exactly surprising this time either. | [11:34] |
| mircea_popescu: | anyway, there's a self-evident neglected angle here. do you have an article in the pipeline explaining why the de facto item can't be used ? | [11:35] |
| mircea_popescu: | something like "and here's why cal3d data format's no good" or w/e it is we in fact use. is that the one ? or rather "cs data format" ? | [11:35] |
| diana_coman: | mircea_popescu: hm, my pipeline for this part was/is empty; not sure I fully get what you have in mind there; currently the client uses a mixture really ie cal3d for the animations/skeletons but otherwise set & loaded from xml/cs format | [11:39] |
| diana_coman: | aka xml specifies which cal3d file to use where, pretty much (when there is any cal3d file used at all, ofc). | [11:39] |
| diana_coman: | I didn't contemplate as such any removal of the cal3d data format, no | [11:40] |
| diana_coman: | removal of the xml/cs yes. | [11:40] |
| diana_coman: | do you mean an article explaining why the cs xml format is no good? | [11:42] |
| mircea_popescu: | diana_coman, well, it literally says, "currently work on nailing down the comms protocol is stalled on a definitive universal data model" | [12:01] |
| mircea_popescu: | inasmuch as we do have a ~de facto~ data model, the gap must be bridged. "why aren't you using what you are already using again ? | [12:02] |
| mircea_popescu: | " | [12:02] |
| mircea_popescu: | in fact, do we even have an actual statement of wtf data model we use for graphics ? given a file called graphics.tar.gz, can we establish whether it is or it is not eulora graphics through any other process besides "put it through the runtime see what happens" ? | [12:03] |
| diana_coman: | mircea_popescu: the key trouble with "what you are already using" is that it's meant for preloading/known upfront; this ties in to some extent with the xml because in the xml everything is hard coded and has to be already in place/can't change etc. | [12:04] |
| mircea_popescu: | let's unwind this. | [12:06] |
| diana_coman: | mircea_popescu: there is no actual statement as such of data model, no; the way cs goes about it is to say here and there that you may specify this or that in one place or another but I haven't found a proper data model anywhere; and otherwise it would need extraction from the xml loaders essentially. | [12:06] |
| diana_coman: | ok; just to let you know that I'll need to go in ~10 minutes. | [12:06] |
| mircea_popescu: | a ok. | [12:06] |
| mircea_popescu: | then listen, ping me when it's convenient we get to it. | [12:06] |
| diana_coman: | all right; I expect to be back the latest 7:30pm so in 3.5 hours from now. | [12:07] |
| mircea_popescu: | cool, i'll be around | [12:07] |
| diana_coman: | thanks | [12:07] |
| mircea_popescu: | for that time : there's two different items here, not related in any fundamental sense though i suppose married by happenstance and coincidence. | [12:08] |
| mircea_popescu: | firstly, if man says "i went as far as i could, but as i reached X-seashore, i needed either a boat or a plane to continue. for lack of either, i had to turn back." then man is held to show three tings : 1. that indeed the X-seashore is liminal, a categorical discontinuity in the medium ; 2. that indeed "boat or plane" ennumerates the list of possible manners of crossing ; 3. that indeed he lacks each of them for fundamenta | [12:14] |
| mircea_popescu: | l, irremediable reasons. | [12:14] |
| mircea_popescu: | lack of answer to the very simple "why didn't you merely continue on foot [as you went before]" defeats all three of these. | [12:14] |
| mircea_popescu: | thus, to be able to say, like we have, "look, can't continue here, because we don't know what we want the data to look like, and we don't know how to find out" we must, besides the various cases we've covered, also explain what is wrong with ~the thing we're currently using~. | [12:17] |
| mircea_popescu: | it obviously can't be unusable just because we're using it ; and it has to be wrong ~enough~ to warrant even taking notice in the first place. | [12:18] |
| mircea_popescu: | now, secondly, to the other item : there's perhaps some issues with the "can't change" symbol above, above and beyond the contextually-self-obvious ambiguity, whereby it's not really clear what sort of property it is and to what kind of node it attaches. | [12:19] |
| mircea_popescu: | do you mean something like "xml does not permit a model animated by scenes a, b, c, d and e be changed on the fly such as to be now animated by scenes a, c, d, f and g" ? | [12:20] |
| mircea_popescu: | or do you rather mean something like "the way ps packaged cs's packaging of cal3d is SO FUCKING FRIABLE, we won't be able to use the ~actual graphical data~ in any sensible way without first breaking their dumb shit". | [12:21] |
| mircea_popescu: | because these aren't at all the same thing, breaking their dumb shit, world.xml or whatever it is, the inept wrapper masquerading as a top level node after the fact has no actual bearing on genuine loading or the gfx data model at all. | [12:21] |
| mircea_popescu: | i think i said somewhere, that minute change in the vein of the first lobe above, where we decide mid-run to alter the interior properties of a game object, is not seriously contemplated, and even if to be ever implemented it will be implemented on the structure of having BOTH objects, and switching one for the other ; there's no interest in fully exposed parametrization whereby the (say, by way of example) shade hue of the | [12:24] |
| mircea_popescu: | flaming portion of a flaming sword is reflective of the player wielding it birthdate. | [12:24] |
| diana_coman: | mircea_popescu: I'm here and I re-read your statements a few times, still not fully sure what your current view of the whole thing is, hm. | [15:34] |
| diana_coman: | first of all, there is *no clear definition* of "current graphical data format", mainly because there isn't even just one, but a mixture of versions of different things depending on which exact level you want to look at. Second and even leaving that mixture aside for a moment, I still consider the root trouble the fundamental difference of purpose: their purpose was literally to a. list FULL set of resources b. describe some resources ... | [15:38] |
| diana_coman: | ... (it's not even clear if absolutely ALL of them...) via xml so that non-programmers/no compiling required to change them | [15:38] |
| diana_coman: | there is indeed at the very least one layer of ps-packaging of cs's packaging is enough to send one screaming; but it's unclear if that's the full trouble; and ftr current client doesn't use much of cal3d as such anyway, rather minimal (the chars are not made out of submeshes as they should be, for the most obvious thing). | [15:43] |
| diana_coman: | I think it's also worth noting that if we "define graphical data format" on the basis of "this is what current xml & assorted requires", the result is cs/ps (and even version, at that) specific, not so much focused on what we want to be able to do with it as focused on "what can be done with this existing pile". | [16:00] |
| mircea_popescu: | there's definitely a de-facto definition since the item compiles | [16:22] |
| mircea_popescu: | now, it might be very messy and ad-hoc, but it's not wishy=washy " a lot of different" literautre. | [16:22] |
| mircea_popescu: | diana_coman, it's not clear we "want" anything in the first place, besides "the damn thing to work" | [16:25] |
| diana_coman: | mircea_popescu: uhm, I'm rather confused; I thought we wanted to be able to send *everything* to client; don't we? | [16:30] |
| mircea_popescu: | yea | [16:30] |
| diana_coman: | so then I don't quite follow. | [16:31] |
| diana_coman: | are you saying "investigate how to make use of existing formats so that we can send ...uhm, everything via them"? | [16:31] |
| diana_coman: | or "what can we send using existing formats"? | [16:32] |
| mircea_popescu: | "do we even know WHAT of everything can't be sent by existing formats" stumbled into "do we actually even know wtf tey are" | [16:33] |
| mircea_popescu: | we seem to have agreed something needs fixing without, apparently, either establishing what or why. | [16:33] |
| diana_coman: | uhm; the part that "needs fixing" was initially "fully pre-defined world AND resources" needs changing to "load on the fly everything" | [16:35] |
| diana_coman: | then there is existing PS "communication protocol" that doesn't support sending resources as such | [16:36] |
| mircea_popescu: | alright. | [16:36] |
| diana_coman: | unless one calls "resource" a text message (limited length though I don't know by heart how much exactly) | [16:36] |
| mircea_popescu: | this is fine. but at this juncture the observation fits, that indeed fixing that does not automatically require changing the underlying data structure. | [16:36] |
| diana_coman: | I guess the trouble starts from the other end, namely that we don't actually know what data structure we want/need in the first place | [16:37] |
| mircea_popescu: | no, that's well established. in which context, explaining what we don't like about what we presently have can't be "we use it stupidly" | [16:39] |
| diana_coman: | uhm. | [16:39] |
| mircea_popescu: | is this still unclear ? | [16:40] |
| diana_coman: | I don't fully get how is "we use it stupidly" even supposed to figure out there; but the only thing I can see now is to go back into the whole thing, do what nobody did and document the spaghetti so that then we can say here's the spaghetti. | [16:41] |
| mircea_popescu: | what i meant by "we use it stupidly" here is this : that there's some data model, apparently entirely undocumented, which gets used through some ad-hoc stupid ps-style thing, call it "world.xml" | [16:43] |
| mircea_popescu: | the fact that the world.xml item adds a lot of friability is not imputable to the models loaded per se, but is due to the way in which they are loaded. | [16:43] |
| mircea_popescu: | this makes no sense ? | [16:43] |
| diana_coman: | ah, you mean "the cs xml might still be fine even if the ps xml is not"? | [16:44] |
| diana_coman: | because yes, there's the added confusion that BOTH cs AND ps add their own layer of xml "formats" | [16:44] |
| mircea_popescu: | something like that. | [16:44] |
| mircea_popescu: | i dunno even if the cs xml per se, or sometrhing even deeplier buried in cal3d, or maybe some remnant only partially digested by cs | [16:44] |
| mircea_popescu: | there's a lot of similarity between this sort of forsenic approach to computer science and fucking cladistics over here. | [16:46] |
| diana_coman: | cal3d data format was never under discussion for change; it is clear enough and documented and it was considered fine for what it is | [16:46] |
| diana_coman: | that being said, it's not a universal format anyway in that it doesn't include everything we want as "graphics" | [16:46] |
| mircea_popescu: | but what's missing ? | [16:46] |
| diana_coman: | what's cladistics? (it turns out I'm quite tired too) | [16:47] |
| mircea_popescu: | cladisticts is the effort to sort all living things into a proper v-tree | [16:47] |
| mircea_popescu: | such that all groups include all the downstream members. | [16:47] |
| diana_coman: | I can see the similarity indeed. | [16:47] |
| mircea_popescu: | it's typically preoccupied with producing monophyletic groups, by wringing the polyphyletics out of paraphyletic groups. | [16:48] |
| diana_coman: | mircea_popescu: cal3d formats allow def for: skeleton, animation, mesh, material. | [16:48] |
| diana_coman: | that's it | [16:48] |
| mircea_popescu: | we want something more than that ? | [16:48] |
| diana_coman: | so no terrain for instance | [16:48] |
| mircea_popescu: | it can't be a mesh/material ? | [16:48] |
| diana_coman: | it's fine for characters; arguably at a pinch for structures too since they can be "characters lacking this and that" | [16:49] |
| diana_coman: | but zero terrain, zero 2D icons and whatnots (gui which is also graphics); not to mention sound and particles whatevers | [16:49] |
| mircea_popescu: | this is the sort of q that'd have been copiously helped by a :"here's all the gane art currently known to mankind : 114 YB. choosing cal3d models throws out 112YB. choosing this throws out X" and so on | [16:50] |
| mircea_popescu: | diana_coman, i don't understand, an icon, the simplest iota of grapics, a fucking square image, is somehow unsuported ? | [16:50] |
| diana_coman: | everyone was very busy creating new formats really. | [16:50] |
| diana_coman: | cal3d format is meant specifically for describing animating *skeleton-based* sprites. | [16:51] |
| diana_coman: | not even "animated" in general | [16:51] |
| mircea_popescu: | so the idea being that it's incomplete as such ? | [16:51] |
| diana_coman: | sure, I can look/think if one can force-stuff it somewhere | [16:51] |
| diana_coman: | it's ...specialized, yes; not universal, no. | [16:51] |
| diana_coman: | not even meant to or claiming to be universal. | [16:52] |
| mircea_popescu: | so it's not proper to say cs is a wrapper class on cal3d wrt graphics, it does a lot of actual genuine extension, for instance by supporting anything besides "character models" | [16:52] |
| diana_coman: | well yes; cal3d is "character animation library", that's it. | [16:54] |
| diana_coman: | (and as I mentioned earlier: skeleton-based character animation, to be precise) | [16:55] |
| mircea_popescu: | do you recall at some point cca 2017 we did a test run of "importing gfx", i published an article on trilema. what was it ? | [16:57] |
| diana_coman: | let me dig it out | [16:57] |
| diana_coman: | mircea_popescu: http://trilema.com/2016/eulora-012/ | [17:00] |
| mircea_popescu: | keks 2015. we added those houses, as you recall they weren't there to begin with ; needless to say chet didn't document it uselfully. did you document anywhere at the time or hence how the process that yielded eg http://trilema.com/2016/eulora-012/ ? | [17:00] |
| mircea_popescu: | ha, simultaneous | [17:01] |
| diana_coman: | turns out 2016 ; I recalled I had it linked from my http://ossasepia.com/2018/03/30/my-first-2-years-as-cto-for-minigame/ | [17:01] |
| diana_coman: | surprisingly useful that single article of mine on the topic, huh. | [17:01] |
| mircea_popescu: | yeah | [17:01] |
| mircea_popescu: | but yes, it was mid-2016 | [17:03] |
| diana_coman: | re documenting that process: somewhere in the archives I still have all the scripts and the mess but it didn't get streamlined as such, mainly because of all the issues with ...different bits and pieces in the .blend files anyway; I don't recall publishing a write-up (at that time it was way less public too) | [17:03] |
| diana_coman: | I attempted to script the process, yes | [17:04] |
| mircea_popescu: | was it pretty much "collect blend files, select those that work" ? | [17:04] |
| diana_coman: | it was: here's this 2GB (or similar) archive with .blend files; get out of them whatever works to put in the client. | [17:04] |
| diana_coman: | I attempted to figure out the whole shit (I was clueless re Blender to start with and so on) | [17:05] |
| mircea_popescu: | Buoyed by having reached at least the end of the 32 bits to 64 bits migration swamp (it felt like hell at the time but retrospectively it was of course just a minor puddle of a swamp, there was and surely is worse to come), everything seemed suddenly within reach in the summer of 2016: the practically infinite landscape, the migration to RSA-based authentication, the graphics market place and with it the final client releas | [17:05] |
| mircea_popescu: | e that could be afterwards seamlessly updated as and when the server made new content available. | [17:05] |
| diana_coman: | I attempted to script the whole thing so that it runs headless blender, exports what's needed, then writes it automatically in client's favourite xml places | [17:05] |
| mircea_popescu: | funny what passed for "back years ago"... back years ago. the quote is q1 2018 discussing q3 2016, ringing q1 2020 | [17:05] |
| diana_coman: | myeah, there were quite a few turns of the sort "oh, now you need to do the client too because guess what, who else" | [17:06] |
| mircea_popescu: | communities, the greatest thing ever for as long as nothing needs to be done. | [17:07] |
| diana_coman: | the scripting part went fine as long as there was the expected in the expected place, as scripting tends to go. | [17:07] |
| diana_coman: | but the sad thing was that the "expected place" and even the whole of "what is there" was utterly random pretty much | [17:08] |
| mircea_popescu: | why did you care ? | [17:08] |
| diana_coman: | I don't recall now how many .blend files were in total, but there are there those that made it and they don't seem all that many | [17:08] |
| mircea_popescu: | is the idea the original search was ~exhaustive ? | [17:08] |
| diana_coman: | mircea_popescu: what do you mean? how do you even decide "where should they be" if there's no standard they should be there/here/x ? | [17:09] |
| mircea_popescu: | you mean eulora doesn't look in always the same place ? | [17:09] |
| diana_coman: | I don't know how that archive was put together and I have a hard time thinking that the archive was the result of exhaustive search | [17:09] |
| diana_coman: | no, I mean the .blend files don't a. have all the same things b. even when they have the same things, in the same places. | [17:09] |
| mircea_popescu: | yeah. so some suck, why would you care. | [17:10] |
| mircea_popescu: | "because how thefuck do i pick which is the right set" | [17:10] |
| diana_coman: | the write to eulora's xml mess was the less troublesome part aka once I figured out where they should go, they went in there (added to the pile, sure) and that was that. | [17:10] |
| diana_coman: | exactly. | [17:10] |
| mircea_popescu: | so, to return to the original point of discussion, why exactly can't we simply declare "make it like so and put x and y there and that's the format" | [17:11] |
| diana_coman: | (fwiw I still have that archive of .blend files in the...archives, too, yes) | [17:11] |
| mircea_popescu: | what size is it ? | [17:11] |
| diana_coman: | a few gigs as stated above, don't recall exactly; do you want me to dig it out to see? | [17:12] |
| mircea_popescu: | not urgently but yes | [17:12] |
| diana_coman: | we can declare anything, sure; what's it worth though if we go at it ...uhm, on what basis exactly? | [17:12] |
| mircea_popescu: | let's revisit : http://ossasepia.com/2020/01/16/eulora-logs-for-16-Jan-2020#1001411 | [17:13] |
| ossabot: | Logged on 2020-01-16 12:14:57 mircea_popescu: firstly, if man says "i went as far as i could, but as i reached X-seashore, i needed either a boat or a plane to continue. for lack of either, i had to turn back." then man is held to show three tings : 1. that indeed the X-seashore is liminal, a categorical discontinuity in the medium ; 2. that indeed "boat or plane" ennumerates the list of possible manners of crossing ; 3. that indeed he lacks each of them for fundamenta | [17:13] |
| mircea_popescu: | http://ossasepia.com/2020/01/16/eulora-logs-for-16-Jan-2020#1001414 | [17:14] |
| ossabot: | Logged on 2020-01-16 12:17:19 mircea_popescu: thus, to be able to say, like we have, "look, can't continue here, because we don't know what we want the data to look like, and we don't know how to find out" we must, besides the various cases we've covered, also explain what is wrong with ~the thing we're currently using~. | [17:14] |
| mircea_popescu: | that's the basis : "this is how IT CURRENTLY WORKS. fuck you all." | [17:14] |
| diana_coman: | I see. | [17:14] |
| mircea_popescu: | that was the original problem, yes ? http://logs.ossasepia.com/log/trilema/2019-12-30#1956382 | [17:15] |
| ossabot: | (trilema) 2019-12-30 mircea_popescu: diana_coman, let's restate this, so currently work on nailing down the comms protocol is stalled on a definitive universal data model, which is stalled on graphical use in the client, that about it ? | [17:15] |
| mircea_popescu: | i suspect an implicit, never verbalized but quite fucking poisonous wart built in all that is, specifically, | [17:15] |
| diana_coman: | I suppose part of my trouble - maybe only mine - is that hard "definitive universal" | [17:16] |
| mircea_popescu: | "what if in x time a holier-than-thou moron shows up, be his name stanislav dumbkopskyi, and starts whining about how shit that works differs from his retarded 9yo boy's apprehensions of the world, what do we say to him ? what if he's uncommonly gifted and very VERY good at theoretical masturbation ???" | [17:16] |
| mircea_popescu: | definitive here means that i'll affix gifted boys of the masturbatory theoretical persuasion by it with rusty nails driven through their guts ; not that i'll hang the people that made it work off it at the instigation of beings an engineer. | [17:18] |
| mircea_popescu: | it's definitive in the sense death&damnation is definitive, not in the sense mathematics is definitive. | [17:18] |
| mircea_popescu: | definitive as a painful and insulting imposition upon the "human rights" of the living. | [17:18] |
| diana_coman: | I see; and indeed, I was working with mathematics-definitive definition rather. | [17:19] |
| mircea_popescu: | i am elated we finally managed to actually put this idiocy in words. | [17:19] |
| diana_coman: | so the idea is: get back to (which version of) client and see *what could be made to work* to send the damned graphics? | [17:20] |
| mircea_popescu: | the idea is -- we skipped a step, specifically that one. | [17:20] |
| mircea_popescu: | i'm not committed to it as such, for all anyone knows maybe it's not worth the skinning. but shouldn't we at least ~look~ ? | [17:21] |
| diana_coman: | tbh I always thought it had been already done/planned before, hence never questioned it as such; huh. | [17:21] |
| mircea_popescu: | because in my notes it doesn't actually figure we indded did look. are my notes out of whack even ? | [17:21] |
| diana_coman: | we didn't look at that specifically, as per above; I thought it had been looked at before my time, when CS was selected namely. | [17:21] |
| mircea_popescu: | but the look back then came out with "well... it should work, mostly" | [17:22] |
| mircea_popescu: | that, mind, was like 2012. it'll soon be a decade. not that anything ever changes, but, you know, computervomit. | [17:22] |
| diana_coman: | trouble is that this sort of thing either is looked at in quite the detail to *know* it works or otherwise it tends to be more of the "seem like it should work, in principle" and then,well. | [17:24] |
| diana_coman: | in the end all code will work for anything - it just takes more or less...re-writes. | [17:24] |
| mircea_popescu: | this is so. | [17:24] |
| mircea_popescu: | the proposed solution however can't be "let's withdraw into a solipsistic hell of our own making". | [17:25] |
| diana_coman: | I'm not arguing for any such solution, no. | [17:25] |
| mircea_popescu: | do you see another ? | [17:25] |
| mircea_popescu: | it seems to me to be going straight for ye olde "is it better to have loved and lost than never loved at all" | [17:25] |
| diana_coman: | atm I'm not even arguing for any particular solution as such; still trying to grok what options there might be. | [17:26] |
| mircea_popescu: | alright. but as far as the needs of conversation go, you're as satisfied as i am we actually understand each other re the original ingrown hair that started the whole discussion today ? | [17:27] |
| diana_coman: | the "definitive"; the lack of a clear evaluation regarding usefulness for us of the existing cs/ps/cal3d formats | [17:28] |
| mircea_popescu: | that and otherwise some bells and whistles, right. | [17:29] |
| diana_coman: | and obviously, the clear need for it. | [17:29] |
| diana_coman: | on the bright side, I can say that at least I'm better prepared now to even look at it than I was in 2016, there is that. | [17:30] |
| mircea_popescu: | absolutely. | [17:30] |
| diana_coman: | mircea_popescu: at any rate, if we go for the "small improvements delivering benefits", then it's anyway gradually grafting stuff on the currently working client. | [17:36] |
| diana_coman: | or rather: off of. | [17:36] |
| diana_coman: | mircea_popescu: library with .blend files was 3.7GB | [17:39] |
| mircea_popescu: | aha. | [17:41] |
| mircea_popescu: | as far as i can discern this was never billed or reported as anything but small experimental run. "spent a few hours getting some stuff" | [17:41] |
| diana_coman: | that seems fitting really | [17:42] |
| diana_coman: | as I was saying recently, there are TONS of .blend files and quite intricate/loads of stuff | [17:43] |
| diana_coman: | by now I suppose the potential issue is that they'll be so huge as to end up unusable for being too slow/millions of vertices whatevers | [17:44] |
| diana_coman: | this part possibly changed from 2012 to now. | [17:44] |
| mircea_popescu: | i dunno, steam regularly downloads 20gb of crap for a game that doesn't even work. | [17:45] |
| diana_coman: | well yes, unusable but ...large | [17:46] |
| mircea_popescu: | what im saying is that i suspect largeness stopped connoting unusability cca 2014. | [17:46] |
| mircea_popescu: | look at a webpage sometime. yes it's nice that eulora is so compact it works at 100fps on mobo included gfx chips | [17:47] |
| mircea_popescu: | but since they're paying me 0 for this priviledge, it has 0 priority on my balance sheet. | [17:47] |
| diana_coman: | trouble may be deeper aka the way it processes that ton of vertices; precisely because it doesn't expect whatevers otherwise | [17:48] |
| mircea_popescu: | possibly. | [17:48] |
| mircea_popescu: | http://ossasepia.com/2018/03/30/my-first-2-years-as-cto-for-minigame/?b=at\%20the\%20moment&e=looking#select << heh, re-reading i am reminded we ended up with like a month+ of downtime in 2018, too. totally forgot about it. | [20:37] |
| mircea_popescu: | holy shit pizarro was a pos. | [20:37] |
Comments feed: RSS 2.0