tyrlite vs big maps vs mh_coloredlight

[hondobondo]

I'm rather sure what MH means is that your *map* doesn't have fullbrights, not that the engine you are using doesn't have them. Whether or not an engine supports fullbrights doesn't have anything to do with lightmaps.

He just means your textures in the map aren't using any fullbright colors and his tools uses that to generate the colored light data.

so what textures are fullbright textures?

There's no set list of such textures. Any one containing a texel with a palette index > 223 (or was it 224?) is a candidate here. Even this is not an absolute hard and fast rule, as fullbrights in software Quake come from the colormap, so it's really any one where the corresponding colormap column doesn't darken. An even then it's not hard and fast as software Quake could allow inverse lighting if the colormap was set up accordingly, but in practice you won't see this at all.

Yeah, it's complex like that.

well hell. so do i change the map or change the engine? and how do i do either?

[mh]

Before you do anything you should have a read of this: http://www.quaddicted.com/software-vs-g ... llbrights/ this: http://www.celephais.net/stuff/texturefaq.htm and this: http://quakery.quakedev.com/qwiki/index ... e#Colormap

(These are essential reading for all content creators, by the way).

If you want MHColour to work you will need to change the textures in the map. Find textures which have fullbrights in them (by running another map in either software Quake or an engine which supports fullbrights) and use those textures.

I personally don't recommend this approach. MHColour is a specialised tool which is only appropriate in certain well-defined circumstances; using it for general mapping work is not a good idea. Creating a map with support for coloured light in the first place is the right thing to do all the time.

If something doesn't work in the engine you're using, cross-check it with another engine. This is always a good idea anyway, even if that something does work, and especially if you're using Bengt Jardrup's engine (or something derived from it).

Bengt's engine is a great mapping tool, but it has several serious drawbacks which prevent it from being suitable for general use. One of those is it's lack of fullbrights and overbrights. Content which looks perfectly fine in his engine can quite easily look awful in something else. It's even inconsistent with his software engine in this regard.

Another is that his engine carries forward a lot of CRAP from GLQuake which the world would be a lot better off without. I've personally seen content run over 10 times faster in engines that have had their renderer designed better.

None of this is to say that he did a bad job; by his own admission (http://user.tninet.se/~xir870k/readmegl.txt) his engine is a mapping tool and it should be treated as one. A key point that mappers frequently miss is that the engine that is best for them while mapping is not necessarily best for the person who's playing the end result. Understandable but sometimes frustrating.

So coming back to where I said "if something doesn't work in the engine you're using, cross-check it with another engine": right now we don't know where the bug you're getting is. It could be in the engine. It could be in the map. It could be in the tools (and not necessarily just the light tool). The only way we're going to know, and be able to advise where to go next, is if you cross-check, experiment and try to pin down the source.

[Baker]

Even textures don't belong in bsp files, they were removed in later quake engines and made optional in half-life, and for good reasons.

Well, I don't really agree with that philosophy for a simpler engine like the stock Quake engine.

I like the idea that a Quake map is entirely encapsulated in a single file.

There is something to be said for simplicity. I understand the opposing point of view but I don't believe in one size fits all solutions. Those things might be good for some other game or game in the Quake series, but represent unnecessary overhead for small gains with the original Quake.

The original Quake engine's small footprint, portability and simple file system are things I consider "good" things about the engine and the game.

I also don't like cvars much and don't much believe in most settings ... call me old school. I have an anti-complexity point of view. I actually do not even like external replacement textures for Quake, but accept that it is the only generally accepted way around the palette limitation at this time.

[revelator]

cant say i love having textures in the bsp, but i accept it because we can override them pretty easily.

would be cleaner having them seperatly though, and also makes it easier to update content without having to override existing textures.

seen a few quake engines try and use a Q3 shader system for handling content and its definatly doable (phoenix quake) but the code needs some fixing, (the vertex array code was completly fubar) mh could do wonders with it im sure

cvars allways been rather meh to me, but atleast they have there merits (better way to do it ?) hmm.

[frag.machine]

Even textures don't belong in bsp files, they were removed in later quake engines and made optional in half-life, and for good reasons.

Well, I don't really agree with that philosophy for a simpler engine like the stock Quake engine.

I like the idea that a Quake map is entirely encapsulated in a single file.

There is something to be said for simplicity. I understand the opposing point of view but I don't believe in one size fits all solutions. Those things might be good for some other game or game in the Quake series, but represent unnecessary overhead for small gains with the original Quake.

The original Quake engine's small footprint, portability and simple file system are things I consider "good" things about the engine and the game.

I also don't like cvars much and don't much believe in most settings ... call me old school. I have an anti-complexity point of view. I actually do not even like external replacement textures for Quake, but accept that it is the only generally accepted way around the palette limitation at this time.

I agree with your point of view - but, OTOH, we can't deny that this would be good to the PSP and even maybe the Flash version of your engine.

[mh]

I've no objection to cvars so long as they've got sensible defaults. For the most part Quake actually hits the spot right, but there are a few that obviously date it, most likely on account of the fact that nobody at the time actually knew what the best settings for a full 3D FPS were going to be.

Adding new cvars always bothers me though; there's a real danger of going in the Quake II direction, which - IMO - suffers somewhat from second system effect:

the tendency, when following on from a relatively small, elegant, and successful system, to design the successor as an elephantine, feature-laden monstrosity.

(any QSB proposals would also do well to be wary of this...)

On the other hand I'd love to replace Q1 BSP with Q2 BSP, or at least a variant of it (probably replacing the remainder of the unsigned short limits with ints). Aside from anything else, Q2 BSP is a lot more empowering for mappers.

On the other hand again, the brutal simplicity of Q1 BSP can't be denied. There's a reason why Q1 BSP is still preferred by the really talented mappers, and why new maps are still being made almost 15 years later, and that's a genuine power of the format that it would be a shame to say goodbye to.

[leileilol]

Don't forget there's the possibility of integrating textures into HLBSP also. This was used a whole damn lot.

HLBSP with Quake hull-sizes is what you're all asking for... except mh's q2 proposal. so far the only quake engine I know that does q2bsp is FTEQW (which also can play the games Quake2, Quake3 and Hexen II)

[qbism]

Wasn't there a utility at one time to replace map bsp textures with blanks, reducing file size and making it reliant on external textures?

[leileilol]

How would that reduce filesize? Don't you need textures of the same size as before to even have properly sized replacement textures to use on?

[metlslime]

Yeah... UV mapping is generated at load time, the bsp only contains texture translate/rotate/scale info (which relies on texture dimensions to make sense)

[goldenboy]

A q2bsp variant with patches added would probably be neat. Personally I'd switch in a heartbeat, but I have a feeling I'd be very lonely. People hate having to adapt.

Tool coding in Quake is in a very sad state of affairs as well, who's going to make the new map compilers? What about editors?

[hondobondo]

http://www.moddb.com/mods/bondos-superduper-quake-25/downloads/superduper-quake-engine-096

there are some weird artifacts however, if you look close. (DON'T LOOK CLOSE)

they're hard to miss, unfortunately


http://media.moddb.com/images/downloads/1/29/28799/quake04.jpg