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


  • Content count

  • Joined

  • Last visited

About Coraline

  • Rank
    Senior Member

Recent Profile Visitors

5952 profile views
  1. Coraline

    3DGE settings won't save.

    Sorry for the bump! I’ll fix it so these variables save in the next development build (I will mark it in our Bugs list if @Lobo hasn’t yet). It’s been a minute since I’ve been able to give proper attention to EDGE - or at the very least, compile new builds with all of the bugs we’ve been focused on correcting lately. I’ll make it a priority today.
  2. 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! 🖤
  3. 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.
  4. Hi Coraline, good to see you around still. Nice that you were finally able to change your username ;)

  5. 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..
  6. 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.
  7. I'm a fan of your Edge source port :)

    1. Coraline


      :-) It’s always very warming to hear things like this, especially from new users.

      I know EDGE has its quirks and sometimes work on our goes from slow to ludicrous speed, but I’m happy to hear you enjoy the port!


      Plus, hehe, this is definitely motivating on my part to continue doing what I do and I’m sure the other team members will feel the same! 


      Feel free to join our Discord, ZDoom+EDGE Official, I’m always logged in (as the others are as well), so I’ll always be available to help even if I get a little busy:



      We also have a Wiki for general Engine editing and other cool stuff:



      See you around! ☺️

  8. 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 🥰
  9. Coraline

    New mobile ports (iOS, Andriod)

    It appears to be a continuation of the previous port which is even stranger...
  10. 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 ;)
  11. @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.
  12. 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


      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)

  13. 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.
  14. 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.
  15. 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.