Func_Msgboard: WAD/BSP Embedded PNGs/JPGs

Posted by 3t0 on 2020/10/15 10:52:17

Hello,

I would like to ask if anybody knows whether any advanced source port supports "hack" common in modern dooms: raw PNGs and JPGs embedded directly into WAD lump?

At first I thought it's pretty silly, but coming across more and more doom WADs doing it, I now think it's kinda neat hack. I was too lazy to look at the code, but it seems dooms reads lump into buffer as usual, and then look at PNG/JPG magic bytes there, if they are found, lump is considered to be PNG or JPG lump, otherwise it is seen as normal palleted graphics lump and is handled accordingly.

In the beginning it seemed bit strange, but now I see it makes it easier to break away from "brown" 256 color look.

Anybody knows?

#1 posted by oh, that person on 2020/10/15 11:37:40

Embedded - no.

But source ports support loading external textures that are unrestricted in color depth.

https://www.quaddicted.com/reviews/?filtered=external

#2 posted by mh on 2020/10/15 12:08:24

A useful variant might be for each BSP texture to have it's own palette. Half Life does this, I think.

Something like this was considered as a feature for BSP2, but ultimately rejected in order to keep the implementation simpler, and to allow 8-bit software engines to support it.

#3 posted by metlslime on 2020/10/15 18:37:52

also, i know this isn't the same thing, but quake has PAK files which can bundle up a bunch of separate assets into a single one (like doom WAD files.) There are annoying limits with this but it's one way to reduce clutter.

#4 posted by 3t0 on 2020/10/15 20:33:40

I was trying to dig up some info on how to do hires replacements, but besides looking at things already done, there is not easy way to find out information these days. So thank you guys for quaddicted "external" filter! I will inspects those releases, to learn how it's done.

I used to go to quakesrc back in the day (I think was the name - it had pretty good wiki too), but nowadays quake info silos seem quite fragmented and lacking unfortunately, and most of it is probably only in working memory of members here.

So best way to go about it these days would be qbsp with -notex and archive it together with textures?

I also got some pak tools to compile but pathname limit seems quite imposing, so pk3s are way to go?

mh: I know about valve palleted "bmp"s but even that seems quite weak this day and age.

#5 posted by Joel B on 2020/10/16 01:25:12

pak files are better than pk3s for compatibility with all Quake engines.

3t0 Take A Look

#6 posted by dumptruck_ds on 2020/10/16 06:37:43

I have a texturing series and this episode covers what otp referred to above.

https://youtu.be/kZFP4PwbfCg

#7 posted by mh on 2020/10/22 19:29:49

I know about valve palleted "bmp"s but even that seems quite weak this day and age.

That's a valid criticism and I don't disagree.

However, and in practical terms, whether or not a feature succeeds depends more on ease of implementation and broadness of compatibility. The lesson learned from BSP2 was that everybody could join the party with just a few lines of code and a few more simple changes. It takes maybe 30 minutes to adapt an engine for BSP2, and it even works with software engines. I dug my heels in over that when designing it, it was the right set of decisions, and that's why it succeeded.

It's notable that even after 20 years, the only high-res/high-colour option we have is external replacement textures, and we still don't have broadly agreed standards for some of it.

You must be logged in to post in this thread.