Need testers for Eureka DOOM Editor

Eureka is nearly ready for a new release, and it would be great if some people could test it for a while, see if any new problems have cropped up.

Attached is the Windows binary package.  Linux users will need to clone the git repository and build from source.

This version mainly fixes lots of bugs and annoyances.  The only truly new feature is support for creating and editing text lumps (including map header lump of the currently edited map, e.g. for Fragglescript).  See the full changelog here: http://eureka-editor.sourceforge.net/?n=Main.Changes124

eureka-123-WIP.zip

The only funky thing I've noticed at this point is that sometimes when I go to type a number in the sector floor/ceiling height box it reads as hitting the grid size hotkeys instead.  Otherwise it seems pretty solid as far as anything I've thrown at it thus far.

I won't have the ability to check this new update out until later today, but what does "new setting for raw sidedef manipulation buttons" mean? Isn't that what the pane to the very right in linedef mode is for? You can edit specials texture offsets and references there, how much more raw can you realistically get without giving people the option to edit the actual address of the sidedef in the compiled map 😂 Which I'm sure *totally* wouldn't cause problems at all..

Also since there is a text editor now do you think in the next version you can add a preference for a path to an ACS compiler and have a button in the text editor to compile the text as ACS and put the compiled acs into the Behavior lump? That would finally make it pretty much able to do anything specifically mapping related you can think of. Aside from actual support for Decorate though I imagine that would be a bit harder to do than just adding a button so I can totally wait for that.

2 hours ago, therektafire said:

I won't have the ability to check this new update out until later today, but what does "new setting for raw sidedef manipulation buttons" mean?

 

The setting shows "ADD" and "DEL" buttons which create / remove sidedefs from lines.  It is very easy to create broken geometry using them, which is why they are hidden by default.

Quote

have a button in the text editor to compile the text as ACS and put the compiled acs into the Behavior lump?

It is a good idea.

Currently you can edit the SCRIPTS lump, which is a per-level lump that can contain ACS scripts for the corresponding level (though nothing actually uses it).  I wonder if such a feature should be limited to that lump?

Support for automatic parsing of DECORATE is probably not going to happen, I would want to support other source ports too (Eternity's EDF, EDGE's DDF, even DEHACKED lumps) and it ends up being a lot of work.

Just now, andrewj said:

The setting shows "ADD" and "DEL" buttons which create / remove sidedefs from lines.  It is very easy to create broken geometry using them, which is why they are hidden by default.

Oh is that why upper and lower sidedefs aren't shown for 1 sided lines? Can you finally add those so you don't inevitably make broken switch textures by having the texture copied to both the upper and lower parts which causes it not to animate? I've been able to get around this by making my switch lines 2 sided and applying the switch to the middle texture but it would be nice to quickly make 1 sided switch lines also since technically that's how you are supposed to do it...

I will update the map checker to find 1S switches with a duplicate texture, with a button to fix them.

I'll build the Linux version and give it a spin. I assume master branch is right?

(that switch upper/lower texture bug is a new one to me. I'd never heard of it before)

Edit: I forgot, cloning Git from SF.net is incredibly slow and unreliable for some reason. I've got an rsync mirror of the headless repository as the rsync was more reliable and re-startable at least. But it's probably worth being aware a fresh clone from SF is tricky and this could be a barrier for some folks

the magic rsync command you need is, FYI,something similar to

rsync -va --delete rsync://git.code.sf.net/p/eureka-editor/git.git/ git.git/

Thanks to @chungy for suggseting rsync for SF.net

8 hours ago, Jon said:

(that switch upper/lower texture bug is a new one to me. I'd never heard of it before)

 

Yeah I had some trouble with it when I first started mapping last year, I first round out about it when I was making a speedmap for the eagle speedmapping sessions (that shitty warehouse one) and was wondering why my switch wasn't animating right. Turns out that was the reason why

9 hours ago, Jon said:

(that switch upper/lower texture bug is a new one to me. I'd never heard of it before)

It's not really a bug, it's just a question of priority.

/
// Function that changes wall texture.
// Tell it if switch is ok to use again (1=yes, it's a button).
//
void
P_ChangeSwitchTexture
( line_t*	line,
  int 		useAgain )
{
    int     texTop;
    int     texMid;
    int     texBot;
    int     i;
    int     sound;
	
    if (!useAgain)
	line->special = 0;

    texTop = sides[line->sidenum[0]].toptexture;
    texMid = sides[line->sidenum[0]].midtexture;
    texBot = sides[line->sidenum[0]].bottomtexture;
	
    sound = sfx_swtchn;

    // EXIT SWITCH?
    if (line->special == 11)                
	sound = sfx_swtchx;
	
    for (i = 0;i < numswitches*2;i++)
    {
	if (switchlist[i] == texTop)
	{
	    S_StartSound(buttonlist->soundorg,sound);
	    sides[line->sidenum[0]].toptexture = switchlist[i^1];

	    if (useAgain)
		P_StartButton(line,top,switchlist[i],BUTTONTIME);

	    return;
	}
	else
	{
	    if (switchlist[i] == texMid)
	    {
		S_StartSound(buttonlist->soundorg,sound);
		sides[line->sidenum[0]].midtexture = switchlist[i^1];

		if (useAgain)
		    P_StartButton(line, middle,switchlist[i],BUTTONTIME);

		return;
	    }
	    else
	    {
		if (switchlist[i] == texBot)
		{
		    S_StartSound(buttonlist->soundorg,sound);
		    sides[line->sidenum[0]].bottomtexture = switchlist[i^1];

		    if (useAgain)
			P_StartButton(line, bottom,switchlist[i],BUTTONTIME);

		    return;
		}
	    }
	}
    }
}

As you can see, the logic is "animate the first switch texture you find, going from upper, then middle, and finally lower".

So if you have a switch on a middle texture, however the upper texture is also a switch (but is invisible because it's a one-sided line and upper/lower textures are only visible on two-sided lines), then the invisible upper texture is updated and the middle texture is forgotten about.

A more logical order would probably be middle, lower, upper, to give priority to middle texture first (since most switches will be on one-sided lines, and the middle texture is always visible when set (except on some console ports but let's not worry about them)), the player moves on the floor and switches sticking out of the floor are more frequent than those hanging down from the ceiling. But we're over two decades too late to change the logic. :)

Wellp, TIL why that one switch in Mountain King's Domain wouldn't animate right.  Good to know.

@Jon Yeah master branch.  Disturbing to learn that cloning from SF is very slow or unreliable.  With the full release, there will be a source code package to download, so that would help I think.

just poking around some, never used this editor before

middle-click drag scrolling seems choppy on my machine (windows 10, i5-3450, radeon hd 7800something). also possibly delayed, but that may have to do with it just being choppy. perception is tricky.

ok something is definitely slow.

loading choz.wad renders the editor nearly unusably slow on my machine while just moving the mouse around.

other wads that i use to test my editor sometimes like rebelsky.wad and port_glacia.wad seem very slow too. nuts.wad seems quite bad in things mode too, and bad if i view the whole map in lines/vertices mode but not bad if i zoom in a lot. port_glacia seems to be irrespective of zoom level. i guess this is tied to renderering, after some testing, as choz.wad isnt so bad if i zoom into a part of the void.

regarding the delay, here's a little video clip

you might not be able to do much about this. no matter what any application's stuff always going to be at least a frame away from the Windows cursor? so some delay is expected. however, this seems like more? and again, that might just be tied to the how long it's taking to redraw everything.

also i seemed to get what appears to be a weird triangulation bug?:

also, what's with the blank space between these menu options? (i'm on 125% scaling on windows 10 if that matters):

otherwise everything seems to work, nice. hope these reports help

3 hours ago, anotak said:

middle-click drag scrolling seems choppy on my machine (windows 10, i5-3450, radeon hd 7800something). also possibly delayed, but that may have to do with it just being choppy. perception is tricky.

ok something is definitely slow.

I'm guessing you have a 4K monitor?

Eureka renders everything using software (i.e. the CPU) and does not use the GPU (OpenGL etc), so when the window is large then things can get very slow.

I'm thinking that a low-resolution version of the sector floor rendering may be a useful addition.  The floor rendering can be disabled in the View menu, which will be a lot faster.  Similar for things mode rendering the sprites can be turned off there too.

Yeah the floor rendering is not perfect and shows some black horizontal lines sometimes.  I haven't been able to fix it yet.

The blank spaces in the menus are divider lines, they will look better once I have applied a patch to the FLTK toolkit to draw the divider line in the middle of the space (instead of at the bottom).

i'm on 1080p

it seems to scale not with drawn pixels but with amount of geometry & things

edit:

for example this size screen is still very slow

21 hours ago, anotak said:

also i seemed to get what appears to be a weird triangulation bug?:

That looks like you either switch the sector render mode from floor to ceiling or you turned a floor texture into a sky on accident, I believe there is a shortcut for that that you may have hit accidentally but I can't think of what it is at the moment

On 6/27/2018 at 5:52 AM, andrewj said:

I'm guessing you have a 4K monitor?

 

Eureka renders everything using software (i.e. the CPU) and does not use the GPU (OpenGL etc), so when the window is large then things can get very slow.

 

I'm thinking that a low-resolution version of the sector floor rendering may be a useful addition.  The floor rendering can be disabled in the View menu, which will be a lot faster.  Similar for things mode rendering the sprites can be turned off there too.

 

Yeah the floor rendering is not perfect and shows some black horizontal lines sometimes.  I haven't been able to fix it yet.

 

The blank spaces in the menus are divider lines, they will look better once I have applied a patch to the FLTK toolkit to draw the divider line in the middle of the space (instead of at the bottom).

@anotak

I've noticed that large maps do slow everything to a crawl. With 1.21, I tried to load the Impromptu Minidido and Nova II Meggido maps and both ran at a crawl (at least, at a large scale) until I disabled floor rendering. I haven't tried nuts.wad (or similar), but I would figure similar things would happen with large numbers of things.

One of the nice features is to have the various sectors and things rendered visually, so a low-resolution mode, while not ideal, would be nice.

11 hours ago, therektafire said:

That looks like you either switch the sector render mode from floor to ceiling or you turned a floor texture into a sky on accident, I believe there is a shortcut for that that you may have hit accidentally but I can't think of what it is at the moment

The default hot-key for that is w, if I remember correctly. It's rather easy to press that and mistakenly have your floors and ceilings switched (it's happened to me more than once). I think that's more likely than switching the sector render mode, unless there's a water ceiling, which seems unlikely to me.

I still have version 1.09, so I will have to update.

I have tried Eureka several times, but have always been unable to figure out how to do tricky stuff.

I have gotten used to using Yadex where I can create something that may be invalid, but then I had the commands to fix the invalid stuff and make it right.

I have tried to use Eureka to deal with some bad wad files, and I could not make them better, but it was too long ago to remember details.

I will have to try it again, but don't have any current editing projects.

If the grid is turned off, then hitting the grid size hotkeys still leaves it invisible; it only appears when you use the dropdown selector at the bottom.

Even if it is software draw, it should still be drawing it at 20 frames a second.  Every Doom port can do that.

It has to be the geometry structures are too complicated to traverse fast, or else you have a bug in your drawing routines.

Tried to make the drawing routine too simple, or you have some common function that should have been specialized.

But to really slow things down to a crawl, you have to re-traverse the entire structure several thousand times with every render.

Such things happen if something gets invalidated while drawing, and it cascades to invalidate something else.

If you are going to have trouble with rendering floors so slow. then I have to ask the question, what is rendering the floors trying to accomplish?

This is an editor, so a great display of the floor (top down) is not a great feature that makes creating a level such a better experience.

If what you need is to see that all the floor in an area have the same texture then it would be equally useful to have one of the check functions

that shows you all the sectors (in orange or some highlight), that match the floor texture you point at.

Then you could easily find any sectors with mismatched floor texture.

It would also help to have the capability to click a menu selector on a sector to make it's floor texture match the reference sector.

That is one capability in Yadex that I use often, but the Yadex version makes it the same sector.

For more selective changes, I use the group change capability of Yadex.  Select a bunch of sectors, then any attributes you change,

changes all the sectors at the same time.

I will have to check in Eureka for similar capability, because I use those quite often.  I am not sure if it is not there or I just have not figured how to do it yet.

Quote

It would also help to have the capability to click a menu selector on a sector to make it's floor texture match the reference sector.

This is implemented since 1.11 -- a right click on a texture shown in the Sector or LineDef panel will set that texture to the default (from the Default Properties panel).

Quote

For more selective changes, I use the group change capability of Yadex.  Select a bunch of sectors, then any attributes you change, changes all the sectors at the same time

Eureka already works this way -- if you select multiple sectors, changing something in the Sector panel will change all the selected sectors.  The background color of the panel turns red to indicate that multiple sectors (etc) will be affected by any changes.

P.S. I am going to profile the drawing code for any bottlenecks.

7 hours ago, ETTiNGRiNDER said:

If the grid is turned off, then hitting the grid size hotkeys still leaves it invisible; it only appears when you use the dropdown selector at the bottom.

Yeah it probably should reshow the grid -- noted.

On Mac, whenever I turn on fullscreen, the menu bar is permanently hidden and there's no known hotkey to restore it. On modern macOS, a lot of apps which didn't have fullscreen have gained it. I suspect it's a FLTK problem unless you can set a special flag in the code. Doesn't seem to be fixed in the development builds of FLTK.

I would have posted this as an issue on sourceforge but I'm not logged in.

User experience reactions (maybe it's old):

1. Sector flat rendering is too slow to be usable. I turn it off, but whenever I start or open a new wad, it's back on. It's only saved per project.

2. By default grid is hidden and snapping is off, which is wrong.

3. Did you remove the option to use vertical and horizontal wheel/touchpad scrolling to pan the map? Now it only zooms, and i have to use keys to pan.

4. I find the commands to get the next free tag too heavy. There needs to be a little button next to the tag field.

5 hours ago, printz said:

User experience reactions (maybe it's old):

1. Sector flat rendering is too slow to be usable. I turn it off, but whenever I start or open a new wad, it's back on. It's only saved per project.

2. By default grid is hidden and snapping is off, which is wrong.

3. Did you remove the option to use vertical and horizontal wheel/touchpad scrolling to pan the map? Now it only zooms, and i have to use keys to pan.

4. I find the commands to get the next free tag too heavy. There needs to be a little button next to the tag field.

1. I will soon add a preference for the flat rendering (and defaulting to off)

2. "wrong" is just your opinion

3. I don't know, the whole way of handling mouse buttons and the wheel got reworked for v1.21.  I will have to check the code to be sure

4. I like the fresh tag button idea, and have started to implement it

Regarding the fullscreen issue, again I don't know since I don't have a Mac to test on.  It is probably an FLTK bug.  Eureka uses the Fl_Sys_Menu_Bar widget which does special things on MacOS (to show the menu at top of screen, like normal apps on that platform).

P.S. to use mouse wheel for scrolling the 2D view, go into key bindings in preferences and bind the wheel to the "WHEEL_Scroll" command.  It needs a parameter for the speed, e.g. 100

Testing under Linux (Lubuntu, so LXDE based desktop), if the mouse cursor passes over the map area / 3D preview area, it automatically pops the Eureka window to the top even if it's not the currently focused window.  Not sure if this is a Eureka thing / FLTK thing / LXDE thing but it's annoying so I'd appreciate it changing if it's something under your jurisdiction.

9 hours ago, ETTiNGRiNDER said:

Testing under Linux (Lubuntu, so LXDE based desktop), if the mouse cursor passes over the map area / 3D preview area, it automatically pops the Eureka window to the top even if it's not the currently focused window.  Not sure if this is a Eureka thing / FLTK thing / LXDE thing but it's annoying so I'd appreciate it changing if it's something under your jurisdiction.

In the preferences (General tab) there is a setting "require click to focus".  Turning it off disables this behavior, however it also makes something not work quite right (e.g. input boxes in the panel seem to hog the keyboard focus).  I don't know how to properly fix this yet.

I have discovered why drawing in the 2D view (with no sector rendering) is slow under X windows.  It basically comes down to something in the FLTK toolkit, the fl_color() function is used to set the color of the next draw operation but it is very slow under X windows.  So drawing 27000 knobbly linedefs takes 103ms when using fl_color() before each one, but only 7ms without it.  That is really fucked up.

I would probably be better off to simply draw the map view to an off-screen buffer using custom line-drawing (etc) code.  But it requires some major work which I don't have the energy for right now.  Using multiple passes over the lines (e.g. drawing all light-gray lines in the same pass) gets the time down to decent numbers, so that's the approach I will take.