I agree that a voxel engine is probably more productive for such a "toy" console approach. You can basically use the same techniques as the one you'd use on the PICO-8, just with an added dimension.
Polygonal 3D is a huge step compared to 2D engines. You can't just create assets with a simple bitmap editor, you need to learn 3D modeling and it's a huge can of worm. And then you need to learn to animate your models...
With voxels you can just sculpt your models minecraft-style, it's a lot more intuitive I think. And animations could be done like for sprites: you just key your animations with different 3D voxel models.
That looks cool, but I think what GP wants is a PS1-like virtual console with limited palette, 32x32 textures, and unlit, unfiltered, non-projective texture mapping.
PS1 can support 256x256 truecolor (or 4bpp/8bpp paletted) textures, dithering and gouraud shading! It also has a very weird graphic pipeline that I don't think would be very friendly to a novice: the 3D projections are done on the CPU and the depth buffering is handled by... the DMA. The GPU is purely 2D, hence the lack of perspective correction in the texture mapping.
The Pico-8, in both its aesthetic and its imposed constraints, creates a "fantasy version" of the experience of working on actual 8-bit consoles. It presents that era as people remember it, instead of as it actually was. I think a similar thing could be done for the N64 generation.
As others here said, while this is cool, it uses voxels which are unrelated to the techniques used in early 3D video games. Not much nostalgia value there.
You can use modern modeling tools with self-imposed limits on model complexity and texture sizes. (Blender is even era-appropriate — its first public release was in 1998.)
Alternatively, see Crocotile3D, which approaches that era's aesthetic from a different angle of simplified tile-based modeling: http://www.crocotile3d.com/
This abomination has the ability to put more than decent computer into a miserable slug. I cannot imagine how much my client would have saved in productivity from all its employees and contractors if that thing was uninstalled.
> Good software is reusable. I can import functions from 1,000,000 different npm modules all into my project and they don't fuck with each other, right?
I just spent the whole day trying to fix compatibility issues between different versions of npm libraries transitively imported in a project. Reusability in JS is a joke.
As a primarily JS/React developer, I think there is irony if JS is held as a good design pattern in comparison to CSS with respect to reusability. Inasmuch as what are being called CSS "workarounds" are in fact workarounds, so too has been the case with JavaScript itself. I am old enough to remember jQuery and Prototype colliding over the dollarsign namespace.
Don't get me wrong. I am not a JS (or CSS) hater. I think these "workarounds" are more than adequate in making these technologies easy to work with. Which I suppose is sort of my point. I see a lot of overengineered codebases with Byzantine solutions to relatively simple problems.
Also, to parent poster:
> Let's say you wanted to pull in a button from Bootstrap for one part of your page, a button from Material UI elsewhere, a button from Semantic UI elsewhere, etc.
1) First of all, don't do this. Perhaps you were just saying this to make a point, but obviously don't include 3 monolothic libs with overlapping functionality in order to implement 3 things with the same functionality.
2) It sounds like your problem with this is more with the libraries themselves. When I write a component, I always namespace it myself. Obviously, if libraries are properly namespaced, then you could easily include buttons from three separate button libraries.
What dependency system anywhere on earth is free of the problem of "two things require different versions of the same library"? I don't see the relation to JS at all.
I've had this problem with JavaScript-before-npm-existed, Python, apt, Homebrew, Portage...
Note that npm also supports having multiple versions of the same package installed just fine.
The problem:
I use X to create an object with library A v1.0.
I use Y to create an object with library A v2.0.
These objects are not necessarily compatible, so X and Y have problems communicating.
I would be very surprised if you told me nix or stack inherently make objects from multiple versions of the same library magically compatible with each other.
How would objects created from X and Y can reach each other and communicate when X is not dependent from Y or otherwise? You need global mutable state or your own code witch depends from both X and Y is somehow connecting them.
So one top thing FP movement argues against is global mutable state so of course you don't have that ...Unless you are wrapping some non-FP thing like QT...
And if it's your own code it shouldn't be different that Y creates B:s instead of A v2 since your code is aware from two different versions anyway.
That's more subtle, as individual anonymized data point can not identify an individual, but a linked set of those can, with a very high percentage of confidence.
Facebook can always play the card that each data point are anonymous, hence not part of your data, and keep everything.
Exactly this. Assuming that shadow-profiles are derived on-demand, the only way to "delete" one would be to delete the datapoints it's built from.
We know that facebook can use contact info to identify clusters, right? Suppose that I don't have facebook, but a bunch of my friends do, and facebook has all their contacts' phone numbers. They can infer the circle of friends of "whoever owns phone number X" using just this info. This is probably not the extent of a shadow-profile, but I think it's a plausible stab at the underlying mechanics (repeat again with email, with browser fingerprint, etc).
In order to "delete" my phone-shadow-profile, facebook needs to remove my phone number from their internal copies of my friend's contact lists. They also need to keep a copy of my number in a "do not shadow" list, or else they'll just add me back in next time they scrape my friends' contacts. Armed with a such a do-not-shadow list, there's no need to actually do the deletion, rather than simply marking the deletion.
So, assuming my speculations of the nature of shadow-profiles are about right, the only way to really avoid facebook having one is to register your fingerprints with them, so they can tell which parts of their data are you, in order to know not to use that data to draw inferences about you.
That, or give up on drawing inferences between disparate data-sources at all.
> In order to "delete" my phone-shadow-profile, facebook needs to remove my phone number from their internal copies of my friend's contact lists.
This is (potentially) not viable. Your friend's contact list is not your data, it's their data (about you) and they store it on FB servers. Right now it's probably used only for ranking and friend suggestion, so what you suggest would work. But if FB would decide that say messenger should work also as contact sync app (it already allows you to send SMS to people in your contact list), this would cause that your contact could not be synced, and really break user experience, as you would be able to delete your phone number from your friend's phone books.
More philosophical question: if you should be able to do that [delete your phone number from your friend's phone book on FB], should you be able to do that also from google contact sync server? From gmail? From your friends phone? Or from your friends physical (manually written) phone book? Where to draw a line, or how to approach this?
John Biggs can use TechCrunch's platform to deliver his message without necessarily agreeing with everything TechCrunch does (such as advertising for Facebook via those buttons).
Additionally, if you're encouraging people to delete Facebook, your target audience is people on Facebook, so...
> Oh, and don't forget to share our article using the little facebook widget at the bottom...
These kind of comments add no value and rest on incorrect belief that either:
1) authors control the marketing tech stack on the major sites they write for or
2) they can afford to sacrifice audience for their messages, etc. in order to be hyper-picky in order to forestall internet heckles.
The truth is that neither of those things are true. Writers will write, activists will get their messages out, and that's their job. Sometimes they will criticize something so ubiquitous that even they can't avoid it totally, but that doesn't make them hypocrites. In fact, criticizing bad things that literally everyone does is the first step towards fixing those things. If stupid insinuations of hypocrisy like yours had any value, it would be impossible to make progress on many fronts.
I generally agree with this point, in the same way that I think that people are far too ready to call "hypocrisy" when the deed that is 'hypocritical' is just a small subset of the original 'evil'.
Having said that, I also think it's worthy to highlight the impact of the facebook sharing button, which isn't dealt with in the original article. The point is that it's not enough to say to individuals "don't use facebook"; you're still 'at risk' if you visit a site that uses the sharer widget, even if you don't have a facebook account.
As an aside to the aside, techcrunch has to be the first site I've encountered that redirects you when you scroll beyond a certain point of the article, or when you try to search in-page (unless that's a bug, of course).
From Facebook's perspective, dissatisfied users who delete their accounts are a sort of immune system response. The spread of contagious memes like "Facebook is a pointless, addictive time suck" are contained because those "infected" with them take themselves out of the population.
Rather than just deleting your Facebook account, if you spend some time using it to push articles and posts out onto your feed describing your position, then the memetic contagion can spread over Facebook. If enough people do that, it could hasten their collapse (unless they actually manage a heroic effort to successfully address the critics, not just a PR band-aid).
P5 is indeed the official port of Processing for Java (Processing.js being an independent attempt from John Resig).
But like Processing, P5 is more about artistic realisations than applied use, which all of your alternate descriptions tend to lead to.
> P5 is indeed the official port of Processing for Java (Processing.js being an independent attempt from John Resig). But like Processing, P5 is more about artistic realisations than applied use, which all of your alternate descriptions tend to lead to.
This sounds unnecessarily negative. Even in the light of pure artistic realisation, I found 3 of the 4 points still very good.
The first point _is_ very much about artistic realisation:
- p5 speeds the creation of animations on your site
The second and last point are about the accessibility of the artistic stuff. Some don't care, but others want to show their stuff and all their intermediate stuff to the widest audience possible:
- p5 allows beginners to create complex interactions compatible across devices
- p5 shrinks site size by replacing videos with animations
But as gp said, this list is just an inspiration and the real list of benefits needs to be determined empirically with the community of (potential) users.
