Page 1 of 1

OK to include brightmaps for graphics that don't exist?

Posted: Sun Nov 22, 2009 17:02
by Enjay
I've been looking at putting together a bugfix version of my Burghead mod to fix a couple of issues that have been flagged up by recent changes in Zdoom etc. I'm making it compatible with the current SVN versions so I plan to release it some time after the next official GZdoom release happens.

Whilst I'm at it, I thought that I may as well include a few tweaks and improvements. One of these will probably be brightmaps. The easiest option for me would be for me to include all the brightmaps for my Aspects mod and simply copy all their definitions into the doomdefs lump. despite the fact that there are a lot of brightmaps, they are pretty small file-size wise and so have a minmal impact on the overall download size.

I initially started going through the brightmaps and weeding out the ones that are for sprites and textures that exist in Aspects but which do not exist in the Burghead mod. However, finding the images, deleting them and editing the doomdefs lump to delete the entries was taking forever. So, other than a little bit of wasted file size, I was wondering if there was any harm in merely putting the whole lot in the project pk3. GZdoom doesn't object when I do this and it would make my life a lot easier but I don't want to do something that would cause the mod to break a few revisions down the line.

So, is there any likely mod-breaking harm in including brightmaps (both brightmap images and doomdefs entries) in a mod that doesn't actually contain some of the images that the brightmaps correspond to?

Re: OK to include brightmaps for graphics that don't exist?

Posted: Sun Nov 22, 2009 17:52
by Graf Zahl
You'll get error messages but since the engine can't make any sensible use of such images they just get ignored.

Re: OK to include brightmaps for graphics that don't exist?

Posted: Sun Nov 22, 2009 22:21
by Enjay
Actually, it doesn't even give the error messages.

I do get error messages if I delete the brightmap image but leave the doomdefs entry in place. However, if the pk3 contains both an entry in the doomdefs and an actual brightmap image, GZdoom does not give an error message even if the image that is being mapped to doesn't exit in the project. eg if I have a brightmap for a texture called NJTEX01 and an entry in doomdefs for the brightmap, there is no error message even if the texture NJTEX01 is not actually in the pk3.

If I was getting error messages, I would have persevered with the deleting process because I hate seeing error messages at the console. It just makes the mod look untidy IMO. Which is why, I guess, I was asking the question. As long as I'm not getting error messages and there is no problem with having these entries, I'll leave it as it is. If I am going to get errors, I'll have to find and delete all the orphaned brightmaps and doomdefs entries.

Re: OK to include brightmaps for graphics that don't exist?

Posted: Sun Nov 22, 2009 23:09
by Graf Zahl
Errors not displaying error messages are generally bugs and may change without notice. Never rely on that!

Re: OK to include brightmaps for graphics that don't exist?

Posted: Sun Nov 22, 2009 23:28
by Enjay
Fair enough.

I think that I may have cracked it though.

If I remove the brightmap images from the pk3, GZdoom gives me a list off all the missing brightmaps and the ones that do not have a corresponding graphic in the project are listed as being mapped to 'null'. So, I can do a quick conversion on the GZdoom logfile to delete all the non-null entries and then do a find/replace to change it to a batch file that deletes all the unwanted bitmaps, then do a 'dir*.png /b >doomdefs.txt' and use that as a basis to regenerate my doomdefs for the graphics that are left.

should work...

Re: OK to include brightmaps for graphics that don't exist?

Posted: Sun Nov 22, 2009 23:49
by Enjay
Enjay wrote:should work...
Done! Almost 3000 brightmaps reduced to the just over 450 that I actually need in a few minutes. I love Textpad's macro features.