The commercial game Halloween (FPS) for Linux is now the open source project


I think that your changes in linux.cpp and opengl.cpp should be added to the Halloween project on GitHub.

I noticed some weird differences between the distrib directories and the other files:

entity:

45 items, totalling 1,4 MB (GitHub)
45 items, totalling 1,5 MB (Windows)

maps

23 items, totalling 12,8 MB (GitHub)
23 items, totalling 13,0 MB (Windows)

hconfig.cfg

1,6 kB (1 638 bytes) (GitHub)
1,7 kB (1 713 bytes) (Windows)

hconfig_mac.cfg

2,2 kB (2 247 bytes) (GitHub)
2,4 kB (2 352 bytes) (Windows)

hconfig_win.cfg

2,3 kB (2 263 bytes) (GitHub)
2,4 kB (2 368 bytes) (Windows)

hkey.ini

41 bytes (GitHub)
43 bytes (Windows)
 
Last edited:
That might be down to the double length line ending characters that windows uses. Unix/linux uses just LF, but windows using CR+LF. I'm not sure what github does if given the window endings.
 
as @levi said the difference in bytes should came from different line ending of win/linux and i think is not so important (unless some files are corrupted) regarding image files. The important thing to check is the number of files (but they seems to be in equal number ...).
 
Thank you for the answers.

This is the correct explanation if I look at the hkey.ini files


Well, I will have to look again, which files have the different size in directories.
In the case of hconfig.cfg, we have few differences:

filemap h1m1.map 0.000000 (Windows)
filemap mapbonus0.map 0.000000 (Github)

Windows

fullscreen 0 0.000000
colordepth 16 32.000000
videomode 2 5.000000

GitHub

fullscreen 1 1.000000
colordepth 16 16.000000
videomode 2 2.000000

Halloween crashes when I try to change the colordepth to 16 32.000000:


Do you have the same issue with the colordepth?
 
Last edited:
Brizzly added the missing TGA images, and we will have to wait when he will add the missing wav files:


Unfortunately, I have to turn off the music, and even after it, the sound is sometimes terrible for my ears. In this case, I decided to post this issue on the un4seen forum, and below is the answer:

Ian @ un4seen
Administrator
From the source code, it looks like it is/was using an old BASS version that still had the BASS_ChannelSetAttributes function. That was replaced with BASS_ChannelSetAttribute in BASS 2.4, and I see the code has been updated to use that but the issue is that the BASS_ATTRIB_VOL setting ranges 0-1 rather than 0-100, so you need to divide the old "volume" value by 100 in those calls. For example:

Code:
res = BASS_ChannelSetAttribute(gSoundObjet[SoundID].channel3D[sound_pos],
        BASS_ATTRIB_VOL,
         volume / 100.f);

I don't have the Pandora game console. I'm wondering if you tried to build it on any device with an ARM processor. It probably requires some additional changes.

I have somewhere my old Raspberry PI 3, and I can try to build Halloween on it.
However, I don't know if it makes sense when the new version is available.

@Farox
I added your change that fixed the issue with loading TGA images, but I wasn't fast enough with the second file. Pocak100 was faster, and he added a lot of great changes that made this game playable on Linux. I didn't know he was working on it, but we can finally play it!
 
Last edited:
I added your change that fixed the issue with loading TGA images, but I wasn't fast enough with the second file. Pocak100 was faster, and he added a lot of great changes that made this game playable on Linux. I didn't know he was working on it, but we can finally play it!
Yeah i saw and following the recent changes, and i like that Pocak100 is working on it, i'm not a programmer and don't know how to (quickly) solve some of the problem, instead he is capable of coding and solving most of the bug/missing features that the game will require.
I'm really looking to port/recompile this on my Pyra and Pandora one of this days...i have yet to try the new fix by Pocak100 on my linux box.

Thanks also for asking on the Bass forum...i need to test also this.
 
Ok so i rebuild the Pocak100 code on my linux box (i have re-adapted the "build" file using libjpegturbo), and the game run....but controls don't work.

After i have modified the bass volume like ian@un4seen suggested ....and the audio is working good and is amazing...i really love it.

So to have a working audio open "libbass.cpp" and search for "BASS_ATTRIB_VOL" (there are 3 ) next there is the "volume" word
change every line from
volume);
to
volume / 100.f);
or
(float)volume);
to
(float)volume / 100.f);
and that's it.

Now hope Pocak100 is fixing the keys/controls.
 
Thank you for the answer.

I have to check it.

In the controls menu, try to click on the small circles using a mouse cursor, and then press the key to assign it for the specific action or movement.
 
@Farox

It works, and I added it to the main repository of Halloween on GitHub.

Unfortunately, I can confirm that Halloween crashes when I select a screen resolution higher than 1024x768:


Do you have the same issue with it?
 
Do you have the same issue with it?
No...on my linux box i can change every resolution without a crash (16 and 32 bit), but instead on my machine it seems not to register the keys (and yes i try to change it on the options menu), also it seems not to work save the screenshot (with numpad 5).

Anyway i built a test with my Pyra...

hallow3d_testpyra_1.jpg
hallow3d_testpyra_2.jpg


But i have problem with the texture using GL4ES on it maybe @ptitSeb could help here...i'm pretty new on the pyra.
It run using Mesa with pretty low fps at 800*600 windowed (around 6 fps..)...using gl4es i think we could reach a good fps.

Next i want to try a version for Pandora.
 
I looked a bit at the code.
I see the game want to use FLAT shading, so you better use the GLES1.1 backend (use "LIBGL_ES=1" on the pyra), bacuse it's ignore on GLES2.0.
I don't really see why the texture would not work. It's using automatic MIPMAP but that's supposed to be correctly handled. I'll probably try to debug that later, probably some bug in gl4es.

If you still have white texture on GLES1.1 backend, add "LIBGL_MIPMAP=3" to ignore the mipmap and that should do it (until I find and fix the bug)
 
Ok, so I built the game on my side and I reproduce the issue. I have made a PVRTrace capture so I can debug

1637422976507.png


Something strange here. it's the first logo screen (I guess, I only see white). I can see two texture beeing created correctly, and than a 3rd one is created, left empty, and is used to display the white square...
 
Ok, so I found the issue.

tl;dr:
Comment this line https://github.com/brizzly/Halloween3D/blob/master/HalloweenSrc/opengl.cpp#L1040 and update gl4es to latest version.

long version:
The game use glGenTextures is a strange way. It use predefined Textures ID, and try to use glGenTextures to create those ID. But it's not working like that! glGenTextures is used to get textures ID that are guarantied to be unique, but there is no garanties that the 1st will be "1" or any other assumption.
Software MESA gives you 1, 2, 3... for the firsts textures, so it works. But PVR will gives you 700001, 140002.... And so that's why texture were black. Because the texture is loaded in ID "700001", and than the ID "1" is drawn on screen.
So just don't use glGenTextures(...) and simply use the ID that the game wants. It's perfectly legal OpenGL code (even if not recommanded)...

But I did notice an issue with gl4es on texture not create with glGenTextures. You need to use LIBGL_MIPMAP=3 on older gl4es version to have it displayed correctly if you don't update gl4es...
Screenshot at 2021-11-20 18-15-58.png
 
Thanks
About update gl4es ..i have to do
"sudo apt update" on a terminal right ?
 
Back
Top