OK... I need an editor.

Eponasoft said:

OK... the only thing I don't really like about DB1 thus far is that it seems you cannot create sectors without also creating linedefs. That's taking some getting used to.

That reminds me how levels with the old DEU was made...vertex by vertex and then connecting the lines.

Heh, I have "fond" memories of having to do that in DoomCAD. At least I was able to make some semi-cohesive rooms with it. I tried DETH before it and for some reason was too stupid to figure out how to actually draw anything. :P

Xaser said:I tried DETH before it [/B]

Oh, that brings back fond memories :-)

If I could figure out how to make it run like in the good ol' days, I would still be using it.

It may have been a programmer's nightmare, but it sure had some niffty features which I miss dearly.

Have you tried running it under DOSBox?

Xaser said:

I tried DETH before it and for some reason was too stupid to figure out how to actually draw anything. :P

Heh - I had the same problem with DB1 before reading Dr. Sleep's tutorial.

Mr. Chris said:

That reminds me how levels with the old DEU was made...vertex by vertex and then connecting the lines.

That's what I was expecting to do with DB1, but I guess it's not the same.

Eponasoft said:

32/64 bit malconfiguration? Never seen that before with yadex since my system was 32 bit and everything was built that way... did you build it from source?

Maybe it's because I have a 64-bit system and I've installed 64-bit Gentoo.

I may redo it in 32-bit because a lot of VST plugins won't work in 64-bit. Extremely frustrating.

More than likely. This system has a 64 bit CPU but we run a 32 bit OS on it to avoid such problems. Unless you have a real need for a 64 bit OS, there's no point in using one...

Eponasoft said:

OK... yadex allows you to move a vertice after you've placed it by clicking and dragging. DB1 doesn't seem to have this capability.

(...)

OK... the only thing I don't really like about DB1 thus far is that it seems you cannot create sectors without also creating linedefs. That's taking some getting used to.

Sounds like you want to be using WadAuthor then. Drop sectors in without drawing lines and no need to switch mode to select verticies.

Eponasoft said:

More than likely. This system has a 64 bit CPU but we run a 32 bit OS on it to avoid such problems. Unless you have a real need for a 64 bit OS, there's no point in using one...

I'm coming to this conclusion. I'd prefer everyone catch up with the times - 64-bit is far from new now - but I also like to take a "whatever works" approach.

audiodef said:

I'm coming to this conclusion. I'd prefer everyone catch up with the times - 64-bit is far from new now - but I also like to take a "whatever works" approach.

I kinda feel the same way. I'm running 64-bit Windows 7 and had tons of headaches getting my favorite older games to run on it. I've been lucky to find sourceports and editors that work with it though, so I really can't complain much. But if asked to give advice to someone, especially a Doom mapper, building a new rig, I'd say stick with the 32-bit for now.

OK... DB1 is starting to piss me off with its automatic sectoring. It keeps changing the sector numbers around during development, making it very difficult to keep things consistent. There HAS to be a way to shut this off! >:(

Eponasoft said:

OK... DB1 is starting to piss me off with its automatic sectoring. It keeps changing the sector numbers around during development, making it very difficult to keep things consistent. There HAS to be a way to shut this off! >:(

...and why would you want to turn it off? It's not like it matters at all, unless you're working on some special engine hack effects, and even those depend on the node builder on what the requirements are.

It matters greatly because it keep changing sector numbers all around, and I need previously-built sectors to stay where they are and not change numbers... I often make changes to existing geometry, and it messes everything up when I add new linedefs.

Eponasoft said:

It matters greatly because it keep changing sector numbers all around, and I need previously-built sectors to stay where they are and not change numbers... I often make changes to existing geometry, and it messes everything up when I add new linedefs.

What? How does this matter at all? Sector numbering is something that you only ever have to pay attention to if you're making a self-referencing sector, and it's not going to randomly change in the middle of doing that.

Oh forget it... nevermind, I said nothing. Ignore me.

I (literally) wrote the manual on DB.
It's a great editor.

I personally like it better than DB2, not because of .NET, but because several features are no longer available in DB2.

That being said, I like what DB2 does with certain things... so... I have *gasp* both installed and used them both in my last pwad.

audiodef said:

Eponasoft: I just installed yadex on my Linux machine, but when I try to run it, I get:

Yadex 1.7.0 (2003-12-28)
Reading config file "/etc/yadex/1.7.0/yadex.cfg".
Error: sizeof u32 is 8 (should be 4)

Any idea what this is and how to fix it?

Yadex does some internal tests (assertions) to see what C number types are on different platforms. Unfortunately, it's assertions were programmed before Linux ever had a 64-bit version, which means if you try to compile it under 64-bit Linux, the assertions fail on that platform, Yadex doesn't understand the length of the integer types on that platform. It would work fine on 64-bit Solaris for example, because there's been 64-bit Solaris forever.

You could compile it on a 32-bit Linux machine of the same distro/release version, then tar it up and copy it over, and it should work. I have Yadex compiled fine under 32-bit Debian Lenny and Ubuntu 9.10/10.04, so I know it will work on a 32-bit machine.

If it helps, I have all of the patches that I know about compiled together [1]. I also have some patches for compiling Yadex on Mac OS X [2], it replaces the Insert key with the backslash '\' key, as I still haven't figured out what the Insert key is on a Mac; both of my Mac keyboards (laptop and external) lack an Insert key.

You could also contact the developer and ask him/her to update the software. Who knows, you may get lucky.

Thanks,

Brian

[1] http://code.google.com/p/portaboom/source/browse/patches/yadex-1.7.0-all_patches.diff
[2] http://code.google.com/p/portaboom/source/browse/patches/yadex-1.7.0-all-osx_keybinding.diff

Thanks, Brian!

spicyjack said:

If it helps, I have all of the patches that I know about compiled together [1]. I also have some patches for compiling Yadex on Mac OS X [2], it replaces the Insert key with the backslash '\' key, as I still haven't figured out what the Insert key is on a Mac; both of my Mac keyboards (laptop and external) lack an Insert key.

Fn + Return, or Fn + Enter. Personally I just use the I key for what'd be bound to insert by default, in Doom Builder at least.

OK so I got DB2 to sort-of work by increasing the amount of VRAM allocated to the video circuit. I loaded a couple of my maps but noticed that the display still has some issues... a lot of linedefs don't show up depending on where they are on the screen. I figured at first that it was an issue with the screen resolution... that happens sometimes with some applications on LCD monitors... but then I expanded the resolution to beyond the screen's normal limits (making a scrolling desktop) and the issue still happened so that isn't the problem... does anyone have any other ideas?

It sounds like you have trouble with your video card. When you play a commercial wad, does this happen? What kind of card do you have and what OS are you running?

SiS Mirage with 64MB VRAM, Windows XP SP2. I never use the 3D edit mode, only the normal linemap mode.

Herculine said:

I kinda feel the same way. I'm running 64-bit Windows 7 and had tons of headaches getting my favorite older games to run on it. I've been lucky to find sourceports and editors that work with it though, so I really can't complain much. But if asked to give advice to someone, especially a Doom mapper, building a new rig, I'd say stick with the 32-bit for now.

OK, have fun with your 3gb of usable RAM (2gb or less if you have a good graphics card)

Eponasoft said:

SiS Mirage with 64MB VRAM, Windows XP SP2. I never use the 3D edit mode, only the normal linemap mode.

The 2d modes also use the hardware accelerated 3d functions.

Mr. T said:

OK, have fun with your 3gb of usable RAM (2gb or less if you have a good graphics card)

Right, but I believe we're talking about Doom here, not Oblivion, Fallout 3 and the like. Re-read what you quoted please.

Well, the reason I asked if he has this problem while playing the commercial wads is if he doesn't, then he's doing something wrong drawing the map. If he is, maybe he just needs to update or configure his graphics driver.

This isn't a problem that occurs when playing a wad in any engine, this only happens in DB2's normal edit mode. OK... screenshot time.

http://www.eponasoft.com/db1-map33.png
http://www.eponasoft.com/db2-map33.png

A picture's worth a thousand words. :)

Looks like DB2 can't allocate a drawing buffer the size of your drawing area and is given a smaller buffer by the videocard instead (which is stretched out over the real size). That is definitely a videocard and/or driver issue. But I don't understand why parts of lines are missing, logically it should just give you a low resolution. Try updating your videocard's drivers using the manafacturers website. I doubt this will help in this case, but try to turn OFF "High quality display rendering" in Tools -> Preferences -> Appearance tab.

Doom Builder 1 uses software rendering for it's 2D modes, so it is not surprising that it works there.

EDIT: Thinking about this again while looking at the screenshot; It could also be a memory issue. The things and floor textures look fine (albeit in low resolution), but only the lines are missing pixels. It could be that it has enough memory for the line drawing buffer (which gets full resolution) but has no memory left to draw the final buffer at full resolution so it is given a smaller buffer instead. The pixels in the lines go missing when they are copied over from the high resolution buffer to the small resolution buffer, because these are copied 1:1 without resize filtering (it was never meant to resize anyway). Indeed a picture is worth a thousand words. Try making your window smaller and see if that helps. But also try updating drivers and the option above, just to make sure.

The video drivers are up to date... I always keep the system updated as best as possible (I just won't install SP3). I could increase the allocated VRAM to 128MB and see if that helps. Also, I unchecked the high quality setting and reduced the size of the window... nothing changed at all. I'm fine with DB1 for now... software rendering is just fine for me... but solving this issue would be good.

Have you considered if the line-segment drawing problem could be due to anti-aliasing?

EDIT: Missed your edit. Clearly you have.