Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
timmie

Another planned feature (looking for input)

Recommended Posts

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.

Share this post


Link to post

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...

Share this post


Link to post

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.

Share this post


Link to post
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"...

Share this post


Link to post

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.

Share this post


Link to post

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
   }
}

Share this post


Link to post

Multiple blending modes for layers. Additive, for example (projectile sprites use this, I believe).

Share this post


Link to post
Ed said:

Multiple blending modes for layers. Additive, for example (projectile sprites use this, I believe).


That would be the blendFunc field :)

Share this post


Link to post

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 ;)

Share this post


Link to post

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.

Share this post


Link to post

ok if there is a pharser in zdoom already its too much work

*nag nag* and the upscaling ?? ;)

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×