Woops! All trans

Apply the double-colormap ordering fix to R_DrawTiltedTranslucentSpan_8 as well.

Please note that standard compilation procedures do not actually apply this update for some reason unless you do a clean build for r_draw.o.

that depend on what build system are you using On Linux with Makefile, gcc -E make this for depends:

../objs/Linux64/SDL/Release/r_draw.o: r_draw.c doomdef.h doomtype.h g_state.h m_swap.h endian.h \
 doomstat.h doomdata.h d_player.h p_pspr.h m_fixed.h tables.h info.h \
 d_think.h sounds.h p_mobj.h d_ticcmd.h d_clisrv.h d_netcmd.h command.h \
 r_local.h screen.h m_bbox.h r_main.h r_data.h r_defs.h p_polyobj.h \
 m_dllist.h r_state.h r_bsp.h r_segs.h r_plane.h r_sky.h r_things.h \
 r_draw.h st_stuff.h d_event.h i_video.h v_video.h m_misc.h w_wad.h \
 hardware/hw_data.h hardware/../doomdef.h hardware/hw_glide.h \
 hardware/../screen.h m_aatree.h z_zone.h console.h hardware/hw_main.h \
 hardware/hw_data.h hardware/hw_defs.h hardware/../doomtype.h \
 hardware/../am_map.h hardware/../d_event.h hardware/../d_player.h \
 hardware/../r_defs.h r_draw8.c

so it does rebuild r_draw.o when r_draw8.c is changed

added 1 commit

• 145c050e - ...and R_DrawTranslucentSplat_8, even though it isn't used!

Compare with previous version

I wonder if the compilation troubles may be to do with r_draw8.c not actually having its own .o file or something, since it's included as part of r_draw.c IIRC?

But I'm only speculating really.

Yeah, the build setup on Windows is a hack. But it's not a big problem - I just included that information for hobbyists wishing to play with this commit ahead of any integration into official branches.

merged

mentioned in commit 653fd303