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

SLADE3 beta ('final' beta 7 up, test away)

Recommended Posts

It's been a long time since I announced SLADE3 originally, so I think it's about time I at least released something. So here it is, SLADE3 beta 1. I must stress that this release is very much for testing purposes, it's still incomplete and may have quite a few bugs etc. So please keep backups of anything you edit with it :P

I'd appreciate any opinions on how well the interface works for people - how easy it is to find things or use the features, etc. I've tried to make things as intuitive as possible, but of course my idea of intuitive may not be everyone else's :P

Also of course bug reports should be either posted here or emailed to me :) Anyway here's a quick list of what's in and what's not:

What's in:
- Ability to open/edit Wad and Zip/Pk3 archives, using a tabbed interface ala SLumpEd
- All the basic archive entry management stuff (import/export/rename etc)
- Cut/copy/paste entries (and directories in zips)
- Gfx entry viewer with the ability to change offsets (and PNG offsets)
- Mass gfx offset editing (works exactly the same as it did in SLumpEd)
- Gfx format conversion, this time hopefully better than it was in SLumpEd, includes a nice dialog with before/after previews and some conversion options
- TEXTUREx editor
- Audio entry player
- Advanced text editor features (hilighting etc)
- Entry list filter/search
- Anything else that was in SLumpEd that hasn't been mentioned :P

What's not (yet):
- Map editor


Download it from the SLADE website: http://slade.mancubus.net

To build on linux, checkout the latest svn from http://mancubus.net/svn/hosted/slade/trunk and follow the instructions in README-unix

Share this post


Link to post
SlayeR said:

- Gfx format conversion, this time hopefully better than it was in SLumpEd, includes a nice dialog with before/after previews and some conversion options

Does it still assume index 247 is transparent? This is a source of headaches with Heretic/Hexen/Strife graphics.

Edit: apparently not. Yay!

Share this post


Link to post

I found some problems.

The graphics of any type are not displayed in the Entry Contents box, but the type is correctly displayed in the Entries column. For example, in Doom II IWAD it recognizes KEENA0 as a sprite, but the graphics do not show up in the Entry Contents box. If I minimize the window and then restore it, the contents of the windows below it are shown.

Screenshot

If I try to export the entry, it wants to save it as KEENA0.lmp. If I change the extension to .png or .bmp and save it, it is not converted to the corresponding format.

Here are my system specifications:
Lenovo S10e Netbook

  • Operating System: Microsoft Windows XP Home Edition 5.01.2600 Service Pack 3
  • Processor: Intel Atom N270 @ 1600 MHz
  • Video Card: Mobile Intel 945 Express Chipset Family
  • Physical Memory: 1024 MB (1 x 1024 DDR2-SDRAM )
  • DirectX: Version 9.0c (March September 2009)
I know this is not a priority, but would it be possible to add support for the Doom alphas and Press Release Beta? I would really like to see a modern tool capable of working with them. The only available options right now are, to my knowledge, DeuTex for DOS and Yadex for Unix and Linux. WinTex and XWE both have problems with sky textures.

Currently SLADE opens the alpha and beta wads and displays the entries in the Entries column. It recognizes sprites and patches, but not the graphics lumps. If I choose a sprite, it crashes with the Unhandled exception error message and if I choose a patch, it crashes with the following error message.
Stack Trace:
0: ()
I really like the interface, it is simple and logical. The only thing I miss is the entry list filter/search, but you already said it was planned.

EDIT: Updated DirectX

Share this post


Link to post

Opened a few files and browsed around. I like it so far. The "edit as text" button is great and I hope it remains available for map markers even if the map viewer is brought back from Slumped. FraggleScript support depends on it. (With Slumped, there's the clumsy workaround of copy/pasting the marker lump just next to itself, and deleting the "old" one.)

Oooh, how about an "Edit as hex" window? There are plenty of binary lumps that could use it; including stuff like PNAMES, TEXTUREx, SWITCHES and ANIMATED. And even if full-blown editors get implemented for all these types, it might still be handy to have hex access sometimes (see the Slumped+XWE combo bug with PNAMES).

Maybe a possibility to change the vertical place of the "bottom" line for sprite view? It's quite rare that offsets set thing sprites below that line; but on the other some hi-res sprites can be tall enough to take more than half the view panel... So their head is cut off. For example, the CYBRE? sprites in harm1.wad. (At least on my 1280x800 laptop screen.)

I miss the ability to open embedded wads, but I guess that's part of the features that'll come later.

I love the little palette chooser in the image viewer, by the way. I'm glad it made it in! I've already added a few additional palettes (from other ZDoom IWADs, and some custom ones).

Share this post


Link to post

Awesome :D

There's a major issue I'm having with this, though. Non-power-of-2 graphics seem to be getting scaled down to the nearest power-of-2 size and then scaled back up. As a result, they look like someone ran a Mosaic filter over them.

In addition, some 16384x16 textures I'm using as scrolling news tickers are just appearing as solid white.

Share this post


Link to post
esselfortium said:

Awesome :D

There's a major issue I'm having with this, though. Non-power-of-2 graphics seem to be getting scaled down to the nearest power-of-2 size and then scaled back up. As a result, they look like someone ran a Mosaic filter over them.


Ancient OpenGL assumptions?

Awesome :D
In addition, some 16384x16 textures I'm using as scrolling news tickers are just appearing as solid white.



Most modern graphics cards still have a texture size limit and it looks like that's coming into play here.

Share this post


Link to post
Graf Zahl said:

Most modern graphics cards still have a texture size limit and it looks like that's coming into play here.

Indeed. Ingame the tickers are drawn correctly in software, but in GL they get squeezed down to 1/4th their width and scaled back up, turning them into an illegible blur.

Share this post


Link to post

Graphics cards have a limit per dimension, which ranges between 4096 and 8192 for most common graphics cards. 16384 is too much.

Share this post


Link to post
Xtroose said:

The graphics of any type are not displayed in the Entry Contents box, but the type is correctly displayed in the Entries column. For example, in Doom II IWAD it recognizes KEENA0 as a sprite, but the graphics do not show up in the Entry Contents box. If I minimize the window and then restore it, the contents of the windows below it are shown.

Hmm, that looks to me like a problem with your system (opengl drivers perhaps). The wxGLCanvas doesn't look to be refreshing properly.

If I try to export the entry, it wants to save it as KEENA0.lmp. If I change the extension to .png or .bmp and save it, it is not converted to the corresponding format.

This will be added in the future. Actually I had kinda forgot about it, so thanks for pointing it out :P

I know this is not a priority, but would it be possible to add support for the Doom alphas and Press Release Beta? I would really like to see a modern tool capable of working with them. The only available options right now are, to my knowledge, DeuTex for DOS and Yadex for Unix and Linux. WinTex and XWE both have problems with sky textures.

Currently SLADE opens the alpha and beta wads and displays the entries in the Entries column. It recognizes sprites and patches, but not the graphics lumps. If I choose a sprite, it crashes with the Unhandled exception error message and if I choose a patch, it crashes with the following error message.

Hmm, I'll look into it. It really shouldn't crash at least. Wonder why the stack trace doesn't work :/

Gez said:

Opened a few files and browsed around. I like it so far. The "edit as text" button is great and I hope it remains available for map markers even if the map viewer is brought back from Slumped. FraggleScript support depends on it. (With Slumped, there's the clumsy workaround of copy/pasting the marker lump just next to itself, and deleting the "old" one.)

I'll keep that in mind when adding the map preview.

Oooh, how about an "Edit as hex" window? There are plenty of binary lumps that could use it; including stuff like PNAMES, TEXTUREx, SWITCHES and ANIMATED. And even if full-blown editors get implemented for all these types, it might still be handy to have hex access sometimes (see the Slumped+XWE combo bug with PNAMES).

That would be nice, I'll add it to the feature requests list. Also since I'm now well aware of how XWE reads PNAMES entries, there shouldn't be compatibility issues between SLADE3 and XWE there.

Maybe a possibility to change the vertical place of the "bottom" line for sprite view? It's quite rare that offsets set thing sprites below that line; but on the other some hi-res sprites can be tall enough to take more than half the view panel... So their head is cut off. For example, the CYBRE? sprites in harm1.wad. (At least on my 1280x800 laptop screen.)

I plan to add the ability to scroll the gfx viewer eventually.

esselfortium said:

There's a major issue I'm having with this, though. Non-power-of-2 graphics seem to be getting scaled down to the nearest power-of-2 size and then scaled back up. As a result, they look like someone ran a Mosaic filter over them.

In addition, some 16384x16 textures I'm using as scrolling news tickers are just appearing as solid white.

Ah, I knew there were some things I was forgetting about using opengl textures for the gfx viewer :P Not sure it's a huge priority to support ridiculous sized images as yet, but the non-power-of-two thing I should get to fixing soon.

Share this post


Link to post

Would it be possible to add the ability to move selected lumps up and down in the list by dragging them? Being able to drag lumps while mousing over another open wad's tab and then drop them off at a position in that wad's lump list, to copy them into that wad, would be pretty fantastic as well, along the same lines.

Share this post


Link to post

HOLY SHIT I HAVE WAITED FOR THIS DAY TO COME

Awesome, can't wait to try this.

Share this post


Link to post
SlayeR said:

What's not (yet):
- Map editor
[...]

When can we expect this?
I dont want to reboot everytime i want to fool around in a map editor. ;)

Share this post


Link to post

Apparently, the FreeImage API has changed a little bit. I've installed the beta in the same dir as Slumped (I know I shouldn't have), and it overwrote FreeImage.dll. And now Slumped displays all graphics upside-down. :)

Share this post


Link to post

Just noticed this in the SVN:

ConsoleCommand et_test_entry_types(_T("test_entry_types"), &c_test_entry_types, 0);
Console commands???

Share this post


Link to post

There are no precompiled svn builds, no. I actually haven't built it in windows for a while, and as such the VS project is probably in need of updating. But once it is updated, you should only have to download/install wxwigdets 2.9 and freeimage, set them up in VS, then compile the SLADE3 solution.

There is currently no easy way to compile in windows if you don't have VS though, but I have switched over to CodeLite in linux, which is cross-platform - so sometime I'll get to setting that up in windows which might make things easier...

Share this post


Link to post

wxWidget is abominable. Why do I have to compile a library myself? Why can't they just give precompiled .libs and .dlls? Why can't they at least include a setup.h file that's configured in a way which allows successful compilation? I already had to add a dozen of #define wxUSESTUFF 1 to it.

I ended up having to rip out huge chunks of wxchar.cpp because compilation aborted in... inactive preprocessor blocks. WTF?

And stc refuses to be compiled because none of the functions match their prototypes. This is really frustrating.

Too bad, I was eager to try out the changes you've made just after beta 2.

Share this post


Link to post
Gez said:

wxWidget is abominable. Why do I have to compile a library myself? Why can't they just give precompiled .libs and .dlls? Why can't they at least include a setup.h file that's configured in a way which allows successful compilation? I already had to add a dozen of #define wxUSESTUFF 1 to it.

I ended up having to rip out huge chunks of wxchar.cpp because compilation aborted in... inactive preprocessor blocks. WTF?

And stc refuses to be compiled because none of the functions match their prototypes. This is really frustrating.

Too bad, I was eager to try out the changes you've made just after beta 2.

In Windows? All I've ever had to do is change wxUSE_GLCANVAS to 1 in setup.h and the VS solution compiles fine.

Share this post


Link to post

But 2.9 is not stable and snapshot I downloaded doesn't compile at all.

Share this post


Link to post

I've been building with the 'unstable' 2.9 they have there and it's fine :P I tried an svn snapshot a while back but couldn't get it to work properly.

Share this post


Link to post
SlayeR said:

I tried an svn snapshot a while back but couldn't get it to work properly.

Well, same. ;)

But I don't see any non-snapshot download for 2.9.

Share this post


Link to post
Gez said:

wxWidget is abominable. Why do I have to compile a library myself? Why can't they just give precompiled .libs and .dlls? Why can't they at least include a setup.h file that's configured in a way which allows successful compilation? I already had to add a dozen of #define wxUSESTUFF 1 to it.



I'd have to agree. The library itself is very good but the maintainers are idiots.

It's virtually impossible to compile it in a genrerally useful way that works for everything. There's so many options to be set and unset that you basically have to recompile it for each application.

Worse, their predefined configurations for static were done with MSVC++ 6.0 and never changed so if you want something that does not require the CRT DLL you have to alter the setting in every single project file they distribute!. The end result is the same: It's nearly impossible to distribute a project depending on wxWidgets without distributing wxWidgets and all its bloat along.

When I tried to explain this to the developers some time ago they reacted the same as many other developers who are too locked into their own way of thinking: They claimed that all is fine, people would have no problems with it and generally ignored every point I brought up. So I'm done with these jerks.

Share this post


Link to post

Will you give any support for EDGE LUMPs such as DDF or RTS?

If you look here: http://edge.sourceforge.net/phpBB2/viewtopic.php?t=374

You may find a EDGE Config File for your SLade Map Editor. You may use it for the future upcoming map editor.

Also, I was doing a DDF & RTS EDGE Keywords, functions, operators... list for SLumpEd Text Editor. Although I didn't continued it, I can try finishing it and sending for you to include in the text editor if you need.

Just let me know.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×