[a Work In Progress fork, expect history overwriting]
Find a file
Igor Molchanov e754dd54ba Some compatibility fixes for Elbrus compiler (and others based on EDG front end) (#157)
* Reduce alignment to 16 due to stack variables alignment
On some archs (e.g. elbrus) there is no possibility to align
variables on stack by more that 16 bytes.

* Added check for -Wno-typedef-redefinition
In C11, there is legal to redefine typedef with the same type,
but some compilers like elbrus's lcc and, probably, intel's icc
generate a warning about that. So we disable it.

* Typo fix

* Fix __builtin_unreachable() warning on some frontends like EDG

* Added check for __attribute__((designated_init))
It doesn't work for elbrus'c lcc and clang; but clang does not
generate warning by default, but we still disable it just in case.

* A hack to avoid -Wtype-limits for compilers with unsigned enums

* Rewritten unreachable __builtin_unreachable() behavior.
According to https://bugs.llvm.org/show_bug.cgi?id=13910,
old clang versions also suffer from this issue along with lcc.
And also this warning option is removed from gcc since 4.5.0,
and it's likely there is no unreachable code analysis at all:
https://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Warning-Options.html

* Fixed unneeded stray UNREACHABLE which caused warnings

* Removed alignas() which is unneeded after lowering alignment requirements

* Removed a hack of -Wunreachable-code disabling on certain compilers
Actually, there was a wrong opinion that most of unreachable code
warnings are produced by __builtin_unreachable() itself,
not the certain use of it. After commit 36493d3, it is finally
figured out that it wasn't the case.

* Added dummy element to a struct in a test for designated_init
This test will enexpectedly fail when GNU extensions are not available
2019-02-07 10:11:13 +02:00
atlas Revamp (and fix) data packaging and installation 2019-01-26 15:57:38 +02:00
doc Some refactoring 2019-01-24 22:24:43 +02:00
external fixup cglm subproject 2019-01-23 16:32:00 +02:00
misc Some refactoring 2019-01-24 22:24:43 +02:00
resources fix build 2019-01-26 16:18:19 +02:00
scripts improve version pattern matching 2019-01-30 04:57:54 +02:00
src Some compatibility fixes for Elbrus compiler (and others based on EDG front end) (#157) 2019-02-07 10:11:13 +02:00
subprojects Some refactoring 2019-01-24 22:24:43 +02:00
xdg Lots of disorganized (mostly) visual overhaul (#156) 2019-01-05 00:59:39 +02:00
.gitignore Rendering system rewrite, tons of refactoring, optimizations, and other cool stuff (#116) 2018-04-12 17:08:48 +03:00
COPYING Lots of disorganized (mostly) visual overhaul (#156) 2019-01-05 00:59:39 +02:00
meson.build Some compatibility fixes for Elbrus compiler (and others based on EDG front end) (#157) 2019-02-07 10:11:13 +02:00
meson_options.txt add 'developer' option to decouple cheats etc. from build type 2019-01-25 02:02:56 +02:00
README.rst packaging woes (fuck debian) 2018-10-19 02:51:59 +03:00

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Taisei
======

.. contents::

Introduction
------------

Taisei is an open clone of the Tōhō Project series. Tōhō is a one-man
project of shoot-em-up games set in an isolated world full of Japanese
folklore.

Installation
------------

Dependencies
^^^^^^^^^^^^

-  SDL2 >= 2.0.5, SDL2_mixer
-  zlib
-  libzip >= 1.0
-  libpng >= 1.5.0
-  libwebpdecoder >= 0.5 or libwebp >= 0.5
-  freetype2
-  OpenGL >= 3.3 or OpenGL ES >= 3.0
-  libshaderc (optional, for OpenGL ES backends)
-  crossc >= 1.5.0 (optional, for OpenGL ES backends)

Build-only dependencies
^^^^^^^^^^^^^^^^^^^^^^^

-  meson >= 0.45.0 (build system)
-  Python >= 3.4
-  pkg-config
-  docutils (optional, for documentation)

To build and install Taisei just follow these steps.

::

    mkdir build
    cd build
    meson --prefix=$yourprefix ..
    ninja
    ninja install

This will install game data to ``$prefix/share/taisei/`` and build this
path *statically* into the executable. This might be a package
maintainers choice. Alternatively you may want to add
``-Dinstall_relative=true`` to get a relative structure like

::

    $prefix/taisei
    $prefix/data/

``install_relative`` is always set when building for Windows.

The OpenGL ES 3.0 backend is not built by default. To enable it, do:

::

    meson configure -Dr_gles30=true -Dshader_transpiler=true

See `here <doc/ENVIRON.rst>`__ for information on how to activate it.
Alternatively, do this to make GLES 3.0 the default backend:

::

    meson configure -Dr_default=gles30

Note that while it's also possible to enable a GLES 2.0 backend, it's currently
not functional.

Where are my replays, screenshots and settings?
-----------------------------------------------

Taisei stores all data in a platform-specific directory:

-  On **Windows**, this will probably be ``%APPDATA%\taisei``
-  On **macOS**, it's ``$HOME/Library/Application Support/taisei``
-  On **Linux**, **\*BSD**, and most other **Unix**-like systems, it's
   ``$XDG_DATA_HOME/taisei`` or ``$HOME/.local/share/taisei``

This is referred to as the **Storage Directory**. You can set the
environment variable ``TAISEI_STORAGE_PATH`` to override this behaviour.

Game controller support
-----------------------

Taisei uses SDL2's unified GameController API. This allows us to
correctly support any device that SDL recognizes by default, while
treating all of them the same way. This also means that if your device
is not supported by SDL, you will not be able to use it unless you
provide a custom mapping. If your controller is listed in the settings
menu, then you're fine. If not, read on.

An example mapping string looks like this:

::

    03000000ba2200002010000001010000,Jess Technology USB Game Controller,a:b2,b:b1,back:b8,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,dpup:h0.1,guide:,leftshoulder:b4,lefttrigger:b6,leftx:a0,lefty:a1,rightshoulder:b5,righttrigger:b7,rightx:a3,righty:a2,start:b9,x:b3,y:b0,

There are a few ways to generate a custom mapping:

-  You can use the
   `controllermap <https://aur.archlinux.org/packages/controllermap>`__
   utility, which `comes with SDL source
   code <https://hg.libsdl.org/SDL/file/68a767ae3a88/test/controllermap.c>`__.
-  If you use Steam, you can configure your controller there. Then you
   can add Taisei as a non-Steam game; run it from Steam and everything
   should *just work™*. In case you don't want to do that, find
   ``config/config.vdf`` in your Steam installation directory, and look
   for the ``SDL_GamepadBind`` variable. It contains a list of SDL
   mappings separated by line breaks.
-  You can also try the `SDL2 Gamepad Tool by General
   Arcade <http://www.generalarcade.com/gamepadtool/>`__. This program
   is free to use, but not open source.
-  Finally, you can try to write a mapping by hand. You will probably
   have to refer to the SDL documentation. See
   `gamecontrollerdb.txt <misc/gamecontrollerdb/gamecontrollerdb.txt>`__
   for some more examples.

Once you have your mapping, there are two ways to make Taisei use it:

-  Create a file named ``gamecontrollerdb.txt`` where your config,
   replays and screenshots are, and put each mapping on a new line.
-  Put your mappings in the environment variable
   ``SDL_GAMECONTROLLERCONFIG``, also separated by line breaks. Other
   games that use the GameController API will also pick them up.

When you're done, please consider contributing your mappings to
`SDL <https://libsdl.org/>`__,
`SDL_GameControllerDB <https://github.com/gabomdq/SDL_GameControllerDB>`__,
and `us <https://github.com/taisei-project/SDL_GameControllerDB>`__, so
that other people can benefit from your work.

Also note that we currently only handle input from analog axes and
digital buttons. Hats, analog buttons, and anything more exotic will not
work, unless remapped.

Troubleshooting
---------------

Sound problems (Linux)
^^^^^^^^^^^^^^^^^^^^^^

If your sound becomes glitchy, and you encounter lot of console messages
like:

::

    ALSA lib pcm.c:7234:(snd_pcm_recover) underrun occurred

it seems like you possibly have broken ALSA configuration. This may be
fixed by playing with parameter values of ``pcm.dmixer.slave`` option
group in ``/etc/asound.conf`` or wherever you have your ALSA
configuration. Commenting ``period_time``, ``period_size``,
``buffer_size``, ``rate`` may give you the first approach to what to do.

Contact
-------

http://taisei-project.org/

#taisei-project on Freenode