Thanks.

I failed to capture the essenence of what my project is. The APIs are really what's exciting. But you can't see APIs, they're like the wind, you have to see them in action, through their side effects. I should have waited until I had made more things that show off how innovative these APIs are. I released it too soon.

Absolutely not too soon! This is a great project; it's so amazingly, ridiculously overengineered, in the best way possible! The most beautiful bike shed I have ever seen. You even implemented your own reactivity system.

I love it.

It's just right for a Show HN. I was able to find the Hello World tour and grasp what's going on here, from previous PICO-8 and React experience. Looks pretty cool, and I think 16:9 is a good pick. PICO-8 being square is awkward.

Thank you for launching early.

Definitely launch often.

10,000 iterations. One down. 9,999 more to go.

No sir, you didnt launch too soon. You're doing great.

Oh, no, sorry for the confusion. The color picker is as far as I got with that app, it's relatively new. I can probably get it fully working within an hour though.

Also thanks, that's exactly what I was going for! I wanted to capture the fun and excitement and raw power of creating GUI apps in the 90s (but without all the inconveniences). Hence the name 90s.dev

I'm not sure it's implemented yet. If you click the "hash" button in the upper-left of the window, you can click "View Source". From there you can see it's just a mocked up UI, the scroll area just draws pinstripes.

Not working for me either.

I think I figured out how to explain it:

I basically wanted to make a much more usable pico8 for game prototyping. Hence the 320x180 design, and this prototype: https://90s.dev/v1/ But I also wanted the full convenience of VS Code, including full type checking and autocompletion support for TypeScript. So I designed it to be a platform that can be used to make and publish the things that pico8's tabs contain.

Now I see that I released this much too soon.

I like the aesthetic, but 16:9 and 90s computing together is just wrong.

The back breaking not quite square trinitron monsters were the best.

Thanks!

Explaining stuff is so hard! In fact, this entire article is just me trying to explain what this is in the shortest way possible.

Maybe the shortest version is: 90s.dev is an API around a 320x180 web canvas, designed specifically for making games and game maker tools, with sharing capabilities built-in, and an innovative GUI for making game maker tools quickly and easily.

No, that's still too vague. I give up.

You might also be interested in Picotron[1], made by the same guy who made Pico8. It's basically a desktop OS with the same basic design as Pico8 but with slightly looser restrictions. I've never really tried it, only looked at his gifs once a long time ago, but I think he and I had the same basic idea: make a platform that you could make pico8 in. We just went different routes.

[1] https://www.lexaloffle.com/picotron.php

Thanks.

The current method of building a game is the same as the walkthrough for building an app[1], except you make a custom view and override its draw method. For higher performance, you can create an OffscreenCanvas and draw into it however you want. There's no API to wrap WebGL2 more conveniently than this yet.

I definitely should and will wirte a guide that takes you from nothing to a full fledged game. But right now, the guides are all geared towards making apps, since before we can make games, we need to make gamemaker tools, like spritemakers and mapmakers.

[1] https://90s.dev/getting-started/hello-world.html

Thanks for the feedback.

You're likely using Firefox, right? This feature relies on showDirectoryPicker which Firefox doesn't support. You'd have to use Chrome for the getting started guide.

Also, the drive name shouldn't have a path. Name it something like "foo". I'll udpate the guide to reflect this. Then foo/helloworld.app.js will point to /some/local/path/helloworld.app.js, as long as you mounted "foo" to point to the directory at "/some/local/path"

  import 'http://localhost:8080/index.js'

I agree. To be fair, naming things is one of the three hardest problems in computing (the other one being cache invalidation).

Thanks for letting me know. Hmm, I don't know what Floorp is doing differently. I'd need more of a stacktrace. It works in regular Firefox though. Feel free to paste a stacktrace and/or stacktrace screenshot on the issues page and I'll take a look.

It should be fixed now! Can you try it again?

Ha, yeah. I intentionally avoided any ctx.clear() calls just so we could have mouse trails again when things crash :D

Collaboration has always been one of my favorite things. Shortly after starting this project, the focus began to center around making sure users could create first-class apps and libraries and easily find and use them in their own creations. Much of the API evolved around supporting this idea.

I haven't made any games with it yet. I barely finished any of the game making tools. The platform itself is relatively stable, which is what I spent so much time on. And the hope was that the community would help make the game making tools and the games. But maybe you're right, maybe I have to finish some game maker tools, finish some games, and finish some tutorials to make game maker tools and games, and then relaunch in a few months.

Thanks! Well, kind of. The JSX is mostly for making the apps that comprise gamemaker components, like pico8's spritemaker and mapmaker tabs. Once those apps are made, you can use them to make game assets. But those apps run in the same canvas that games would run in. A mapmaker and a game would use the same GUI for drawing into the canvas. But a game would probably create a single View and override its draw method to draw most of the game, though it could use JSX to build up the views that comprise game panels like Minecraft's inventory views.

I took great pains to make sure it does. The one thing that Firefox doesn't support is mounting a local drive so you can develop your app, library, or game more quickly, which needs https://developer.mozilla.org/en-US/docs/Web/API/Window/show...

It doesn't on Firefox ESR.

Thanks! Hopefully it'll give you an idea of how fun it was to make GUI apps in the 90s!

For games, 320x200 (non-square pixels) or 320x240 were pretty standard resolutions up through the mid-90s or so.

In the immortal words of Pitch Meeting's Screen Writer Guy, I'm gonna need you to get allll the way off my back about the name being innacurate.

It's basically MIT. I used to have it injected at the top of the source files. I forgot why I took it out.

[edit] Just added MIT licenses to the top of all the files.

You're right. I definitely need to put more work into making very full tutorials for this.

I tried to make it even more interactive than that. If you click any of the links on this site that start with `/os/#` then it will open (or close) an iframe under it that actually launches the app you're linking to. There's also an interactive demo on the hello world page: https://90s.dev/getting-started/hello-world.html

Not that you're asking, but https://www.littlewargame.com/ is a good WC1/WC2 clone with a lot of good QoL features included.

Thanks!

Actually I am planning on shifting it towards importing 'https://' URLs directly.

Honestly, the main difficulty I have is keeping full TypeScript support of remote modules. It's actually easier to do this if I import https:// modules directly, though it's not as convenient as it could be[1].

But I'm also trying to figure out whether I should continue to compile TSX to JS in the service worker[2], which requires no special dev-time setup and allows publishing raw .tsx files anywhere on the net such as github, or require users to compile TSX -> JS ahead of time, which would require a build step.

On top of that, I'm considering going further and making it so packages can import bare-specifiers like `import "somelib"` and publish a plugin to compile this into an https:// import specifier.

[1] https://stackoverflow.com/questions/79628025/is-there-a-way-...

[2] I currently use a service worker to map imports like `/os/fs/{ghb,npm}/...` to `jsdelivr.net/{gh,npm}/...` and compile them and return with the right content-type.