Coraline
-
Content count
1197 -
Joined
-
Last visited
Status Updates posted by Coraline
-
Good to be back, finally got over my job stress, light depression, and housing move. Thought I was finished, glad to know that indeed wasn’t the case .. 😝
Picking up where I last left off on EDGE, I’m ready to make the last bigger commits and some things that were promised but only half implemented at the time. And of course, cherry picking some good stuff from the Classic port w/o breaking EDGE.
First full release since 2016? Didn’t realize it’s been that long…! -
Three days ago was EDGE's 20th birthday! <3 What are your fondest memories of EDGE? What do you think about the current development builds of the engine, and do you believe it is heading in the right direction? Do you think there's still room for the port and the unique offerings it brings in 2021?
Finally, if you haven't tried it lately, give it a spin!
SpoilerWhile I was working hard to try and get a release out in time for the celebration, I was of course unable to (day before was my daughter's 8th bday) and I feel like crap about that. Originally there was to be this big ol' thing and a new release with all bugs fixed and stuff but it just didn't end up working out like usual. We are a small team again and just can't always find the right time to all hook up and hammer things out together. So ya...always looking for help... :)
- Show previous comments 1 more
-
I remember I used to have to go an "internet bar" with a couple of diskettes to download DosDoom which later became EDGE.
-
I recently started mapping again for a project targeting EDGE and it's been pretty enjoyable for me. I played a lot of EDGE mods back in the day and remember it fondly.
The first mod I made for EDGE was for myself and my cousin, and it was a mod where some of the demon enemies dropped ammo for their own attack. We had several different weapons that all used the same punching animation but shot the different enemies attacks back at them. It was a really awesome feeling killing some of the demon type monsters and gaining some amount of ammo or "power" out of them, throwing imp fireballs at shotgunners & chaingunners, baron of hell attacks at pinkies, etc... It was even more awesome to be able to put that all together just by editing some text files. At the time I loved playing around with the Duke3D .con files, and was blown away that there was something like that for doom.
Anyways, I thought I'd share a memory that this post dislodged.
-
That’s awesome @compy286! Sorry a bit late to respond, but I’d definitely be interested to see what you/the project/etc produce!
-
Hey Doomworld - Low key, looking for beta testers for EDGE as we prepare for our first full release (at v2.2.0) in the coming month.
It’s been over 2 years that we’ve been in bug crunching mode via DRDTeam and are confident EDGEs serious issues have been mostly addressed. There are way too many to list here that we’ve since fixed (everything from physics bugs to dehacked parsing) so I’m hoping the port speaks for itself in terms of our progress. We also release Linux devbuilds now, too.
if it’s been awhile since you’ve tried EDGE, or have never played it before, get one of the current [url=https://devbuilds.drdteam.org/3dge/EDGE-x64-2.1.0pre-155-gb7b9af898.7z]development builds[/url] and give it a spin.
Make sure you have an IWAD in the directory. If you wanna play with DOOM and DOOM2 at the same time, make sure both are present, and drag and drop Doom.WAD over EDGE. Or go all out and drag both Doom and Sigil together over the EXE for the full 6 episode experience - it’ll resolve Doom2.wad automatically. 😊
You can report bugs or make suggestions either at our forums (http://tdgmods.net/smf) or at our Github (http://GitHub.com/3dfxdev/EDGE). Or you can always reach out via Discord, which ZDoom kindly hosts our channel via their server. Or just shoot me a message here on Doomworld. As we get closer to release we will eventually open up a thread here, too.
Thanks to anyone interested and I hope everyone else finds some fun to be had with EDGE!
Kindly,-Corbachu
-
Dear Doomworld and EDGE-bois,
My apologies about the lack of EDGE devbuilds lately - my time has been eaten up by my job, full-time single parenting, WFH, specifically I’m doing a universal Win8.1 and Win10 IPU (from Win7 and Win8.0) for the hospital I work for, on about 3K endpoints with 1.5K different softwares and preTPM fuckery, Windows patching and ugghhhh ...during the COVID pandemic...talk about stress and OT out the ass. Plus raising my daughter by myself with online school at the same time... 🤪
But regardless, it’s a passion project that led to my rapid promotion and current team...it’s not easy but at the same time, it’s an incredible passion project since WindowsNT first came into my life in enterprise... anyways, just wanted to explain that to everyone. EDGE is still placent in my heart and my passion is still there even if it seems I am quiet and not making a lot of releases.Tl:dr : Be safe, wear a god-damn mask, be smart and get vaccinated when it is available! Positive vibes and love to my DW and EDGE families...xoxoxo ♥️❤️🙏😷😘
#EDGE2021
-
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. .
-
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)
-
-
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.
-
So, now EDGE can read 100% from ROTT (DARKWAR.wad) without any hacks (except essential images EDGE needs to operate), but now this happens:
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.
-
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! :)
-
Sorry everyone for the lack of work on EDGE...radiation sickness is kicking my butt (my own dumb fault)...
Quick, someone type in IDBEHOLD!
- Show previous comments 1 more
-
-
Yeah, treatments + antibiotics apparently don't go well together, and I completely forgot to mention that I've been on heavy antibiotics for the last month or so, but it'll pass. Usually its only mild symptoms, but this time it felt like my whole body was shutting down; puking, dizzy, bowel pain, head pain (doesn't help that I have sinusitis and two inner ear infections I guess, and on top of that my 3rd umbilical hernia surgery spot got infected god knows why, thinking stitches or something), but I'm still at work pushing through. Ugh. I'm on perma-STFOUCH today it seems :/
"Picked up a Medikit that you REALLY need!"
-
-
Anyone else tend to get C and C++ mixed up? Maybe because EDGE, while C++, writes a lot of stuff using C style. So annoying when I make a dumb mistake like that, maybe it is my ADHD? Bleh, makes me feel like a novice sometimes :-(
/rantover
-
The EDGE team is proud to present EDGE 2.1.0-Test3! Grab it from Sourceforge:
https://sourceforge.net/projects/edge2/files/3DGE binaries/2.1/2.1.0/Test-3/
There are such a massive amount of changes, bugfixes, additions (like ZDoom/Vavoom/etc UDMF support, PolyObjects, DDF improvements and additions, Camera-Man Scripting engine, and completely fixed framerate interpolation/Vsync, and lots of speed additions)!
Far too many changes to list here (see CHANGELOG.txt for more information...and I KNOW I've left out a ton that can be found logged on Github).
Test2 should now be avoided LIKE THE PLAGUE!
The things that we didn't have time for that will be on the roadmap for 2.1.0 Final:
* Complete ROTT support
* Complete PolyObject support
* GUI-based IWAD Selector
* Multiplayer
* More GLSL shaders, including a compiler at run-time for custom user-made stuff
* Inventory Support (Heretic, Hexen)
* heavily-optimised BSP walking/rendering
* Finalised BOOM support
* Even closer compatibility to ZDoom, like ACS, etc.
There are so many people to thank -- the wonderful EDGE programmers (especially Andrew Apted), the stupendous EDGE community, the amazing GZDoom team, our friends from ZDOOM, Quasar|Eternity/Fraggle/etc, the amazing programmers here at Doomworld, and all of the contributors that have helped preserve the legacy of DOSDoom/EDGE. So much to do and not enough time to do it :-)
So, enjoy! Keep reporting those bugs, and if all goes well, 2.1.0 Final won't be far off! Sure as hell won't take us another 15 months for a release, but that's what hard work and a dedication can do sometimes...lol! :-D
-
ROTT Progress:
Now I have walls loaded in properly with the correct colors from the ROTT PAL, but the images still need to be rotated 90 degrees. There is a command in DDF to do this automatically, but I'm just lazy for now.
So far so good. Can't read in skies yet (that's a dummy sky EDGE loaded in), question marks are missing sprites, HUD is non-existent -- though I do have dynamic lights working and overall the colors match up correctly. The game feels so much better at a higher framerate, with diminished lighting and real dynamic lights ;-)
Though now I see what palette problems some other EDGE users have with the engine, which is noticeable with the flamewall block -- those black pixels. . .
-
Thanks! <3 so far so good! ^_^
Turns out some of the menu patches are in yet ANOTHER format (pic_t, which I believe is from the DOOM alphas), so I gotta write a pixel translator for those too. Overall, its coming together much quicker now that i have a clear understanding of the IWAD formats.
Next up, coding in player classes (which will be instrumental for Hexen support later too), and after that is all finished, going to work on the BSP translator and pushwall code.
Glad you are enjoying the progress :-) it'll be nice to have a modern, extendable source port for ROTT at any rate ;-)
-
-
ROTT progress screens:
Not much to show yet, both are still using the EDGE/DOOM traditional menu system for now, but we have patches! :-)
-
Also, this, but you can see the color issues. The patch was converted internally and then modified to match the ROTT pal, but I already figured out how to load them in as-is from the IWAD to use ROTT's global "PAL" (like Dooms PLAYPAL). This was just an earlier screen of progress :-)
-
That is definitely on the roadmap. Birgir and myself have a whole host of things we want to do with EDGE and ROTT and that had been discussed :-)
Though really, you'll want to just use UDMF as ROTT can take the biggest advantage of that format :-)
-
-
General question to all DOOM port authors:
When supporting multiple games in the engine, is it a bad idea to use a global book value for them upon IWAD detection? Wondering if there's a cleaner way, or maybe I'm doing it right (or wrong). :-)
-
ROTT Progress Update:
With some debugging help from @Blzut3 and @Gez and tech assistance from @fraggle and fellow EDGE coder @Chilly Willy, EDGE can now read in the ROTT patch format. There is still some work to do as certain masked textures use a translevel short, which will be read and translated by EDGE further down the road. Huge milestone as now I can get to work on the basic things (VOC2WAV), get other raw image formats from ROTT working, and the main menu coded in. After that, the BSP translated from Wolf2Edge will be overhauled to support moving and regular pushwalls (the tech side of it has much inspiration from Rebecca's MacWolf port), and the conversion of GADs to true 3D things via DDF. So, its coming along well, and I'll attach what I have so far in the repo tonight. And also. Maybe a screenshot or two :-)
While offsets are now correct for images, some patches (ROTT's CURSORx) still won't display properly, as I suspect it might have to do with the translevel in ROTTs masked_patcht struct.
Other than that, supporting the basic ROTT patch format was one of the biggest hurdles, and in the coming months, hopefully sooner rather than later, we will have a source port that can fully support ROTT with some extra features. :-)
Special thanks to Doom's wonderful programmers for taking time to answer my questions!
- Show previous comments 1 more
-
:-) That's what makes the DOOM community special is that we all can rely on each other when we need the help ^_^ albeit I don't get too annoying ;-)
-
I really hope that you'll succeed, as the only moderately usable ROTT port (winrott) dates from like 2005, crashes all the time, has broken netplay and is generally kind of a pain to use. The game being a pain to play doesn't help it either, but that's another story. :]
So, umm, thank you for being you, good luck, all the usual stuff. :]
-
-
ROTT progress update:
While I continue hunting for the best way to convert all graphics from the ROTT IWAD to DOOM formats, I have successfully gotten VOC playback (fixed only to ROTTs format) working. Right now it uses SLADES VocToWav, which means the engine has to preprocess the sounds before the game loads, but I'm thinking of going the extra step eventually to support true VOC decoding and playback using EPI's sound_data_c class.
I have also completed the ROTT->DOOM map conversion utility with Birger's help, which runs at startup, then passes the data over to glBSP for processing (which will save to the /cache folder as a GWA). Still need to complete ROTT-like pushwall support though. That should be uploaded sometime later tonight. On the topic, the author of Map2Wad has also been working on his custom EDGE-side conversion utility for Wolf3D's map format, which will also pass the data to glBSP for conversion.
In short, so far so good. I can't wait until the hard work is finished so we can have the defacto port for Rise of the Triad via EDGE :-) Dream is coming true.
Special thanks to all the programmers for helping me on this quest (Gez, Birger, ECWolf, dpJudas, among others), but I'm proud that this will be supported :-)
Any suggestions to the graphics issue? I'm all ears. I was partial to converting the data to PCX, but I might end up going the PNG route instead, that way the images can be defined inside of Images.DDF.
-
ROTT progress report:
I'll be creating a branch in the EDGE repo for people to test ROTT tonight :)
Birger Andreasen, the developer of WinROTT and WinROTTGL has kindly teamed up with me to bring true ROTT into EDGE, which is even better now because he is well versed with it :-)
-
ROTT -> EDGE progress report:
The layout of the ROTT IWAD took a little longer to hack together into EDGE than originally anticipated, partly due to some strange image formats, but I should have something to show tonight. The only 3 graphics I had to copy into the ROTT namespace inside of edge2.pak were the raw 320x200 images (converted to Dooms patch format) since writing code for just 3 original ROTT raw images plus 2 SNEA images would be a little overkill. I hope people don't mind, but are there any other better suggestions?
Next up, I'm working on the menu system (the flipping background), but I'm not going to mirror ROTTs exactly since EDGE uses a common menu for all supported games, but at least it will support everything the original did.
The only real addition I need to add is the player classes, but I'm just going to copy the players into PLAYER1-5 via DDFTHINGS and have it work like that. After that, everything else should work out! Then the hard part comes (RTS for GADs, DDF for gamecode), which will take the most time.
-
I'm very interested to see how this turns out, while I keep waiting for ROTT support on ECWolf.
-
Definitely! In EDGE its a bit trickier since I'm handling most graphics as a secondary sprite/patch_t format, AKA different to how ECWolf does it. But that port and its author have been very forthcoming in, for instance, handling the namespaces for the ROTT patches than can be loaded into the pseudo-combined patch_t format.
Then there's the whole process of converting the RTL data into BSP format which glBSP can then dissect into a normal DOOM map (where ECWolf AFAIK uses an enhanced version of Wolf's raytracer).
Now, in the original DOOM, and by extension EDGE, sprite names are supposed to have 8 characters -- in ROTT (shapes) are varying character lengths, so I wonder if I should pad the sprite names or just have EDGE ignore that limit for ROTT shapes.
Ideally what I should do is support something where I have the namespaces already defined in edge2.pak (empty), and have PHYSFS/w_wad.cc just insert markers that way, since the way I do it is through the normal DOOM sprite/flat/texture markers...hmmm...
-
I also briefly considered converting the entire IWAD at runtime to a format similar to how glBSP caches maps (GWA) or even as a PAK, and that way it can generate a clean base instead of doing the insane amount of marker inserting/etc I have to do currently with ROTT data..but it might take longer than I would like it to...
-
-
Rise of the Triad: DARKWAR support in EDGE is making good progress! Someone wanna help write the DDF? I'd be forever grateful ^_^ screenies should follow tonight or tomorrow!
Also, EDGE 2.1.0 Test3 is releasing tonight with a huge amount of bug fixes, some new features, and better stability than Test2 :-)
-
Port Authors: how do you guys handle the grab chunk? It works great for PNGs that are not player weapon sprites. Might have to alter some code further down the chain. A printf let's me know that the grab offsets are applied correctly (checking in SLADE and grabpng), but for some reason HUD weapons are SOL. Any suggestions? :-)
-
@Everyone: What is one big (but totally essential) thing I can do to improve 3DGE's user-friendliness? Having automatic IWAD detection/chooser? Improving the menu layouts/fonts? 3DGE's 3D physics? While the team has a feature set we are slowly tackling (between different team members), I would like to personally ask all of you. I know people have heated opinions about 3DGE but I'm *really* trying to change that, and it would definitely help taking a "poll" of what the port absolutely needs to improve the end-user experience. Thanks guys and gals!!! <3
-
Getting ready to announce this total-conversion (3DGEKatana) in its own thread! If anyone sees this before I announce it properly, I am looking for at least one mapper (UDMF preferably) - and of course, it's for the 3DGE source port. Not only is it a Daikatana themed TC, it's using new models, new skins on old models, new animations for old models, sounds, music, modified textures, and voice overs!
-
3DGEKATANA: Thought this might be a good time to casually talk about this. It's a project I've been working on for awhile now in secret, utilizing the best parts of Daikatana with the best parts of my unfinished QDOOM 2 project.
While this is based on Daikatana, it does not follow the canon. Rather, it takes place after the ending of 'Daikatana'. Mikiko has been kidnapped by a new villain (still working on his name), who plans on using her knowledge of her father's technology to carve a hole into the Earth dimension, letting demons and other apparitions through to our world.
It's now up to Kaeko Ebihara (pictured in red armor), Mikiko's twin sister, to track her down, find the bad guy, and seal the tunnel. Short, sweet, not overly complicated.
So, obviously it's a project exclusively for 3DGE. It utilizes some beta material from Daikatana, including parts of the skin I put together for Kaeko's model (which is why Mikiko's overall model is different). It will only utilize a few weapons from the main Daikatana campaign, while using some of the monsters, weapons (no more god damn wall-bouncing projectiles!), and other things from Episode 1 and Episode 4, respectively. Part of merging QDOOM 2 into this project is that most of the monster models came over (so you'll definitely see some Quake monsters/etc in here as well), as well as a few levels. Of course, the maps will use Daikatana's textures. Things like sounds will all be there, but a lot less annoying as I've tweaked the overall volume and repetitive nature of the sound effects. Only the beta music will exist -- the rest will be all new tracks, most of them created by Fanatic.
I don't feel entirely comfortable releasing screenshots until I polish some of the first level I put together for it. I'm no level designer, so I was forced to learn UDMF _mapping_ features in order to pull off some of the effects the Quake 2 engine can generate in similar taste. Though, it will be great to show off just what 3DGE and its GLSL shader/vertex-lighting system can do =)
Okay, enough talkie - when I get actual screenshots polished up I'll announce the project properly in a thread.
Feel free to ask any questions or whatever, I'm open to anything.
-
When people use 3DGE, I'm assuming you all set the monitor size to something like 16:9 or 16:10. In splitscreen mode, using those mods shrinks both screens - making it a bit too cramped. Is using something like 4:3 in splitscreen a big deal for aspect ratio enthusiasts? Using that mode on splitscreen at least makes the viewports use up the whole screen, allowing players to use the space to see more of their FOV.
BTW, Splitscreen renders correctly again as of this recent devbuild, but input separation is still ongoing (thanks Rachel!) ^_^
