Status Updates posted by Remilia Scarlet
Eschatology 2 will be delayed just a few days, probably like Sunday or so. I have mental health stuff going on, among other things ^_^;
So! Doom stuff!
As I sorta mentioned before, I'm splitting Eschatology up into multiple releases. This is being done mostly for mental health reasons, and partially so I can focus more on other hobbies, like programming and music. Here's how it'll work:
- Eschatology's story will be told over a series of individual releases, just like with Freaky Panties, but with a bit more emphasis on the story. Freaky Panties' story is kinda just background fluff that's almost non-existent ("Doomguy searching for his favorite pair of panties, which the demons stole"), but Eschatology's will be obvious (and more serious).
- Eschatology will have no start map. Each release is an individual pk3 that you load up and play. Just like Freaky Panties.
- Eschatology 1 ("esc01") will be out this coming week (!!!). It will include the map "Decayed Faith".
- Eschatology 2 ("esc02") will be out sometime between the 20th and 30th. It will have the map "Dismembered Doll Parts".
- Eschatology 3 ("esc03") will be out in the late fall or early winter, depending on my programming projects. It will be the map "Colombian Necktie", which is the one with the hellfire.
- Eschatology 4 ("esc04") will be out just before December, and will be the remixed/expanded version of Halls of The Goat Child.
- Eschatology 5 ("esc05") will be started on next year sometime.
- I'll try to slip in a Freaky Panties map or another non-Eschatology map in this year, too.
Eschatology will still require K8Vavoom to run, so be sure to download it if you want to play Eschatology. It will not run in GZDoom.
CL-MeltySynth v2.2.0 and midi123 v1.4.0 are both now out. The notable new features in midi123 are:
- The parallel MIDI rendering that I mentioned before (which is a bit faster now, even). You can do something like "midi123 -s soundfont.sf2 *.mid -n" and it'll just spew out WAV files using as many logical CPU cores as you have. Or you can limit how much it does in paralle with the new --jobs parameter.
- Rendering to different bit depths (16-bit, 24-bit, 32-bit float, 64-bit float... and so on). Playback is always 32-bit float, however, due to a limitation in the cl-portaudio bindings.
- Clozure CL compatibility as an alternative to using SBCL. I don't suggest using Clozure CL to build it, however. Rendering Duke3D's "Stalker" to a WAV takes a SBCL build about 4 seconds, while a Clozure CL build takes about 37 seconds :-P
Also, midi123 is now a separate project in its own repo (linked below). There is a 64-bit Linux AppImage of v1.4.0 available on that link as well if you want a binary. It should work on pretty much any Linux system.
midi123 v1.4.0 announcement and source code: https://chiselapp.com/user/MistressRemilia/repository/midi123/technote/f068eff9dfe188fc9ea3948e17503c7d9d0d6796
CL-MeltySynth v2.2.0 announcement and source code: https://chiselapp.com/user/MistressRemilia/repository/CL-MeltySynth/technote?name=f5996dd68422709e4c80c5d87d47d890160064fa
Awww yeah! :D I just added support for rendering multiple MIDIs in parallel using midi123. It can render the entire Rise of The Triad soundtrack (34 separate MIDI files) to separate WAVs in about 13 seconds.
For the record, rendering these to WAV in serial takes 1 minute 37 seconds on my machine, so... yeah, nice speed improvement by doing stuff in parallel.
Also, some geekier stuff:Spoiler
Up until now, CL-MeltySynth and midi123 both required SBCL, the Common Lisp compiler/implementation I tend to use most often. It's known to be a very good Lisp implementation. But I've also added support for using Clozure CL (that's "Clozure" with a Z, not a J) since I sometimes use it instead of SBCL. Both compile Common Lisp code to native machine code.
Well, adding support for ClozureCL gave me a chance to benchmark the two implementations with actual real-world code, and so I did by rendering "Stalker" from Duke Nukem 3D to a WAV:
- SBCL (cubic interpolation, Zita-Rev1 reverb, soft clipping, TPDF dithering): 4.995071 seconds
- SBCL and using Freeverb: 4.138059 seconds
- SBCL and using Freeverb, no chorus, and linear interpolation: 3.831054 seconds
- Clozure CL (cubic interpolation, Zita-Rev1 reverb, soft clipping, TPDF dithering): 37.679654 seconds
- Clozure CL using Freeverb: 43.52037 seconds
- Clozure CL and using Freeverb, no chorus, and linear interpolation: 41.71585 seconds
- Unfinished Crystal port (Freeverb, no chorus, linear interpolation, no soft clipping, no dithering): ~3.7 seconds
Definitely a larger difference in compiled code speed than I expected :-P
That last one was merely a curiosity since I tend to use Crystal (think "Ruby-inspired, but compiled to native code with LLVM) whenever I don't use Common Lisp. I think I may actually finish my old unfinished Crystal port just because it gives me a really good real-world benchmark to use.
FWIW, FluidSynth tended to take about 2.9-3.2 seconds on my machine for this same file, and it uses something based on Freeverb for its reverb afaik.
Interesting. Never heard about Crystal. I guess programming languages are coders next favorite pet after frameworks. 😏
Crystal is a nice language, quite easy and fun to work with. And their compiler produces really nice native code, it seems. I helped out with the Crystal dependency manager/build tool called Shards not long ago by add Fossil support to it.
My only problem with Crystal is that I'm not sure quite how to fit it into my normal workflow. Crystal seems to be especially good for things like command line programs (which I normally do in Lisp) and web-based programs (which I almost never write, save for Matrix bots). So I haven't really found much benefit in using it over Common Lisp. But I keep hoping I'll find more use for it because damn is it a nice language to work with, and I find its syntax particularly pleasant.
Oddly, Crystal was the language that actually got me interested in Ruby and using it for things like Rakefiles and some other scripting tasks. Most people seem to go the other way, where they were Ruby users first, then became Crystal users.
Heed this warning!
With a drought of sacrifice comes Xala'noth,
Who will again beget the Goat Child.
With terrible strength it destroy those who do not give
And become a symbol of death once again.
The remaining souls, floating in the death,
will be devoured by shapeless Vordessa.
Bludgeoned and mangled between her thousands of teeth.
Then the cursed souls will be thrust
Into the acidic bowels of their new hell,
forever clawing at the flesh until their digits bleed in agony.
And then the Goat Child will die in its mother's smiling grasp,
Sleeping in death, waiting for her call once again.
This is the prophecy of our time.Spoiler
Don't mind me, i had a random idea for some flavor text for my personal mythology I keep reusing in my levels.
- Show previous comments 3 more
As long as you don't know of Xala'noth,
Xala'noth will not know of you.
But those who do not know Xala'noth
will be the first to die.
So wait, are you returning to Eschatology then??
Oh sure, it's definitely going to be finished. I'm just taking a break from mapping for a while to work on other things (though I am getting the itch to start mapping again...)
A little something I made tonight just for fun: connecting my CL-MeltySynth library to a MIDI editor through JACK to use it as an actual virtual synthesizer. Actually anything can be connected that can send MIDI data through JACK. The video goes up to 4k 60fps in case the text is hard to read.
CL-MeltySynth v2.1.0 and midi123 v1.3.0 are now released!
midi123 is a command line MIDI player written in Common Lisp that uses the CL-MeltySynth library. It can load MIDI files, RMI files, and SoundFonts.
CL-MeltySynth is a MIDI SoundFont synthesizer library with minimal dependencies written entirely in Common Lisp. It can be used to provide MIDI playback in any Common Lisp project with minimal dependencies.
chmod a+x midi123-1.3.0-x86_64.AppImage
and then you can run it like any other binary. You can then try
to see the command line arguments.
For source code, clone the Fossil repository and checkout tag v2.1.0
fossil clone https://chiselapp.com/user/MistressRemilia/repository/CL-MeltySynth/ && cd CL-MeltySynth && fossil checkout v2.1.0
Notable library changes in CL-MeltySynth v2.1.0:
- RIFF-based MIDI File Support: Also known as .rmi files, these are basically MIDI files wrapped in a special container. Some .rmi files also contain instrument samples, but CL-MeltySynth only loads the MIDI data.
- Added SYNTH-ACTIVE-CHANNELS: This method allows you to query which channels currently have active note-on/note-off messages. This is a bit rudimentary at the moment, but it works well enough for basic display information.
Notable changes to midi123 in v1.3.0:
- New Defaults: The default interpolation mode is now cubic spline. Also, looping is now disabled by default and can be enabled with --loop.
- Multiple MIDI Files: Multiple MIDIs can now be specified on the command line and will be played one after the other automatically if looping is not enabled. Or, when rendering, they will be rendered to WAV files with the same filename as the MIDI (e.g. foo.mid -> foo.wav). This should make bulk conversions a cinch.
- Volume Control: The new --volume argument controls the main output volume of the synthesizer. This is especially important for certain combinations of songs and SoundFonts (for example, Descent 2 Mission 2's song paired with the WinGroove SoundFont v1.2).
- More Information: More information is displayed regarding the SoundFont and MIDI file, including the length of the MIDI and the remaining play time.
- Reverb/Instrument Tails: When a song finishes, and midi123 is not looping, the reverb and instrument "tails" will now be played instead of immediately cutting off. This applies to both playback and rendering.
Ok, Prism-Stream (my 100% Common Lisp MIDI player) now shows channel note on/off activity, the next/prev commands are working, the "remove song from current playlist" command works, and has a skeleton file browser screen. There's even some live coding in the video because I realized while I was recording that I was drawing channel activity one line too high lol. Yay for Lisp.
So yeah, this is now usable enough that I can use it as a MIDI player while I'm playing Satisfactory or doing dishes :D I mean, I could just use Emacs + EMMS + midi123 for that, but that's not nearly as fun now, is it?
No release until the file browser is implemented, though. Right now you can only load up songs from the command line, and that's not ideal.
Also, CL-MeltySynth now has support for RMI files (RIFF-based MIDI files). I apparently have some of those in my collection, and I thought it would be nice if I could listen to them with Prism-Stream or midi123 :-P Any DLS data or other info in them is currently ignored.
me as of late:
Well, the next CL-MeltySynth update won't be as big as v2.0.0 was, and is still a ways away, but the midi123 example program it comes with will still have a few improvements:
- songs don't immediately cut off when not looping, so you'll hear the instrument and reverb tails
- The playing time is now displayed
- Volume control
- It'll now come as an AppImage!
I've also started work on Prism-Stream (the full-featured fork of midi123), but man has it been a while since I've done ncurses programming in Lisp... Gotta refresh what I know ^_^
The current draft of the NEWS file is here.
Also, testing this with the MIDIs I have has led me to firmly believe this:
Ooh, neat! That looks like fun, best of luck working on it.
Lisp has never been my strong suit – most recent thing I remember, I wrote a simple CLI program where you'd paste a matrix of dots and exes representing a Minesweeper field, and it'd reprint it with the numbers added for you. Useful when I had to make Minesweeper challenges for Discord! (Yes, I made a few of those.)
And yeah lol, re the image, those MIDIs definitely are neat! And quite a lot of notes.
Thank ya! Common Lisp is the language I'm probably most comfortable in since I've been writing stuff in it for so long. Not so much other Lisps, though, oddly enough. I think the things I've done in it that I'm most proud of are the ports of MeltySynth from C# (CL-MeltySynth) and the associated Zita-Rev1 from C++, a Doom utility called Dwaddle, a Discord library I wrote, and my Matrix bot/library. The rest was either done for work a long time ago, or is just stuff I've written for myself.
Anyway, last update for a few days, it's actually usable as a player now (though not nearly ready for release yet):
The bug is from the player, not the library. Something with how I'm doing the PortAudio handling or a buffer, I think. But at least the songs automatically advance (not shown), I can switch songs without pressing "stop", the playlist is being loaded from the command line, and my TUI library renders smoothly. Next up, a file browser screen.
CL-MeltySynth v2.0.0 is now released, along with its example command line player, midi123 v1.2.0. This is my port of MeltySynth (and Zita-Rev1) to 100% pure Common Lisp code. Source code repository is here: https://chiselapp.com/user/MistressRemilia/repository/CL-MeltySynth/
Changes in v2.0.0 relative to to CL-MeltySynth v1.1.0:
- A 64-bit audio path is now used internally to provide greater headroom.
- Selectable reverb types. There are four reverbs available: a port of Zita-Rev1, and three Schroeder-style plate reverbs based on Freeverb.
- Drastically improved SoundFont loading performance.
- Reverb parameters can now be controlled via the API.
- Tweaked the sound of all Schroeder-style reverb units.
- The chorus unit now obeys the interpolation mode.
- The chorus and reverb units can now be turned on/off individually.
Changes in midi123 v1.2.0 relative to midi123 v1.1.0:
- Greatly improved performance* - the block size was set incorrectly in previous versions.
- Removed the --block-size parameter since it was being used incorrectly.
- Added the --reverb-type parameter to select the reverb type. The default reverb is Zita-Rev1.
- Better PortAudio handling, buffer underruns should be fixed.
- Reverb and Chorus can now be turned off individually.
- Better memory usage.
Linux binary (x86-64, for CPUs released circa 2011 or newer): https://alexa.partition36.com/files/midi123/midi123-v1.2.0-x86_64.tar.bz2
What's next? I'm going to focus on some other things for a bit. There's some game engine code I want to keep working on, and I want to fork midi123 into a more full-featured program (rather than just an example program) with a curses-based interface and a spectrum visualization. I'm thinking of calling that fork "Prism-Stream" as a tongue-in-cheek reference to these fine ladies. Plus, you know... Doom mapping, assuming I can get over the stress, anxiety, and depression that's been keeping me from it :-P
* While not exactly an apples-and-oranges comparison (but not an apples-and-apples one, either), midi123 generally uses less CPU than FluidSynth, at least on my system.
Coming soon(ish) to CL-MeltySynth... selectable reverbs. There will be four available reverbs for CL-MeltySynth v2.0.0, three plate and one hall:
- The original Freeverb-based plate reverb.
- A very slightly tweaked Freeverb (using Freeverb3's all-pass filter calculations).
- A more substantially tweaked Freeverb I'm calling "RemiVerb". It's somewhat warmer and fuller than the other two Freeverb-based options.
- A port of Zita-Rev1, a (mostly) hall reverb that is, imo, a higher quality reverb than Freeverb.
You can hear a demo of the output with the new Zita-Rev1 code here (with purposely heavy reverb to show the results; SoundFont is some SC-55 font I have): https://www.partition36.com/random-stuff/human2-zita.opus
The reverb port isn't 100% finished yet, but it's producing output. I'll continue to tweak it a bit, as well as add controls for it, before release.
Speaking of controls, the reverb units now expose the API to control them in v2.0.0.
Aside from the reverb stuff, v2.0.0 will use a 64-bit audio path internally. This should provide more headroom while mixing things going forward since I want to add a few more audio features in the future. There's also the usual bug fixes, including one where I forgot to apply the interpolation mode to the chorus effect :-P
midi123 itself has drastically better performance now, with the program now using somewhere between 0.1% and 3.9% CPU on intensive songs. I was apparently setting the buffer size wrong :-P
So yeah, soon (^_^) The code is still 100% Common Lisp, too.
All tweaked, I think this is a good solid beta for v2.0.0. Performance takes a very slight hit when using the Zita-Rev1 reverb, but that's to be expected due to its different design. I'll continue testing it and release it within the week.
Demo song with all the new bells and whistles (full cubic interpolation + Zita-Rev1 reverb + 64-bit internal audio path):
The midi123 example program is getting to be a bit hefty for an example program, so I'll probably not add anything else to it going forward. Instead I'll fork it after this, add a nice optional ncurses interface, and create a more full-featured command line player.
That feeling when you fix a bug in code that has eluded you for over a year :')
I finally tracked down a bug in that CrDoom source port (a port of Managed Doom to Crystal) I started a while back. It turns out it was just a typo, where I typed FRAC_TO_BLOCK_SHIFT instead of BLOCK_TO_FRAC_SHIFT, which looks almost identical to my eyes. I also found the bug where, if the player shot, they would shoot themselves. So yeah, Doomguy finally stopped punching himself in the face.
Maybe I'll actually get this source port in a playable state this year :D
In related news, I ported MeltySynth to Crystal as well. Technically I started my Crystal port of MeltySynth before I started on my Common Lisp port of it, but I ran into issues with some bugs that I had trouble tracking down, and so I started the Lisp port instead. Now both are working and are in-line with the original C# code by Sinshu, plus a few extra things I ended up wanting. I'll keep the related midi123 command line player I wrote in Lisp, however, since it's a good example program. Anyway, I'll get MeltySynthCr released this week.
I actually do this fairly often, where I do something in Lisp + some other language. It usually helps since I can prototype and find issues in Lisp code faster than in something like Crystal just due to its nature, and it's nearly as fast as something like Crystal or C in most cases anymore. So often times, if I'm running into issues, I'll do it in Lisp first, work out the issues in an abstract way, then do it again in Crystal or whatever I'm programming in. It probably helps that I tend to write procedural and OOP stuff in Lisp, and not much functional stuff.
iirc, Ken Silverman does (or at least used to do) something similar, where he prototyped stuff in QuickBASIC or something like that.
Interesting that Lisp doesn’t get in your way even if you don’t program in functional style. It’s such a powerful paradigm.
It is... but Common Lisp is a bit different than, say, Scheme. Once I embraced the idea that Common Lisp really was meant to be a multi-paradigm language that lent itself well to OOP and procedural stuff (plus good functional support - it is a Lisp, after all), I finally managed to be productive in it. I use functional stuff occasionally, for sure, but probably not as much as other Lispers.
CL-MeltySynth and midi123 v1.1.0 is now released! This update adds selectable interpolation modes (linear, the original mode; and cubic spline), as well as some minor performance improvements. You can select the interpolation mode that midi123 uses like this: "midi123 -s mysoundfont.sf2 -f mymidi.mid --interpolation cubic". Or replace "cubic" with "list" to see available modes. I may add additional options in the future.
Source code repository: https://chiselapp.com/user/MistressRemilia/repository/CL-MeltySynth/
Linux binary (x86_64 only): https://alexa.partition36.com/files/midi123/midi123-v1.1.0-x86_64.tar.bz2 (sha1: c7a4ec06d19ea9028dd84c50abb74cd38c49d9ce)
v0.2.0 of my CL-MeltySynth library (and its example program, midi123) is now up: https://chiselapp.com/user/MistressRemilia/repository/CL-MeltySynth/
- Pitch bend fixed.
- RENDER-* functions now return NIL if whatever is using them should stop playing, or T if they should continue.
- midi123 supports rendering to WAV files.
- midi123 now has a --no-loop parameter to disable MIDI looping.
Preliminary Linux binary for the midi123 example program: https://www.partition36.com/random-stuff/midi123-0.2.0-x86_64.tar.zst
Notes about the binary:Spoiler
- Your mileage may vary with the binary since it's compiled for recent-ish CPUs (Sandy Bridge, so 2011ish and newer). I don't really have any sort of infrastructure in place at the moment to build for other OSes or CPUs, and Lisp is a bit different from things like GCC in how it compiles native code ^_^
- This was built on Slackware 15, which has glibc v2.33
- You'll need PortAudio and zlib libraries installed.
- I tested this on Ubuntu 20.04 and found the glibc was too old, so that one won't work.
- I also tested this on Ubuntu 21.10 via QEMU and it worked fine after I installed PortAudio (sudo apt-get install libportaudio2).
- Do not strip the binary, you'll break it.
So I've been taking a break from Doom. In the meantime I've been working on something for fun: a port of Sinshu's excellent SF2 MIDI synth MeltySynth to Common Lisp.
There's still a few bugs to iron out, like the timing and a few bits of audio, but I can at least recognize the MIDIs I send through it :D I have reverb and chorus purposely disabled in this video since I haven't finished getting the code working for those yet. I'm using the TimGM6mb.sf2 SoundFont in the video.
The synth code is 100% pure Common Lisp, and quite unoptimized right now. I'll post code next week after some fixes to the timings and audio, and some optimization. I also want to add an option to redirect unknown bank/patch combos to the default banks since most of my MIDI files are modified to use specific banks to playback on my old JV-1010 correctly.
Oh, and the comment about the "SDL Library" in the video is an error. I use some PortAudio bindings to play back the rendered audio right now.
- Show previous comments 2 more
That’s so impressive! 🤯 I couldn’t figure out Lisp so far. Nor MIDI. 😵💫 Lovely hobbies you have… 🙂
Source code is up: https://chiselapp.com/user/MistressRemilia/repository/CL-MeltySynth/index
And a video for v0.1.0 (which now has chorus and reverb and proper timing):
I'm away from home and stuck on a bargain bin laptop for up to a week currently. So, to pass the time, I've decided to do a study where I do a map for Doom in vanilla format in just one week. The catch: the map will be done entirely in Eureka.
Got this concept area hammered out last night to establish a bit of a visual theme.
I unfortunately also did not have my mouse with me last night, and so this was also done just with a touchpad and therefore took longer than I wished ^_^;
Yay, another year of Doom! The Cacowards are top notch as always, and the winners are all very deserving of their awards, so congrats to them ^_^
For me, I did a lot more with Doom than I normally do this past year. Oops! All Greyboxes! was released, as was The Unending and Freaky Panties IV. Then I also finally finished up my in-development-for-25-years megawad Kill. That was something I had been working on consistently in small increments here and there. Thanks to a friend poking me to finally finish it ^_^
Of course I also found Wadazine. That place has become a home for me, and I am SOOOO thankful to be there. I love working with everyone there, especially on the Wadazine Master Collection series, which will see FOUR releases this year! Insane. Those maps are always a blast to play and putting together the resource packs is always fun. And WMC means another four maps from me - again, a lot more with Doom than normal XD So yeah, check out WMC01, WMC02, WMC03, and WMC04 once it's released very, very soon.
This month I'm having to take an extended break from Doom due to some family health issues. Not mine, but a close family member will be having a major surgery and has been needing my help during the lead up, and will need more help afterward.
The Eschatology series will see its first release next year for sure. I'm still turning it into a series of individual maps instead of more episodic releases, but I did decide to go ahead and keep the hub idea for the first release just because spliting up my development tree was too much work for too little gain. Each map will just be added to that as I go, then. Kind of a compromise between what I originally intended (larger project with packs of 4-5 maps released once every year or two) and what I mentioned in my last major status update (all concise individual maps released as they're finished, each one a small project).
Speaking of "development trees", I seem to have standardized how I manage/structure my projects. I need to do a write-up on that sometime, because having a set structure has really made it easy for me to spin up a new project quickly. Kinda along the lines of the practice of having "src" and "doc" folders together with a Makefile/configure script for programming projects. Things like reusable ACS libraries for common things I do in every map, a standard set of folders and tools, consistent versioning rules, that sort of thing. Call it an early initial foray into "Wad Engineering" (like Software Engineering), if you will. Just a concept I'm tinkering with that I think may help others.
Anyway, happy birthday to Doom! Go eat some cake.
PS: Don't forget to join my Matrix server.
I find this interesting and inspirational, as I've been going through some fairly similar mapping process issues, but from a different position - I have a lot of half-finished maps floating around and not a lot actually released, so my task is to try and start releasing stuff. I've been pleased to be able to help significantly with K8Vavoom's development though.
I had a foray into mapping for Quake and for Arcane Dimensions, inspired by Ben "Makkon" Hale's textures, but eventually figured that it would take longer to create maps in full 3D, and it would be tough to get close to the level that the Quake community is currently doing. I also surprisingly found that there were features of K8Vavoom that I couldn't easily get in Quake. But I think it's been useful, as Arcane Dimensions and Dimensions of the Machine have given me the idea of having a central hub map with sets of 1 to 3 maps branching out from it, and gradually expanding those over time, rather than full episodes or megawads, which I think had been too overambitious and had held me back. Your plans for Eschatology resonated with me and reminded me of this.
Good luck with the family issues, especially the surgery.
Time to rethink some things!
I think I'm kinda at junction in life. I recently got some mental health diagnoses* that have really gotten me thinking about how I approach my mapping hobby. Specifically, I'm thinking that large projects like Eschatology, Umbra of Fate, or SoTNR are just a bit too much for me to handle anymore. Even if I do complete them, I'm left feeling incredibly drained and it takes me forever to recuperate. They just aren't fulfilling and I don't feel that they're a good fit for me or my mental issues.
So from here on out, for the foreseeable future, I think I'm mainly going to concentrate on individual maps. Things like my Freaky Panties series, or WMC, or my one-off maps like The Unending or Halls of The Goat Child. All of those have been far more fun and rewarding to work on than any sort of large project. In a way it makes sense, too. If I consider the maxim "build what you want to play", then long huge projects aren't what I enjoy playing. What I enjoy playing are concise 10-25 minute long maps, bite sizes pieces of gameplay and artistic expression that leave me satisfied yet unburdened by obligation. That's what I enjoy most playing when it comes to maps (Doom and Quake).
Eschatology, while not exactly the antithesis of all that, doesn't really align with what I enjoy. It's a large project with multiple levels, a hub, and a story that further extends my personal Doom cannon. It's not bite sized pieces, it's long and (potentially) never ending. To put it bluntly, it's not what I want to do. Buuuuuut... I still like and am happy with Eschatology. Heck, I very proud of what I've done with it so far, as it's probably some of my best Doom work ever. It's just that it's turned into an odd dichotomy for me. So is there a way to reconcile this dichotomy? Well, I think there might be, actually.
Freaky Panties started off as a single one-off map. It was just an experiment, a short "let's see what I can do in one month's time" combined with an idea for how to do a dynamic difficulty system. Then came Freaky Panties 2, which had a similar theme (techbase), a short development time, and continued with experimentation (this time more backend/workflow stuff). Then I joined WMC and made Freaky Panties 3: Spooky Panties for WMC01: The Rising. Again, it was techbase + experimentation + short development time ("make a map compatible with both GZDoom and K8Vavoom" specifically). Now there's Freaky Panties IV, which will be released this month and continues with the trend of techbase + experimentation + short development time. It has, effectively, turned into a mapping series, and since they're all the exact kind of bite-sized concise maps that I enjoy, it's a mapping series that's been immensely fun and rewarding to build.
So... why not do the same with Eschatology? The levels are already "separate" in a sense. The way the game unfolds currently is just like in Arcane Dimensions, where you have a hub that you use to select any level in any order, and each one is a pistol start. It's basically a mapping series... digest? I guess? But with extra steps. So why not take out the extra steps and just turn it into an actual mapping series? I can still have its overarching backstory for flavor (slightly adjusted now so that it's less confusing; thanks to those who have given me feedback!). You can still play them in any order. I can still use all the same resources. But rather than it being inflexible, where I try to shoehorn it into some awkward idea of a "digest" of maps every year or so, it becomes more fluid.
So that's my plan. Eschatology as a mapping _series_, with individually released maps utilizing a common theme. They'll all feel and play similar (just like Freaky Panties tends to feel similar between maps), they fulfill my desire to create concise one-off maps, and it relieves the pressure of managing a huge Doom project.
And of course I'll continue to head up the WMC series :-P That has been incredibly fun, and has also been a wonderful learning experience since it's successfully brought me outside my comfort zone.
Side Note: On a technical side note, I think as far as my own levels go, K8 and Doomsday will be the ports I target anymore. I find them easiest to work with, and they have the features I want. And they deserve some love <3 So I'll likely be reworking some of my past stuff, like the first Freaky Panties, for K8 in the coming months as well.
* If you're curious, I was diagnosed with Paranoid Personality Disorder, as well as something sorta like PTSD.
- Show previous comments 2 more
Following your creativity, I have always been amazed at your productivity and innovation. Until now, I have not played your largest projects, but I tried to match their quality, taking screenshots as samples. Recently, I burned out so much that starting a new map became a psychologically difficult threshold, which caused the skipping of all very promising projects of this year (RAMP, WMC series, etc), and places that could previously be done in a few days now stretch over months. Mapping has ceased to be enjoyable at any stage, and I don't even know what I will do with it...
Perhaps it is in your new works that I will again be able to find some kind of impulse to creativity. Maybe I will even overpower myself and join WMC. Take care of yourself and keep creating. I always be glad to see new stuff from you!
You'll never see me complaining about excuses to load up K8 or Doomsday.
After sitting on it for ~25 years or so, I suppose it's about time I finally finish up and release the Doom project I started back circa 1995/1996.
So, coming very soon: Kill - A previously unreleased megawad I did as a teenager for Doom 1, in all its mid 90s glory.
I went ahead and did a refresh of my homepage today. It's something I've been planning for a while, and today seemed like a good day to get it all done. My Doom and Quake levels now have individual pages rather than all being on one long page. I also cleaned up my programming page quite a bit, and made a few other visual changes. Soon I'll be adding some other Doom projects that I never have posted on it.
A little something I've been working on for about a month now... CrDoom is my own source port of Doom to the Crystal programming language. It's based on Managed Doom, but is using a basic OpenGL renderer that's based on my CL-DoomView program.
It's obviously far from finished, but the gamesim is partially working, and enough gets drawn that you can at least get around the levels (and die).