Engine standards for mod compatibility

[leileilol]

If alpha support is included in the standard, software renderers are excluded. As far as I understand it.

It's nothing a few lookup tables can't solve. Hexen II's software renderer has many of these things already. ToChris has software skyboxes and interpolation, Makaqu has EF_ADDITIVE and scaling (again, more lookup table stuff)

I was working on a DOS/Win software engine that implemented my favorite things about Darkplaces (additive, md3, new gun bobbing, much higher limits), and stopped for some reason.

In addition to LH's list of minimums, modeltoclient/viewmodeltoclient, movetype_follow, fake CD tracks (alternate music playback for midi, ogg and mod formats, tons of Doom ports do this) and md3 support with attachments are the only things I feel that are missing.

And for the love of... if you guys are making completely not-Quake games on the engine I strongly encourage using an all new color palette. It helps a LOT to making a fresh feel to a derivative game.

[goldenboy]

leileilol, care to write a good tutorial on some of these things?

You have to make it super-easy for people to adapt it.

[leileilol]

I don't have time to write tutorials, but Makaqu's source code is well commented, you can learn how by just reading the .c's.

What is needed first is to get the lookup tables loaded and initialized. A lookup table is a 256x256 raw LMP that has rows of all colors blending into columns of all colors. It's how you blend, what amount is blended, and where. Technically you can make any blend mode in a software engine using lookups, but in the '90s it was popular to use just 66% alpha transparency.

Second, is the blending function of looking up the actual colors against the colors rendered behind it (what 'lookup tables' are about). Hexen II has some fast ASM functions for this if you're doing this for slow x86 machines.

Third is indicating how the entity in the engine is to be blended. This is the hard part IMO, hooking up .alpha or EF_ADDITIVE.

[mh]

Or look at QuakeII's software renderer (it does alpha via stippling). Or even do your own alpha blend modes: all an alpha blend is after all is an averaging function of a few colours, so if you're doing a 32 bit software renderer there's no reason why you wouldn't be able to emulate almost anything a hardware renderer does. For 8-bit you could assume that all alpha is at either 0 (in which case don't draw), 25, 50, 75 or 100 (no alpha). Build 3 lookup tables, one for each of 25, 50 and 75, and cross-reference the palette indexes for src and dst to get a new palette index. There would be a 192K RAM overhead and a lookup overhead, but it shouldn't hurt too much.

[FrikaC]

25% and 75% can be the same lookup table, just swap what value goes where. (75% is 75% A and 25% B and 25% is 75% B and 25% A)

[Baker]

Vwep support, independent palette per texture support like Half-Life bsp, movetype_follow and tagging, frik_file, md2 and md3 support. And a 24 bit software renderer.

Ability to copy the console to the clipboard (ProQuake does this).

And I would vote to strike the idea of external texture support.

External texture support is a HACK. All textures should be compiled into the .bsp. If you want high resolution textures, the right way to do this is make a new map format i.e. not Quake BSP Version 29.

Case in point demonstrating the hackness of external texture support, if there is a map on a server and the client downloads the .bsp, they don't have the textures.

External texture support is a kludge, it is great for certain purposes but it isn't a "standard" and is more useful for testing on the fly.

Case in point, put Rygel .pk3 and something else .pk3 in a folder and prepare for a nightmare of conflicts.

p.s. skyboxes and lits should be compiled into the .bsp too. The Quake map format was designed well in the sense that the BSP has everything you need including the textures.

Don't undesign it simply because external lits and external skyboxes and external textures are normal in engines. Instead, up-design it and get that built into the map format and eliminate external everything.

[mh]

25% and 75% can be the same lookup table, just swap what value goes where. (75% is 75% A and 25% B and 25% is 75% B and 25% A)

Good point, I missed that.

[mh]

And I would vote to strike the idea of external texture support.

External texture support is a HACK. All textures should be compiled into the .bsp. If you want high resolution textures, the right way to do this is make a new map format i.e. not Quake BSP Version 29.

Case in point demonstrating the hackness of external texture support, if there is a map on a server and the client downloads the .bsp, they don't have the textures.

External texture support is a kludge, it is great for certain purposes but it isn't a "standard" and is more useful for testing on the fly.

Case in point, put Rygel .pk3 and something else .pk3 in a folder and prepare for a nightmare of conflicts.

p.s. skyboxes and lits should be compiled into the .bsp too. The Quake map format was designed well in the sense that the BSP has everything you need including the textures.

Don't undesign it simply because external lits and external skyboxes and external textures are normal in engines. Instead, up-design it and get that built into the map format and eliminate external everything.

Yes, this this this this THIS.

At least LITs are reasonable standardized, but back at the dawn of time everyone had their own implementation of skyboxes and external textures, and it ended up that there were multiple standards for even basic things such as which directory they went into. One of the most frustrating things is to have to code your engine to support all of those standards.

My humble proposal: use the BSP version number, but in a slightly different way to the old BSP 30 hack. Instead bitwise-and the version with 0xff and check the result, which should always be 29. Then bitwise-and the version with 0xffffff00 and check the result of that for flags (256, 512, 1024, etc) that can indicate extensions. These should be included as extra lumps in the BSP (they don't need to be at the end of it, you could put an MPEG in a BSP and as long as the standard lump offsets and lengths were correct it would still load in even DOSQuake) so that engines which don't support the extended data formats can happily run with the original data.

Only concern is that the BSP size would bloat, but you could do clever things like using compression.

All current engines would need to be modified to at least do the if ((header.version & 255) != BSPVERSION) test before this could be reasonable of course.

[Downsider]

I think all diffuse/bump/whatever except lightmap textures should be external, with a modified BSP format that has no built-in textures except lightmap textures.

Easier to develop with, in my opinion, and allows for less hard drive space to be taken up ;P

[leileilol]

I don't find the lack of self-containment to be a problem. That's exactly what PK3 is for, and external elements (tex, sky, sound) is what Quake2 pushed forward to, to reduce redundancy and disk space, same goes for Half-Life and external WADs for textures.

I'm not against the ebsp idea, but a self-containing BSP29 on steroids won't "solve" any problem. Consistent standards on sites could, though. It's ironic that MD2/MD3 support is demanded as minimal while this is suggested at the same time.

[Downsider]

I don't find the lack of self-containment to be a problem. That's exactly what PK3 is for, and external elements (tex, sky, sound) is what Quake2 pushed forward to, to reduce redundancy and disk space, same goes for Half-Life and external WADs for textures.

I'm not against the ebsp idea, but a self-containing BSP29 on steroids won't "solve" any problem. Consistent standards on sites could, though.

This is exactly my mindset here.

[goldenboy]

You are seriously suggesting that we come up with a new map format for this standard?

In addition to several engines implementing new software renderers with alpha support etc. from thin air?

Perhaps we should aim for something more realistic and push stuff like a new bsp format back to version 2.0 if there ever is one.

I'd rather see something less ambitious get done than something overly ambitious fail again.

Edit: I would think that external texture support, again, should be left to the individual engines instead of bloating this new standard.

[Downsider]

Hardly new, just modified a teensy bit, to remove a bit of redundancy and hard drive waste.

But I think we're getting away from the real discussion, is it really about eyecandy and new features or fixing the old ones? I think it's the latter. Eyecandy should be up to the engine dev.

[metlslime]

Regarding external textures, enhanced bsps....

I think the best chance of success would be to create a standard that is at least close to the current implementation of these features in most engines, rather than a re-invention. That way fewer engines have to change, and those that do will have a smaller change to make.

[MeTcHsteekle]

here's one that should be standard, being able to bring the text marker in the console backwards without DELETING EVERYTHING YOU JUST TYPED! AAAGGH ITS SO ANNOYING !!!~!