I was going through the build instructions and I was confused by the cmake command. The instructions state to run -DSDL2_LIBRARIES="../../SDL2-2.0.10/lib/x86/SDL2;../../SDL2-2.0.10/lib/x86/SDL2main;../../SDL2_mixer-2.0.4/lib/x86/SDL2_mixer". Aren't you supposed to link directly to the libraries like this: -DSDL2_LIBRARIES="../../SDL2-2.0.10/lib/x86/SDL2.lib;../../SDL2-2.0.10/lib/x86/SDL2main.lib;../../SDL2_mixer-2.0.4/lib/x86/SDL2_mixer.lib". If you don't link to the libraries, the build fails with the error SDL2.obj not found.

Does the PhysicsFS library sources in the repo correspond to a specific upstream version (if yes, which?) or does it has custom changes on top?

I have X held down the entire time in this gif

It seems in one of the more recent commits, data.zip being in the current working directory was forced. Earlier I was able to extract the assets to ~/.local/share/vvvvvv (Yeah I know the folder is uppercase now)

Maybe in addition to $PWD, also include the ~/.local/share/VVVVVV folder in the search?

In this code, the graphics.backBuffer is created in 32bpp, but with the color masks from gameScreen.GetFormat() (which might be 16bpp for example if the gamesScreen has that format):

According to the SDL documentation, if this value is larger than 8, then the masks are used anyway. So I assume this is a bug?

Note that all other surfaces (like foregroundBuffer) use fmt->BitsPerPixel instead.

It would be nice to have SDL includes and libs found automatically, and used in the project. I found an interesting project that can be used here.

https://github.com/aminosbh/sdl2-image-sample

Thank you

Hello!

First, a huge thanks for releasing this incredible game source code :D! This is truly awesome! But what could be even better, is to package it properly for Linux Distributions. And you seem to not be against this idea according to your comment in #2. So, this is a basic checklist to what needs to be done in order to have it packaged (at least, in RPM):

Mandatory changes

• Technical: Adding a .desktop file: would allow it to show in start menus
• Technical: Adding a .appdata.xml: would allow it to show in application stores
• Technical: Adding the possibility to load this data.zip from XDG_DATA_DIRS to avoid having a .zip in the binary directory (#139)

I would be happy to help with these.

Optional changes

• Legal: Adding a non-proprietary, "redistributable" data.zip: or that would mean that the user should do some further steps to get it working which would defeat the whole purpose of packaging

• [REFUSED] Legal: Change the license to choose a more common one: easier to be accepted by distribution's legal teams #7

Progress

With all those who declared their interest in packaging VVVVVV in this thread. Please confirm you're willing to package it ;).

• Flatpak: Through Flathub (?) and Athenaeum
• Snap: ?

• Arch: Already available
• Debian: ?
• Fedora: Through official repo (need Legal review process) or RPM Fusion (@LyesSaadi)
• Gentoo: (@lanodan ?)
• NixOS: (@dkudriavtsev)
• Ubuntu: ?

Documentation

• Requirements: (SDL2, SDL2_mixer / libsdl2, libsdl2-mixer)
• BuildRequirements: gcc, make, cmake, (SDL2-devel, SDL2_mixer-devel / libsdl2-dev, libsdl2-mixer-dev)
• Desktop and AppData entries [WIP]

I also have to insist on the importance of the legal changes if you want VVVVVV to be packaged. If the second of the optional changes (license) is not met, it would be a LOT harder to get it to land in official repos, maybe some unofficial ones. And if the first (data.zip) is not met, packaging would be useless.

But, hey, this is your (awesome) game and these are your choice. So, feel free to decide otherwise :).

Also, I would be happy to be VVVVVV's Fedora Packager.

Just thought I'd raise this. It's probably related to #15 as when I compiled it 8 days ago it didn't.

For now, I'm happy to just revert the change on my end when I build, but thought I'd raise it.

Keep up the great work!

Thought it would be cool if we had this, any reason why CI doesn't upload them?

As discussed on the Steam forums, the icon (at least for the Windows executable) only goes up to 64x64. I cannot verify this; as I only have the 3DS version atm; but there should preferably be 96x96, 128x128, and 256x256 icons across Windows and Linux (and maybe 512x512 on OS X). Creating these icon sizes should be trivial, as the art style permits a integer upscale of the lower-resolution icons.

https://github.com/gabomdq/SDL_GameControllerDB

SDL2 supports reading from a file in the PWD/environment variable path containing a mapping of controllers centralized around the Xbox 360 mapping. This makes it dead simple to instantly support most every controller out there and easy to add new ones by just appending mappings to the file.

Would be great to have this support in VVVVVV

I've been trying to get the code compiling in Haiku shortly after the announcement dropped. I've added a few minor changes to some of the source files, which can be seen in this fork. This is being done in the latest Haiku x86_64, with libsdl2_devel and sdl2_mixer_devel installed along with their dependencies. I was eventually able to get everything to build, but linking fails with this:

/boot/system/develop/tools/bin/../lib/gcc/x86_64-unknown-haiku/8.3.0/../../../../x86_64-unknown-haiku/bin/ld: libphysfs-static.a(physfs.c.o): in function `calculateBaseDir':
physfs.c:(.text+0x1efc): undefined reference to `__PHYSFS_platformCalcBaseDir'
/boot/system/develop/tools/bin/../lib/gcc/x86_64-unknown-haiku/8.3.0/../../../../x86_64-unknown-haiku/bin/ld: libphysfs-static.a(physfs.c.o): in function `PHYSFS_init':
physfs.c:(.text+0x20dd): undefined reference to `__PHYSFS_platformInit'
/boot/system/develop/tools/bin/../lib/gcc/x86_64-unknown-haiku/8.3.0/../../../../x86_64-unknown-haiku/bin/ld: libphysfs-static.a(physfs.c.o): in function `doDeinit':
physfs.c:(.text+0x273f): undefined reference to `__PHYSFS_platformDeinit'
/boot/system/develop/tools/bin/../lib/gcc/x86_64-unknown-haiku/8.3.0/../../../../x86_64-unknown-haiku/bin/ld: libphysfs-static.a(physfs.c.o): in function `PHYSFS_getCdRomDirs':
physfs.c:(.text+0x2f3f): undefined reference to `__PHYSFS_platformDetectAvailableCDs'
/boot/system/develop/tools/bin/../lib/gcc/x86_64-unknown-haiku/8.3.0/../../../../x86_64-unknown-haiku/bin/ld: libphysfs-static.a(physfs.c.o): relocation R_X86_64_PC32 against undefined hidden symbol `__PHYSFS_platformDetectAvailableCDs' can not be used when making a shared object
/boot/system/develop/tools/bin/../lib/gcc/x86_64-unknown-haiku/8.3.0/../../../../x86_64-unknown-haiku/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
CMakeFiles/VVVVVV.dir/build.make:551: recipe for target 'VVVVVV' failed
make[2]: *** [VVVVVV] Error 1
CMakeFiles/Makefile2:137: recipe for target 'CMakeFiles/VVVVVV.dir/all' failed
make[1]: *** [CMakeFiles/VVVVVV.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

Is there a flag that needs to be passed or files to be changed? Asking since the PhysicsFS static library version in the repo does seem to have some Haiku support already:
https://github.com/TerryCavanagh/VVVVVV/blob/master/third_party/physfs/physfs_platforms.h

So cool to see this source code available!

However, I'm getting the following build error after running make:

...
[98%] Building C object CMakeFiles/VVVVVV.dir/src/SteamNetwork.c.o
/tmp/makepkg/vvvvvv-git/src/VVVVVV/desktop_version/src/editor.cpp: In member function ‘voideditorclass::findstartpoint(Game&)’:
/tmp/makepkg/vvvvvv-git/src/VVVVVV/desktop_version/src/editor.cpp:1597:45: error: array subscript -1 is below array bounds of ‘edentities [3000]’ [-Werror=array-bounds]
 1597 |         game.edsavedir=1-edentity[testeditor].p1;
      |                          ~~~~~~~~~~~~~~~~~~~^
/tmp/makepkg/vvvvvv-git/src/VVVVVV/desktop_version/src/editor.cpp:2207:19: note: while referencing ‘edentity’
 2207 | extern edentities edentity[3000];
      |                   ^~~~~~~~
cc1plus: all warnings being treated as errors
make[2]: *** [CMakeFiles/VVVVVV.dir/build.make:89: CMakeFiles/VVVVVV.dir/src/editor.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:111: CMakeFiles/VVVVVV.dir/all] Error 2
make: *** [Makefile:84: all] Error 2
==> ERROR: A failure occurred in build().

Kinda unsure why it outputs cc1plus: all warnings being treated as errors, as the cmake file should disable this.

System details

• I'm using this AUR PKGBUILD (which pretty much just follows the build instructions for Linux)
• Build using

$ uname -mor
5.4.10-arch1-1 x86_64 GNU/Linux
$ g++ --version
g++ (GCC) 9.2.0
$ cmake --version
cmake version 3.16.2

It's cool that you released the code! Unfortunately it's not actually an open source license!

I would recommend you use something like the GPLv3+ like John Carmack did when he release Quake source.

Happy to answer any licensing questions you have! Good luck!

I feel like this should have a proper Contributor License Agreement which gives you more rights to relicense in the future.
So if #7 or something go through (now or in the very distant feature), then you don't have to contact all the original contributors (Remember MAME?).

Even now it's getting problematic to reach out to contributors because GitHub doesn't demand a proper e-mail address in commits + it doesn't allow PMs + some people only use nicknames in the contributor file.

Software like https://cla-assistant.io/ could also be used to automate this step, to avoid situations like #29 (comment)

The issue with CLAs would be that some people are passionately against them; however, the same goes for the current license and the very lighweight CLA that already exists, so I don't think a more complete CLA would be problematic. I'm also not convinced that the existing lightweight CLA is even legally binding (same for the license). #notalawyer

The mobile version README.md links to https://thelettervsixtim.es/opensource/vvvvvv%20mobile%20data%20folder.zip
The desktop version doesn't seem to have such a file. This leads to the following crash:

[New Thread 0x7fffeef91700 (LWP 165545)]
double free or corruption (out)

Thread 1 "vvvvvv.x86_64" received signal SIGABRT, Aborted.
0x00007ffff761ff25 in raise () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007ffff761ff25 in raise () at /usr/lib/libc.so.6
#1  0x00007ffff7609897 in abort () at /usr/lib/libc.so.6
#2  0x00007ffff7663258 in __libc_message () at /usr/lib/libc.so.6
#3  0x00007ffff766a77a in  () at /usr/lib/libc.so.6
#4  0x00007ffff766c5d0 in _int_free () at /usr/lib/libc.so.6
#5  0x00005555555db1d9 in FILESYSTEM_freeMemory(unsigned char**) (mem=0x7fffffff8be0) at /home/fox/Data/Projects/VVVVVV/desktop_version/src/FileSystemUtils.cpp:116
#6  0x0000555555826bed in SoundTrack::SoundTrack(char const*) (this=0x7fffffff8c50, fileName=0x555555947f8e "sounds/jump.wav") at /home/fox/Data/Projects/VVVVVV/desktop_version/src/SoundSystem.cpp:36
#7  0x00005555556ad3e2 in musicclass::musicclass() (this=0x7fffffffaf00) at /home/fox/Data/Projects/VVVVVV/desktop_version/src/Music.cpp:8
#8  0x00005555558ebade in main(int, char**) (argc=1, argv=0x7fffffffe888) at /home/fox/Data/Projects/VVVVVV/desktop_version/src/main.cpp:98
(gdb) 

I'm able to work around this issue by this patch:

diff --git a/desktop_version/src/FileSystemUtils.cpp b/desktop_version/src/FileSystemUtils.cpp
index c2f936c..f664bdb 100644
--- a/desktop_version/src/FileSystemUtils.cpp
+++ b/desktop_version/src/FileSystemUtils.cpp
@@ -75,7 +75,8 @@ void FILESYSTEM_init(char *argvZero)
 #else
        strcpy(output, "data.zip");
 #endif
-       PHYSFS_mount(output, NULL, 1);
+       PHYSFS_mount("data", NULL, 1);
 }

You then have to extract the mobile game versions data folder to your binary path, and also convert some files manually. Audio, however, won't work.

I'm running v2.2 on 64-bit Fedora Linux.
Steps to reproduce:

1. Start game from terminal via shell script.
2. Play as normal.
3. Hit enter key to pull up map screen, arrow over to save option, and save game.
4. Hit escape key to exit, confirm decision to exit, reach title screen.
5. Choose to start game, choose to continue, arrow down to quick save, select it.

Expected results:
Continue from quick save point, e.g. ship room to the right of teleporter.

Actual results:
Continue from last teleporter save.

Additional notes:
On my initial play, the terminal output showed "Quick Save Not Found". After the first save, I tried exiting and re-launching and that line was no longer in the output.

Here's the permissions on the save folder:

$ ls -la /home/(redacted)/.local/share/VVVVVV/saves/
total 28
drwxr-xr-x. 2 (redacted) (redacted) 4096 Jan 13 18:35 .
drwxr-xr-x. 4 (redacted) (redacted) 4096 Jan 10 18:33 ..
-rw-r--r--. 1 (redacted) (redacted)  270 Jan 10 21:32 levelstats.vvv
-rw-r--r--. 1 (redacted) (redacted) 2635 Jan 10 21:21 linewrap.vvvvvv.vvv
-rw-r--r--. 1 (redacted) (redacted) 2356 Jan 13 19:12 qsave.vvv
-rw-r--r--. 1 (redacted) (redacted) 2347 Jan 13 19:28 tsave.vvv
-rw-r--r--. 1 (redacted) (redacted) 1290 Jan 13 19:28 unlock.vvv

Let me know if there are any additional logs or output needed to assist debugging.

This one's for @ePirat, @charliebruce, and also @cybik since this will pretty much directly affect our ANGLE-Builds system for FNA and friends.

Basically, 16.04 is supposed to be supported by GitHub Actions, but for some reason it doesn't work. VVVVVV needs it for compatibility testing, ANGLE needs it so our builds target a low enough glibc/libstdc++ for people to safely distribute with, so we need to find out why 16.04 is not cooperating with us.

Currently all third party libraries have their own folder in the top level of the repository alongside with src.

For better structure and clarity it might be a good idea to move them all into a subfolder called third_party or something, so it is clear this is not really part of VVVVVV and should not be touched (except when updating with upstream).

Additionally that would mean you can easily clarify that the license and copyright does not apply to all things in third_party instead of listing every single project, which would be especially useful if a project is added or removed there.

Hi! Thanks for opensourcing this. I pulled the code down on ubuntu 19.10 did the following:

git clone
cd VVVVVVV/desktop_version
mkdir build
cd build
cmake ..
-- The C compiler identification is GNU 9.2.1
-- The CXX compiler identification is GNU 9.2.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- No TARGET SDL2::SDL2, or SDL2, using variables
-- Configuring done
-- Generating done
-- Build files have been written to: /home/ross/project/VVVVVV/desktop_version/build

make
(completes successfully

cd build
./vvvvvv.x86_64
Base directory: /home/ross/.local/share/VVVVVV/
Save directory: /home/ross/.local/share/VVVVVV/saves/
Level directory: /home/ross/.local/share/VVVVVV/levels/
libsteam_api.so not found!

	       VVVVVV
	
	
	  8888888888888888  
	88888888888888888888
	888888    8888    88
	888888    8888    88
	88888888888888888888
	88888888888888888888
	888888            88
	88888888        8888
	  8888888888888888  
	      88888888      
	  8888888888888888  
	88888888888888888888
	88888888888888888888
	88888888888888888888
	8888  88888888  8888
	8888  88888888  8888
	    888888888888    
	    8888    8888    
	  888888    888888  
	  888888    888888  
	  888888    888888  

double free or corruption (out)
Aborted (core dumped)

##Compiling under PuppyLinux (binary compatible with Ubuntu 14.04)

Sorry I'm not so experienced in compiling.. anyway.
cmake version 2.8.12/libSDL2 2.0.0

First I had to add to CMakeLists.txt to find SDL.h etc:

set(SDL2_INCLUDE_DIR /usr/include/SDL2)
set(SDL2_LIBRARY /usr/lib/libSDL2.so)

then I had to add c++ flag -std=c++0x to CMakeLists.txt

 CMAKE_CXX_FLAGS:STRING=-std=c++0x

for Graphics.cpp.o to avoid this "error: ‘nullptr’ was not declared in this scope"

then
I got this issue for Screen.cpp.o :

... In member function ‘void Screen::ResizeScreen(int, int)’:
Screen.cpp:121:50: error: ‘SDL_RenderSetIntegerScale’ was not declared in this scope
Screen.cpp:126:70: error: ‘SDL_RenderSetIntegerScale’ was not declared in this scope

..and stuck.

p.s.
BTW
if I run precompiled binary I'm getting this:

./x86/vvvvvv.x86: undefined symbol: SDL_RenderSetIntegerScale

finish ;)

The PhysFS and TinyXML are both zlib and (c) other people.

I just tried to compile VVVVVV on MacOS Catalina, and it was failing as follows:
[ 41%] Building CXX object CMakeFiles/VVVVVV.dir/editor.cpp.o
In file included from /Users/ethernet/tmp/VVVVVV/desktop_version/src/editor.cpp:5:
In file included from /Users/ethernet/tmp/VVVVVV/desktop_version/src/Music.h:4:
/Users/ethernet/tmp/VVVVVV/desktop_version/src/SoundSystem.h:4:10: fatal error: 'SDL_mixer.h' file not found
#include <SDL_mixer.h>
^~~~~~~~~~~~~
1 error generated.
make[2]: *** [CMakeFiles/VVVVVV.dir/editor.cpp.o] Error 1
make[1]: *** [CMakeFiles/VVVVVV.dir/all] Error 2
make: *** [all] Error 2

I've found the fix by copying SDL_mixer.h into "src" folder under desktop version.
So maybe path checks, or auto discover should be added into Makefile to get the real path of SDL_mixer.

To compile on Mac, I had to do the following steps:

1. Download SDL_mixer.h and put it in desktop_version/src.
2. Run

$ brew install sdl2 sdl2_image sdl2_mixer
$ export LIBRARY_PATH="$LIBRARY_PATH:/usr/local/lib"

3. Change line 18 of desktop_version/src/SoundSystem.cpp to

m_music = (Mix_Music *)Mix_LoadWAV_RW(rw, 0);

Hope this is helpful.

This code SDL_SetWindowIcon(m_window, icon); in Screen::Screen() line 65 causes stack overflow in SDL library
Exception thrown at 0x00007FFCEFA0AF88 (SDL2.dll) in VVVVVV.exe: 0xC00000FD: Stack overflow (parameters: 0x0000000000000001, 0x000000D4F4613000).

Unhandled exception at 0x00007FFCEFA0AF88 (SDL2.dll) in VVVVVV.exe: 0xC00000FD: Stack overflow (parameters: 0x0000000000000001, 0x000000D4F4613000).

Commenting out the icon code makes the error go away and game launches perfectly fine. albeit, without icon on the window

Specs : Win 10 64-bit, running x64 Debug version of the game in Visual Studio with 64-bit SDL libraries provided by vcpkg

Would 60 fps be possible now?

Looks like this started happening after the text outline accessibility option was added in 6e9712f.

For some reason, I can't hold down left-click in the editor to place tiles with the tile tool, they're only placed on the first frame the button is held. Holding down right-click works, though!

You may not still have these, but it'd be interesting to look at old revisions of the source code to see how the game changed throughout its development.

Is it just out of date? Have a look, and update if needed.

VVVVVV 2.0 failed review on the Mac App Store because it stores saves and player levels in the ~/Documents folder, which is fair enough. But due to time constraints at the time, we launched on Humble/Steam with the ~/Documents folder on OSX. This now leaves VVVVVV with a complicated situation on Mac:

• Saves should be in ~/Library/Application Support
• Many people on mac will have their saves from 2.0 in ~/Documents, and the game will need to scan that folder at startup and migrate them for a potential 2.3 update, and delete the old save folder.

For some reason my gamepad does not work after 45491a0, I use the SDL-GameControllerDB and it worked fine before this commit.

before when I ran VVVVVV it said

Opened SDL_GameController ID #0, odroidgo2_joypad

Now this text does not appear at all, if I compile a version prior to this commit it works perfectly fine again.

Built with reasonable ease (thanks!!) on Ubuntu 19.10, but when I try to run I get this error:

vvvvvv.x86_64: ../src/mesa/drivers/dri/i965/brw_disk_cache.c:405: brw_disk_cache_init: Assertion `note && build_id_length(note) == 20' failed.
Aborted (core dumped)

Any ideas on what it could be? (Googling suggests it could be some kind of mesa shader cache error... maybe?!)

I have data.zip from the retail (Steam) version of the game copied next to my built executable.

(Note: I built using CMake's Ninja generator - could that be related?)

Thanks!

I compiled the desktop version for the Odroid Go Advance, it runs perfectly except for one small caveat, the Odroid go advance needs screen rotation to -90 (or 90 CCW), is there a possibility this could be added?

Thanks

Right now, VVVVVV comes with its own copies of tinyxml, physfs, and lodepng. It would be nice if there was a switch in the CMakeLists.txt to replace these with the operating system's versions if desired. This reduces binary sizes and allows VVVVVV to take advantage of library updates delivered by the operating system's own package management.

Would it be possible to support GOG Galaxy achievements in addition to Steam?

I have no idea if they offer an SDK for this like Steam or something, and apparently its impossible to get any info about this without being a GOG-approved Game developer.

Currently, as it is, "The source code to VVVVVV!" doesn't mean anything to anyone not familiar with VVVVVV. Why even have a description at all if you're going to re-print the name and nothing else?

Instead, it could do well to at least somewhat describe the game. Maybe something like "A retro game about reversing your gravity".

• https://github.com/flathub/flathub/wiki/App-Submission
• https://gitlab.com/librebob/athenaeum

I can't help but notice that the code base has a mix of tabs and 4 spaces based indentation. I realize you don't want to take formatting patches, but what is the preferred indentation style to use when submitting a patch?

I don't really want to ask y'all to put in a bunch of extra labor to figure out Linux build requirements when I'm assuming you just used what shipped with CentOS 7, but it would be nice to know what the additional build requirements are for other systems like Ubuntu especially, which is the most common base environment folks would be using who would want to build on Linux. It's possible we could figure this out just by trying to install and following the error messages.. I'm opening this issue to be able to track what those requirements are and hopefully add them to the desktop readme.

I tried writing my own replacement but idk what it's supposed to do. otoh I got backgrounds and tiles to render, if with the wrong colors...

but uh, about sprites...

It seems like if you're in stretch mode, the game will still keep tracking your mouse position as if the window was still 320x240. So if your window is (say) 640x480, then the mouse position is more accurate near 0,0 but gets slowly more out-of-sync with the in-game cursor the more to the right and bottom you move it.

I recommend trying this on a build without 146cdde so you can clearly see the mouse cursor.

First and foremost, thank you very much for releasing the VVVVVV source code!

I took the opportunity to see if I can build the program on a Raspberry Pi 3 running Raspbian, so that my nieces can play the game on their (educational!) computer. It's really just a quick try... I have OpenGL enabled with KMS. Amazingly, the source builds just fine. I got a copy of the data.zip file from Steam and placed it in the build directory and ran the game.

The initial load screen appears, but then I end up with a black screen. At the moment, I don't have speakers connected, so I'm not sure if there's sound.

The following are the console messages.

Base directory: /home/pi/.local/share/VVVVVV/
Save directory: /home/pi/.local/share/VVVVVV/saves/
Level directory: /home/pi/.local/share/VVVVVV/levels/
libsteam_api.so not found!
		
		
		       VVVVVV
		
		
		  8888888888888888  
		88888888888888888888
		888888    8888    88
		888888    8888    88
		88888888888888888888
		88888888888888888888
		888888            88
		88888888        8888
		  8888888888888888  
		      88888888      
		  8888888888888888  
		88888888888888888888
		88888888888888888888
		88888888888888888888
		8888  88888888  8888
		8888  88888888  8888
		    888888888888    
		    8888    8888    
		  888888    888888  
		  888888    888888  
		  888888    888888  
		
		
Unable to open file mmmmmm.vvv
The complete reloaded file size: 61651755
data/music/0levelcomplete.ogg unpacked
data/music/1pushingonwards.ogg unpacked
data/music/2positiveforce.ogg unpacked
data/music/3potentialforanything.ogg unpacked
data/music/4passionforexploring.ogg unpacked
data/music/5intermission.ogg unpacked
data/music/6presentingvvvvvv.ogg unpacked
data/music/7gamecomplete.ogg unpacked
data/music/8predestinedfate.ogg unpacked
data/music/9positiveforcereversed.ogg unpacked
data/music/10popularpotpourri.ogg unpacked
data/music/11pipedream.ogg unpacked
data/music/12pressurecooker.ogg unpacked
data/music/13pacedenergy.ogg unpacked
data/music/14piercingthesky.ogg unpacked
data/music/predestinedfatefinallevel.ogg unpacked
Quick Save Not Found
Teleporter Save Not Found

Some interesting notes:

• libsteam_api.so is probably impossible to get on the raspberry pi, but I assume it ignores it.
• Not sure what mmmmmm.vvv is, but I'm assuming it's music and I can see it loading them as .ogg files from the zip file... unless I'm missing something?

Any hints on where to look next to fix would be appreciated.

Arch Linux 5.4.11 x86_64. Game compiles perfectly, but when I try to run it, it segfaults after outputting the crewmate ASCII-art. If I run it as root, it freezes, outputting Unable to play WAV file: Tried to play a NULL chunk every once in a while. I have no idea how to fix this, maybe you do?

It's your game, your code, and I'm sure a lot of us are happy that the source code of this great game can be studied and tinkered with. However, following the example of John Carmack (id Tech 1 - 4 and Quake engines) and releasing the source code under the GPL license would provide several advantages to the community with no practical disadvantages to you (that I'm aware of anyway):

• Under the GPL, FOSS projects such as Debian have liberty to include the engine in its official repository.

• It effectively becomes a part of a large community of dedicated programmers, and with the legal clarity that the GPL provides, it would foster a healthier community of modders around the engine/game, and may serve as a base for new games.

• Commercial use, in principle, is not directly allowed, only support for the software may be sold, or something alongside the compiled source code (in this case, the proprietary game assets). Everyone who distributes a binary of the engine must also release the source code, even if there's a price tag.

• You can still dual license. For example, id software allows any developer with enough green to negotiate special proprietary licensing to use their engines, although they encourage you to just stick with the GPL.

For the benefit of the community, I hope you will consider this proposal 🙂

Current repo descriptoin:

The source code to VVVVVV, now open and public!

As this game is not an open source game, I recommend to remove the word “open” to avoid misleading users.

This game is not open source software as the license is too restrictive to meet the Open Source Definition (namely, commercial). The correct term is “source-available software”.

https://en.wikipedia.org/wiki/Source-available_software
https://opensource.org/osd

I am using 64-bit Windows 10 with following CMAKE options :
cmake -G "Visual Studio 15 2017" .. -DSDL2_INCLUDE_DIRS="D:\github\vcpkg\installed\x64-windows\include\SDL2;" -DSDL2_LIBRARIES="D:\github\vcpkg\installed\x64-windows\lib\SDL2.lib;D:\github\vcpkg\installed\x64-windows\lib\SDL2_mixer.lib" -DCMAKE_GENERATOR_PLATFORM=x64

In trying to compile VVVVVV project within the solution, and the error gets thrown is :
LNK2019 unresolved external symbol WinMain referenced in function "int __cdecl invoke_main(void)" (?invoke_main@@YAHXZ) VVVVVV D:\github\VVVVVV\desktop_version\build\MSVCRTD.lib(exe_winmain.obj) 1

Now, adding main as entry point in Visual Studio Linker options, adds more to the compilation problems. Apparently SDL also defines a main which causes linker to complain. Solution is doing undef main before VVVVVV's main. This results in more MSVCRTD related unresolved symbol errors.

Anyone had success in compiling on windows ?

From http://distractionware.com/blog/2020/01/vvvvvv-is-now-open-source/:

All the actual levels in the game are hardcoded in huge arrays that I generated with my own map editor, which exports the levels in source code that I could read in. This is just kind of how it worked when making a flash game in 2009 – accessing external data assets is hard to do, so it just made sense at the time to compile that into the game instead. All the really big files (like Spacestation2.cpp, Finalclass.cpp and so on) were made this way. I’ve uploaded the code for the editor here for completeness, but it’s not really useable anymore to be honest (it requires Allegro and Mingw to compile). I made a similar tool for rearranging the final level layouts!

Therefore, the content of https://pastebin.com/9wqvBGuD should be added to the repository to archive it and allow future changes. A CMake file should be created.