mpo/VVVVVV
1
0
Fork 0
mirror of https://github.com/TerryCavanagh/VVVVVV.git synced 2024-06-27 23:18:30 +02:00
Code Issues Releases Wiki Activity
b8fdbe53b9
VVVVVV/desktop_version
History
Misa b8fdbe53b9 Fix loading plain font.png Unicode indexing out of bounds 
This code was introduced by Dav999 in
abf12632bb (PR #1077), but it contains a
memory error. I spotted this with Valgrind.

The problem comes from the fact that `max_codepoint` is calculated from
the width and height of the surface (which will have the same width and
height as the source `font.png` from the filesystem). Let's work through
an example using a typical 128 by 128 `font.png` and an 8 by 8 glyph.

`chars_per_line` is calculated by dividing the width of the image
(`temp_surface->w`, or 128) by `f->glyph_w` (8), yielding 16.
`max_codepoint` is calculated by first calculating the height of the
image divided by the height of the glyph - which here just happens to be
the same as `chars_per_line` (16) since we have a square `font.png` -
and then multiplying the result by `chars_per_line`. 16 times 16 is 256.

Now it is important to recognize here that this is the _amount_ of
glyphs in `font.png`. It is _not_ the last codepoint in the image. To
see why, consider the fact that codepoint 0 is contained in the image.
If we have codepoint 0, then we can't have codepoint 256, because that
would imply that we have 257 codepoints, but clearly, we don't. If we
try to read codepoint 256, then after working through the calculations
to read the glyphs, we would be trying to read from pixel columns 0
through 7 and pixel rows 128 through 135... in a 128 by 128 image...
which is clearly incorrect.

Therefore, it's incorrect to write the upper bound of the for-loop
iterating over every codepoint as `codepoint <= max_codepoint` instead
of `codepoint < max_codepoint`.
2023-12-29 11:55:09 -08:00
..
fonts Fixed duplicated/shifted characters 2023-11-29 10:24:07 -08:00
lang Fix minor [Press ACTION to save your game] overflow in German 2023-12-23 10:50:12 -08:00
src Fix loading plain font.png Unicode indexing out of bounds 2023-12-29 11:55:09 -08:00
VVVVVV-android Android: Update README.md for Maven package 2023-11-14 17:29:34 -08:00
.dockerignore Run CI on CentOS 7 (#574) 2021-01-11 00:30:15 -05:00
.gitignore Optimize recompilation from changing commit hash 2022-08-23 00:00:38 -07:00
CMakeLists.txt Add level debugger screen 2023-11-19 17:34:23 -08:00
CONTRIBUTORS.txt Update my GitHub username and Ved repo link 2023-10-28 19:04:44 -07:00
Dockerfile Update to SDL 2.24.0 2022-08-21 16:07:51 -07:00
fixupMac.sh Remove SDL2_mixer line from fixupMac.sh 2022-03-29 02:27:15 -04:00
icon.ico Updated .ico 2021-09-03 15:57:16 -04:00
icon.rc Embedded .ico 2021-08-28 11:21:49 -04:00
README.md README: Delete section on compiler quirks 2023-11-27 13:43:23 -08:00
version.cmake Fix %cs showing instead of commit date on Windows (or older git?) 2023-11-13 14:42:48 -08:00

README.md

How to Build

VVVVVV's official desktop versions are built with the following environments:

  • Windows: Visual Studio 2010
  • macOS: Xcode CLT, currently targeting 10.9 SDK
  • GNU/Linux: CentOS 7

The engine depends solely on SDL2 2.24.0+. All other dependencies are statically linked into the engine. The development libraries for Windows can be downloaded from SDL's website, Linux developers can find the dev libraries from their respective repositories, and macOS developers should compile and install from source. (If you're on Ubuntu and your Ubuntu is too old to have this SDL version, then see here for workarounds.)

Since VVVVVV 2.4, git submodules are used for the third party libraries. After cloning, run git submodule update --init to set all of these up. You can also use this command whenever the submodules need to be updated.

Steamworks support is included and the DLL is loaded dynamically, you do not need the SDK headers and there is no special Steam or non-Steam version. The current implementation has been tested with Steamworks SDK v1.46.

To build the Make and Play edition of the game, uncomment #define MAKEANDPLAY in MakeAndPlay.h.

To generate the projects on Windows:

# Put your SDL2 folders somewhere nice!
mkdir flibitBuild
cd flibitBuild
cmake -A Win32 -G "Visual Studio 10 2010" .. -DSDL2_INCLUDE_DIRS="C:\SDL2-2.24.0\include" -DSDL2_LIBRARIES="C:\SDL2-2.24.0\lib\x86\SDL2;C:\SDL2-2.24.0\lib\x86\SDL2main"

Note that on some systems, the SDL2_LIBRARIES list on Windows may need SDL2/SDL2main to have .lib at the end of them. The reason for this inconsistency is unknown.

Also note that if you're using a Visual Studio later than 2010, you will need to change the -G string accordingly; otherwise you will get a weird cryptic error. Refer to the list below:

  • VS 2012: "Visual Studio 11 2012"
  • VS 2013: "Visual Studio 12 2013"
  • VS 2015: "Visual Studio 14 2015"
  • VS 2017: "Visual Studio 15 2017"
  • VS 2019: "Visual Studio 16 2019"
  • VS 2022: "Visual Studio 17 2022"

To generate everywhere else:

mkdir flibitBuild
cd flibitBuild
cmake ..

macOS may be fussy about the SDK version. How to fix this is up to the whims of however Apple wants to make CMAKE_OSX_SYSROOT annoying to configure and retain each time Xcode updates.

Including data.zip

You'll need the data.zip file from VVVVVV to actually run the game! You can grab it from your copy of the game, or you can download it for free from the Make and Play page. Put this file next to your executable and the game should run.

This is intended for personal use only - our license doesn't allow you to actually distribute this data.zip file with your own forks without getting permission from us first. See LICENSE.md for more details. (If you've got a project in mind that requires distributing this file, get in touch!)