textures2quake

[dfsp_spirit]

I intended to ask how to convert textures to quake format without much hassle for some days. Never found the time to post. Now I came here to finally ask and read that baker created the solution before I could even ask. Thanks heaps man!

And I still got a question on this: what's the common way of shipping the textures with your map? Somebody mentioned compiling them into the bsp (Halflife-style). How do I do that and what are the disadvantages? Is there any modern engine that can't read the HL bsp format?

Any alternatives if I don't want to compile them into the bsp? Do you need to put them in a pak then or can you just distribute them in id1/textures/mapname/* inside of a zip file?

[Dreadlorde]

Iirc, DarkPlaces can read HL BSP's. I'm not sure if any other engines can.

[Baker]

Most engines support hlbsp:

ProQuake 4
DarkPlaces
Qrack
ezQuake
FuhQuake
FTEQW

The only significant engines that don't:

FitzQuake 0.85
Enhanced GLQuake

Even then, the tutorial to add HLBSP to an engine is trivial:

Inside3d Forums :: View topic - Basic Half-Life Map Support For Stock GLQuake

Two potential options for avoiding the Quake palette:

1. Half-Life map format (please compile textures into map if you end up doing that)
2. Quake map format, with the intent of using replacement textures for the map

If you do #2, recommendation is for all textures to be zipped into

\textures\<your mapname>\*.* (as you mentioned)

Maybe as both as an uncompressed .pk3 (for DarkPlaces), with all textures ideally in the tga format for fastest load times although using .jpg is almost as ok and .png is adequate.

Note that only .tga is universally supported by all texture replacing engines (FitzQuake 0.85 and Enhanced GLQuake only support TGA, for instance ... but most other engines do png, tga, jpg).

NOTE: FitzQuake 0.85 does not support loading textures from a .pak file. Most engines do, but FitzQuake 0.85 doesn't and it is popular enough to consider as a target engine for virtually any project.

[dfsp_spirit]

Thanks for the info, feels like I know everything I need to know on this now.

[monoz]

have any q3 maps been converted for q1 for ctf? There are few good maps that I wouldnt mind seeing in q1. If not, how hard would it be to make these.

[Baker]

have any q3 maps been converted for q1 for ctf? There are few good maps that I wouldnt mind seeing in q1. If not, how hard would it be to make these.

Func_Msgboard has a lot of experts mappers for both Q1 and Q3.

Func_Msgboard: Latest News

[dfsp_spirit]

have any q3 maps been converted for q1 for ctf? There are few good maps that I wouldnt mind seeing in q1. If not, how hard would it be to make these.

I made maps for both q1 and q3. The conversion itself ain't that difficult as you can use the brushes and if the textures are all custom made (or you ignore the EULA) you should be able to use them too - you'd have to scale them though. You obviously have to replace stuff like curves, decals, some of the func_*s and other stuff that q1 doesn't support. And rebalance items. No problem so far. Maybe 10-20 hours of work for a map, depending on size and other stuff. (This assume that you have the .map source file btw. I know there's bsp2map utilites but I also know how good they work so don't even consider it.)

The problem is that a map that plays well in q3 doesn't automatically play well in q1 if you just convert everything. You'll have to rescale the map because jump distances, player height and the maximum number of brushes allowed differ between q1 and q3. This means a complete rebuild of the map.

For me, there is another issue (though of different nature): building a map is fun because it's your map and you used your creativity to invent the layout. Rebuilding an existing map is boring. Just my 2 cents of course.