Closed adolfintel closed 6 years ago
I guess you are not familiar with building software from source? In general, typing ‘make’ does stuff. This is how stuff works with at least 99,9% of open source projects. Basically with almost anything you download from the Internet. Sometimes you need to type ‘./configure’ first, but this step is not required for ADLMIDI. Funny that you didn’t think of it.
Well, unless you are running Windows. If you have chosen to encumber yourself with a Windows-based platform, then… my condolences.
I do it occasionally on linux, but here I'm trying to use Cygwin on windows, which is a pain in the ass. You have a screenshot of the program running on Windows 7 on your site, how did you build it?
Maybe this is your first open source project you come across. In that case, being more polite and not starting off with language like “fuck” would be a good start.
For Cygwin… you type ‘make’.
It doesn't work, that was the first thing I tried. I'm trying to install the deps it needs one by one, right now I'm at SDL, which package is required?
My apologies for yelling at you, I've been trying to build it for over an hour.
As a general notion though, Windows support is provided as least-effort without any guarantee of being maintained. I don’t run Windows except very very randomly and occasionally, and it is even rarer that I try to build software on Windows. So pardon me that I have not expended effort in writing extensive instructions for Windows-encumbered people.
If SDL is not available in Cygwin package manager, you will have to build it from source. Unfortunately I don’t have access to a running Windows system at the moment, so I am unable to provide instructions how to do that, at least not instructions that would be better than those available within SDL website or its source code package.
And then, for ADLMIDI… You may have to edit Makefile and switch out the compiler definition near the beginning of the file, because for one reason or other, the default does not work on Windows. Zero or more of the provided examples at the top of the file might work. I say zero, because things seem to have changed every single time I try it in Windows. Things aren’t easy in Windows-land.
As for -std=c++1y not being recognized looks like you are running a rather obsolete compiler version. You can try if an earlier standard version is supported by your outdated compiler, e.g. -std=c++0x. I can’t remember if ADLMIDI uses c++14 features or not. You can delete the -fopenmp option though, I don’t remember there being anything in this project that requires it. It’s in Makefile.
It's gcc 6.4.0
Does it cross-compile from linux or does it require some modifications?
-Ofast has been supported by GCC since version 4.6. The version that prints those errors cannot be GCC 6.4.0.
Ah, it looks like gcc was installed but not in the path. Now it almost builds. It's missing SDL.h now.
You can try cross-compilation for Windows from Linux. Like I said things are provided at least-effort. Windows support is not exactly a priority for me. I am open for push requests that improve things in a well designed manner though. It is likely that the CC= settings at the top of Makefile are actually meant for a cross-compiler.
I understand your point of view, but you have an awesome project here, and Windows has 95% of the market share...
This is not a commercial project, so I could not care less about market.
Windows is a hostile environment for developers, and that keeps me out from it.
Oh by the way, SDL is not required for the Windows version. The code that depends on SDL is automatically disabled if either __WIN32__
or __CYGWIN__
is defined (which is defined if you are building for these targets).
Thanks for the tip. 😄
Looks like adldata.hh wants it though
Cross-compilation from Linux seems to mostly work if you switch the CC defines and disable the SDL defines in Makefile. There seems to be at least one standard function (setbuffer) that is missing from at least my version of mingw, so I digress.
adldata.hh does not want it, if you use a compiler (CC) that builds native Windows binaries (and not cygwin/linux).
Yup, with this patch it compiles on Linux with ‘make’ and builds a Windows binary.
index dcbb570..c121725 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
#CXX=i686-w64-mingw32-g++ -m64
-#CXX=x86_64-w64-mingw32-g++ -m64 -static-libgcc -static-libstdc++
+CXX=x86_64-w64-mingw32-g++ -m64 -static-libgcc -static-libstdc++
-CXX = g++
+#CXX = g++
CXXLINK = $(CXX)
#DEBUG = -O0 -fno-inline -D_GLIBCXX_DEBUG -g -fstack-protector-all -fdata-sections -fsanitize=address
@@ -12,11 +12,11 @@ DEBUG=-Ofast -g -fopenmp -march=native
# -march=pentium -mno-sse -mno-sse2 -mno-sse3 -mmmx
-CPPFLAGS += $(shell pkg-config --cflags sdl)
-LDLIBS += $(shell pkg-config --libs sdl)
+#CPPFLAGS += $(shell pkg-config --cflags sdl)
+#LDLIBS += $(shell pkg-config --libs sdl)
#CPPFLAGS += $(SDL)
-#LDLIBS += -lwinmm
+LDLIBS += -lwinmm
CPPFLAGS += -std=c++1y -pedantic -Wall -Wextra
diff --git a/midiplay.cc b/midiplay.cc
index 119b831..64eb612 100644
--- a/midiplay.cc
+++ b/midiplay.cc
@@ -358,7 +358,9 @@ public:
std::memset(slots, '.', sizeof(slots));
std::memset(background, '.', sizeof(background));
std::memset(backgroundcolor, 1, sizeof(backgroundcolor));
- setbuffer(stderr, stderr_buffer, sizeof(stderr_buffer));
+ #ifndef __WIN32__
+ std::setbuffer(stderr, stderr_buffer, sizeof(stderr_buffer));
+ #endif
RawPrn("\r"); // Ensure cursor is at the x=0 we imagine it being
Print(0, 7, true, "Hit Ctrl-C to quit");
}
(Warning: resulting binary is UNTESTED)
There is also the option of using make -f Makefile.w32
or make -f Makefile.cygwin
#include <usual disclaimer>
Alright, that seems to work, I have some exe files. But it only plays while I'm playing that tetris thing? There's some blocking call to read the keyboard?
Shouldn’t be blocking. If it blocks, try fixing it. I don’t have a Windows computer here at hand to test it out and to debug it.
I removed the tetris game. It plays but it stutters like hell. Any suggestion?
Try a different buffer size perhaps. Or try the older version that I used when recording this video: https://www.youtube.com/watch?v=7IeO7CYFd9E (probably commit 8330d5cbf35b7745a10d2bb89e75ea000a33387d)
I already tried changing the buffer size. I think it has something to do with how you draw to the screen. I'll see if I can do something
setting const double OurHeadRoomLength = 5; "fixes" the sound stuttering. The screen is all messed up though, even on xterm.
Looks like this in all terminals I have installed
Yeah I am aware the terminal size recognition is wonky and does not quite work properly. (And even if it recognizes it, it does not perfectly honor it. You are better off using a large terminal with small font :-)) This problem is not specific to Windows, it affects Linux too.
However, the random letters (which are not random, they indicate notes being voiced) appearing over metadata is intentional. If they fail to disappear as the note keys off, then there is a bug.
Just for curiosity, I see you have included a way to output to ffmpeg. Does that work? I have an (unpublished) project where I used ffmpeg to do stuff in real time and it was a pain in the ass
It worked when I needed it. That’s what I have used for the videos on https://www.youtube.com/channel/UCHFXRDwqIlcwcRSSSUmJJ5g/videos . Whether it still works I am unable to say for sure. It is not an advertised feature.
I thought the UI lag and the sound stuttering were related but I was wrong, How odd.
Either way, it's good to have a decent Midi OPL player.
In case some other poor soul wants to use this on Windows, I'll leave the binaries here. binaries.zip
Thanks again for your help. I can send you a donation if you want ;)
Seriously, there are no build instructions and no binaries, what the fuck am I supposed to do? Guess how to build it?