EDuke32 Changelog Unofficial archive

What changed in EDuke32, build by build

2,117 builds · 8,866 commits · 25 authors · October 2009 – August 2026

Commits per year

Showing 2012 · select it again to see every year
SVN era · r1519 – r8798 Git era · voidpoint.io, from april 2020
Filters · 3 active

Showing 5 builds · 6 commits

Export CSV
Display options
Commit details:

October 2012 3 builds · 3 commits

Build 3093

21 Oct 2012 · 1 commit · 1 author SVN
Open build
  • only let emitshadow affect shadows, not lightmaps.

    Plagman r3093 21 Oct, 11:41 Engine
    Show details

    Lightmaps are already opt-in anyway.

Build 3092

20 Oct 2012 · 1 commit · 1 author SVN
Open build
  • add support for negative lights

    Plagman r3092 20 Oct, 21:52 Engine
    Show details

    And hook them up to cstat 128 (half-submerged, 'c' in mapster).

Build 3091

20 Oct 2012 · 1 commit · 1 author SVN
Open build
  • add a prlight flag to make shadow-less spotlights

    Plagman r3091 20 Oct, 20:41 Engine
    Show details

    And hook it up to SE cstat 64 ('1' in mapster32). This disables both lightmaps and shadow maps for the spotlight; please let me know if you have a usecase where you want lightmaps but no shadow maps for specific lights.

March 2012 2 builds · 3 commits

Build 2536

25 Mar 2012 · 2 commits · 1 author SVN
Open build
  • cull sprite lights after computing sprite geometry

    Plagman r2536 25 Mar, 17:55 FixEngine
    Show details

    This was broken ever since updatesprite() had been forked off drawsprite() and would cause static lights to never hit static sprites until one or the other changed, after which the light would always get culled against outdated sprite geometry.

  • don't shadow-optimize light culling in cached sprites

    Plagman r2535 25 Mar, 17:55 Engine
    Show details

    Since updatesprite() only happens once for static sprites, avoiding light culling if we hit it in a shadow pass means that sprite will never be lit as long as that happens.

Build 2443

10 Mar 2012 · 1 commit · 1 author SVN
Open build
  • fix animations that loop to frame 0

    Plagman r2443 10 Mar, 22:52 FixEngine
    Show details

    With VBOs enabled, the virtual pointer to the geometry of frame 0 of a model is always NULL. This was confusing the polymer code responsible for deciding whether to enable smooth animations or not, which meant that any animation that would loop to frame 0 would do it as if animation interpolation was disabled, which looks very choppy.