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

Coraline

Members
  • Content count

    1177
  • Joined

  • Last visited

Everything posted by Coraline

  1. UPDATE: EDGE 2.1.0-RC-1.5 has been released via SourceForge! Binaries for Linux are coming later as I didn't have time to compile and upload before work! https://sourceforge.net/projects/edge2/files/3DGE binaries/2.1/2.1.0/RC-1/RC-1.5/ (ignore the Malware Detected thing on SF, I'm not sure why it says that as it detects the crashlogger from Eternity Engine as the culprit, but I have verified with Quasar that it is not the case, SF is just dumb - if it helps, Github does not complain!) * There is a huge list of changes between 2.1.0-Test3 and 2.1.0-RC1.5, so make sure to check out the CHANGELOG (or scroll down this post a bit). ** Downloads are only available currently for 32-bit and 64-bit Windows platforms as of 10.17.18 - I will release Linux builds when I have more time to compile/upload/test, though it can be built from source! It is also important to note that if you are looking for Windows XP support, we only support XP on the 32-bit builds of EDGE (x86). We will not be supporting XP at all in the 64-bit releases, so keep that in mind if you are looking to run it on that OS. This release candidate is one of many that we are putting out before 2.1.0 Final, in the hopes that we can catch bugs and serious issues before the final launch. Please download and give it a spin! It's been three years since any official release of EDGE (the last being 2.0.4 in 4/2016!) and seven full years since the last release of EDGE in general (back in 2011), so I wanted to make a thread detailing what to expect from the upcoming 2.1.0 build. If you've been keeping up with the development builds via DRDTeam you have an idea or two, but I've just released 32-bit and 64-bit builds of EDGE that will closer represent 2.1.0 Final. You can find those here. I am working on a Roadmap to 2.1.0 Final and should be available in our Wiki later today. Click the spoiler below for the full changelog for RC-1. If you want a generalized summary of features we have added and how they work, please see this post on the ZDoom forums. The biggest additions to these latest devbuilds and the ones from before June 2018 is our reworked Image handling/decoding, rendering improvements, COAL improvements, and archive support (PK3/PAK/EPK). The extension .EPK (which stands for Edge PacKage) is the equivalent of PK3 or PKE from Eternity. Having audio issues?? Look below: If you see this in the console or in your logfiles, SDL2 has initialized audio properly: SDL_Audio_Driver: default I_StartupSound: trying 48000 Hz, 32 bit Stereo I_StartupSound: Success @ 48000 Hz, 32 bit Stereo I_StartupMUS: Couldn't load the midi mixer I_StartupMusic: OPL Init OK Encountering OTHER bugs? Look at the CHANGELOG in the above post to see if it is already there - if so, give us time, we are working on fixes!! This is also a great time to list any concerns, bugs, criticism , or any other issues you have or were having with previous versions of EDGE that affect your experience with the engine. If you know of something, feel free to reply at this thread; I'd like to iron out any major and or potentially serious issues regarding EDGE before the release goes live. And while I know newer generations of DOOMers will probably say stuff like 'it's shit' or 'suxx no brutal doom' - just keep in mind while the team is open to criticism of ALL kinds, please be sure your issue has not already been solved in the past or that you are following conventions (no IWAD? Is there an IWAD in the root? No?...). If you happen to find a bug, the team is more than happy to fix it for you - the least we can do is provide quality support for you guys! ;) In closing - please play-test and submit as many bug reports as you can! We want this upcoming release to be the biggest and most revamped version of EDGE in its entire history (with UDMF, Polyobjects, archives, multiplayer, and other modern support systems already working but not completed) and we can't do it without those who are willing to give a few minutes of their time to check it out! Thanks everyone! (Did not mention, but if you have any feature requests now is the time to raise those as well!)
  2. You know, something I just thought of... Is there a function within EPI endianess routines to convert from an Integer to unsigned short? I just realized...if I did that i could technically avoid having ROTT patches in their own struct entirely. . .keep the code tidier by just having everything in the base patch_t structure and that could potentially make it easier to handle those patches.

     

    Also, does EDGE explicitly require a pnames and/or TEXTURE1/2 for textures and patch displays? Since ROTT just displays patches directly, i wonder if even a lone dummy value would work..its either that or i would need to meticulously hand-roll one... I want to say EDGE has that capability but I could be wrong. .

    1. andrewj

      andrewj

      Sometimes a struct like patch_t is used to represent the exact (bit-for-bit) structure of the binary data in a lump or file.  So you cannot change, for example, a short to an int in that structure because the sizes are different (16 vs 32) and it won't read the binary data in the lump properly anymore.

       

      Other structs are used in memory, and it is less important if a field is a short or an int.  EDGE code does not make the distinction between these two usages very clear.  In Eureka and AJBSP, the file w_rawdef.h contains the structs for on-disk binary data, and they are only used to read/write the binary lumps, other structs are used for in-memory version (of a linedef, sector, etc).

       

      For example, raw_linedef_t is a struct for the raw (on-disk) representation of a DOOM linedef, and raw_hexen_linedef_t is the variant use in the Hexen map format.  These are converted to a single in-memory struct "linedef_t" by code which reads the LINEDEFS lump in maps.  This linedef_t has enough fields for both the DOOM version and the HEXEN version.  The types of fields can be "wider" too, e.g. the "flags" field in linedef_t is an "int" (32 bits) whereas the on-disk structure uses a 16-bit value (a "short").

       

      The EPI endianness conversion functions need to be a specific size, like 16 bits, since they need to work on the raw representation of binary data.  If you are reading the value into a different struct, you can have a wider type (like an "int"), but you don't need any extra endianness functions, in C and C++ integers of different widths are automatically converted.

       

      (will answer the other question later)

  3. The translevel/hdr_size stuff is safe to be completely removed, I am intentionally leaving out the translevel stuff and using the single struct to handle all cases of it; we do this in the column drawing code anyway. In r_image, I restored the rpat->origsize buffer and got rid of that custom rolled one so it's read like the other EPI_LE_S16(pat->[]) values.
  4. We did at one point. But it got sidetracked as bigger features that were in higher demand were done first (OpenAL is a big one, finishing up polyobjects, UDMF, COAL stuff, ROTT). Maybe we will revisit it sometime, maybe not, but the important thing there is that we get all of those issues done first. We know that UDMF is in demand for better map support, things like OpenAL are necessary to replace horrid SDL2 audio and all the features that have been long requested, etc. Split screen though needs to be addressed first however, the input reworking is sort of a big deal right now as major parts will need to be added onto for configurable controls across both players. Which, once splitscreen is done, will pave the way for at the very least LAN play across a network. Haven't looked into it heavily as it was def in a state of flux, having been reworked a handful of times across development of the engine.
  5. That's precisely why I haven't had the team take on that solution - all of the engines I've seen that moved to such a model did it very early in their development cycles. It would be too daunting for the team to rework EDGE for such a thing when there's more practical work that needs attention. If we had someone skilled in such a task and had a coordinated way of going about it - fine, but we aren't in that position to allocate resources in a huge way. It is an issue we will eventually address (as its even listed in our Git issues, so we talk about it from time to time), but will probably end up going with something like the first suggestion if/when we get around to it.
  6. Thank you Fanatic! Very honored to hear this from you! PS: QDoom 1.01 works great ;) Also, we have just released EDGE-2.1.0-RC1.5 via SourceForge. This is a very small bugfix that makes screenshots work in both JPEG/PNG formats again. It also contains slight additions for ROTT support and a few QDOOM 1.01 fixups ;-)
  7. Found an additional serious bug: PNG screenshots are broken (due to our new image backend code) - we are working on a fix. Sorry for the inconvenience! FIXED IN RC1.5!
  8. The resolution changes depending on what your screemode is (window or full). You can also explicitly set EDGE to start up with the resolution of your choice. I'll add that into our possible screenmodes enum just in case though! @VGA From the Readme: Try running EDGE with those command-line parameters and let me know if it works out.
  9. @wesleyjohnsonI was waiting until we released RC1 (today) before I switched us back to the Git versioning system. That way RC1 will be uniquely identified in this point of history without tags or commits. I'll check out your PM later today. Without further ado: EDGE 2.1.0-RC-1 has been released via SourceForge! Binaries for Linux are coming later as I didn't have time to compile and upload before work! https://sourceforge.net/projects/edge2/files/3DGE binaries/2.1/2.1.0/RC-1/ There is a huge list of changes between 2.1.0-Test3/2.0.4 and 2.1.0-RC1, so make sure to check out the CHANGELOG. Downloads are available currently for 32-bit and 64-bit Windows platforms. This release candidate is one of many that we are putting out before 2.1.0 Final, in the hopes that we can catch bugs and serious issues before the final launch. Attached is a listing of the currently known bugs in the engine - before you ask for help, please look here first.
  10. The problem is that you need to have your IWAD in the EDGE root. EDGE can also read from DOOMWADDIR and DOOMWADPATH variables, respectively. We have been brainstorming a way to write an IWAD selector, ala ZDoom or Eternity - but have not came up with any solutions as of yet. Are you building from source? Make sure 'edge.epk' is in your root folder with all of the other folders/dll, and copy/paste your IWAD in the folder. I'm working on "couldn't open file" to be a little more verbose, as well. EDIT: Big ol' long spiel about video cards and drivers -- turns out EDGE was issuing an extra glFinish command when it was being done a little earlier in the I_FinishFrame loop. Dumb bugs like that always kill me!
  11. Coraline

    Complete iwad list

    Also, speaking of the IWAD list, we need to add "Rise of the Triad: Dark War" - since EDGE validates it and work is ongoing to support the game.
  12. I apologize for the outdated information - lib_versions.md was written while we were in a transitional state from Make to CMake, and I honestly forgot I had created that document in the first place. Alas, I have updated it for completeness' sake. Note that we only need six out of those ten libraries now -- once OpenAL support is finished we won't need libogg or libvorbis either. You are also free to use the setup scripts in the directory /quick_setup_scripts, but I have only really tested on x64:Xubuntu so I can't say for certain if those scripts will work for Slackware or not, or if a custom one will need to be rolled. Please try the updated instructions out and let me know if you are still running into problems.
  13. Andrew, feel free to join and/or comment/observe on the discussion of the EDGE/3DGE Wiki merge:

    https://doomwiki.org/wiki/Talk:EDGE

     

    The new article I linked to (on the EDGEWiki) has a much more involved history, and I gathered most of them as factually as I could from old releases, changelogs, and other archival websites on the history of DOSDoom and the move to EDGE. If anything is incorrect or needs to be revised (since you were there from the beginning, you might remember more that is left out and/or possibly incorrect), you are 100% free to do so and/or comment at will.

    1. andrewj

      andrewj

      Thanks for the heads up.

  14. The software renderer was dropped with EDGE 1.29, which was released back in 2007; EDGE was still in active development by the previous team. Funny that you mention that -- I've been working on it, but honestly I can't seem to wrap my head around how other ports manage splitscreen controls and I can't figure out how I had fixed it before. I don't think I committed those fixes at the time, unfortunately - if anyone has any knowledge or advice about how to get both players to handle sharing inputs without a completely separate TicBuilder for the second player...please let me know.
  15. Thank you Andrew! We are truly humbled and honored by this! :) Well, it is still referenced by some as 3DGE/hyper3DGE and we acknowledge anyone calling it that. When the port started off it was rocky (from an abandoned branch of EDGE), suffered from numerous technical issues, my knowledge was limited, and EDGE 1.35 was still unreleased; hence the port needing a different name at the time. Over the past few years, our team has put in so much dedication and hard work into the engine; in order to lessen the confusion and the existence between the two, we agreed to officially continue the port as EDGE and will herein reference it as such. The torch was passed and acknowledged. Besides, a lot of what my team has worked on were things that the original EDGE team wanted to do but did not have the time to implement; if our team was involved with EDGE back when Andrew Apted was still working on it full time, we would have continued development under the existing name without issue. I am not sure how this will affect its Wiki standing; I'll have to consult with the DoomWiki administrators, but really it's not that big of a deal. We'll keep the separated SourceForge websites, but we have already merged in EDGE's complete SVN/CVS history into our Github repository and moved most of the documentation over, so it only makes sense from here on out.
  16. Coraline

    3DGE Splitscreen Help (controls)

    @BlackFish The way it is set up now is to have player 1 always use the mouse/keyboard, and player 2 always use the gamepad (or maybe it is reverse, I can't remember offhand). Make sure the joystick has nothing assigned to it for player 1 (the default, normal set of controls). By default, starting a game should have player1 use the keyboard/mouse, and the other should use the joystick automatically. I have tested this (and played through CJ's Batman Doom fixup) with my brother the whole way through with this method a few months ago for EDGE, and it all worked flawlessly. I think I even have a video we recorded of us romping through it that I don't think I ever got around to uploading. . . EDIT: It appears that something else broke this from the time it was working until now (maybe someone merged or overwrote something, not sure what happened). I'll work on it ASAP (thank goodness for Github). . . sorry about that!
  17. So, now EDGE can read 100% from ROTT (DARKWAR.wad) without any hacks (except essential images EDGE needs to operate), but now this happens:

    shot01.png.491d92cb377224e6b4dc1ea9e714cf03.png

    Does anyone here know enough about how DOOM's patch -> column rendering works, and how it would need to be modified to load in graphics that aren't row-major? (e.g. column-major, w*h)? 

     

    I know how DOOM's works, but the problem is, it is reading them in as if it is assuming row-major from DOOM's patch_t format, rather than column-major from ROTT's patch_t format. 

    1. Voltcom9

      Voltcom9

      It's awesome to hear such progress has gone on with the ROTT support. I'm eagerly anticipating this next 3dge release. It's odd that the palette was changed like that.

  18. Looking for feedback for the latest x64 Devbuild of EDGE, as we've successfully created

    a 64-bit version of the engine. If you guys could please test and let me know if everything

    seems okay, I would *really* appreciate it! Make sure you have the x64 MSVC redists

    installed and/or up to date! Thanks! :)

  19. Coraline

    Announcing AJBSP

    On this topic (while we are mentioning glBSP) -- as per discussion with @andrewj, the version of glBSP in the EDGE repo that we plan on releasing externally (v2.28) will be appropriately renamed edgeBSP (or eBSP for short) once we release it stand-alone. We have made changes to the command-line and the overall glBSP code (such as supporting the building of glNodes via WADS embedded inside of archives, CMake support, C++ refactor) and other small tweaks (integrating the never-released changes from Andrew's glBSP 2.27). I am in the process of updating the GUI (glBSPX, which will just be named eBSPX). Internally to EDGE's source code, eBSP will still be named glBSP, but as far as new releases we make -- they'll be called edgeBSP/eBSP for now on. It's considered a direct continuation of glBSP, so I just wanted to give you guys a heads up to avoid any confusion there. As soon as I have everything built stand-alone and do some bug-testing, we will make a new release at the SourceForge website. However, we are planning on integrating ajBSP nonetheless (since we support edgeBSP, zdBSP, and TinyBSP for ROTT/Wolf3D) and making a small side-launcher to pick your preferred nodebuilder (instead of command-line switches). EDGE however will always default to either edgeBSP for GLNodes, unless the map is in UDMF format, which our internal version of zdBSP takes over to build nodes for UDMF). TinyBSP is always used for Wolf-based conversions as well, and at one time, was used to build glNodes in EDGE 1.32/1.36. @Jon I will look into making updates to the command line switches for edgeBSP once we release it!
  20. Coraline

    Block Rocking Bytes

    Some potentially useful info (via EDGE-2.1.0pre-7800-g740de2002): ------------------- MAP01: P_SetupLevel: Load GL info (glBSP) GenerateBlockmap: MAP (-1216,-320) -> (352,640) GenerateBlockmap: BLOCKS 13 x 8 TOTAL 104 Blockmap size: 13x8 --> Lightmap size: 4x2 Created 21 seclists from 56 vertices (37.5%) ------------------- MAP02: P_SetupLevel: Load GL info (glBSP) GenerateBlockmap: MAP (-1189,-335) -> (379,625) GenerateBlockmap: BLOCKS 13 x 8 TOTAL 104 Blockmap size: 13x8 --> Lightmap size: 4x2 Created 21 seclists from 56 vertices (37.5%) ------------------- MAP03: P_SetupLevel: Load GL info (glBSP) GenerateBlockmap: MAP (-1216,-352) -> (480,640) GenerateBlockmap: BLOCKS 14 x 8 TOTAL 112 Blockmap size: 14x8 --> Lightmap size: 4x2 Created 23 seclists from 63 vertices (36.5%) ------------------- So far, the first two maps render without error, but MAP03 does have a texture issue, I've attached two shots.
  21. Coraline

    QuakeDroid - A perfectionist Android Quake

    Getting a red tint to the screen renderer, using an Alcatel Idol 4S - would love to fix it and bugtest for you!
  22. Okay, so got inspired by the GZDoom post :D Since we are almost done with the bugfixes, its time to move onto features :) Anything from DDF to other game support (etc), would like to hear some suggestions ^_^ Thanks everyone for your time ^^
  23. Coraline

    Features you would like to see in EDGE

    Sure, that can be done in COAL. I can just bake it into EDGE (so I think we are up to 4 or so choices for the HUD) for the next release. @SiFi270 you mean something similar to how prBoom shows the stats during gameplay, right?
  24. Coraline

    Do any Doom ports support Ambient Occlusion?

    I have thought about coding it in EDGE, we will see what happens :)
  25. Coraline

    Features you would like to see in EDGE

    @Death Egg is right. Heretic and Chex Quest are supported already (for Heretic, we still need to implement some sort of inventory handling in EDGE). DeHacked works fine, too. Hexen still needs ACS(vm), and Strife is completely doable but I don't have much time yet to code that game (I instead chose to work on ROTT, but that even feels like too much at once). I would much prefer focusing on things that need attention (bugs being fixed, BOOM 241/242, UDMF, IWAD selector, engine speedups, scripting language enhancements).
×