Page 3 of 5
Re: [~85%] Unwad - a minimal wad tool (syntax spoiler updated)
Posted: Wed Sep 10, 2008 2:54 pm
by bagheadspidey
Code: Select all
/* XPM */
static char * unicycle_xpm[] = {
"37 60 7 1",
" c None",
". c #FFFFFF",
"+ c #FD0000",
"@ c #000000",
"# c #555555",
"$ c #888888",
"% c #FD6500",
" ++++ ",
" +++++++ ",
" ++++++++++++++++++ ",
" ++++++++++++++++++ ",
" ++++++++++++++++++ ",
" ++++++++++++++++++ ",
" ++++++++++++++++ ",
" ++++++++++++++ ",
" +++++++++++ ",
" @@ ",
" @@ ",
" @@ ",
" @@ ",
" @@ ",
" @@ ",
" @@ ",
" @@ ",
" @@ ",
" @@ ",
" @@ ",
" @@ ",
" ####@@### ",
" #######@@###### ",
" #########@@######## ",
" #######$$$@@$$####### ",
" #####$$$$$$@@$$$$$##### ",
" ####$$$$$ @@ $$$$$#### ",
" ####$$$$ @@ $$$$#### ",
" ####$$$ $ @@ $ $$$#### ",
" ####$$$ $ @@ $ $$$#### ",
" ###$$$ $ @@ $ $$$### ",
" ####$$ $ $ @@ $ $ $$#### ",
" ##%%%%%%%%%%% @@ $ $ $$### ",
" ###%%%%%%%%%%%$ @@ $ $ $$$### ",
" ###%%%%%%%%%%%$ @@ $ $ $$### ",
" ###%%%%%%%%%%%@$ @@$ $ $$$### ",
"###$$$ $$$ @@@#@@# $ $$$ $$$###",
"###$$ $$ @@@@@## $$ $$###",
"###$$ $$##@@@@###$$ $$###",
"###$$ ###@@@### $$###",
"###$$$$$$$$$$$###$@@@##$$$$$$$$$$$###",
"###$$ ###$$@@@# $$###",
"###$$ $$######@@@$$ $$###",
"###$$ $$ ######@@@ $$ $$###",
"###$$$ $$$ $ ##### @@@ $$$ $$$###",
" ###$$$ $ $ $ $ @@@ $$$### ",
" ###$$ $ $ $ $ @@@ $$### ",
" ###$$$ $ $ $ $ @@@ $$$### ",
" ###$$ $ $ $ $%%%%%%%%%%%## ",
" ####$$ $ $ $ %%%%%%%%%%%## ",
" ###$$$ $ $ %%%%%%%%%%%# ",
" ####$$$ $ $ %%%%%%%%%%%# ",
" ####$$$ $ $ $ $$$#### ",
" ####$$$$$ $ $$$$$#### ",
" ####$$$$$ $ $$$$$#### ",
" #####$$$$$$$$$$$$$##### ",
" #######$$$$$$$####### ",
" ################### ",
" ############### ",
" ######### "};
Re: [~85%] Unwad - a minimal wad tool (syntax spoiler updated)
Posted: Wed Sep 10, 2008 2:56 pm
by Da Spadger
<Spadger> AWESOME
Re: [~85%] Unwad - a minimal wad tool (syntax spoiler updated)
Posted: Wed Sep 10, 2008 2:59 pm
by Kate
Haha, that is the best ascii art I've seen in a while. But considering that a format like this could be endlessly useful, I would have to support adding this type of image syntax to ZDoom, since adding things that would have to be embedded into metadata could simply be written directly into the image information itself with XPM's C syntax.
Re: [~95%] Unwad - a minimal wad tool (need windows builder)
Posted: Fri Sep 12, 2008 10:00 pm
by bagheadspidey
Alright, who wants to build this thing for windows?
you'll need these libraries and headers:
libmagic (guess unknown file types)
libboost_filesystem (make directories, etc)
libboost_regex
libpng, png++ headers
libFLAC, libFLAC++
Warning
There is a lot of safety checking that needs to be done, so don't do anything stupid like point it at non-existing files or use weird filter or replacement strings that don't conform to the syntax in the help file and in the title post. That will be fixed soon.
Other than that it's very useful already although I'm still adding stuff =) eventually I'd like to get a svn set up, but for now...
unwad v. 0.01 pre-beta source
.
Re: [~85%] Unwad - a minimal wad convertor and extractor
Posted: Sat Sep 13, 2008 8:52 am
by .+:icytux:+.
Enjay wrote:.+:icytux:+. wrote:this would be, converting bmps to pngs.
Why would that be useful? There shouldn't be any WADs with BMPs in them. I'm not aware of any engine that supports BMPs.
Also, just making a blanket "make the sound file smaller" filter wouldn't appropriate either because some sounds don't work as well in some formats as they do with others.
umm. isn't the original doom sprites bmps? it was stuff like them i was thinking about, they take aloooooot more room than a png.
Re: [~95%] Unwad - a minimal wad tool (need windows builder)
Posted: Sat Sep 13, 2008 9:48 am
by wildweasel
The original Doom graphics format is basically raw pixel data, as far as I can recall...
Re: [~85%] Unwad - a minimal wad convertor and extractor
Posted: Sat Sep 13, 2008 10:21 am
by Zippy
.+:icytux:+. wrote:umm. isn't the original doom sprites bmps?
Not at all. Doom knows nothing about BMPs and the same is true for ZDoom. Doom used its own image format (which we might as well call Doom Image Format). They are quite different.
Re: [~95%] Unwad - a minimal wad tool (need windows builder)
Posted: Sat Sep 13, 2008 10:26 am
by bagheadspidey
Flats are like raw pixel data, but all other doom images are very different. Instead of being organized in rows (left to right, top to bottom) like other images, they are organized as columns (top to bottom, left to right), with each column beginning and ending at the edges of the visible area of the sprite rather than the edges of the image. That's where the transparency comes from, transparent pixels have no data stored and are simply not drawn (so it doesn't take up a palette entry).
Basically, the doom image format is very much unlike any common image format that exists.
edit - zippy beat me to it ;p
Re: [~99%] Unwad - minimal wad tool (windows build pretty plz?)
Posted: Sat Sep 13, 2008 6:00 pm
by bagheadspidey
Nobody wants to take a crack at building this for windows? Gez? Enjay? Almost everything discussed has been implemented (check the title post). Safety checks are in place and everything is running smoothly. This thing is very useful so far. I'd say it's more powerful than deutex in many ways already, although it doesn't support any obscure alpha formats yet.
So, what do I need to do to get you guys to build yourselves a windows version of this thing so we can start testing it out on a larger scale? Seriously, let me know.
Here's the link again (updated) -
http://bagheadspidey.sitesled.com/unwad/unwad.zip
Re: [~99%] Unwad - minimal wad tool
Posted: Tue Sep 16, 2008 5:42 pm
by bagheadspidey
ok, so flac refuses to link properly with g++ on windows and i cant find any precompiled dlls for the boost.filesystem stuff... so i gave up on building it on windows.
But, that doesn't mean there won't be a windows build.
This post helped a ton. Stay tuned =)
Code: Select all
owner@vaio-fs:~$ cat test.cpp
#include <iostream>
using namespace std;
int main()
{
cout << "Hello World!" << endl;
}
owner@vaio-fs:~$ i586-mingw32msvc-g++ -Wall test.cpp -o test.exe
owner@vaio-fs:~$ file test.exe
test.exe: MS-DOS executable PE for MS Windows (console) Intel 80386 32-bit
owner@vaio-fs:~$ wine test.exe
Hello World!
Re: [~85%] Unwad - a minimal wad convertor and extractor
Posted: Sat Sep 20, 2008 1:24 am
by Graf Zahl
Enjay wrote:
And, by the sound of what people have been saying, it is planned to do one thing that Slumped can't - run on Vista without crashing. However, I neither use Vista (yet) nor Slumped so I can't really comment on that.
All crashes in Slumped are programming errors. It mostly works fine for me. It's just too bad that it is no longer maintained...
bagheadspidey wrote:
So, what do I need to do to get you guys to build yourselves a windows version of this thing so we can start testing it out on a larger scale? Seriously, let me know.
Don't use crap libraries and compilers that nobody uses on Windows. Unless there's a VC++ project it won't happen. Strange that LInux users always complain about Windows only developement but then fall into the same trap.
That said, my biggest issue with it is all the autoconversion stuff going on, especially MUS->MIDI. My general experience with this is to leave these file formats alone.
And if you ask me: Too much use of C++ library crap (I hate IOstream.)
Re: [~99%] Unwad - minimal wad tool
Posted: Sat Sep 20, 2008 5:15 am
by Tormentor667
That tool owns
Re: [~85%] Unwad - a minimal wad convertor and extractor
Posted: Sat Sep 20, 2008 7:00 am
by Rachael
Graf Zahl wrote:Don't use crap libraries and compilers that nobody uses on Windows. Unless there's a VC++ project it won't happen. Strange that LInux users always complain about Windows only developement but then fall into the same trap.
Will agree immensely with that one. Had enough trouble setting up VC++ on my Vista computer, and I have MinGW installed on my XP one but no libraries installed. Won't go through the crap again.
That said, my biggest issue with it is all the autoconversion stuff going on, especially MUS->MIDI. My general experience with this is to leave these file formats alone.
This one, I really think it should be left to user preference. Give options to decide whether and what to convert, and possibly even to what.
Re: [~85%] Unwad - a minimal wad convertor and extractor
Posted: Sat Sep 20, 2008 10:44 am
by bagheadspidey
Graf Zahl wrote:I hate IOstream.
What? cout owns, and the iostream stuff compiles fine on windblows. Is there some alternative I should be using? It seems to work great for me.
It's only flac and boost.filesystem that won't link on all platforms. Maybe they have some dependencies I need to link as well, not sure. I think i'm gonna ditch flac for .au / .wav and write the filesystem stuff by hand, one copy for windblows and one for linux.
SoulPriestess wrote: graf wrote:That said, my biggest issue with it is all the autoconversion stuff going on, especially MUS->MIDI. My general experience with this is to leave these file formats alone.
This one, I really think it should be left to user preference. Give options to decide whether and what to convert, and possibly even to what.
Agreed. This is a planned feature. It will be no problem to add, but I want to get it compiling on all platforms first.
As for vc++, once I get rid of the "crap libraries" (in this case flac and boost.filesystem, apparently) it should be easy enough to create a build file for vc++ by looking at the included g++ build files, right? I don't own that program so unfortunately someone else will have to do that, unless there is a free version I am unaware of?
Re: [~85%] Unwad - a minimal wad convertor and extractor
Posted: Sat Sep 20, 2008 11:32 am
by Graf Zahl
bagheadspidey wrote:Graf Zahl wrote:I hate IOstream.
What? cout owns, and the iostream stuff compiles fine on windblows. Is there some alternative I should be using? It seems to work great for me.
iostream is inefficient shit. Everyone not seeing this has never been in a situation where this bloated abomination hasn't blown an application out of proportions - both in code size and performance.
And before you ask: Yes, I have seen it - and rewriting all output to use (f)printf not only made the executable 25% of its original size but also made it run magnitudes faster. Since that day I have sworn never *ever* to use IOStream again for anything.