Copy Link
Add to Bookmark
Report

Doom Editing Digest Vol. 01 Nr. 160

eZine's profile picture
Published in 
Doom editing
 · 24 Apr 2024

From:      owner-doom-editing-digest 
To: doom-editing-digest@nvg.unit.no
Subject: doom-editing-digest V1 #160
Reply-To: doom-editing
Errors-To: owner-doom-editing-digest
Precedence: bulk


doom-editing-digest Wednesday, 15 February 1995 Volume 01 : Number 160

request
Re: DEU 5.3 Beta
Re: DEU 5.3 Beta
Re: almost objective editor comparison
Re: DCK 2.0
Re: DoomCAD BETA list
Re: DEU 5.3/editor comparison
BSP for unix
Sender: owner-doom-editing@nvg.unit.no
Re: almost objective editor comparison
Re: almost objective editor comparison
Re: BSP for unix
Re: DEU 5.3 Beta
Re: BSP for unix
Re: BSP for unix
Re: DEU 5.3 Beta
Re: DEU 5.3 Beta

----------------------------------------------------------------------

From: Ian Springer <ips@remus.rutgers.edu>
Date: Tue, 14 Feb 95 21:32:33 EST
Subject: request

can someone plz put up the Heretic wad that has a deep-water sector again?
thanx...(an explanation of how to create the deep-water effect would also
suffice)..

thanx.


- ------------------< Ian Springer (Rutgers College '98) >---------------------
ips@eden.rutgers.edu (general) ips@remus.rutgers.edu (computer science)
ips@usacs.rutgers.edu (USACS) ips@gandalf.rutgers.edu (honors program)
- ---------------------< http://remus.rutgers.edu/~ips >-----------------------

------------------------------

From: bmorris@islandnet.com (Ben Morris)
Date: Tue, 14 Feb 95 21:04 PST
Subject: Re: DEU 5.3 Beta

> >
> > > Finally! Its out! YES! Beta 1 is great...it just has those usual
> Could someone be able to tell me as to where I could ftp this file
> from, as I thiknk a renewal of wad editing is due.. :)
> Thanks
> Derek
> aka Hawkeye
> (byrneda@alf2.tcd.ie)

Don't get your hopes up.

Five months for a very minor update (and a buggy first one at that) .. I'm
not very impressed :)

Out of interest, have the DEU team been keeping up-to-date with any of the
latest versions of the other editors? They're all far more sophisticated
than the 5.3 beta is - FAR more.


- ---------------------------------------------- * --------------------
the felix of your truth will always break it / Ben Morris
and the iris of your eye always shake it / ..your typical CN
- -- "Iris" / Live -------------------------- / -----------------------
revel in your perception * bmorris@islandnet.com

------------------------------

From: tedv@geom.umn.edu
Date: Tue, 14 Feb 95 22:39:31 CST
Subject: Re: DEU 5.3 Beta

> Could someone be able to tell me as to where I could ftp this file
> from, as I thiknk a renewal of wad editing is due.. :)

If you are a beta tester, you should already know where it is. (It's in
the top secret beta tester's directory on bear.) But if you're not, don't
touch it. The bugs are rather disappointing. We're working on fixing
them though.

- -Ted
- --
Ted Vessenes | "The only force stronger than fate is dramatic irony."
tedv@geom.umn.edu | "[William] Shatner couldn't direct his way out of the
tedv@cs.umn.edu | bathroom with both hands and a map!"

tjvessen@midway.uchicago.edu -Ryan Ingram (1st), -Kibo's .sig (2nd)

------------------------------

From: GREG@HUNTER.POMONA.EDU
Date: Tue, 14 Feb 1995 21:29:45 -0800 (PST)
Subject: Re: almost objective editor comparison

>So please don't start more editor wars based on this document
>I'm very fed up with the wars we have already!

Wars don't do anyone any good. Civil discussion and comparison
are another matter, however difficult that may be to actually
achieve on the net...

>A comparison chart like this is also bound to be unable to capture
>the small things that makes editors nice to use:
>easy scrolling, nice preview facilities etc.

So forget the chart. I'll go ahead and make the same offer I
made in rec.games.doom.editing a month or so ago (to which I
got exactly one response): I am willing to compile a document
containing the collective net.wisdom regarding what a WAD
editor should do and how individual programs stack up. If you
have experience with a particular editor (either good or bad),
I'd be happy to have you e-mail me with your comments and I'll
try to collect them all into a useful format. If you are
willing to participate by providing some information, please
e-mail me. If I actually get enough people to provide a decent
amount of information I'll send back messages and let the info
start pouring in. As should be obvious, I'm not interested in
messages that simply say "<editor> rules/sucks", and opinions
on long-out-of-date versions probably are a little less than
useful. What I'm particularly interested in is evaluations of
the strong and weak points of each editor. From there, the
reader of the final document can make the comparisons that are
of value to him or her.

Sound good? Sound coherent? Let me know in the morning...

Greg Orman

------------------------------

From: DOOM Master <dschwenk@pepperdine.edu>
Date: Tue, 14 Feb 1995 21:53:03 -0800 (PST)
Subject: Re: DCK 2.0

> > > > I have also encountered this problem. My P90 has lock ups every few
> > > > minutes as well. It can't just be the P90...(unless because it is a
> > > > fixed chip. :)
<snip>
> Sorry, but the Pentium bug would have nothing to do with your system locking
> up. The Pentium bug is only a very rare accuracy issue with very specific
> Floating point divides.
>
> Is there something specific that you do when it locks up or does it just
> all of a sudden lock. It could be something in the code...probably memeory
> management that is causing it. Could you be more specific on what causes
> the lock up?

Sorry I started this whole mess about chips. It was just a joke.
I've had poblems with the DPMI. Seems to work now...

**********************************************************************
* Derek Schwenk | DOOM and iD = saviors of DOS *
* dschwenk@pepvax.pepperdine.edu | "Hell on earth is here. Rejoice!" *
**********************************************************************




------------------------------

From: matt.tagliaferri@pcohio.com (Matt Tagliaferri)
Date: Tue, 14 Feb 1995 19:42:00 -0500
Subject: Re: DoomCAD BETA list

DO>How do I get on DoomCad Beta list?
DO>Mike

General Post to the list: I'm going to TRY to ftp dCAD 6.0 beta to
ftp.cdrom.com tomorrow night. The operative word is TRY, because
my Netcom ftp access is dog slow and times out whenever it feels like
it.

matt tag
- ---
þ OLX 2.1 TD þ Dammit Jim, she's dead! Get off of her!

- ---------------------------------------------------------------
PC-Ohio PCBoard pcohio.com
The Best BBS in America Cleveland, OH
DATA: 216-381-3320 FAX: 216-291-2685
- ---------------------------------------------------------------

------------------------------

From: Bernd Kreimeier <Bernd.Kreimeier@nero.uni-bonn.de>
Date: Wed, 15 Feb 1995 12:43:35 +0100
Subject: Re: DEU 5.3/editor comparison

> From: bmorris@islandnet.com

> Out of interest, have the DEU team been keeping up-to-date with any of the
> latest versions of the other editors? They're all far more sophisticated
> than the 5.3 beta is - FAR more.

I haven't been keeping up with any editor lately, and my knowledge is
negligible. Thus I'd appreciate any editor comparison including:


> DEU PFME (your editor here)
>
> Full Source Y ?
> available ?
>
> Unix/X11R6 ? Y
>


To be perfectly honest, I have no idea if there is any other editor source
available. Anybody care to enlighten me?



B.




------------------------------

From: Robert E Arthur <rea@st-andrews.ac.uk>
Date: Wed, 15 Feb 1995 11:43:45 +0100
Subject: BSP for unix

OK - not having much experience with the machine-independant side of c
programming, I am trying to compile BSP12 for use with sunos. I am not
having much luck, however - it mis-reads the wad_header, giving a ridiculous
number of dir entries. Obviously this is due to a machine-indepentant size
of the long int type, but I am unsure how (if possible) to fix this, short of
a pretty major re-write.

The reason for trying this is as follows:

I don't have a coprocessor.
IDBSP hangs on the seg processing (due to lack of memory I think...)
NODEBLD (the one with DOOMCAD) has finally given up the ghost, and totally
screws up one of my rooms.
DEU12X (with EMU387) *completely* screws up. I have a feeling that it is the
blockmap, rather than the nodes themselves, since by using nodenav, the node
structure *seems* OK (though I am not particularly good at telling :) ). This
is the same problem as DEU521GCC's node-builder - DEU never gave perfect
results, but the GCC version completely screws up the level. Is there some
bug in EMU387?

Any other good, fast (on my machine, time is of the essence!) non-copro builders
out there?

Humph. S'pose I'd better get a proper computer after all :(

Byeeeee,
Bob.

------------------------------

From: Steven Lorch <lorchs@wasc.egginc.com>
Date: Wed, 15 Feb 1995 10:20:55 -0500
Subject: Sender: owner-doom-editing@nvg.unit.no

I too have noticed the gradual shift away from advanced editing
topics here on doom-editing. Like many of us, I learned a great deal
from the regulars here, and hope the list returns to it original
purpose.
In that respect, I have a possible solution. The DOOML mailing
list is now back up. DOOML covers Doom, Doom ][, Heretic and Quake
issues. I suggest moving iD - related posts that are off topic over
there.

To subscribe, send mail to : majordomo@doomgate.cs.buffalo.edu

with a body of: subscribe dooml

or

subscribe dooml-digest


Hope this helps to end the congestion here.

-SLorch



------------------------------

From: "Jason Hoffoss" <hoffo002@gold.tc.umn.edu>
Date: Wed, 15 Feb 95 10:55:27 CST
Subject: Re: almost objective editor comparison

Ok, here's an update to your list.. :)

> You've seen cheesy little comparison charts in the trade rags. Let's make
>one for mission editors.
>
> Here's my entry. If you can add any categories you feel relevant or
>distinguishing, feel free. User evaluations are welcome.
>
> PFME DMapEdit (Your editor here)
>Full edit
>capability Y Y
>
>multi-object
>selections Y Y
>
>Prefab
>operations 1 3 (note 1)
>
>Freeform
>sector N Y
>draw
>
>Multi-view Y N
>
>Multi-mission Y Very soon (half done right now :)
>
>Cut&paste Y Y
>
>Undo/Redo N N
>
>Built-in NODES
>builder 0% 100% (note 2)
>
>Built-in BLOCKMAP
>builder N Y
>
>Built-in REJECT
>builder N N
>
>Game
>support D2H D2
>
>Spawn doom session ? N
>
>3D preview ? W/S
>
>Demo support ? Y
>
>Supported Linux/SunOS DOS
>platforms X11R5
>
>Memory limitations ? XMS/EMS
>
>Compiled under ? DJGPP
>
>Cost $0 $10 shareware (note 3)
>
>
>Legend:
>
>Full edit capability: The editor allows the user to completely
>control every value in the resources THINGS, VERTEXES, LINEDEFS,
>SIDEDEFS, and SECTORS. It is not required to be able edit the SEGS,
>SSECTORS, NODES, BLOCKMAP, or REJECT resources.
>
>Multi-object selections: The editor supports operations upon multiple
>objects of the same type (thing/vertex/etc.).
>
>Prefab operations: A rough count of how many "prefab" operations the
>editor supports. Prefab operations include "make door from sector",
>"make lift from sector", "insert polygon", "arrange stairs". These
>operations must actually work in game terms.
>
>Freeform sector draw: The ability to draw a genus 1 object with a
>series of clicks and have the editor build a sector with the necessary
>sidedefs, linedefs, and vertices.
>
>Multi-view: The editor can maintain several views of the same
>mission with changes to the mission being displayed in all views in a
>timely manner.
>
>Multi-mission: The editor can edit and view several missions at
>the same time.
>
>Cut&paste: The editor can copy entities of any sort (sector,
>sidedef, linedef, vertex) of the mission from one place to another.
>If there is no way to place both sectors and things in the cur buffer
>for pasting, then the editor only scores 1/2. If the editor can
>cut&paste between different missions in memory, then score 2!
>(fractional scores for limited cut&paste ability are permitted).
>
>Undo/Redo: The editor has the ability to back out of changes or
>redo them (travel both directions through the undo history). Editors
>with only Undo score 50%. Editors that can not Undo in all cases
>score less than 50% (depending on how often during editing the typical
>user performs an indelible act).
>
>built-in NODES builder: The editor can generate the NODES, SEGS,
>and SSECTORS resources when writing a mission to disk. This is a
>percentage score which is an estimate of how solid your code is.
>Occasional fuck-ups rate a 95%.
>
>built-in BLOCKMAP builder: The editor can generate the BLOCKMAP
>resource when writing a mission to disk. This is a boolean. Either
>your code is correct or you're a bonehead.
>
>built-in REJECT builder: The editor can generate the REJECT
>resource when writing a mission to disk. This is a percentage score
>based on speed and accuracy of the algorithm.
>
>(10) Game support: Does the game support Doom I, Doom II,
>and/or Heretic?

Spawn Doom session: Can you run Doom with your test map from within the
editor?

3D preview: Either none, or what methods of viewing a map your editor
supports. W=Wireframe, s=Solid walls, S=Solid walls and floors/ceilings,
t=texture mapped walls, T=texture mapped walls and floors/ceilings.

Demo support: Can you run a demo/demos with your editor to demonstrate
various things? Something like Doom's lmp files. This may seem kinda
like a silly catagory, but I'm predicting it'll be pretty popular as more
people see DMapEdit's abilities in this. I think most other editors will
add this in.

Memory limitations: Mainly for DOS editors. Does your editor only support
conventional (base) memory? Or does it support XMS and/or EMS?

Compiled under: What you compile a program with can say a lot about it, if
you are a programmer. :) Can also give you an idea of what to expect, if
you are familiar with the strengths/weaknesses of a certain compiler.
Btw, Doom used the watcom compiler.

- --------------------------------------------------------------------------

Notes on DMapEdit:

1) Prefab operations are: Convert sector into Door
Auto staircase builder
Polygon creator

2) Node generator is 100% reliable now. I challange anyone to find a map
it cannot build nodes for. It is also 'the fastest node generator on
the face of the planet!' Since WARM made this claim of it's node
generator, and mine beat it, I guess it's my title now.. :)

Node generator build times for E1M1

WARM DMapEdit
11 seconds 9 seconds

Anyone else want to compare theirs?

3) DMapEdit is shareware, but it is not crippled/maimed/limited in any
way. There is no registered version. There is only one version. It's
all up to you to decide if DMapEdit is worth supporting. You are free
to use it even if you don't.

-Jason


------------------------------

From: "Jason Hoffoss" <hoffo002@gold.tc.umn.edu>
Date: Wed, 15 Feb 95 11:44:05 CST
Subject: Re: almost objective editor comparison

On Tue, 14 Feb 1995 14:08:11 EST,
Robert Forsman <thoth@cis.ufl.edu> wrote:

>Steve McCrea <sm@eng.cam.ac.uk> ,in message <199502141707.26072@club.eng.cam.ac
> .uk>, wrote:
>
>> Why do so few people know about dmapedit?
>
> Inertia. They find something that works and they are loath to invest time
>learning something else.

True. It also used to be hard to figure out, too, I think maybe. Dck and
Edmap came along later, and people talk about them now pretty often. I
think it really all comes down to a matter of advertising, actually.
People usually try out the editor they hear about the most, and almost no
one seems to say anything about DMapEdit except me. And I can pretty much
say whatever I want about it, and people will always consider me biased,
since I'm the author. People who don't give it a try and the one that are
losing out, though. Should at least give every editor you know about a
try, I think.

> I used DooMCAD for a while (it had the best consistency checking) and
>switched to deu5.21gcc when it came out (didn't have to boot windows). After
>that, I didn't even consider anything else (15M available memory is mighty
>swell). I would have just run with the DEU source, but djgpp had a habit of
>rebooting my machine and DOS sucks as a software development system.
>
> I need to take a look at DCK and DoomEd and a couple of others, but I'd
>have to ftp them, boot DOS, read docs (which isn't easy in a uni-tasking
>environment) and spend time figuring out what is and isn't there. One of
>these days I'll have to do that, but not now. Besides, restarting slip in
>the middle of the afternoon is impossible (lines are full).

All the editors seem to be getting better, making it possible to use them
without reading the docs, really. At least if you want to check it out
and see if it's anything you'd be interested in using. Usually you can
figure most of the stuff out, but not all of it. DMapEdit used to be
really hard to figure out how to get to the 'more advanced' type of
options. Now, however, everything is pretty much in a toolbar and menus,
so if you take all of 10 seconds max, you should be able to find what you
want. It gives you information about toolbar buttons and menu items at
the bottom of the screen, in case you can't figure out what something is
from it's name or icon. And with demos now, you don't even have to read
the docs, really. Just run a demo and sit back and watch as it teaches
you how to use it, explaining things it's doing along the way. DMapEdit
is probably the easiest editor to switch to from another editor. I've
worked hard to make it easy to use and work like you'd expect it to.
DMapEdit has changed a lot. The hard part is just trying to convince
people to give it a try.. :) The source code is also released with each
new official version release, just like DEU does. How many people are
aware of that?

-Jason


------------------------------

From: fenske@rocke.electro.swri.edu (Robert Fenske Jr)
Date: Wed, 15 Feb 95 10:53:08 CST
Subject: Re: BSP for unix

>OK - not having much experience with the machine-independant side of c
>programming, I am trying to compile BSP12 for use with sunos. I am not
>having much luck, however - it mis-reads the wad_header, giving a ridiculous
>number of dir entries. Obviously this is due to a machine-indepentant size
>of the long int type, but I am unsure how (if possible) to fix this, short of
>a pretty major re-write.
Your big problem here is little-endian vs big-endian. The SPARC
architecture is big-endian so all the integer fields contained in any WAD
file must have their bytes swapped to be interpreted correctly. So I believe
it would be tedious at best to rework BSP12 for a big-endian environment.

>Any other good, fast (on my machine, time is of the essence!) non-copro
>builders out there?
You can try my WARM program v1.1 (WARM11.ZIP) which I put on
ftp.cdrom.com the week before last. It should run on your machine using
the supplied EMU387. There is a SunOS executable supplied as well, if you
are so inclined to continue trying to work under SunOS.

Robert Fenske, Jr. rfenske@swri.edu Sw | The Taming the C*sm*s series:
Electromagnetics Division /R---\ |
Southwest Research Institute | I | | "The Martian canals were the
San Antonio, Texas USA \----/ | Martians' last ditch effort."


------------------------------

From: David Damerell <djsd100@hermes.cam.ac.uk>
Date: Wed, 15 Feb 1995 17:29:57 +0000 (GMT)
Subject: Re: DEU 5.3 Beta

On Tue, 14 Feb 1995, Ben Morris wrote:
> > > > Finally! Its out! YES! Beta 1 is great...it just has those usual
> > Could someone be able to tell me as to where I could ftp this file
> > from, as I thiknk a renewal of wad editing is due.. :)
> Out of interest, have the DEU team been keeping up-to-date with any of the
> latest versions of the other editors? They're all far more sophisticated
> than the 5.3 beta is - FAR more.

That, of course, is a matter of opinion. I'd say that DEU 5.21 is
indisputably superior to most other editors, although DCK looks like it
may be quite cute. So unless 5.3 is a big step backwards...

But that's just my opinion. OTOH, yours seems a lot more extreme - you
think the Windoze editors are better than DEU?

David Damerell, GCV Sauricon. djsd100@hermes.cam.ac.uk Trinity, Cambridge
WOODHAL2.WAD ftpable. CUWoCS President. METLMAZE.WAD sometime soonish.
|___| Loneliness pours over you: Emptiness can pull you through. |___|
| | | Your mother's eyes, from your eyes, cry to me... Queen, '39. | | |


------------------------------

From: Robert Forsman <thoth@cis.ufl.edu>
Date: Wed, 15 Feb 1995 12:30:53 EST
Subject: Re: BSP for unix

Robert E Arthur <rea@st-andrews.ac.uk> ,in message <22797.9502151043@bute.st-an
drews.ac.uk>, wrote:

> Obviously this is due to a machine-indepentant size
> of the long int type, but I am unsure how (if possible) to fix this, short of
> a pretty major re-write.

Suns use network byte order. 80x86s use the reverse byte order. Here's
bytecount.h for your perusal. It's what enables the Sparc/SunOS version of
the PFME to painlessly read the DOOM wad file. (Yes, I know it's not as
"tight" as it could be. Ask me if I care :)

// Emacs -*- C++ -*-

//
// Copyright 1994, 1995 by Robert Forsman
// of Purple Frog Software
//

//
// $Log: byteorder.h,v $
// Revision 1.1 1994/12/23 00:33:29 thoth
// Initial revision
//

#ifndef byteorder_h_
#define byteorder_h_

typedef long INT32;
typedef short INT16;

typedef unsigned long UINT32;
typedef unsigned short UINT16;

inline INT32 get_int32(const void*v)
{
const unsigned char *b = (const unsigned char *)v;
return b[0] + 0x100*(b[1] + 0x100*(b[2] + 0x100*b[3]));
}

inline INT16 get_int16(const void*v)
{
const unsigned char *b = (const unsigned char *)v;
return b[0] + 0x100*b[1];
}

inline void put_int32(INT32 val, char*b)
{
b[0] = (val>>0)&0xff;
b[1] = (val>>8)&0xff;
b[2] = (val>>16)&0xff;
b[3] = (val>>24)&0xff;
}

inline void put_int16(INT16 val, char*b)
{
b[0] = (val>>0)&0xff;
b[1] = (val>>8)&0xff;
}

#endif // byteorder_h_

------------------------------

From: sky@verity.com (Sky Golightly)
Date: Wed, 15 Feb 1995 09:34:32 -0800
Subject: Re: BSP for unix

I just re-compiled the latest version of WARM for SunOS. It seems to work
just fine. I'd be happy to send you the binary (155K unstripped).

> On Feb 15, 11:43, Robert E Arthur wrote:
>
> OK - not having much experience with the machine-independant side of c
> programming, I am trying to compile BSP12 for use with sunos. I am not
> having much luck, however - it mis-reads the wad_header, giving a ridiculous
> number of dir entries. Obviously this is due to a machine-indepentant size
> of the long int type, but I am unsure how (if possible) to fix this, short of
> a pretty major re-write.
>
> The reason for trying this is as follows:
>
> I don't have a coprocessor.
> IDBSP hangs on the seg processing (due to lack of memory I think...)
> NODEBLD (the one with DOOMCAD) has finally given up the ghost, and totally
> screws up one of my rooms.
> DEU12X (with EMU387) *completely* screws up. I have a feeling that it is the
> blockmap, rather than the nodes themselves, since by using nodenav, the node
> structure *seems* OK (though I am not particularly good at telling :) ). This
> is the same problem as DEU521GCC's node-builder - DEU never gave perfect
> results, but the GCC version completely screws up the level. Is there some
> bug in EMU387?
>
> Any other good, fast (on my machine, time is of the essence!) non-copro builders
> out there?
>
> Humph. S'pose I'd better get a proper computer after all :(
>
> Byeeeee,
> Bob.
>-- End of excerpt from Robert E Arthur



- --
Sky Golightly, Software R & D E-Mail: sky@verity.com
Verity, Inc., 1550 Plymouth Office: +1 415.960.7685
Mountain View, CA 94043-1230 Fax: +1 415.960.1421

------------------------------

From: Eric Fisher <efisher@moose.uvm.edu>
Date: Wed, 15 Feb 1995 14:57:29 -0500 (EST)
Subject: Re: DEU 5.3 Beta

>
> > >
> > > > Finally! Its out! YES! Beta 1 is great...it just has those usual
> > Could someone be able to tell me as to where I could ftp this file
> > from, as I thiknk a renewal of wad editing is due.. :)
> > Thanks
> > Derek
> > aka Hawkeye
> > (byrneda@alf2.tcd.ie)
>
> Don't get your hopes up.
>
> Five months for a very minor update (and a buggy first one at that) .. I'm
> not very impressed :)
>
> Out of interest, have the DEU team been keeping up-to-date with any of the
> latest versions of the other editors? They're all far more sophisticated
> than the 5.3 beta is - FAR more.
>
I think 5.3 is an attempt to improve the GUI of DEU 5.3, but since I
don't have it I really dont know... that situation could be correct <hint
hint> Just kidding... I like DCK 2.0 and DEU.. I will have to give
Dmapedit and Doomcad a try... there are too many good editors out there...

Eric

- ---------------------------------------------------------------------
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
- ---------------------------------------------------------------------

------------------------------

From: Eric Fisher <efisher@moose.uvm.edu>
Date: Wed, 15 Feb 1995 15:00:46 -0500 (EST)
Subject: Re: DEU 5.3 Beta

oh yes... in order for me to take a look at these other editors, I need
to know their latest version numbers...

any others out there wanna comment on the latest versions of their
products??
I know...
DCK is 2.0
DEU is 5.21
Doomcad?
Dmapedit?

any other worthwhile editors while I am still curious...

Eric

- ---------------------------------------------------------------------
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
- ---------------------------------------------------------------------

------------------------------

End of doom-editing-digest V1 #160
**********************************

← previous
next →
loading
sending ...
New to Neperos ? Sign Up for free
download Neperos App from Google Play
install Neperos as PWA

Let's discover also

Recent Articles

Recent Comments

Neperos cookies
This website uses cookies to store your preferences and improve the service. Cookies authorization will allow me and / or my partners to process personal data such as browsing behaviour.

By pressing OK you agree to the Terms of Service and acknowledge the Privacy Policy

By pressing REJECT you will be able to continue to use Neperos (like read articles or write comments) but some important cookies will not be set. This may affect certain features and functions of the platform.
OK
REJECT