pouët.net

reeto: er, wz3 is not farbrausch only, actually. :)

decipher: what do you mean? clearly you must be confused, because this is actually the best coding style evar.

nicestep: what's looking uselessly complex? the file list? :)

ryg: let's fight over this at tUM or breakpoint! I claim 2 spaces per indentation is completely heretical! :P

For whatever it's worth: Seeing the s-prefixed type-names gave me some warm feelings... :-)

they stand for Sanity as far as I know, a long-running tradition of Chaos' from the Amiga times :)

Sanity Class Library to be exact..

I still have a copy of it somewhere on my HD.

Fun fact is, that the lib (which was written by chaos) actually does not contain that much classes. Instead it conained replacements for each and every c standard-lib function that you may need.

sMemCpy, sMemSet ect... That was fun...

decipher, seriously, that's it? sheesh.

and of course, the s stands for schtzngrmm.

Die "FR-guys" hab'n doch alle "ein' am laufen" .. oder nich' ^_^ ?! .. den "UBER-VEKTOR" hab'n die doch auch .. oder ?!

exactly, the file list :p

oh well at least it gives you the usual coder excuse to go get a coffee/smoke: "It's compiling" :D

Awesome - chinese software pirates on pouet.

Nicestep: Wz3 compiles in about 1 min on my old 2.2GHz Athlon X2, far less on my current laptop (2.4GHz Core2Duo) and less on my "big" machine still (Quadcore). That's rebuild from scratch, including 3 different player versions (intro, demo, kkrieger) and a bunch of "associated" projects (shader permutation generator, image codec used in "of spirits taken" and "malpasset").

Complexity is relative - considering that Wz3 contains the collected code for >15 releases between 2003 and 2009 (candytron, kkrieger, theta, basso continuo, debris, precision, of spirits taken, platinum, 828, gravity of the moon, disintegrates, momentum, tonikum, euphotic, human sources, id08, patient zero, project: snowblind, and i probably still forgot some), i'd say the whole thing is in pretty decent shape. sure there's lots of stuff, but that doesn't necessarily mean it's more complex. for example, there's two mesh generators, one pretty full-featured one that was developed for kkrieger, and the smaller "minmesh" (minimal mesh generator) used in the wz3-based 64k intros. the two coexist, you can use either of them, and both ultimately result in a list of vertices and indices annotated with material/shader definitions (which is what we want for rendering no matter what, even when not using a mesh generator at all and just loading files from disk). the rest of the code doesn't have to care about which it is, so there's very little extra complexity from having two, even though there's lots of extra code, obviously.

and wz3 has lots of stuff that exists in multiple variations. there's the "old" material/lighting system (used in kkrieger and theta, pixel shader 1.x level), the "new" material/lighting system used in debris (ps2.x), and an even newer one that was used in momentum. there's the old image postprocessing system (used from candytron onwards, only requires dx7-level hardware) and a new one (first used in debris, actually using pixel shaders and non-power-of-2 textures, woohoo). and then there's this whole simplistic fps game in there, too. :)

it sure is a lot, but then, what do you expect, the project had two coders actively working on it in a lot of their spare time between 2003 and 2007 (after debris we started "phasing out" wz3). other coders have project directories with 200 things started within 4 years, we have one project with 30 subprojecs actually finished within 4 years, i'd say we did okay. :)

My engine/editor consists of 1045 files. (excluding third party libraries).

then if it were GPLed, you'd have spent about one sixth the amount of space on boilerplate license conditions that we spent on werkkzeug3 source code!

a-ma-zing.

ryg, you could be really proud of the done work. it does not matter how long this takes. very cool work 4 sparetime project :). the result the so called wz3 is a very strong & effective tool.

the idea behind is innovative, and i am looking forward whats coming up in the future.

cheeRs & thx

:) lexxy

wz itself is an amazing piece of software and its even more impressive that you did in your sparetime. not to mention the fun stuff you have made with wz. I would really like to know your secret how you produce this much quality in sooo little time?

little time? not really. after all, the werkkzeug "lineage" goes back roughly eight and a half years now :)

im coding away on my wz program and I'm only seeing the tip of the iceberg. fr-08 was made with a very early version of wz, which must have been around 1 year old at that time. That is c.r.a.z.y and made in a very short time. so yes, lots of quality in short time.

fr-08 wasn't made with werkkzeug at all. the fr08 tool was called "generator" and the whole thing including content was done in about 3 months, give or take a few weeks (started around october 2000), with code nearly completely written by chaos (doj contributed a bit too, but that was later). viruz2 was also designed by kb in the same timeframe, with the actual coding (gui+synth) plus the fr08 tune done mostly within two weeks.

interestingly, in retrospect, neither chaos, fiver2 nor kb have the slightest clue how the fuck that worked out :). nowadays we're happy when we get a serious production done within 6 months, and that's with tons of infrastructure working from day one.

lets hope you find the secret recipy again :-)

kind regards
a devoted fan

"and that's with tons of infrastructure working from day one. "

could it be exactly that? I mean, with more infrastructure there's sometimes less time spent working on the actual thing and more time spent on finding a way to make it with the given tools.

Also, first projects are usually way more interesting, since it's a whole new world you're discovering.

or it's just a question of available free time. i'm sure you'll get back into massive producing once the kids have left the house :D

that's not the kind of infrastructure i mean; i'm talking about stuff like window creation+message loop, vector/matrix math libraries, 3d api initialization, resource management, music playback (v2m/mp3/ogg/whatever), gui framework for the tool(s), mesh+animation exporters and importers, and so on; on a slightly higher level, none of us want to ever work without at least a rudimentary texture generator in our tools again - we tried skipping it, but it sucked; the ability to just get test textures on the fly into everything without writing even one line of code is an enormous convenience.

all stuff that's at a higher level than that, we'll change upon starting a new project when we feel the old code pushes us into the wrong direction. that's precisely why we have multiple texture generators, multiple mesh generators, multiple material/lighting systems, and so on. this is precisely how this kind of stuff all starts to accumulate over time :).

anyway, at some point a lot of the basic stuff needs some radical cleanup too; partly due to our long-term focus on size optimization, a lot of the low-level code in our older projects up to and including werkkzeug3 was far less flexible than it should've been, because the extra flexibility comes at a size tax we weren't willing to pay (the alternative of having tool and player use different low-level systems and different code is something both chaos and me independently tried earlier, and it's even more unattractive). in short, even though the modularity aspect works out pretty well, there's still a significant amount of code rot because the underlying landscape keeps changing (it certainly did over the course of the last 6 years!). and, as with every project, there's some design errors you make that tend to annoy you more the longer you have to live with them. that's why there's several different werkkzeug versions with no direct continuity between them.

that's also the main reason why chaos and me both lost our interest in doing size-optimized stuff: when we started wz3, ps1.x cards were starting to get a solid hold on the graphics market, but it was all 8-bit RGBA with poor precision, so CPU was pretty much the only choice for rendering textures; nowadays you'll use the GPU (and who can tell where the development of CPUs and graphics hardware will take us within the next 6 years?). for the ps1.x cards we were targeting for kkrieger, shadow volumes were the only viable choice (no hw support for shadowmaps on non-NV ps1.x cards, and NV was just starting to seriously suck at the time, these were the GF5 days), nowadays shadow maps are a much better deal; the way you write postprocessing code has changed a lot (for the better) with the wide availability of ps2.x cards and non-power-of-2 texture support; ps1.x shaders were so limited you basically had to write them in asm and maybe change individual instructions if you wanted to multiply a detail layer instead of adding it, so that's what our material system did at the time; ps2.x was still asm-centric but basically a shader fragment linker; nowadays you'll just use static ifs and let the hlsl/glsl compiler handle the rest. when we started, multiple cores weren't a serious concern, now they're a given (and while the basic operator design leads itself quite well to parallelization, if your system wasn't intended to harness the fact, that's a lot of work coming your way). there's tons of things like this, and all of it is maintenance intensive. now you can make code that's easy to maintain or you can make code that's optimized for minimum size, but both at the same time just doesn't work. as a result, the wz3 code is (in parts at least) harder to maintain than we'd like while at the same time being much bigger than we'd prefer.

with the state that 64ks are in right now, that's really a no-win situation; these projects are (by far) big enough for us to not want to start from the basics every time, but the environment keeps fighting back by changing just enough between releases to require structural modifications that are very hard to make to code once you've done an actually size-optimized intro with it. the last straw for me was most virus scanners now flagging any kind of compressed executable as probable trojan; no thanks, i don't want to keep running after AV vendors and re-checking every three weeks to make sure people can actually watch my intros, not on top of all the work they take in the first place.

so now we're working with code that's a lot easier to maintain, we don't have any of these weird problems you only have if you're targeting for 64ks (like not being able to use lots of precompiled hlsl shaders because of their size), and if some code sucks we can just throw it away and redo it without having to spend a few days with boring size optimization work just to make sure we're not worse off than we were before.

end of rant. for now! :)

That's a nice seminar'ish post ;)
Please continue :)

Ryg: all of this just makes me think you're covering for the fact that you're cooking up something small and amazing.. :)

everyone should start making 64k business apps and i'm sure you guy's would get noticed.

64k is not enterprisey enough for business

that is the challenge. convince people not to be stupid.