Author Topic: Development thread  (Read 15820 times)

sirjuddington

Development thread
« on: July 08, 2011, 07:13:02 am »
So this thread will be like an 'unofficial' news thread, where I'll post small development updates about SLADE3 that don't really warrant a proper news post.

So, for the first post, I've been working on the map editor a bit lately, and here are a couple of screenshots of the interface so far:
http://slade.mancubus.net/dev/3/s3me_ui2.png
http://slade.mancubus.net/dev/3/s3me_ui2.png

So far I've gone with more of an 'overlay' approach than the SLADE2/DB2 style info panel. For two reasons: firstly, it obscures less of the editing area itself, and secondly, wxAUI can be a pain to deal with :P

The main problem so far is that, for font rendering, I'm using an SFML RenderWindow integrated into the wxWidgets window. Unfortunately I can only get it to work in windows so far, on linux/gtk the fonts don't show up (an SFML bug most likely), and on mac osx it doesn't draw anything at all :/ So I might have to take another approach to the font rendering, which would mean more external library dependencies and dlls, which is a pain. Still, I haven't given up on SFML just yet :P

Gez

Re: Development thread
« Reply #1 on: August 29, 2011, 09:51:07 pm »
So I was told that Slade crashes on the infamous "Infected Base" trollwad, the one that weighs one megabyte to download but one gigabyte to extract. And indeed, attempts to open it (either infebase.zip or infebase.pk3) will result either in an unhandled exception crash, or in a period of unresponsiveness followed by nothing, the open failing silently.

Well I've traced the points of failure to the wxBlah::Read functions. I guess they don't like it when they're asked to load a full gigabyte in one go.

So it may be worthwhile to look into using do ... while loops in ZipArchive::open(filename) and MemChunk::importFile(filename) at least, so as not to tax the wxFunctions too much, by loading the file or zipstream in small chunks if they are above some arbitrary limit.

sirjuddington

Re: Development thread
« Reply #2 on: August 30, 2011, 06:40:02 am »
Hmm, that might be a good idea, although it might be worthwhile to see just how large a file wxXX::Read can handle - if it's large enough (say up to 200mb or so) there probably isn't much point since no single entry is going to legitimately be anywhere near 1gb in size.

Eventually though I would like to implement a more robust and memory-efficient way of reading entry data, where it is dynamically loaded/unloaded from memory when needed. As things are now SLADE uses a lot more memory than it really needs to.

Gez

Re: Development thread
« Reply #3 on: September 25, 2011, 10:05:06 am »
So I tried building the map editor branch. It crashes on startup. :/ The stack trace, when available, shows the break either in SplashWindow::init() or in loadIcons(); but the culprit is actually SFML. E.g., when porting parts of the map editor branch to my working copy of the trunk, the crash happens when and only when backporting the changes in the Draw files and using SFML.

I had already a negative opinion of that lib because in a small project I tried with it I was forced to tolerate memory leaks since calling the sf::Sprite destructor caused an application crash...

So, following advices to ditch 1.6 and use 2.0, I download  the latest SFML, configure it, compile it,  yadda yadda. Well it doesn't work either because of API changes.

I guess I'll have to try checking if FTGL works on Windows.

sirjuddington

Re: Development thread
« Reply #4 on: September 25, 2011, 01:08:03 pm »
I'd like to switch over to SFML 2 also, but supposedly the API for that is still under development and will change pretty rapidly. Seeing as it's crashing on startup with only the Draw stuff in, perhaps it's crashing when trying to load the fonts?

FTGL works fine in windows (at least in my experience). The main reason I'm not using it in windows is that SFML does pretty much the same thing (and better), and I'm using that for audio anyway. Plus needing extra libs is more of a pain when compiling in windows than it is in linux :P Oh and it'd add the need for even more dll files.

Gez

Re: Development thread
« Reply #5 on: September 28, 2011, 01:43:46 pm »
Oddly enough, it crashes before. Either in SplashWindow::init() or in loadIcons(), both of which are called before Drawing::initFonts(). The stack trace goes somewhere in the wx stuff, which doesn't seem accurate since the exact same code is in the main trunk which doesn't crash.
Code: [Select]
Version: 3.0.2 r1045MS
Stack Trace:
0: strnicmp()
1: strnicmp()
2: png_memset_check()
3: (d:\application\visual studio\wxwidgets\src\png\pngrutil.c:3202) png_read_start_row()
4: (d:\application\visual studio\wxwidgets\src\png\pngread.c:577) png_read_row()
5: (d:\application\visual studio\wxwidgets\src\png\pngread.c:895) png_read_image()
6: (d:\application\visual studio\wxwidgets\src\common\imagpng.cpp:576) wxPNGHandler::LoadFile()
7: (d:\application\visual studio\wxwidgets\src\common\image.cpp:2352) wxImage::DoLoad()
8: (d:\application\visual studio\wxwidgets\src\common\image.cpp:2419) wxImage::LoadFile()
9: (d:\application\visual studio\wxwidgets\src\common\image.cpp:2171) wxImage::LoadFile()
10: (d:\application\visual studio\wxwidgets\src\msw\bitmap.cpp:1042) wxBitmap::LoadFile()
11: (d:\jeux\doom\source\slade\src\splashwindow.cpp:123) SplashWindow::init()
12: (d:\jeux\doom\source\slade\src\mainapp.cpp:527) MainApp::OnInit()
13: (d:\application\visual studio\wxwidgets\src\common\init.cpp:456) wxEntryReal()
14: (d:\application\visual studio\wxwidgets\src\msw\main.cpp:189) wxEntry()
15: (d:\application\visual studio\wxwidgets\src\msw\main.cpp:414) wxEntry()
16: (d:\jeux\doom\source\slade\src\mainapp.cpp:239) WinMain()
17: (f:\rtm\vctools\crt_bld\self_x86\crt\src\crtexe.c:578) __tmainCRTStartup()
18: BaseThreadInitThunk()
19: RtlInitializeExceptionChain()
20: RtlInitializeExceptionChain()

sirjuddington

Re: Development thread
« Reply #6 on: September 28, 2011, 05:00:00 pm »
Oh actually, this might have something to do with the order in which libraries are linked, the wxpng/freeimage/sfml-graphics ones in particular. Having them the wrong way around can cause some problems IIRC.

The order I have them in the VS2010 project is this:
fluidsynth.lib
FreeImage.lib
wxbase29u.lib
wxmsw29u_core.lib
wxmsw29u_aui.lib
wxmsw29u_gl.lib
wxmsw29u_html.lib
wxmsw29u_adv.lib
wxmsw29u_stc.lib
wxmsw29u_media.lib
wxtiff.lib
wxjpeg.lib
wxpng.lib
wxzlib.lib
wxregexu.lib
wxexpat.lib
wxscintilla.lib
sfml-graphics-s.lib
sfml-window-s.lib
sfml-audio-s.lib
sfml-system-s.lib
sfml-main.lib

Gez

Re: Development thread
« Reply #7 on: September 28, 2011, 06:04:27 pm »
That was it. Once again I underestimated the amount of voodoo that goes in these things. Thanks!

sirjuddington

Re: Development thread
« Reply #8 on: September 28, 2011, 06:08:39 pm »
I'm not completely sure what it is either, really. Best guess is that wxpng/sfml-graphics/freeimage use different, conflicting versions of libpng.

Gez

Re: Development thread
« Reply #9 on: October 05, 2011, 09:07:53 am »
I found a problem I haven't managed to fix. Suppose one of the map lumps (for example, THINGS) is corrupted and not recognized as a map lump; but exists anyway. When you open the corresponding map, the SLADEMap::read<format>Map() function will have aborted after running the relevant sub-function (in my example, read<format>Things()) which means that it will not run the next few functions, notably refreshIndices(). But! Despite read<format>Map() returning false, the map editor opens anyway and tries to show the map anyway, resulting in a crash in MapCanvas because without refreshIndices() vectors such as vis_v will be empty, so accesses like vis_v1 = vis_v[map.getLine(a)->v1()->getIndex()]; in MapCanvas::updateVisibility() provoke a crash.

If you want to test that, open a wad containing a map, then for example click on the THINGS lump and edit is as text. Save it so it'll be completely corrupted. Then double-click on the map header and you'll see the crash.

If the lump is missing or deleted, the MapEntryPanel preview thing will detect the problem when selected and remove the map from the map list, so you can't open. But if it's merely invalid, it can crash. (If you delete a lump, you can also get the crash, but you have to click on the map from the ArchiveManagerPanel's map list.)

sirjuddington

Re: Development thread
« Reply #10 on: October 09, 2011, 01:59:24 pm »
Well, just spent (most of) the weekend writing a polygon splitter class to generate a set of convex polygons from whatever random shape (ie sector). Finally just got it working nicely enough:



It's fairly fast too, takes ~550ms on my machine to generate all sector polygons for DV2 MAP29, ~800ms for Sunder MAP09. There are probably a couple more things I can think of to speed it up too, but for now it'll do.

So next up is getting floor/ceiling textures rendering on the 2d map.
« Last Edit: October 10, 2011, 03:24:58 pm by sirjuddington »

sirjuddington

Re: Development thread
« Reply #11 on: October 10, 2011, 03:23:42 pm »
Aaand... textures:


Gez

Re: Development thread
« Reply #12 on: October 12, 2011, 11:09:16 pm »
So apparently Plutonia MAP01 is a good stress test for the editor's ability to identify sectors:

sirjuddington

Re: Development thread
« Reply #13 on: October 13, 2011, 05:52:59 am »
Heh, strange, probably just a bug in the map loading code somewhere. Might have something to do with compressed sidedefs.

Yup, that was it. Fixed in r1076.
« Last Edit: October 13, 2011, 06:04:29 am by sirjuddington »

sirjuddington

Re: Development thread
« Reply #14 on: October 13, 2011, 04:18:00 pm »
Hmm, seems to have trouble with all the KDIZD maps. Is there anything special these use? I have support in for >32767 sides and compressed sides. Guess I'm missing something?