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

Coraline

Members
  • Content count

    1185
  • Joined

  • Last visited

Everything posted by Coraline

  1. Such a great magazine - concept, design, and readability are all 💯! Personal shout out to the designers and writers for including the dedicated EDGE modding community and their projects! I appreciate it! 🖤
  2. Coraline

    Need advice for a source port

    So apart from the multitude of technical reasons why I can understand and empathize these kinds of reactions - for YOU as a new user of EDGE - what in particular turned you off? Could you kindly provide the build/version you ended up using? Sounds pointless...but without this kind of data, well I will never know what I'm "okay" with when it comes to EDGE, and what most of the populous aren't. My perspective has never been on point.
  3. Coraline

    M.E.G.A. Project: Making EDGE Get Active

    How did I miss this? Great to see you again @Lobo. I had to double check the dates on this thread :D Hopefully this will encourage us to get EDGE 2.1.0 cleaned up and released. Might channel you for some port-side integration since we still don’t have any form of a launcher or GUI, apart from a short-lived autoexec type file..
  4. Coraline

    Coronavirus pandemic chat [no medical advice plz]

    It’s pretty sad. I’m a computer engineer at one of the biggest trauma hospitals in the Central Valley all the way to the Bay Area, and I had to help set up the C19 tents and machines/printers/etc. I get paged out to it daily and nightly - it’s very sad to see people so scared and when you are in there, you look like the doctors and nurses and it’s painful to have to tell people that I can’t help because they are panicked. As I go everywhere in the entire district (3 hospitals, business offices, etc) and practically nothing is off limits to the work I have to do, we are like #2 at risk or something. I’m not overly worried, though. The only thing that I’m depressed about is not seeing my daughter as I live in another smaller county in the Central Valley, I’ve been staying away from practically everyone outside of work just to be precautionary and she absolutely comes first. The way I see it, those machines aren’t going to fix themselves and as long as I keep washing hands, wearing a mask and gloves as I go through the hospital and practice normal hygienic procedures everything will be fine. Shame that this whole thing couldn’t have been handled much earlier and that the government had to wait so long before declaring and rushing everything through.
  5. I’ll test in EDGE and check it out! The old Zombies TC add on for EDGE was what got me into modding in the first place - so this warms my jellies 🥰
  6. Coraline

    New mobile ports (iOS, Andriod)

    It appears to be a continuation of the previous port which is even stranger...
  7. 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!)
  8. RC2 was originally slated to be released but it had some bugs. Figured I would refrain from release until they were further worked out. So we are just skipping RC2 and moving to RC3, which will be released after some end-user testing. Versioning is still a mess but once we merge the base_ddf branch we will officially mark that release as RC3. (Still getting used to git, but at least it is much easier than svn). I pushed current devbuilds to DRDTeam that I would request be play tested; made some changes to the external script location (instead of XXX_ddf folders in root, they are all contained in /base) to keep the root directory simpler. Does not affect internal scripts in archives which are still expected to be found in the /scripts namespace). Other things have been fixed too since the last November builds - please if anyone has time, test them out and report any bugs. I will try to push Linux versions there too. Framerate should be smoother in these builds and I finally fixed the ghosting square in the lower left corner of the screen bug, as well as the solid black screen, upon resolution change. Also got SDL2 mouse-grabbing functional again (now, it is using relative mouse mode). Made some more improvements to the SDL window management. Full screen is still broken (framerate tanks terribly), so I recommend using windowed modes - in EDGE they are border less. Also some COAL additions for player<->camera tuning. Still working on demos, and still working on Wolf3D/ROTT support. Recently took a look at networking code and thinking about implementing a model closely tied to Doom64EX's netcode, but splitscreen needs to be fixed first. Controls still need some tuning IMO, plus they aren't working again for Split screen. Anyone with some decent SDL2 experience would be highly welcome, because EDGE's hand-rolled code for joystick/etc management needs a desperate rethinking. If you guys' can test out those Windows builds that'd be great! If you have AMD/Radeon video cards and getting bad framerates (like I do on my RX580), check out this article on the EDGEWiki for AMD Settings adjustment to fix the problems. AFAIK nVidia users are covered and won't need to tweak anything ;)
  9. @wesleyjohnson from @Chilly Willy: I do the same thing for Xubuntu, so I would need a bit more info on how you have your setup configured. Also I'm updating the Git shortly with the ROTT fixes. I've learned some interesting information though, which I'll share on your wall in a bit. Still not completed, but it is being attended to, we promise. Gah, great catch! I forget how fun Bots are (used to do Botmatch in my old Blood/Hypertension TC). I will patch it so it only affects the player(s) being displayed currently. I'll probably fix it in a devbuild. @VGA I added your resolution to the possible modes list for SDL2. That'll also be in a devbuild due to be uploaded shortly.
  10. 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)

  11. 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.
  12. 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.
  13. 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.
  14. 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 ;-)
  15. 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!
  16. 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.
  17. @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.
  18. 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!
  19. 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.
  20. 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.
  21. 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.

  22. 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.
  23. 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.
  24. 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!
  25. 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. MidnightMage

      MidnightMage

      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.

×