gliptic / liero

How to build (Windows)

Building on Windows

• Install Visual Studio 2022
• Install SDL 2
  • Go to https://github.com/libsdl-org/SDL/releases
  • Download e.g. SDL2-devel-2.26.1-VC.zip
  • Extract the contents to somewhere on your file system
  • Set the SDL2_DIR environment variable to the directory you extracted the files to
• Install SDL2_image
  • Go to https://github.com/libsdl-org/SDL_image/releases
  • Download e.g. SDL2_image-devel-2.6.2-VC.zip
  • Extract the contents to somewhere on your file system
  • Set the SDL2_image_DIR environment variable to the directory you extracted the files to
• Copy everything from the pkg directory to the same folder as openliero.exe ends up in, e.g. out\build\x64-Debug or out\build\x64-Release
• Download SDL 2
  • Go to https://github.com/libsdl-org/SDL/releases
  • Download e.g. SDL2-2.26.1-win32-x64.zip
  • Put SDL2.dll either in your system32 folder or in the same folder as openliero.exe ends up in, e.g. out\build\x64-Debug or out\build\x64-Release
• Download SDL2_image
  • Go to https://github.com/libsdl-org/SDL_image/releases
  • Download e.g. SDL2_image-2.6.2-win32-x64.zip
  • Put SDL2_image.dll either in your system32 folder or in the same folder as openliero.exe ends up in, e.g. out\build\x64-Debug or out\build\x64-Release
• Copy everything from the pkg directory to the same folder as openliero.exe ends up in, e.g. out\build\x64-Debug or out\build\x64-Release

(Optional) Dependencies for building the video tool

• Follow the instructions for installing dependencies needed to build ffmpeg. At the time of writing, the MSYS2 route worked best for me https://trac.ffmpeg.org/wiki/CompilationGuide/MinGW
• Download latest libx264: git clone git://git.videolan.org/x264.git
• Build it: cd x264; ./configure --enable-shared --enable-pic && make -j8
• Download latest ffmpeg: git clone git://source.ffmpeg.org/ffmpeg.git ffmpeg
• Build it: cd ffmpeg; ./configure --enable-shared --enable-pic --enable-gpl --enable-libx264 --disable-programs --extra-ldflags=-L../x264 --extra-cflags=-I../x264 && make -j8

How to build (Linux and Mac)

Building on Linux and Mac

• Make sure you have CMake, SDL2, SDL2_image and gcc installed
• Run cmake:
• $ cmake -G "Unix Makefiles"
• Run "make"
• Copy everything from the pkg directory to the root directory used for the build

(Optional) Enabling and building the video tool

• Download latest libx264: git clone git://git.videolan.org/x264.git
• Build it: cd x264; ./configure --enable-shared --enable-pic && make -j8
• Download latest ffmpeg: git clone git://source.ffmpeg.org/ffmpeg.git ffmpeg
• Build it: cd ffmpeg; ./configure --enable-shared --enable-pic --enable-gpl --enable-libx264 --disable-programs --extra-ldflags=-L../x264 --extra-cflags=-I../x264 --extra-libs=-ldl && make -j8
• Run: make -j8 videotool

Building a release build

• Run cmake:
• $ cmake -DCMAKE_BUILD_TYPE=Release -G "Unix Makefiles"
• Run "make"

Extracting the game data

You need data from the original Liero in order to run local builds. You can get the data from the original game by following these steps:

Windows

Invoke-WebRequest https://www.liero.be/download/liero-1.36-bundle.zip -OutFile liero-1.36-bundle.zip
Expand-Archive -LiteralPath .\liero-1.36-bundle.zip .
.\out/build/x64-Release/tctool.exe liero-1.36-bundle
Move-Item .\TC\liero-1.36-bundle .\TC\"Liero v1.33"
Remove-Item .\liero-1.36-bundle.zip
Remove-Item -Recurse .\liero-1.36-bundle
Copy-Item -Recurse .\TC .\out\build\x64-Debug
Copy-Item -Recurse .\TC .\out\build\x64-Release

Linux/Mac

curl https://www.liero.be/download/liero-1.36-bundle.zip -O
unzip liero-1.36-bundle.zip
./tctool liero-1.36-bundle
mv TC/liero-1.36-bundle TC/"Liero v1.33"
rm liero-1.36-bundle.zip
rm -rf liero-1.36-bundle

liero's Issues

Icon resources

Surprised to see this still has no icon.

Prepared a set for my install - feel free to adopt.
The icons are based on the screenshot from Wikipedia.

For Windows - icons are typically compiled with Resource Compiler and built into EXE.
For Linux - they are just supplied as PNGs.

initial color of laserSight

Hello guys,

First of all, I would like to express my appreciation to all the people who have worked on this repository in the past few years and improved the best game of all time :) big respect especially goes to ahockersten, who has added many improvements recently.

Anyway, I opened this issue because I would like to point out on one more thing which I think would be cool to change. It is not a bug or anything that affects the gameplay much, but I think it would be nice to improve it too.

Namely, I noticed that laserSight (used in e.g. rifle) is drawn with color indices 83-84 and this thing is hardcoded (see line 597 in the "blit.cpp" file). Same colors (precisely 82-84) are also used to "draw blood stains" (in simple terms ofc) on the map when blood stains on dirt (see line 49 in the "bobject.cpp" file).

I think it would be cool to change the initial color for laserSight to another one (e.g. 80, or 104, or 245), because currently, if you want to change the color of laserSight (which can be done by changing the palette ofc), the color of blood spots falling on dirt also changes respectively. I think it would be good to separate these two things, so that these parameters (color of "blood stains on dirt" and initial color of laserSight) could be modified independently.

Alternatively, you could also consider making the laserSight color dependent on the colorBullets parameter of the weapon (like it is done for the laser beam for laser weapon - see line 524 in the "viewport.cpp" file). Imo that would be quite interesting, because it would allow different laserSight colors for different weapons (e.g. different for rifle, different for handgun etc.), which I think would diversify the gameplay.

As I mentioned above, this is not a bug neither a necessary thing to change, so if you find it useless, feel free to close this issue. ;)

Line endings and coding style inconsistent

Some line endings are DOS/Windows style, others are Unix style. This causes VS to complain, and git to generate some pretty bad diffs. Some files lack a newline before EOF too.

Similarly, the code suffers from having evolved through the years, with a coding style that is inconsistent between files and in files.

I'm willing to submit a patch that fixes these issues if I get an OK beforehand (there are some good applications out there for fixing these kinds of issues), but I'd need to know what coding style is preferred beforehand, for example via pointing at a sample file that implements a "good" coding style.

I have no strong opinions (actually, I do, but I'm willing to ignore them because it rarely leads to a fruitful discussion :)) on what coding style should be used, as long as it's consistent throughut the code.

Code explanation

@gliptic could you explain what exactly this code in worm.cpp doing?

if(reacts[RFDown] < 2)
				{
					if(reacts[RFUp] > 0)
					{
						if(reacts[RFLeft] > 0 || reacts[RFRight] > 0)
						{
							//Low or none push down,
							//Push up and
							//Push left or right

							pos.y -= itof(1);
							next.y = pos.y + vel.y;
							iNext.y = ftoi(next.y);

							calculateReactionForce(game, iNext.x, iNext.y, RFLeft);
							calculateReactionForce(game, iNext.x, iNext.y, RFRight);
						}
					}
				}

				if(reacts[RFUp] < 2)
				{
					if(reacts[RFDown] > 0)
					{
						if(reacts[RFLeft] > 0 || reacts[RFRight] > 0)
						{
							//Low or none push up,
							//Push down and
							//Push left or right

							pos.y += itof(1);
							next.y = pos.y + vel.y;
							iNext.y = ftoi(next.y);

							calculateReactionForce(game, iNext.x, iNext.y, RFLeft);
							calculateReactionForce(game, iNext.x, iNext.y, RFRight);
						}
					}
				}
			}

Is it special code for climbing? If not, do you know part of code, which handle moving by ascending surface?
Very appreciate any information. Thanks for great port of awesome game!

support for armv7-armhf

i'm trying to compile on raspberry pi 3b with arm-linux-gnueabihf but it doesnt work.

WObject blowAway won't affect any NObjects of the same owner

https://github.com/gliptic/liero/blob/master/weapon.cpp#L307

This is different from original liero, checked with dosbox. Either reenable that other broken id check or remove the owner check alltogether.

Permission to submit to Greenlight

Hey @gliptic,
I would love to submit Liero to Steam's Greenlight.

I use to put in a ton of hours into Liero and would love to see it easily distributed as a free game through Steam's platform.

I'm willing to foot the Greenlight fee and put in the development hours to fit the Steam requirements.

In order to submit it to Greenlight I need to have explicit authorization to meet their legal requirements.

Thanks for your consideration!

amazing... linux arm support

Hi buddy, can you add linux arm definitions?? also, do you have a binary release for linux? I can just emulate it for now (I dont have a linux x86 platform ready to compile it)

amazing...so much memories... my nephews are amazed with this game

support command line argument for launching in full screen

When you want to integrate this in arcade like machines (kiosk mode), it would be very helpful to be able to launch this in full screen from the get go so you won't see the desktop

Merging SDL2 and other stuff from my fork

Hey, as many are aware I've been maintaining a fork of Liero since quite some time.

The short backstory (as I remember it, 10+ years later), I originally wanted to add a single screen replay mode. Then I wanted SDL2 to address some performance issue when running Liero on high resolution screens and also to be able to add spectator mode. At the time gliptic wasn't very active so my changes ended up quite far from main. Then I had some inspiration and I added some more features. And some more changes. And so on... 😄

Anyways, there's never been a good reason for having two versions, so let's try to see if we can get whatever useful I have in.

Here's a brief outline of how I want to go about to accomplish this:

1. Resave all files in a "modern" editor.
   The line endings are messy and there are inconsistencies which makes it frustrating to work on the codebase in a modern editor. Unfortunately I have used some modern editors on my codebase and I was at times sloppy with how I committed stuff. It would be much easier to just avoid this. I can then rebase my fork on this, which should make the changes clearer.

2. Port all the changes that are needed to compile on modern systems
   That is, latest version of VS and CMake. I have CMake at least, unsure about VS but I think it uses CMake now.

3. Port single screen replay, SDL2 and spectator mode. These are a bit commingled so probably makes sense to do in one go.

4. ???
   We'll see when we get there what's left that seems relevant.

Unless I hear words otherwise I'll get started on looking further into this.

Part of an if condition can be moved outside of a for loop, optimization.

This line:

https://github.com/gliptic/liero/blob/master/weapon.cpp#L395

All those can be moved outside of the for loop, no need to check for every worm. I also recommend adapting wormCollide so that it's always true if that expression would be true.