This is the source code to VVVVVV

Related tags

Miscellaneous VVVVVV
Overview

This is the source code to VVVVVV, version 2.0+. For more context about this release, see the announcement on Terry's blog!

License

VVVVVV's source code is made available under a custom license. See LICENSE.md for more details.

In general, if you're interested in creating something that falls outside the license terms, get in touch with Terry and we'll talk about it!

Authors

Versions

There are two versions of the VVVVVV source code available - the desktop version (based on the C++ port, and currently live on Steam), and the mobile version (based on a fork of the original flash source code, and currently live on iOS and Android).

Comments
  • Port to FAudio

    Port to FAudio

    Changes:

    I was browsing the repo and saw #829, with the note that porting to FAudio should be "really easy" for someone else to do. Answer is no it wasn't (tbf I never touched any audio stuff ever), but I tried nonetheless.

    This should be functional, but buggy. I'm opening the PR to see if I should continue or just stop. ~~Thanks for looking at my awful code~~

    CI is failing because I used a submodule for FAudio. I can either make CI clone recursive or just copy folder contents, will wait for feedback on that. Had to increase C Standard Version due to stb_vorbis (90 -> 99). If someone has suggestions on how to avoid that please share.

    Most Bugs revolve around tabbing in and out of the game. Sometimes there is no Resume() generated for some reason I think. For example, tabbing out during the intro sequence causes the game to stay mute until you do it again during gameplay. I think it might be because of FAudio_StopEngine() in Pause(), but as that was written in the comment I let it be.

    Legal Stuff:

    By submitting this pull request, I confirm that...

    • [x] My changes may be used in a future commercial release of VVVVVV
    • [x] I will be credited in a CONTRIBUTORS file and the "GitHub Friends" section of the credits for all of said releases, but will NOT be compensated for these changes
    required for 2.4 
    opened by N00byKing 93
  • 2.3 TODO

    2.3 TODO

    This is a quick tracker for things we're going to check out before 2.3 is tagged. We're on ~month 6 of the VVVVVV source release and we've gotten a ton of contributions (and horrifying bug discoveries), so I think this is a good time to start thinking about pushing an official update.

    Current Schedule: July 1 will be a feature freeze, and ~July 14 31~ ~October 1 31~ January 10 will be the release. No features will be merged after July 1, only bug fixes will be accepted until 2.3 is out.

    I'll add a milestone tag for issues already filed, but the broader things we need to do featurewise:

    • [x] Merge the 60fps patchset
    • [x] Close or Acknowledge bugs tagged as 2.3 items
    • [x] Update the CONTRIBUTORS file, GitHub Friends list
    • [x] GitHub Superfriends list

    Not much, but the 60fps patchset in particular needs as much playtesting as possible this month. Other than that, @InfoTeddy's got some things from CE to upstream, I'll let them maintain a list here as well.

    required for 2.3 
    opened by flibitijibibo 43
  • Make the game (visually) run at framerates above ~30 FPS

    Make the game (visually) run at framerates above ~30 FPS

    Changes:

    VVVVVV is a game that runs at 1000/34 frames per second, which is approximately 29.4 frames a second, which is close to, but not quite, 30 frames a second. This odd number comes from the fact that the amount of times it takes for each frame is coded to be 34 milliseconds, and not 33.333333333... milliseconds.

    This pull request unlocks VVVVVV's framecap of 1000/34 FPS. It does this in such a way that the underlying engine still runs at an actual framerate of 1000/34 FPS (which we should be calling tickrate now), and in between each actual frame we just draw what the frames in between each frame should be, using something called "linear interpolation". So now the game will visually run at the same rate as your monitor (my monitor is 60hz, I'm not a true gamer :( ​ ​ ​ ​ ).

    What's linear interpolation, you might ask? Well it's basically like drawing a straight line between two points on a graph. But it's more akin to averaging something. All the rendering does is go like, "Ok so on this frame, we have 2, and on the next frame, we have 4. What's the average of 2 and 4? Why, it's 3! So we should draw a frame using 3."

    This approach means that the underlying physics isn't changed, which is a very good thing because if I changed the physics around to update at, say, twice the speed but with half the values, that would run the risk of breaking custom levels. Also, it's easier to do it this way because it requires changing less values, although it does require disentangling all pieces of update code from render code so as to make sure things don't update as quickly as possible. And regardless of those concerns, this approach is the cleanest imo, since the physics don't subtly change depending on your refresh rate (unlike games like Super Meat Boy, which apparently desyncs TASes depending on if your refresh rate is 59hz or 60hz, oh and also different resolutions have different refresh rates, good luck).

    Oh, and by the way, the Switch version (made by some weird company named Nicalis) actually does the screw-up-the-physics approach instead of what I'm doing. They've apparently had to change some custom levels because the way they did it broke things like edge-flipping. Maddening.

    Most of the work I took was from Colon-D's fork of VVVVVV attempting to run it at over 30 FPS. However, his mod is incomplete (for example, the title screen still runs at 1000/34 FPS) and also does some things inefficiently (like re-drawing warp backgrounds every single frame, instead of scrolling a surface + incoming textures after drawing an initial background). Also it hasn't been updated in months.

    This patch also seems to improve the 100 milliseconds of SDL_Delay the unfocus-pause gives, in that it actually seems to have an effect now and be noticeable when you re-focus (possibly because before we were using SDL_Delay as the frame limiter, too, and I guess one of them kind of canceled the other out?).

    To enable this, you need to go into "graphic options" and turn on the "toggle fps" option. You can turn on "toggle vsync" as well if you feel like it, too.

    Honestly, after playing the game at 60 FPS, it feels really strange to play the game at normal 30 FPS.

    #99 is already closed, but seems relevant to mention in this PR.

    (Current base commit ID for this PR: 62441edbc9b279d4e37ea6a640f376288ffc8417)

    Legal Stuff:

    By submitting this pull request, I confirm that...

    • [X] My changes may be used in a future commercial release of VVVVVV (for example, a 2.3 update on Steam for Windows/macOS/Linux)
    • [X] I will be credited in a CONTRIBUTORS file and the "GitHub Friends" section of the credits for all of said releases, but will NOT be compensated for these changes
    required for 2.3 
    opened by InfoTeddy 33
  • Unicode rendering

    Unicode rendering

    Legal Stuff:

    By submitting this pull request, I confirm that...

    • [x] My changes may be used in a future commercial release of VVVVVV (for example, a 2.3 update on Steam for Windows/macOS/Linux)
    • [x] I will be credited in a CONTRIBUTORS file for all of said releases, but will NOT be compensated for these changes

    Changes:

    If font.png is more than 128px tall, it is assumed to be the .png version of the Space Station font. Compatibility with the original font is preserved.

    All characters outside ASCII have a width of 8.

    The Space Station font (font.png) was created by Matt 'Stelpjo' Aaldenberg.

    utfcpp is by @nemtrif. It does not require attribution in binary releases.

    opened by leo60228 31
  • [Question] Linux build requirements

    [Question] Linux build requirements

    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.

    opened by benwiley4000 26
  • SDL in Ubuntu stable releases is too old

    SDL in Ubuntu stable releases is too old

    These commits added the use of SDL_zeroa(): 70b9ffe6a58b71122aa60280bae4194326d026a0 a113662050d29a01819a2f606c9bb1d55d941abb bd97378862c6b01d1de59f59a98a8a53a74fb696

    The problem is that SDL_zeroa() was added in SDL 2.0.12, and the earliest version of Ubuntu that can easily install SDL 2.0.12 via apt is the very latest, Ubuntu 20.10 (see 20.04 and 20.10), and 20.10 is not an LTS version.

    So now anyone on most versions of Ubuntu or related distros (or anywhere else an earlier SDL is used than March 2020) will get a compilation error and will have to be told their SDL is too old. This makes "just" compiling VVVVVV more difficult on those systems.

    wontfix not our bug 
    opened by Dav999-v 25
  • [Docs] License is not open source

    [Docs] License is not open source

    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!

    opened by purpleidea 25
  • [Third Party] Traditional (and Sandboxed ?) Packaging Checklist

    [Third Party] Traditional (and Sandboxed ?) Packaging Checklist

    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

    • [x] Technical: Adding a .desktop file: would allow it to show in start menus
    • [x] Technical: Adding a .appdata.xml: would allow it to show in application stores
    • [x] 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

    • [x] 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: ?

    • [x] 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.

    opened by LyesSaadi 24
  • Don't lie to the player if a file failed to save

    Don't lie to the player if a file failed to save

    2.3 has already fixed the fact that the game doesn't produce an error message if a custom level fails to be saved (#266), but it turns out the game will basically never produce an error message if touching a teleporter fails to save your game, or if quicksaving (in custom level or not) fails to save your game, and so on. This is most noticeable if you playtest a level in Ved and quicksave, where the game will attempt to write the file saves/special/stdin.vvvvvv.vvv, and fails because the special/ folder doesn't exist. The fact that you're able to quicksave (among other things) during command-line playtesting is a separate bug, but the game will still say "Game saved ok!" even though it didn't.

    Furthermore, 2.2's unlock.vvv saving is iffy at best, leading to things like Super Gravitron high scores being lost because the player didn't specifically close the game by using the "quit game" option in the main menu.

    While 2.3's saving is more robust, it would be best if there was a notification saying unlock.vvv got saved properly whenever it gets written to, and if the game attempted to save the file but somehow failed, then it should say that, too.

    Maybe the notification should say "Your score has been saved" for Time Trials and the Super Gravitron, "Your unlock has been saved" whenever something new got unlocked, and "Your settings have been saved" whenever your settings have been saved, but the point is, the player should actually be confident that their progress got saved, the game shouldn't succeed or fail silently, and if it fails the game shouldn't be lying to the player.

    required for 2.3 
    opened by InfoTeddy 18
  • Compiling on Haiku

    Compiling on Haiku

    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

    opened by win8linux 17
  • SDL_mixer.h header missing or not routed on MacOS Catalina

    SDL_mixer.h header missing or not routed on MacOS Catalina

    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.

    opened by gcanosa 17
  • Songs with mismatched sample rates play corrupted

    Songs with mismatched sample rates play corrupted

    There appears to be some issues with certain custom audio playback in latest builds. I have a custom vvvvvvmusic.vvv file for my level, with two tracks. The first track is two seconds long, and the second one is 2:43.

    If I start my level and play the first track followed by the second, the latter will play choppily and at a very low pitch/speed. If instead I play the second followed by the first, the first one will play choppily and at a high pitch/speed. This clip shows both happening (forgive the silly level content):

    https://user-images.githubusercontent.com/44736084/179419073-74d670f0-52a2-4b38-afe1-28a7635fa43b.mp4

    @Dav999-v, using the same vvvvvvmusic.vvv file that I sent him, also demonstrates the second instance happening, though a bit differently with very loud intermittent noises, possibly due to using the Linux build:

    (VOLUME WARNING)

    https://user-images.githubusercontent.com/44736084/179419133-71df0cd6-6c77-4b02-a1bc-56645623ddcf.mp4

    This may be related to FAudio changes, as suggested by Dav.

    Both audio tracks are Vorbis format, 44100 Hz. The first track has turned out to be mono, while the second is stereo - could this have any relation?

    bug required for 2.4 
    opened by Fussmatte 5
  • Steam Deck UX observations

    Steam Deck UX observations

    I just played through the game on the Steam Deck and it was a great experience! However there are a few little UX issues that I wanted to bring up (beyond the lack of Steam Deck controller glyphs due in 2.4).

    While I'm approaching this mostly from the mindset of a user coming to the Steam Deck and looking for a console-like experience, I feel that some of the suggestions I'm making here would apply more broadly and could improve the overall UX for new users (on any PC platform) looking for a more console-like experience out of the box.

    When installing the game for the first time via the Steam UI it installs:

    Version 2.3.6 (Native Linux build)
    

    The default controller layout used is:

    Official Layout for VVVVVV by Terry Cavanagh
    

    I'm not sure if this was intentional and applied by you, the developers, or whether this was set by Valve and their testing team. This layout (created initially for Steam Controller???) uses Steam Input to map keyboard keys to the buttons and overrides the in-game SDL GameController mapping.

    This detail was confusing for me as a user as it was not apparent that the game was not using the in-game controller mappings at first. This lead to some head-scratching moments for me as my attempts to remap controls in the in-game menu did nothing and certain actions (like Right Bumper to restart) were inaccessible given that Steam input was overriding the actual button press in-game.

    Also confusing is that the Steam Input layout binds B to Space/flip. This was not bad in-game, but made for some confusion in navigating the menus as the B button would Accept rather than Go back as is standard.

    I can imagine that there are quite a few Deck users who will be confused when first booting the game due to conflict due to it using this layout.


    There are a few bindings that the Steam input mapping provides that I really liked that I feel would be nice to have in the in-game configuration by default. The Steam input mapping had the left "Back" button (above left thumbstick) bound to Menu and the right "Start" button (above right thumbstick) bound to Enter. By default in the in-game controller configuration, the Back and Start buttons do nothing which feels a bit odd to me as a user who has become accustomed to games using those buttons.

    • Perhaps those buttons (SDL_GameController_Back and SDL_GameController_Start) could be bound to the Menu and Enter actions respectively?

    Other UX concerns (when not using the Steam input layout):

    The option to separate Interact from Enter was not intuitive to me as a user. It was unintuitive to go to the speedrunning options menu in order to activate. I also found it a bit confusing to see the "bind interact" option in the gamepad bindings menu when the option to separate Interact from Enter is false. It led to a bit of confusion when the mapping that I had for interact had no affect in-game and I was still prompted to hit Enter.

    • Perhaps the Interact binding option could be hidden if the option to Separate Interact is set to false?

    When loading up the game for the very first time (prior to a settings.vvv file being created), there are no controller mappings applied at all in the in-game mapping. Once the settings.vvv file is created and the user restarts the game, the default in-game controller bindings will be active. But that initial load for a Steam Deck user without access to keyboard (and not using the Steam input layout) will be very jarring.

    There is no way to reset your controller binding in-game back to the default. Binding the same key to a new action will unbind the prior action, but there is no way to wholesale reset back to their defaults.

    The act of binding buttons in the menu is potentially problematic on the Steam Deck. The current method has the user hit the button they wish to bind when a particular binding menu option is highlighted. However this can conflict with navigation keybindings. For instance, attempting to rebind B to Enter will not work, as the menu back navigation will occur prior to the binding taking place.

    Also given that the button bound to the flip action also performs the menu accept action, there are scenarios in which the user can get themselves into a bad state. If the user binds A to the Esc/Menu action then attempts to toggle an option or enter a submenu with A, it will no longer work as expected. The escape/back menu navigation will precede the affirmative flip/accept action and the user will navigate back to the prior menu.

    This is recoverable when the user has access to a keyboard as a fallback and can easily access the filesystem to delete the offending controller configuration. But on a platform like the Steam Deck this could potentially lead to scenarios that are not easily recoverable.

    • Should the in-game controller actions of flip/menu be separate from menu navigation actions?
    • Should the user first have to hit Menu Accept on a binding option and then press the desired button to bind (in order to allow B to be rebound in-game for instance)?

    On initial load of the game the game screen was very small. Perhaps it was windowed and at a low-resolution/scaling initially? That was easily resolvable when adjusting the graphics options. Is it possible to detect via the Steam API that the current platform is Steam Deck and adjust initial graphics options accordingly?

    opened by jstuder-gh 9
  • Forwards compatibility and scripting discussion

    Forwards compatibility and scripting discussion

    Since #867 was closed, and the conversation was quite valuable, I thought I'd open a new issue with the goal of continuing this discussion further. What was already discussed was the possibility of breaking forwards compatibility to add new features making custom level creation easier, and the idea of a Lua API for more control over the game, to do what scripting currently cannot.

    Additionally, I've created a thread in the (unofficial) VVVVVV Discord server for discussion on what a hypothetical Lua API would look like; however this is just implementation details to make sure that if we end up adding a Lua API, it'll be a good one.

    And continuing from the previous issue, I would rather VVVVVV not become a mess of everything we'd like to implement, and forwards compatibility features be added in moderation, with hopefully more than one reviewer on the PR when it's time to merge. I do not want VVVVVV to go the same way as Community Edition, and I doubt a lot of other people would, either.

    As a personal note, VVVVVV is an important game to me. I've always loved creating cool systems in things that were never intended to be used as such. I absolutely love abusing internal scripting and pushing the engine to its limits for maybe only a few seconds of gameplay. I find this kind of thing fun; it's problem solving taken to the extreme, with the huge payoff of being able to step back and see that you, in fact, made this huge elaborate system in a level editor for a game from 2010. With the addition of a Lua API, some of that charm would go away, and I believe this is the case for a lot of other people. However, I would rather this not stop progress, because what a small group of people enjoy in a game shouldn't stop the rest of the level creators from getting a much better system to create what they want. I'd rather lose that specific enjoyment than stopping everyone else from being able to make what they want.

    With all of that said, I hope this sparks a discussion.

    enhancement 
    opened by AllyTally 6
  • Steam Deck review

    Steam Deck review

    VVVVVV received its Steam Deck review! Here it is:

    image

    We got a "Playable" score, which is fine - most games on steam will get this, I think. We passed all the checks apart from "Controller Glyphs":

    Test failed due to to mouse / keyboard input glyphs being shown. We highly encourage only showing input glyphs for the active devices and not showing mouse / keyboard prompt unless a gamepad is not plugged in, or a mouse / keyboard action was activated by the user. If your game has controller support this may be due to assets with hard-coded glyphs or the Steam Deck's trackpad/gyro input being sent to the game mouse movement. For games under active development we highly encourage supporting mouse-style aim from controllers and to only change to mouse/kb glyphs on mouse click or keyboard press events. For older titles you can also fix this issue by going to the Steam Input settings section of the partner site and setting your default configuration to either the "Gamepad w/ Camera Controls" template for 1st/3rd person games or "Gamepad" template for platformer and sports games. The title was found to only feature mouse / keyboard glyphs across all areas of the title.

    If there's any interest in going for a "verified" score, that'd be nice to have - but not essential. The game runs fine on the Steam Deck, after all.

    Time-wise; this review is "pending" for one week, and then after that will be displayed publicly on the store page. We have the option to rush out a fix and apply for new test before that happens if we like.

    More realistically, it'll still be a while before Steam Decks start getting shipped out, so we could maybe just tack this issue on to the 2.4 to do list?

    required for 2.4 
    opened by TerryCavanagh 14
  • Terry's Localisation To-Do List

    Terry's Localisation To-Do List

    Just a personal checklist of things for me to do on the Localisation project:

    • [ ] Fill in the room name context in the localisation branch (in https://github.com/Dav999-v/VVVVVV/blob/localization/desktop_version/lang/en/roomnames.xml and https://github.com/Dav999-v/VVVVVV/blob/localization/desktop_version/lang/en/roomnames_special.xml)
    • [ ] Check with Bennett about any I'm not 100% sure about
    • [ ] Prepare an example spreadsheet and build in a translator pack for our translators
    • [ ] Figure out an approximate wordcount
    • [ ] Contact Felipe and see if he's available for the Spanish translation
    • [ ] Implement the translation, playtest for issues
    • [ ] Iterate on the translation as needed, find and address problems
    • [ ] Once things are looking good, reach out to the rest of the Dicey Dungeons translators
    localization 
    opened by TerryCavanagh 5
  • Individual translation of graphics files

    Individual translation of graphics files

    This is maybe a bit far off, but I think it'd be worth considering the possibility that individual languages can choose to provide custom graphics. Something similar was done with the Nicalis Japanese ports to translate each enemy into Japanese (with debatable quality).

    Here are some homemade mock-up examples showing translated enemies in action in various languages (graphics mine): image

    One issue that's been brought up with this is hitboxes: they're pixel-perfect in the game and changing an enemy graphic even a little could muss it up. Misa's suggested solution was to load hitboxes with the original graphics but render enemies with another.

    Another is whether this is necessary or worth it at all — I personally think having the option is nicer than not (for example, I think it may help contextualise room names better), but others might (and do) feel differently, that it's rather superfluous and isn't a big deal for most players (which it probably isn't).

    What are your thoughts?

    required for 2.5 localization 
    opened by Fussmatte 3
Releases(2.3.6)
  • 2.3.6(Dec 22, 2021)

    Looks like a patch that was backported wasn't the whole patch... so one last thing before the holiday panic starts!

    • Fix a regression from the hardreset fix in 2.3.5
    • Add some error checking to the image loader
    Source code(tar.gz)
    Source code(zip)
  • 2.3.5(Dec 21, 2021)

    A batch of fixes while 2.4 work continues:

    • Fix achievements regarding total deaths in one playthrough
    • Fix winning in No Death Mode saying "One trinkets"
    • Fix a glitch where someone's name was rendered incorrectly in the credits
    • Removed a trailing space at the end of the "Press to Teleport" dialog
    • The Elephant is now stitched correctly
    • Fix a regression for destroy(platforms)
    • hardreset now resets ingame_titlemode
    • Fix in-game timer going away after playing Super Gravitron
    • Added centiseconds to timer overlays
    • Added outline support to text that previously didn't have it
    • Fix warp sprites of big sprites sometimes not being drawn
    Source code(tar.gz)
    Source code(zip)
  • 2.3.4(Sep 11, 2021)

    Another week, another batch of fixes. I'm expecting this to be the last one for a while!

    • Prevent users from opening the map on the first frame of a gamemode animation
    • Prevent corruption of game state after dying during a collection prompt
    • Fix unused map memory getting initialized to a weird value
    • deletestats now actually deletes all stats
    • A whole bunch of fixes for music playback
    Source code(tar.gz)
    Source code(zip)
  • 2.3.3(Sep 4, 2021)

    Some regression fixes for the weekend:

    • Updated the .ico, RIP the secret Flash logo
    • Fix a case where music fading out didn't happen when it was supposed to
    • Fix the menu key being permanently blocked after certain menu animations
    Source code(tar.gz)
    Source code(zip)
  • 2.3.2(Sep 3, 2021)

    Another minor update to address some more regressions, and also address a UI issue:

    • Add message when player is kicked out of Super Gravitron (invincibility/slowdown is enabled)
    • Prevent user-initiated map menu changes during menu animations, which could cause a softlock
    • Fix the teleporter mode render path during teleporter mode, preventing a possible softlock
    • Fix the transition to teleporter mode when already in teleporter mode
    Source code(tar.gz)
    Source code(zip)
  • 2.3.1(Sep 1, 2021)

    This is a minor update to address some issues found after launch:

    • VSync is now enabled by default when starting 2.3 for the first time
    • Fix not-Flip-Mode flag turning off when returning from options menu
    • Minor fixes for the official build systems
    Source code(tar.gz)
    Source code(zip)
  • 2.3(Aug 31, 2021)

  • 2.2(Jul 11, 2020)

Owner
Terry Cavanagh
Terry Cavanagh
Project is to port original Zmodem for Unix to CP/M and provide binaries and source code for platform specific modification as needed. Based on 1986 C source code by Chuck Forsberg

Zmodem4CPM This repository is intended to foster a RetroBrewComputers community effort to port the original Zmodem source code for Unix to CP/M so eve

null 11 Aug 31, 2022
Reverse engineered source code of the engineowning cheat for cod9 (tags, ignore. Fortnite cheat, engineowning, engineowning cracked, cheat cracked, cod cracked cheat, cod cheat source)

engineowning-cod9 Reverse engineered source code of the engineowning cheat for cod9 Cracked by CODEX notinjector = C:\Windows\Release\ .exe drSYS = C:

null 7 Aug 27, 2022
Source code for the article "Code vs Data Driven Displacement"

Code vs Data Driven Displacement This repo contains the source code for all the demos from this article. It uses raylib or more specifically raygui so

Daniel Holden 367 Sep 19, 2022
Phan Sang 9 Aug 29, 2022
Open Source Cheat for Apex Legends, designed for ease of use. Made to understand reversing of Apex Legends and respawn's modified source engine as well as their Easy Anti Cheat Implementation.

Apex-Legends-SDK Open Source Cheat for Apex Legends, designed for ease of use. Made to understand reversing of Apex Legends and respawn's modified sou

null 101 Sep 5, 2022
Sourcetrail - free and open-source interactive source explorer

Sourcetrail Important Note: This project was archived by the original autors and maintainers of Sourcetrail by the end of 2021. If you want to know mo

Coati Software 12.9k Sep 24, 2022
Single source file ASTC texture decompression in C++ (derived from Google's open source Android project)

astc_dec astc_dec is a single source file ASTC texture decompressor with the Apache 2.0 license, derived from Google's open source Android sources. Th

Rich Geldreich 29 Jul 19, 2022
This is the source code of SATCH a SAT solver written from scratch in C.

The main purpose of this solver is to provide a simple and clean code base for explaining and experimenting with SAT solvers. It is simpler than the source code of CaDiCaL and of Kissat in particular, while still featuring most important implementation techniques needed to obtain a state-of-the-art SAT solver

Armin Biere 66 Aug 14, 2022
Official Vanguard Anti-Cheat source code.

Vanguard Official Vanguard Anti-Cheat source code. Using the compiled binary For ease, an unprotected compiled version of Vanguard is available. Downl

Riot Vanguard 428 Sep 21, 2022
Companion source code for "Programming with C++20 - Concepts, Coroutines, Ranges, and more"

Companion Source Code for "Programming with C++20 - Concepts, Coroutines, Ranges, and more" 1. Edition Code examples This repository contains runnable

Andreas Fertig 141 Sep 15, 2022
Rasdisys Open Source code for a LTE eNB on Qualcomm FSM9955

Downloaded on June 1st, 2021 from https://www.radisys.com/OpenRadisys-4G-RAN-Software which clearly stated that this code was licensed under GNU AGPLv

Harald Welte 15 May 9, 2022
Flutter-v2 Firebase Messaging, Foreground and Background Notifications + Topic Subscription and Broadcast Notifications Source code

Flutter Notification & FCM The repo is about flutter notification and FCM (Firebase Cloud Messaging). It is updated with Flutter v2 and new updates of

Amanullah 31 Sep 3, 2022
Some source code to demonstrate avoiding certain direct syscall detections by locating and JMPing to a legitimate syscall instruction within NTDLL.

hiding-your-syscalls What is this? This repository contains all of the source code from my blog post about avoiding direct syscall detections, which y

null 197 Sep 15, 2022
Open source release of challenges and other code used in the Hack-A-Sat 2 Qualifier in 2021.

Hack-a-Sat 2 Qualifier This repository contains the open source release for the Hack-a-Sat 2 qualifier from 2021. Released artifacts include: Source c

Cromulence 59 Sep 18, 2022
Despertar del Cementerio and M33 CFW source code

DC-M33 Despertar del Cementerio and M33 CFW source code This project is a continuation of the M33 Team's work with using modern technics and exploits.

Balázs Triszka 78 Sep 15, 2022
Source Code for 'Clean C++20' by Stephan Roth

Apress Source Code This repository accompanies Clean C++20 by Stephan Roth (Apress, 2021). Download the files as a zip using the green button, or clon

Apress 19 May 24, 2022
Fully reverse engineered source code of a pasted valorant spoofer called archine.

Archine Valorant Spoofer Fully reverse engineered source code of a pasted valorant spoofer called archine. Please do not buy archine spoofer, the owne

null 13 Feb 18, 2022
A Bouncing Seal Discord Bot's Source Code.

A Bouncing Seal It's a fun bot with leveling and funny bouncing seal videos. Information Invite Support Server How to run locally You need DPP, follow

SirObsidian 4 Sep 10, 2021
Historic source code for version 0.01 of the Linux kernel

Linux v0.01 Source Code (A historic repository of the first official release of the Linux Kernel) About This Repo This repo is a means of keeping and

Robert Menes 3 Jun 27, 2022