WadC 2.0 Now available! Featuring WIP CLI!

[Jon]

EDIT
It's done! http://jmtd.net/tmp/wadc-2.0.zip featuring a tech-preview command line interface!
release notes!
massively revised reference!

demos:

pipeloop.wad, a looping sewer with Boom deep water (sources: pipeloop.wl, water.h) (and yeah, I've spotted the flat/floor bug, it will be fixed)

llevels.wad, a light-level demo map, picture, source

up2/usepipes/pipes, a 9-year old unfinished underhalls tribute, and sewer.h, another one.

end EDIT

Hi, it's been a while (four years!) but I'm preparing to release a new version of WadC. Right now there is some stuff in the github repository but I will probably get a "rc1" binary release zipped up for testing.

New stuff:

• new unfinished tutorial on how to create a random dungeon like a game of D&D or Warhammer Quest
  
• "lisp" lists turned from an example into library code
  
• new builtin die("reason") which terminates processing (might revert this one)
  
• new builtin cat(a,b) to concatenate two things
  
• new builtin seed(number) which seeds the RNG to allow reproducible builds
  
• texture generation!
  
• WadC runtime is now distributed as a JAR file
  
• wadc.cfg is now loaded/saved to $HOME/.wadc , where $HOME might be C:\Users\Yourname or /home/YourName/.wadc
  

Fixes:

• fix zooming in/out of the 2D view with mouse buttons on non-WIndows systems
  
• I'm probably going to hardcode the window size to larger than whatever it defaults to
  
• BSP and doom launching code handles spaces etc. in filenames much better
  

More on texture generation. You can define a new texture and add patches to it like this

   texture("name", 64, 128)
   addpatch("RW24_2", 0, 0)

New textures will be written out in a TEXTURE2 lump. If you refer to a patch not in the IWAD's PNAMES lump, then a new PNAMES will be written out too.

I used this to generate textures with numbers on them for a colormap experiment:



(wadc source for that map)

If anyone uses this, has feedback or feature requests, I'd love to hear them. Features I hope to finish for this release:

• I'll commit my largish unfinished MAP02 tribute
  
• hopefully library code for encapsulating complex boom conveyor stuff, broken out of the above. (didn't want to bump this thread just to say "yes, yes you can.")
  
• new blockmap library code for avoiding overdraw
  

[Jon]

And whilst I'm not bumping old threads, printz asked about editing WadC without the GUI.

At the moment, you have to at least launch the GUI. That might change. (it's all very tightly coupled together at the moment unfortunately). However there is trick you can use to have a nice editor for your map code.

The trick is to have (at least) two files: one that you open in WadC which has something like this in it

#"realmap.wl"

You then put a realmap.wl in the include directory and edit that with a real editor. When you rebuild the map in WadC, it reloads any files that are marked for inclusion.

[Mithran Denizen]

I'm happy for an excuse to take WadC for another spin! I've had fun toying around with it in the past, but never even tried to make a 'playable' level yet.

[Jon]

I'm considering reworking wadc to run out of a jar, but it's quite a big change so I'm not sure.

At the moment you get a big bundle of the source and compiled classes in one, and the wadc examples and includes, all in the same directory structure. The code is very sensitive to your current working directory, which is why the .bat file does "cd src ; java MainFrame" - the config file is read or written within src, and includes are resolved via "../include".

That's all a bit messy, but one upshot is, you are quite close to the source at any time. When you're hacking on a level, you can hack on the include files too. I quite like that, and I quite like the idea of people contributing their levels and changes back to wadc as easily as possible.

But I have seen people be confused by the Makefile, by how to launch it, etc. Doing it in a JAR means

• one-file, one-click run portable app
  
• have to embed includes in the JAR, so not as easy to read them
  
• need to rework where the cfg file is read/written to
  
• source not included/adjacent to the binary
  

Thoughts?


EDIT:

OK JAR-ification is mostly done. Wow, Java is weird. Some parts are quite nice, others are seriously moth-balled. The getResource crap from JARs/classpath is one of the dusty parts. A bug in my handling of that shit stopped me getting an RC out tonight, but hopefully tomorrow.

[fabian]

Hey Jon,

what I've never really understood is if you take WadC as an academic excercise / proof of concept or if you really consider it as an alternative way to algorithmically build Doom maps?

- Fabian

[Jon]

OK! I've built a release candidate ZIP, here it is
http://jmtd.net/tmp/wadc-1.3rc1.zip

The major changes are that it's now distributed as a JAR - the include are bundled inside it, so you can copy/move the JAR around and run it from anywhere.

When you use "include" in a wadc file, WadC now first looks in the directory that your source file lives in to resolve it - so if you are editing c:\doom\foo.wl and you use #"standard.h", it will first look for c:\doom\standard.h. So you can write your own headers or override the "system" ones on a per-map basis.

If it can't find it in that location, it falls back to checking within the JAR.

The wad.cfg file is now written to $HOME/.wadc/wadc.cfg, which on Windows is likely C:\Users\You\.wadc.

If you use the new texture stuff, you need to make sure that you've specified the correct path to an IWAD In our cfg file. WadC doesn't provide a way for you to specify it in the tool itself (well, you can write iwad("path") in the GUI and run it and that works, at least for now). If you don't, you won't be able to write out a WAD for any levels using the new texture stuff. This is because we need to read the PNAMES lump. I might bundle it with the JAR in future.

There are quite a few more example levels in the ZIP now, but I need to do some clean up.

There are still issues around zooming in/out of the preview window and I need to do a lot of work on the docs.

fabian said:

what I've never really understood is if you take WadC as an academic excercise / proof of concept or if you really consider it as an alternative way to algorithmically build Doom maps?

The latter, honestly. Take a look at one of map02.wl / pipes.wl to see an example of a reasonably complex, "real" map I was working on. There are obviously some serious drawbacks compared to a traditional level editor, but it has some great strengths too - so there's a balance. It certainly won't replace a traditional editor, but I think it can complement them. Some of the BOOM 242 stuff I've abstracted in the pipes/map02 level would be a massive pain in a traditional editor. (I say pipes/map02/_map02 because they're all different generations of the same map, pulled out of backups, and I haven't consolidated them yet).

I also find it useful for quick test maps, especially if they involve a lot of repetition. Take al look at "llevels.wl", both the light-level ramp and the custom textures would be a massive pain to do by hand (I know, sadly - I did the textures by hand before I finished implementing the feature :))

However, I believe much more strongly in the concept than the implementation: I've tried to avoid doing a great deal of work on this, because I'd actually like to replace it with a different implementation. I'm considering something similar written in Haskell.

[VGA]

Interesting. If you make the launching code use quotes on file paths it would save me some time, because now it screws up in BSP building and launching when the path has spaces.

[Jon]

VGA said:

Interesting. If you make the launching code use quotes on file paths it would save me some time, because now it screws up in BSP building and launching when the path has spaces.

Yeah that should be an easy fix. That might even explain why running BSP from WadC has never worked for me :)

I'm probably going to re-christen this WadC 2.0., so I'll fix the quoting and put out wadc-2.0rc1.zip with that fix in it.

[Jon]

OK! Here's WadC 2.0 RC1. New from above:

• reworked the bsp and doom loading code, it should now work with files in paths with spaces (except of the doom engine command which still is vulnerable to space issues, will be fixed before 2.0 final)
  
• new built-in 'seed' to set the RNG to a specific value and make predictable builds (see pipes.wl for an example of how it works)
  
• started to update the docs
  

Oh, and the complex level I talked about to Fabian (pipes/map02) wasn't in the distribution, I haven't re-found it again yet!

[jmickle66666666]

feature request: defining extra wads to test with, in the code. So i can set up a path and it will add it to the test path, for ease of use with texture packs etc.

[Jon]

jmickle66666666 said:

feature request: defining extra wads to test with, in the code. So i can set up a path and it will add it to the test path, for ease of use with texture packs etc.

OK! This is actually half done already, aardappel did have three config variables for texture wads but the code didn't do anything with them. It will be easy to plumb them into the doom call.

At the moment you could try hard coding them into your doomcmd value after -file

Care must be taken if you simultaneously rely on texture wads and try defining textures in your wadc code.

(Eventually the doom call will be very flexible, like a string with placeholders which have the iwad substituted, or the wadc wad, etc)

Edit: done, if twad1-3 are defined, they are put into the doomcmd.

EDIT: coming in the next RC, I've split doomcmd up into doomexe and doomargs. doomexe shall just be a path to your preferred port executable, which can therefore include spaces etc. doomargs are the arguments to pass to it, which will be split on whitespace, and should end with -file.

[Jon]

Last bump! Final release imminent, last RC (66666666) link in the first post. The best place to read what's new is the release notes, but of note and not yet mentioned in this thread

• boom deep water helpers (did I mention that?)
  
• embedding the WadC code in the WAD itself!
  
• newtag helpers, library routines, RNG fixers,
  
• a big pile of unfinished shit that I found in backups of backups from 9 years ago
  

[jmickle66666666]

<3

[RestlessRodent]

Before you do your final release, you should put your code in its own package rather than the default package. This would make it easier to potentially include it in other projects and such.

[Jon]

GhostlyDeath said:

Before you do your final release, you should put your code in its own package rather than the default package. This would make it easier to potentially include it in other projects and such.

That's a great idea... but I've just pushed the v2.0 tag and built the ZIP! So I'm too late to see your post. I'll do that for 2.1, which won't be as long a wait as this release was. (I expect the CLI to evolve pretty fast.)

Temporary Zip URL (for the binary release): http://jmtd.net/tmp/wadc-2.0.zip

Sources at github as usual

Oh, one last thing...

I put a first-cut, alpha, tech-preview WadC CLI in there