The main reason for this release is because texture uniforms were uploaded to shaders incorrectly in 3.2.0. However, the rest of master was just bugfixes and minor improvements, so it was merged for this release. (I got permission from Graf to do this release)
Changes from 3.2.0:
Fixed applying of height argument in A_Fire() function
Removed all code needed to support macOS earlier than 10.7 Lion
Fixed crash on attempt to register IDs for undefined class
added vid_cropaspect. This cvar turns vid_aspect into a letterboxing function that will crop the unused sides of the screen away, instead of stretching it. Requires one of the non-legacy OpenGL framebuffers to work.
remove vid_tft and vid_nowidescreen and associated menu option. Their functionality was supersceded and extended by vid_aspect==3 (which has the same effect as setting both to true anyhow), and it was mostly just redundant.
Fixed: don't interpolate view movements if a key press didn't result in any changes.
If *nix, add default gzdoom.pk3 directory to File.Search paths
fixed: inverted color order for post-process textures to BGRA to correctly match the internal texture standard in GZDoom
added ability to change slider color using mapinfo's gameinfo
added 'startuptype' to iwadinfo, allowing to change the game startup screen with custom iwads
Fixed applying of compatibility settings for IWADs
Fixed a few cases when IWAD was checked by hardcoded index
Fixed arch-vile bleeding when damaging target
(Note to OpenBSD users: Please compile or cherry-pick commit b871b1898 - sorry I was remiss in including this one, since it does not affect the currently officially supported systems)
More than a bit late myself, and also thank you kindly for the update.
I am intrigued by this one:
Rachael wrote:
added 'startuptype' to iwadinfo, allowing to change the game startup screen with custom iwads
How do I make this happen? Does the IWAD itself need to contain an IWADINFO lump and (presumably) all the lumps necessary for the startup to work? I take it that it doesn't work via gameinfo in MAPINFO?
@Enjay: The gist of the system is that GZDoom now checks your wad directories for any files that end with ".ipk3" or ".iwad" and then looks for the presence of an IWADINFO lump inside them. The lump detection stuff is only used for GZDoom's internal list, so there's no need to worry about it for your own IWAD.
Presumably this means "aspects.ipk3" is gonna be a thing on the Enjay-drive soon. ;P
Thanks. I was just picking my way through other posts and I had just about got to that understanding but I really appreciate the clarification. I'll have to give it a go now.
Not Aspects though. To be honest, I left that behind as a project some time ago - read years - though I still use resources I created for it etc., obviously. I wanted to know more just for general messing around with stuff and trying to catch up with what I've missed and custom IWADs/games have always intrigued me right from the earliest days of modding.
[edit]
And I've just worked my way through the post announcing 3.2.0. That's an impressive change list. Once again, thank you to all concerned.
[/edit]
Ed the Bat wrote:We still could, yknow. I'm terribly sorry I haven't produced new work for so many months...
Don't worry. I wasn't including your work on Burghead in my sweeping statement and it certainly wasn't a dig. I merely meant that the central project is a thing of the past now and that the collected bits and pieces are not much more than an editing resource for me.
I did not mean that the fixed and improved Burghead shouldn't go ahead as and when you/we have the time to look at it again. I'd still really like for it to happen actually.