Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
andrewj

EDGE 1.29 Released

Recommended Posts

The full version of EDGE 1.29 has been released. It has been in development for a long time and the number of changes is huge; among the most significant changes are:

  • Drag 'n' Drop support.
  • Greatly improved BOOM compatibility.
  • Handle DeHackEd and BEX patches.
  • OGG/Vorbis music playback.
  • Support for PNG and JPEG images.
  • Good emulation of DOOM lighting.
  • Software rendering was removed.
Downloads and more info are at the EDGE website.

Share this post


Link to post

I'm pretty impressed by the attention to detail with this release. The Doom-style light diminuation is almost spot on. I also like the fact that it retains a GL version of the screen melt effect. edit: also, the loading disk icon.

Share this post


Link to post

Good to see that even though it's GL only, it can still be configured to feel rather "classic" (including standard screen resolution). I found a handful things to nitpick:

  • It needs a key mapping function for the console (as opposed to being hardcoded to the "console key")
  • I didn't spot any way to disable the transparency set on the stock flames and energy sprites. This setting shouldn't affect transparency in general, because custom transparency is mod or map specific.
  • Something is wrong with the config related code. EDGE reset a bunch of key mappings to default after I restarted.
  • The console text is unreadable at low resolutions; it should be scaled up
  • It doesn't seem to have a way to disable the garish colors for the status bar percentage numbers

Share this post


Link to post
myk said:

  • I didn't spot any way to disable the transparency set on the stock flames and energy sprites. This setting shouldn't affect transparency in general, because custom transparency is mod or map specific.


  • DDF?

    Share this post


    Link to post

    EDGE used to have option for translucency. According to the logs, it was removed in 2005 because the GL renderer didn't support it. Shouldn't be too hard to restore it. I just wonder how far it should go (e.g. apply to water surfaces and Boom transparent walls?).

    Share this post


    Link to post

    Ajapted said:
    I just wonder how far it should go (e.g. apply to water surfaces and Boom transparent walls?).

    Those would have to work invariably if placed in a level by an author, so that it can work as intended. The only reason to have an option to disable translucency in such cases would be for debugging, if necessary.

    On the other hand, adding translucency to existing (stock) sprites changes the appearance of the artwork in general (and always, unless it's optional), in a way some may prefer and others may dislike. This option should be overridden by DDFs in addons, because if a wad author wants a certain sprite to be translucent, it should be so, even if the user disables tranlucency for the sprites that use it by default in EDGE.

    The Pistol's flame and the Imp's fireball are tranlucent, for example. A user should be able to disable that, although if a wad author applies translucency to the Imp fireball, it should remain translucent even if the user disables the translucency option.

    If deep water is made translucent automatically, you might want to include it in the general option, or, better yet, separately by itself, so that it's possible to play supported Boom levels "as intended" (since in Boom water isn't translucent). If it's a DDF or mapping feature only, there's no need.

    Share this post


    Link to post

    Make a flag in DDF that marks an item as having optional translucency, then stick it on the default Doom items. That way, the creator a resource intensive mod would be able to mark his items for optional translucency when run on a slow computer, for example

    Share this post


    Link to post

    The Pistol's flame and the Imp's fireball are tranlucent, for example. A user should be able to disable that, although if a wad author applies translucency to the Imp fireball, it should remain translucent even if the user disables the translucency option.

    With anything like that I tend to think that it should always be left to the user to make the final decision, regardless of what the wad author wants. So in order of priority:

    1) User-level control with the following modes: a)Respect lower-level priority b)Always On c)Always Off
    2) Resource-specific preference chosen by resource author.
    3) Application default for resource type/group.

    Share this post


    Link to post

    Dehacked? does that mean i can muck around in my old Insanity Please wad in an engine that doesnt crash if you're wearing the wrong colour underwear?

    Bex? Does that mean support for the Zdoom railgun?

    Share this post


    Link to post

    DaniJ said:
    1) User-level control with the following modes: a)Respect lower-level priority b)Always On c)Always Off

    Yeah, that makes sense; if the wad author were to apply translucency specifically to the Imp fireball it would be translucent as long as either "a" or "b" is selected by the player (better done by the wad maker only if the sprite would demand translucency critically, such as making the Imp spray a relatively clear liquid or gas instead of a ball of fire). If the Imp fireball were left alone (preferrably under any case where the sprite is not modified), it would be translucent only when selecting "b".

    Share this post


    Link to post
    deathbringer said:

    Bex? Does that mean support for the Zdoom railgun?

    Probably not, seeing as its a zdoom specific bex extension. I've never seen it in another bex supporting port either.

    Share this post


    Link to post
    entryway said:

    Do you mean the red dots (sky bleed-through)? It is a long standing problem with the renderer. Our rendering code is in very bad shape and really needs to be rewritten. Not sure I have the stomach for it tho.

    If you don't mean that, what do you mean?

    BEX stands for Boom EXtension. ZDoom should call their version ZEX. To answer the question, no we don't support ZDoom's extensions to DeHackEd/Bex.

    deathbringer said:

    Dehacked? does that mean i can muck around in my old Insanity Please wad in an engine that doesnt crash if you're wearing the wrong colour underwear?

    Probably. Do try it.

    Regarding translucency: rather than the engine trying to second guess all the mod makers, it's probably easier for us to make another EDGE.WAD with any special effects disabled.

    Share this post


    Link to post

    I dont know if this is intentional, but=

    Mouselook + Autoaim + melee = annoying

    If you punch a flying enemy, or anything above you, the camera will imediately jerk up to view it. Really annoying.

    Share this post


    Link to post
    doom2day said:

    Ouch. That hurt me in the gut. I hope that gets fixed.


    "Fixed" probably means "worked around". Having seen all sorts of issues come up to do with ATI cards on the GZdoom forum, I'll bet the ATI card, or drivers aren't doing something properly.

    Share this post


    Link to post
    Enjay said:

    "Fixed" probably means "worked around". Having seen all sorts of issues come up to do with ATI cards

    IT IS NOT AN ISSUE OF ATI CARDS.

    It is only an issue with a brain of programmers and laziness. It works on GeForces only by chance.

    Share this post


    Link to post

    I'm not going to pretend to know how that happens in EDGE using ATI cards but I will offer this bit of advice:

    Normally speaking, these artefacts are the result of rounding inaccuracies to calculations performed on vertex position coords. The only way to be 100% sure to avoid this result is to make sure the vertex coords of the primitive on each side of a shared edge are EXACTLY the same and also, that there are the same number of vertices on each side of the edge (which means two).

    This one of the reasons why Doomsday goes to lengths to split segs so that if one-section segs (middle only) neighbour multi-section segs (top/middle/bottom); there are always the same number of vertices on the shared edge.

    Share this post


    Link to post

    Yes you are right.

    Nobody guarantees absence of seams and dots if you do it incorrectly and you are obliged to do correctly instead of being indignant, that some things do not work as you mean and wish.

    Share this post


    Link to post
    DaniJ said:

    Normally speaking, these artefacts are the result of rounding inaccuracies to calculations performed on vertex position coords. The only way to be 100% sure to avoid this result is to make sure the vertex coords of the primitive on each side of a shared edge are EXACTLY the same and also, that there are the same number of vertices on each side of the edge (which means two).

    Yes, the OpenGL specifications only guarantee a solid (no gap) border when each shared edge has the same start and end coordinates.

    The main culprit for EDGE is the LOD subdivision algorithm, used to break up polygons for dynamic lighting and the doom-fading emulation. A further away polygon can get subdivided into less pieces, causing edges with the closer polygon to mismatch.

    Replacing that LOD subdivision algorithm with a better method has been planned for a long time. It wasn't done for 1.29 because we were in feature freeze (and rewriting your whole renderer is a pretty big deal).

    Share this post


    Link to post

    The main culprit for EDGE is the LOD subdivision algorithm, used to break up polygons for dynamic lighting and the doom-fading emulation.

    Ah I see. I wasn't aware EDGE was doing that. Interesting. I take it it subdivides within single subsectors?

    I've thought about doing something similar with Doomsday actually but because I wanted the subdivision to occur across subsector boundries I put it off as it is a "hard" problem. Do you have a particular approach in mind?

    Share this post


    Link to post
    DaniJ said:

    Ah I see. I wasn't aware EDGE was doing that. Interesting. I take it it subdivides within single subsectors?

    I've thought about doing something similar with Doomsday actually but because I wanted the subdivision to occur across subsector boundries I put it off as it is a "hard" problem. Do you have a particular approach in mind?

    Yes it is quite a hard problem. I wrote the LOD polygon splitting code 6 years ago (almost exactly), and it's really awful stuff. Yes it does subdivide single subsectors.

    First it figures out a divide grid based on distance, e.g. 1000 units away may divide by 2x2 (4 pieces), 2000 units away would divide by 4x4 (16 pieces). It divides each polygon in two steps: first vertically, then horizontally. The main logic is just clipping edges that cross the top/bottom of the current grid row or column. An optimisation would be to make triangle strips during the second step, though I never did that and only made separate polygons.

    For Doomsday you could consider modifying glBSP to cut up large subsectors into pieces under a minimum size. Such a modification is tricky because the code uses a real seg as the partition line (for doing checks etc, maybe create a dummy seg for it). The NODES format does not need any seg/linedef for the partition line, so no worries there.

    Share this post


    Link to post
    ×