One key difference: this guy built his demo from scratch, whereas mine's a port of someone else's work. It's great to see another implementation, with its own techniques and features.
Through the nineties, Microsoft software engineers carried on a tradition of writing clever and distinctive software projects alongside the software they were primarily tasked with writing— this is where Solitaire and Minesweeper came from, for instance. These engineers also wrote "easter eggs" into their primary software, such as the beautiful flight simulator hidden in Excel 97.
Amazed by reading the above. I'm a sucker to read and learn from that clerverness.
The video didn't generate much interest so unfortunately I didn't release anything playable.
I can't take credit for Drivey's aesthetics, I'm just honored to have carried it to HTML5 ;) Somewhere out in Australia is the original programmer who I'm sure would love to see this, but who also loves avoiding the spotlight.
I just did a quick scroll of your Twitter feed and jeez you're prolific, this stuff is really cool. I'll try Hexpress this weekend.
P.S. It's a joke. This is a really well executed demo.
I like to joke that Australia (where Drivey originally comes from) has a low enough population that the pedestrians are in no real danger ;)
ａｅｓｔｈｅｔｉｃ 可ぷき
Drivey shows objects as their silhouettes on top of a light background, whereas Nightdrive shows objects as their lights on top of a dark background.
Some people are making a strong case (I think) for calling these types of projects "demos", but also, I think the inability to fit them in the arbitrary structure of existing nomenclature is a good quality for a project to have. :D
Have you considered using a small bokeh image in place of circles in your renderer? Their size is based on the (usually unchanging) optical properties of the eye, rather than the eye's distance to the light, so you'd fade them rather than resize them, and if you round their position to the nearest pixel you might be able to draw them with 2D canvas context speedily.
If you create an issue on the repo, I'll try and figure it out when I have the bandwidth.
EDIT: never mind, it looks like it was, very cool.
The original was written in "JujuScript", with strong types and novel operators. I pretended it was Haxe, and ran around fixing compiler errors it till it compiled to JavaScript. I built out a small Three.js project to hook it to, built up the features, then refactored it into something I felt was maintainable. I tried preserving the organization of the original script as best as I could.
Sidenote: I belong to the "port it" school of software preservation. My friend who runs the BlastEm project belongs to the "emulate it" school. I've seen both approaches have been employed to preserve Glider, which I think implies how important that game is to people. :)
But I don't see anyone else having issues so, is it just me?
A compiler would tell me what all the types should be and if they are being respected. I'd also write a lot of unit tests to make sure that the code is doing what it is expected to as well as enable refactoring more easily. The code isn't formatted consistently, so that also makes it hard for me to read, I'm kind of OCD about that and having tools like eslint/prettier, which do it automatically, makes this super easy to fix. Linting the code would also point out other issues that the compiler misses. Putting it into CI would ensure that all changes get checked and builds would fail, if there are issues.
So I guess that is what I mean when I say 'clean it up'.
What I did was pull the source code, load it up in IDEA, convert the .js files to .ts files. Then looked at the errors. Most of what stood out was that the author included a copy of threejs directly and used parts that TS can't infer types on. Not a huge deal, but makes following the code more difficult for sure. I don't think it would take too much time to update it at all.
I think you're right on many counts, and I appreciate the effort you took to see what TS could do for this kind of project.
If you create an issue on the repo, I can notify you if I make an attempt at using TypeScript to maintain it, in a branch at least. No guarantees, but I've considered it before, and it'd be worth my time once I have some to allocate.