Something I can help with?

[mrugiero]

Hi, my name is Mario, I'm an amateur programmer. I know C and C++, mostly.
I was working as a pet project on Wolfenstein3D Redux (I mostly restored Linux support, which was dropped by the author, and then toyed a bit with some other bits, some modernization for the Linux backend, a little bit of bugfixing, those kind of things). Today I found out there was an actively developed source port and thought of helping you instead of just toying in my own.

A few things I can think about I could do right now are avoiding some unneeded builds on Linux (most dependencies are being built which come by default or are trivial to set up in most Linux distributions, so they could be disabled in Linux and dinamically link them instead), fixing warnings that may appear.

With a bit more work on it, I think it might be good to implement support for texture scaling (I think that's the only missing feature compared to Redux). Maybe porting to SDL2, too.

I'll provide patches for warnings/bugs I can fix, while I wait for any feedback on the other ideas.

[Blzut3]

Hi! There's definitely plenty of work that can be done.

I was working as a pet project on Wolfenstein3D Redux (I mostly restored Linux support, which was dropped by the author, and then toyed a bit with some other bits, some modernization for the Linux backend, a little bit of bugfixing, those kind of things). Today I found out there was an actively developed source port and thought of helping you instead of just toying in my own.

Well if you're looking for a project that will remain active for a long time I believe you came to the right place. I've already determined this will be the one project I keep even if I don't have time for anything else so ECWolf isn't going away any time soon.

A few things I can think about I could do right now are avoiding some unneeded builds on Linux (most dependencies are being built which come by default or are trivial to set up in most Linux distributions, so they could be disabled in Linux and dinamically link them instead), fixing warnings that may appear.

Well keep in mind that I do primary development on 64-bit Kubuntu. Unless you're a clang user, ECWolf should be fairly well maintained on Linux. The only two dependencies that are force static linked are LZMA and gdtoa. I don't believe I've seen a gdtoa package out there so that's why it's statically linked. For LZMA, there are two issues, first packages were rare until recently. Then I believe Randy had to make some modifications to get it compiling on Windows, Mac, and Linux without issues. It would be nice to get this updated to 9.20 and possibly optionally dynamically linked, but my attempts haven't been very successful.

Everything else in the build system are build utilities so there's not much point in trying to optimize those.

With a bit more work on it, I think it might be good to implement support for texture scaling (I think that's the only missing feature compared to Redux).

ECWolf supports arbitrary texture scaling ("texture" in ECWolf means any graphical resource). There are a few ways to define them including the TEXTURES lump, the hires namespace, and the scale property on actors.

Maybe porting to SDL2, too.

Feel free to finish this off if you wish. I experimented with it awhile back (before I used ZDoom's frame buffer code) and the main issue that held me back from supporting SDL2 is that it requires a rework of the input system. Not a huge deal, but I am foreseeing the need to change the input system anyway when a Quake/ZDoom style console is added (something I plan to do for 1.4 or 1.5). So if you wish to do this either keep in mind that the input work may be rewritten (not really a huge deal since it's a fairly small part of the code), or try to implement a console yourself.

For the console the big issue that needs to be solved for that is getting the menus on the 70hz timer (besides making the pull down animation work in the menus, this would also solve some issues with animations in the menus), my new menu code can be redone if need be.

I'll provide patches for warnings/bugs I can fix, while I wait for any feedback on the other ideas.

Have fun. Stop by IRC if you can, I'm usually on (although this weekend will be a bit spotty).

[mrugiero]

Well keep in mind that I do primary development on 64-bit Kubuntu. Unless you're a clang user, ECWolf should be fairly well maintained on Linux.

I use mostly GCC, but I always double check with clang (also, I do like to use it if I'm porting, as it's got colored messages which help me find the lots of errors faster) for warnings and such. I usually also check for cross-building for Windows when Windows is supposed to be supported, although I don't check with MSVC too often because I don't like having to boot to Windows (last time I updated it, it was stupidly trying to install 18 out of 1(ONE!) updates, so annoying). I use mingw for cross-building from Xubuntu and check it with WINE instead.

I don't believe I've seen a gdtoa package out there so that's why it's statically linked.

I didn't even know about gdtoa before seeing this project, I assumed it was some in-house tool from the project.

For LZMA, there are two issues, first packages were rare until recently. Then I believe Randy had to make some modifications to get it compiling on Windows, Mac, and Linux without issues. It would be nice to get this updated to 9.20 and possibly optionally dynamically linked, but my attempts haven't been very successful.

I could give it a try myself to this. Could you explain to me what failed in your attempt?

ECWolf supports arbitrary texture scaling ("texture" in ECWolf means any graphical resource). There are a few ways to define them including the TEXTURES lump, the hires namespace, and the scale property on actors.

This includes using scaling filters like HQ2X or similar? That's what I meant originally (I noticed it scales when changing the resolution), sorry for not being clear about it.

Feel free to finish this off if you wish. I experimented with it awhile back (before I used ZDoom's frame buffer code) and the main issue that held me back from supporting SDL2 is that it requires a rework of the input system. Not a huge deal, but I am foreseeing the need to change the input system anyway when a Quake/ZDoom style console is added (something I plan to do for 1.4 or 1.5). So if you wish to do this either keep in mind that the input work may be rewritten (not really a huge deal since it's a fairly small part of the code), or try to implement a console yourself.

Hmmm, I don't really fancy implementing the console. I'm studying a bit on compilers, so if I can help in that regard with the lexer and parser, I will, but I think everything else console related is out of my expertise. Rewriting the input work may be feasible, though, and that would imply (assuming we are not calling directly GLX or X11; SDL2 can help us create the GC without calling GLX directly anyway) we get Wayland and maybe Mir support for "free" (not really free, since we are porting to SDL2, but you know what I mean).

For the console the big issue that needs to be solved for that is getting the menus on the 70hz timer (besides making the pull down animation work in the menus, this would also solve some issues with animations in the menus), my new menu code can be redone if need be.

I might try to look into this, as it sounds interesting, but currently I lack experience on working with any kind of timer.

Have fun. Stop by IRC if you can, I'm usually on (although this weekend will be a bit spotty).

OK. I have to see how to configure XChat to automatically log into some channels, I'm getting tired of doing it manually every time.

[Blzut3]

I could give it a try myself to this. Could you explain to me what failed in your attempt?

It was mostly an issue of I could use the LZMA SDK from 7-zip and have something that only compiles on Windows, or use p7zip and have something that only compiles on unix like operating systems. I couldn't really figure out what changes were made to make it work everywhere. I haven't tried integrating with xz utils, but I don't think that supports the 7z reading API we're currently using from the old LZMA SDK. Documentation is a bit sparse from what I've seen so I didn't spend a whole lot of time with it.

ECWolf uses the lzma stuff for src/resourcefiles/file_7z.cpp as well as src/files.cpp for reading LZMA streams, and the zipdir utility (which compiles ecwolf.pk3) optionally uses it for LZMA compression in zip files (that's a standardized thing in case you weren't aware).

This includes using scaling filters like HQ2X or similar? That's what I meant originally (I noticed it scales when changing the resolution), sorry for not being clear about it.

Ahh, I thought you were asking about high resolution textures in general (ECWolf can handle Mac style graphics natively along side PC graphics for example). Integrating hqnx sounds like a good idea and shouldn't be too difficult for you to do. I can probably even port it upstream to ZDoom as well.

Probably the way to go about it would be to make a FilterTexture function in FTexture which can be called by the MakeTexture function in each texture type. Would be nice if this could just work automatically, but it wouldn't make sense for it to be run on jpegs for example.

Hmmm, I don't really fancy implementing the console. I'm studying a bit on compilers, so if I can help in that regard with the lexer and parser, I will, but I think everything else console related is out of my expertise. Rewriting the input work may be feasible, though, and that would imply (assuming we are not calling directly GLX or X11; SDL2 can help us create the GC without calling GLX directly anyway) we get Wayland and maybe Mir support for "free" (not really free, since we are porting to SDL2, but you know what I mean).

Just go for a straight port then. If you can try to #ifdef SDL 1.2 compatibility so I can continue to compile for Windows 98, but if you don't feel like doing that I can take care of it. The issue with the input system is just that Wolf4SDL has an array of 256 buttons that is used to store the state of each key on the keyboard. SDL2 expanded the scan codes to 32-bit so this route is no longer feasible. You will need to look at what keys are bound and read those into a smaller array.

Before I switched to ZDoom's frame buffer code, I wrote some 8-bit blitting code you may or may not find useful since SDL 2 no longer supports 8-bit surfaces (for good reasons).

I might try to look into this, as it sounds interesting, but currently I lack experience on working with any kind of timer.

Basically this involves making the entire game call CalcTics during the DemoLoop and the menu event loop. This function will wait until a 70Hz timer fires before returning and then set the variable tics to be how many tics has passed (important for slow systems). Then you just run your menu event function that number of times. You can probably rewrite the menu class hierarchy to inherit from the Thinker class which provides some services like run time type identification, but more importantly automatically places the objects on a list so you can tick them all with one function call. Such objects are also garbage collected if they're removed from the list.

[mrugiero]

It was mostly an issue of I could use the LZMA SDK from 7-zip and have something that only compiles on Windows, or use p7zip and have something that only compiles on unix like operating systems. I couldn't really figure out what changes were made to make it work everywhere. I haven't tried integrating with xz utils, but I don't think that supports the 7z reading API we're currently using from the old LZMA SDK. Documentation is a bit sparse from what I've seen so I didn't spend a whole lot of time with it.
ECWolf uses the lzma stuff for src/resourcefiles/file_7z.cpp as well as src/files.cpp for reading LZMA streams, and the zipdir utility (which compiles ecwolf.pk3) optionally uses it for LZMA compression in zip files (that's a standardized thing in case you weren't aware).

That's weird. Most of the code looks like it should build (and like they got out of their way for it) anywhere. There are some pieces that use Windows specific features, but I think those are expendable, and are probably not in use. I'll look deeper into it later, but I think I could track which are the files we actually need and if they need any change. We can also delete the ones we don't need, so users have a faster download of the source if desired.
In another subject, I'm not sure LZMA really makes sense to store already compressed files. Aren't music and sprites already compressed in other formats? If so, I think it would make more sense to aim for speed on packing, use something like tar, without an extra attempt at compression.

Ahh, I thought you were asking about high resolution textures in general (ECWolf can handle Mac style graphics natively along side PC graphics for example). Integrating hqnx sounds like a good idea and shouldn't be too difficult for you to do. I can probably even port it upstream to ZDoom as well.

Probably the way to go about it would be to make a FilterTexture function in FTexture which can be called by the MakeTexture function in each texture type. Would be nice if this could just work automatically, but it wouldn't make sense for it to be run on jpegs for example.

Well, maybe if we add (or is it already there?) a private variable telling about the texture's format to know if using such a function makes sense or it should be avoided, it could be made automatic without any caring on the side of the class users.

Just go for a straight port then. If you can try to #ifdef SDL 1.2 compatibility so I can continue to compile for Windows 98, but if you don't feel like doing that I can take care of it. The issue with the input system is just that Wolf4SDL has an array of 256 buttons that is used to store the state of each key on the keyboard. SDL2 expanded the scan codes to 32-bit so this route is no longer feasible. You will need to look at what keys are bound and read those into a smaller array.

Ifdeffing sounds easy enough to not bother you, if I have to change something, I just ifdef whatever there was before (of course, in the SDL2 porting, other things shouldn't be needed to ifdef). I'm not sure what you mean by "bound".

Before I switched to ZDoom's frame buffer code, I wrote some 8-bit blitting code you may or may not find useful since SDL 2 no longer supports 8-bit surfaces (for good reasons).

I've read your discussion here; the only little thing I could add is that maybe the fallback could be TinyGL, if we limit OpenGL use to the subset it supports. That's how ResidualVM handles it. It also provides the copy of TinyGL with it. Or we could just assume that if they are using a computer that meets the conditions for SDL2, they can do basic OpenGL? (I mean, Windows Vista and upwards kind of asks you to, and Wayland and Mir does the same; we could keep the SDL1.2 for non-NT Windows and XP and for X11 based distributions, and use SDL2 in other cases)

[Blzut3]

That's weird. Most of the code looks like it should build (and like they got out of their way for it) anywhere. There are some pieces that use Windows specific features, but I think those are expendable, and are probably not in use. I'll look deeper into it later, but I think I could track which are the files we actually need and if they need any change. We can also delete the ones we don't need, so users have a faster download of the source if desired.

The set that ZDoom uses should be about minimal as of whatever version of the SDK it uses, so yes selecting exactly what is needed is fine. The main thing I'm concerned about is making sure LZMA2 support is there.

In another subject, I'm not sure LZMA really makes sense to store already compressed files. Aren't music and sprites already compressed in other formats? If so, I think it would make more sense to aim for speed on packing, use something like tar, without an extra attempt at compression.

While that's true for sampled music and PNG/JPEG textures, the classic resource formats are uncompressed and benefit from the compression. Of course if one wants they can use a supported uncompressed container like WAD, PAK, or even ZIP with compression turned off. Usually utilities, including zipdir, are smart enough to store files that don't compress without compression. Deflate, LZMA, and BZip2 decompression time is usually unnoticable as long as the archive is non-solid.

ECWolf uses the entire resource management code from ZDoom so how things are set up now is compatible with Doom editing tools (as well as Wolf editing tools although I don't particularly recommend using the classic archive formats since, besides being limited, they're horrible for the player experience being 8 different files and all).

Well, maybe if we add (or is it already there?) a private variable telling about the texture's format to know if using such a function makes sense or it should be avoided, it could be made automatic without any caring on the side of the class users.

Not a bad idea, but using a variable would utilize extra memory for every texture. Somewhat needless since the value would be read infrequently and the variable would still need to be set manually. You would even still need to call the currently non-existant Texture::MakeTexture from the inheriting classes any how since MakeTexture is called only when the data needs to be cached into memory.

I'm not sure what you mean by "bound".

The user binds functions to keys in the controls menu. In other words, for SDL2 you would need to look at what keys the user is actually using and scan for only those events instead of catching all key events into an array. (This method should also work with SDL1 as well.)

The bindings array is controlScheme in wl_play.cpp.

I've read your discussion here; the only little thing I could add is that maybe the fallback could be TinyGL, if we limit OpenGL use to the subset it supports. That's how ResidualVM handles it. It also provides the copy of TinyGL with it. Or we could just assume that if they are using a computer that meets the conditions for SDL2, they can do basic OpenGL? (I mean, Windows Vista and upwards kind of asks you to, and Wayland and Mir does the same; we could keep the SDL1.2 for non-NT Windows and XP and for X11 based distributions, and use SDL2 in other cases)

Yeah using GL for the conversion is fine. It should be easy enough to fall back to SDL surfaces and manual 8-to-32 conversion if GL is not available.

[mrugiero]

The set that ZDoom uses should be about minimal as of whatever version of the SDK it uses, so yes selecting exactly what is needed is fine. The main thing I'm concerned about is making sure LZMA2 support is there.

According to LZMA SDK page, LZMA2 is supported since 9.04.