Recent Posts

Pages: « 1 2 3 4 5 6 7 8 9 10 »
81
Cute Discussion / Re: IguaRPG 2 Devlog
« Last post by hubol on October 02, 2023, 05:28:50 PM »
100% agree and I will effortreply to everyone’s effortposts later today!!
82
Cute Discussion / Re: IguaRPG 2 Devlog
« Last post by dcco on October 01, 2023, 10:39:15 PM »
Ducklang unironically a good name for a language lol
83
Cute Discussion / Re: IguaRPG 2 Devlog
« Last post by SquareWheel on September 30, 2023, 09:14:44 PM »
Main features are ADTs and also a function overload system that distinguishes functions of the same name by the argument of the first type.
It only makes sense that ducklang would have some form of duck typing.

I have no clue how any of this stuff works but it sounds very impressive.
84
Cute Discussion / Re: IguaRPG 2 Devlog
« Last post by dcco on September 30, 2023, 10:08:47 AM »
I want to see it!!!!!!!!!!! Do it!!!!!!
I actually did start working on a language for game stuff - doesn't have any of the stuff I was talking about, but it *does* have an actual type system which I'm playing around with a lot. Main features are ADTs and also a function overload system that distinguishes functions of the same name by the argument of the first type. (There will also eventually be polymorphism but I haven't needed it yet). Basically I'm messing around with various type design decisions to see what works and what doesn't.

(syntax highlighter scuffed bc it's hard to keep up with it while actively making the language :U)
85
Cute Discussion / Re: to do
« Last post by SquareWheel on September 30, 2023, 10:05:39 AM »
Was actually rescheduled to today, the 30th.  Might see some performance improvements afterwards, though I'm not sure we'd be able to notice it.
86
Cute Discussion / Re: IguaRPG 2 Devlog
« Last post by dcco on September 30, 2023, 10:02:05 AM »
If JS gets some kind of optional typing that would be dope bc I agree it's one of those things that should just be in the language. I feel like Java was kind of that way wrt Scala where after I adopted Scala, Java slowly began getting more and more features (first-order functions, less type annotations) that would maybe bring me back to it. BUT TS is still kinda nutty in terms of what it can do imo (although I'm really not a fan of how the 'any' type works) so idk JS has its work cut out for it imo.
87
Cute Discussion / Re: to do
« Last post by dcco on September 30, 2023, 09:53:18 AM »
damn how did they go
88
Cute Discussion / Re: to do
« Last post by SquareWheel on September 25, 2023, 05:18:26 PM »
Expected four hours of maintenance on Sept 27th, 7pm GMT.
89
Cute Discussion / Re: IguaRPG 2 Devlog
« Last post by SquareWheel on September 17, 2023, 10:43:42 AM »
That's awesome, thanks for writing all that out.

Windows paths using \ is the worst ever.  It's one of those 30 years ago decisions to allow a certain flag syntax: "program.exe /flag", but now lives with us forever.  Between that, case sensitivity, and \r\n, cross-platform development has lots of interesting pitfalls.

I think it's not terribly uncommon for people to pin specific versions of deps, but I think you're right that it is error-prone.  It's easy to come back a year later and be confused why updating your deps has exploded everything.  Tough situation when there's no upstream fix though.

What's zipping the audio files for?  I figure it can't be adding any more compression, so just for packaging?

I've avoided playing with TS mostly because I haven't needed to, but I secretly hold the idea that eventually JS will get optional typing and TS will become more of a niche utility for its extra features at that time.  In the same way that LESS and SASS have fallen away as CSS has become more powerful, we seem to move towards fewer steps and less bundling where possible.
90
Cute Discussion / Re: IguaRPG 2 Devlog
« Last post by hubol on September 16, 2023, 04:46:41 PM »
Update #2: smooch adventures?!

Since I am writing adequate commit messages, I will use my git history to see what wacky stuff I've been up to!

W1. Normalized paths in console output
I thought it would be a cool idea to rewrite paths printed to the console so that they are relative to the current working directory. Since paths are different on Windows and Unix machines (Windows uses \ instead of /), my logging abstraction also normalizes this. These changes mean that my naive automated tests can check that particular paths are being correctly output! I also think it improves the readability of the logs, which is somewhat of a priority for this project.

Here's a sample:
Code: [Select]
            NativeDependencies Checking that native dependencies are installed to .smooch/native-deps
            NativeDependencies Native dependencies appear to be installed.
                        Ffmpeg Set Ffmpeg path to .smooch/native-deps/node_modules/@ffmpeg-installer/win32-x64/ffmpeg.exe
             SmoochJsonWatcher Started
                     FsWatcher Started with subscriptions: audiCnv
                     FsWatcher Ignored Message #0 (Catch-up) <no events>

W2. Converting audio files
The previous incarnation of smooch used sox to convert audio files. This required the user to install a native dependency before running the tool. You also had to make sure that you installed the liblame thing for mp3 or whatever. It got annoying!

Apparently there are some packages on npm that seemingly abuse the "optionalDependencies" property in package.json. Examples: https://github.com/kribblo/node-ffmpeg-installer/blob/master/package.json , https://github.com/parcel-bundler/watcher/blob/69f3099f009330d53abdb0e7d53e9f9204af04b3/scripts/build-npm.js (this code generates a package.json!)

They use this property to install binary packages that are installable on the user's architecture. I searched for a package like this for sox, but I couldn't find one. So I used the @ffmpeg-installer/ffmpeg library. So, smooch now uses ffmpeg to convert audio files. I implemented this and it seems to work fine! Cool!

W3. Type hints in template programs
A core component of smooch is the ability to get metadata about transformed assets and apply the metadata to a template program to generate a code file. Special context is exposed to the code file, and it's not always intuitive how to use that context without types. VS Code supports loading .d.ts (TypeScript declaration) files from within JavaScript files (our template programs are plain JavaScript files) using JSDoc. I love using TypeScript in clever ways, and don't like doing lots of manual work. So, I found a tool to generate a single .d.ts file from some types (for some reason this feature is not built into TypeScript)!! The result is some example template programs with types embedded using JSDoc!: https://github.com/hubol/smooch/blob/973ade74ca20f731e7a44a1e9da2492b8704ee97/dist/templates/audio-convert.js

W4. Zip archiving of audio files
I got to implement this and it's looking good! At first I was exploring the possibility of keeping a cached zip file and only adding newly converted audio files to it. But on my machine it takes only ~200ms to zip the entirety of IguaRPG's sound files to a new zip file.

W5. Library bugs, version conflicts, native dependencies...
I ran into an issue with one of the libraries I'm using, @parcel/watcher. I observed that when upgrading to version 2.3.0, it was possible for one of the functions exposed to me to hang infinitely. I did some digging and found this commit: https://github.com/parcel-bundler/watcher/commit/9b7c657df8ad1c0d020541eae0dd38b921c94fb8 ...And if I upgrade to that particular version, I also experience the hanging. I tried to create a small repro so that I could report an issue, but to no avail. I am guessing they introduced a deadlock, but I have no idea how to read and/or debug C++.

@parcel/watcher is supposed to provide performant file system events. The library is even used by VS Code! I would like to use it in this project. But, I don't think it's a good idea for smooch to require a specific version of the library...

Imagine we have this package.json in our IguaRPG 2 project:

Code: [Select]
{
   ...
   "devDependencies": {
      "smooch": "^1.0.0",
      "parcel": "^9.0.0",
   }
}

Both packages depend on @parcel/watcher. smooch requires a specific version 2.2.0 due to the aforementioned bug, but parcel might need something higher than that. npm will be unable to resolve this conflict!

This would be no issue if @parcel/watcher had no native dependencies. I could simply pack all of its JavaScript code into my smooch bundle, and there are now no worries about conflicting dependencies.

But because of the native dependencies, I have two choices:
1. Download specific versions of their binaries for all supported platforms, and include them in my repository and require them from my bundle
2. Install the native dependencies using npm at runtime, and place them in a special folder that only smooch is aware of

I went with 2, even though I'm pretty sure it's unorthodox AF. It actually required surprisingly little code: https://github.com/hubol/smooch/blob/f663e32a20f9d0e7486e1150051b449f4001a462/lib/common/native/native-dependency.ts

The NativeDependencies class exposes isInstalled, install, and require methods. And I think they look pretty nice! I also did some crazy shit so that the correct API of the package is returned from the require method (-:

But yeah, now these dependencies are installed to a separate package at runtime, ensuring that the desired version is installed with the correct native dependency! I'm glad that I was able to accomplish this with very little code and by leveraging shit that already exists!
Pages: « 1 2 3 4 5 6 7 8 9 10 »