timmie Posted February 27, 2003 Ok, this is going to be a feature that's purely for the mappers, although I'm sure the people playing will appreciate it :) After exchanging some emails with Kurt Kesler, he's got me all gung-ho about enhancing the ANIMDEFS lump. Basically, I'm going to be adding a new lump ("GLANIMS" or something) that will override entries in the ANIMDEFS lump. The new lump will allow for some impressive new effects, since it's (hopefully) going to be quite similar to the Quake3 shaders. It's going to be built around multitexturing, or texture layers: - each layer will be able to have it's own rotation, movement, etc - specify blending modes per layer - specify a detail texture for the surface - texture coordinate generation (ie: sphere environment mapping) Since it will only override entries in the ANIMDEFS lump, it'll be backwards compatible with the software engine (you just won't see the fancy effects in the software engine). In the future this could be expanded to include such things as bumpmaps, but we'll see. Anyway, I'm hoping to have the basic structure implemented for version 0.8, to coincide with md2 support (so the release will have something for both the gamers and mappers). Any comments/suggestions? I haven't even started on the spec, so I'm even open to suggestions for the syntax. 0 Share this post Link to post
Fredrik Posted February 27, 2003 IMO there should be a single new lump for anything textures. It should be in plain text format, override TEXTURE1 & PNAMES, contain all info about textures including size, resolution, high-res (alternative paths), animations, etc... 0 Share this post Link to post
Linguica Posted February 27, 2003 This is completely irrelevant, but it would be cool if you added shadow mapping for sprites so they cast shadows on the level geometry, heh. 0 Share this post Link to post
timmie Posted February 27, 2003 Linguica said:This is completely irrelevant, but it would be cool if you added shadow mapping for sprites so they cast shadows on the level geometry, heh. I've thought about doing that, actually (with projective textures) :) That'll probably be on the list of "things to look at after 1.0"... 0 Share this post Link to post
Enjay Posted February 27, 2003 The GLANIMS idea sounds very interesting. I can already think of a few things that I could use it for. Would something like the Quake style warping wall effect (like the water) be possible with this? Making it override the ANIMDEFS lump also makes sense too for the reasons stated. In fact I can actually see an argument for making it essential for there to be something in an ANIMDEFS lump that then gets modified in the GLANIMs (maybe helps ensure the level works in software mode) although working between 2 lumps could get clumsy. Mind you, we manage with SNDINFO and SNDSEQ or dehacked etc. 0 Share this post Link to post
timmie Posted February 28, 2003 Well, it wouldn't actually use the data from the ANIMDEFS lump, it'd just override the name. So if you had an animdef with the name "texture tex1" then you could override that tex1 in the GLANIMS lump, using completely different textures. You could also override flats the same way, I guess. Right now I'm thinking of this kind of syntax:texture animname //override "animName" in the ANIMDEFS lump { detail texName // name of detail texture layer texName { blendFunc mod // blend mode (mod, decal, add, etc) warp // quake style warping } layer texName2 { blendFunc mod vector 0 1.0 // movement vector (units/second) } layer texName3 { blendFunc add texgen sphere // environment map this } } 0 Share this post Link to post
Ed Posted February 28, 2003 Multiple blending modes for layers. Additive, for example (projectile sprites use this, I believe). 0 Share this post Link to post
timmie Posted February 28, 2003 Ed said:Multiple blending modes for layers. Additive, for example (projectile sprites use this, I believe). That would be the blendFunc field :) 0 Share this post Link to post
guru Posted February 28, 2003 I was wondering if you might consider using xml syntax? I'm a coder myself and I got quite nice results with xml as you automatically get very nice error checking and error info. still its taking quite some time to set up but it should be worth the work eventually on a sidenote. you still interested in a stand-alone 2xsai implementation? I'd REALLY love to see texture upscaling at runtime timmie. really ;) 0 Share this post Link to post
timmie Posted February 28, 2003 Hmm, I think XML may be a little bit of overkill for this. Plus, I'd have to find a parser and get it to work with ZDoomGL when there's already a parser for this sort of syntax in ZDoom (or close to it, anyway). The error checking should be pretty straightforward, since there won't be many keywords in use and the syntax is fairly simplistic anyway. 0 Share this post Link to post
guru Posted February 28, 2003 ok if there is a pharser in zdoom already its too much work *nag nag* and the upscaling ?? ;) 0 Share this post Link to post
Fletcher` Posted February 28, 2003 There should be a few options for the warping textures. I.E. how far it will stretch (radius), direction it stretches, speed, etc. Would make for some interesting features. 0 Share this post Link to post
Fredrik Posted February 28, 2003 Just an idea: ditch the brackets and rely on indentation for blocks. It's easier on the one that'll write the file, especially if he has 619257 textures to include. 0 Share this post Link to post
chilvence Posted March 4, 2003 Without brackets I think my brain would explode 0 Share this post Link to post