brickviking / night-hawk

Nighthawk is a tribute to one of the most playable and contagious games ever written—Paradroid by Andrew Braybrook. Feel the excitement as you battle through hordes of droids to gain your object of removing all droids on the level.
2 stars 0 forks source link

Alpha tester feedback/recommendations: wotnot@www.austech.info #14

Open jsno8192 opened 3 years ago

jsno8192 commented 3 years ago

Recommendations from wotnot@www.austech.info:

Discussion thread:

https://www.austech.info/showthread.php/119424-Nighthawk-4-0-A-restored-open-source-arcade-game-Requesting-alpha-testers


M'kay..... it compiles fine on debian 10.6 without the need to go outside deb-package repo --- the binary links out like so;

gcb@gallah:~/build$ ldd nighthawk linux-vdso.so.1 (0x00007ffdb0ba3000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f1577510000) libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 (0x00007f15774d0000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f15772b0000) libGLU.so.1 => /lib/x86_64-linux-gnu/libGLU.so.1 (0x00007f1577238000) libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x00007f15771a0000) libglut.so.3 => /lib/x86_64-linux-gnu/libglut.so.3 (0x00007f1576f50000) libvorbis.so.0 => /lib/x86_64-linux-gnu/libvorbis.so.0 (0x00007f1576f20000) libvorbisfile.so.3 => /lib/x86_64-linux-gnu/libvorbisfile.so.3 (0x00007f1576f10000) libopenal.so.1 => /lib/x86_64-linux-gnu/libopenal.so.1 (0x00007f1576e28000) libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1576ca0000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1576b18000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1576af8000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1576930000) /lib64/ld-linux-x86-64.so.2 (0x00007f15775a8000) libGLX.so.0 => /lib/x86_64-linux-gnu/libGLX.so.0 (0x00007f15768f8000) libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007f1576838000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f1576830000) libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6 (0x00007f1576618000) libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007f15764d0000) libXi.so.6 => /lib/x86_64-linux-gnu/libXi.so.6 (0x00007f15762c0000) libXxf86vm.so.1 => /lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007f15760b8000) libogg.so.0 => /lib/x86_64-linux-gnu/libogg.so.0 (0x00007f1575ea8000) libsndio.so.7.0 => /lib/x86_64-linux-gnu/libsndio.so.7.0 (0x00007f1575e90000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f1575e80000) libatomic.so.1 => /lib/x86_64-linux-gnu/libatomic.so.1 (0x00007f1575e70000) libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f1575e40000) libasound.so.2 => /lib/x86_64-linux-gnu/libasound.so.2 (0x00007f1575d38000) libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f1575d18000) libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007f1575b10000) libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f1575908000)

GLUT dependency satisfied by freeglut3 + freeglut3-dev 2.8.1 debian ccmake target package is named cmake-curses-gui pkg-config doesn't register freeglut, but cmake rules work correctly by adding -lglut install_path is goofy somewhere.... on a debian instance, game binary should go to /usr/bin/ (or some would argue that /usr/games/ should be binary_install_dir) -- resource files into /usr/share as per normal *currently it seems 'make install' puts things in ~/build .... (this maybe my bad - I don't particular like cmake ; I'll have a closer look at it later)

Not sure about these complaints;

*@****:~/build$ ./nighthawk Nighthawk v4.0, Copyright (C) 1997 Jason Nunn, Adelaide South Australia. Warning: Could not load scores file '/var/tmp/nighthawk.scores'. Warning: Could not restore preserved session '/home/gcb/.nighthawk.preserve'. Warning: Could not load scores file '/var/tmp/nighthawk.scores'. See ya

Those files don't seem to be created at game launch.... not sure what's going on ; I should rehash the cmake files to make sure it's installed system-wide & recheck

Gameplay (and mastering that) will take me a little time =)

No fullscreen mode? Does work windowed (stretched or fullscreen window), but I did note when you die in game, the grey/white boxes screen doesn't resize to full/stretched window (I'm guessing the game opens in 800x600 res)

I noticed a typo or two in the manpage

This might be messy using this forum to exchange comments ~ if you prefer (I do =), you can hit me up direct with email --->

More later

Cheers


Audio in the game is very good overall ~ and openal works fine (clicking a window closed as opposed to quit the game hoists an openal error, but that'll be a gtk thang for sure)

Just for shits & giggles, listen to the first few seconds of this https://severedheads.bandcamp.com/track/king-of-the-sea ....familiar? =^)

brickviking commented 3 years ago

I think that /usr would be normal install prefix for most packages anyhow, we can address that when we work out how to make RPMs, and it looks like you've started on making debs. By the way, if you can, tap on Adrian Bridgett's shoulder, see if he's still interested in being nighthawk-for-debian's "maintainer".

jsno8192 commented 3 years ago

Hi E

While I'm still coding and game is alpha, I wanted to jail everything to the build directory. But I think the next code changes I do should be my last for 4.0, and then I can safely change the install path to "/usr".

Nb/ I recommend "/usr/local" though, because the user is installing a program that is not a part of their operating system distribution.

I'm not making debs yet. 4.0 is still in early testing stages (I'm still coding etc). There's a few small things that need changing (as suggested by wotnot), but over all, wotnot is happy with the quality of the game. I'm currently getting feedback from another alpha tester.

Regarding RPMs and Debs etc. We can either not worry about that with 4.0, and then crack on with 4.1dev (ie: adding full screen/wide screen support etc, enhancements to ned etc), or leave 4.1dev for a future date and focus on distributing 4.0. What are your thoughts here ?

BTW: Not sure if you've been getting my gmail emails ? (I haven't received any emails from you for a week). My jsno@internode email address is no more now.

J

brickviking commented 3 years ago

Heh, that probably means I haven't checked my email for nearly a week. Sorry about that, but sometimes I don't pick up my email for a week or four.

I think if you're happy with what you've produced for 4.0, you could look at packages. If not, then yes, get the code working at your leisure. No hurry here, after all, I (and others) have waited this long without going mental.

jsno8192 commented 3 years ago

^^ replied by email. In summary, my recommendation:

Roll in some of the easy to implement recommendations from the alpha testers. Then set 4.0 to BETA and freeze it. We then push 4.0beta out of the door. It's done.

We then duplicate 4.0beta to 4.1dev, and development continues with 4.1dev.

jsno8192 commented 3 years ago

More feedback from wotnot:

*confirm openal warning fixed/gone when destroying window

*confirm change of sound FX 'data/fx/trans_terminated.8' (new FX sounds okay)

*confirm install path with the following observations;

*@*****:~$ which nighthawk /usr/local/bin/nighthawk

 - when creating a desktop link, XFCE emitted the following warning  (appears to be normal behaviour in the case of /usr/local/ ) The option 'Launch Anyway' works, and option 'Mark Executable' does that and suppresses any further warning appearing.

Screenshot_2020-10-29_00-21-54.png -- when creating a desktop link, user will need to hunt for an icon, because we don't install one =) I found /usr/local/share/nighthawk/Nighthawk/logo.png as a likely candidate, although one might think about crafting another/different icon file for the purpose --> either way, install needs to do something akin to ln -s /usr/local/share/nighthawk/Nighthawk/logo.png /usr/local/share/pixmaps/nighthawk.png --> once that is so, when creating a desktop icon, the 'nighthawk' icon will appear in 'All Icons' when creating a desktop link and setting a/the icon

Personally, I think the 'untrusted' popup is correct/expected system response here - it is what it is, at any pre-release stage. Mind you, I have one other exe in usr/local/bin (youtube-dl), and I get the same behaviour & untrusted popup. I would wonder if this is just 'policy' being enforced. The 'nice, eloquent' fix, would be (in short) seeing sudo make install result with the game icon appearing on desktop, (with associated entry in program desktop menus), yes? That'd be the packager's job, however at -this- stage the desktop icon file should exist in /usr/local/share/pixmaps/ , so that it may (later) be referenced for entries with freedesktop/xdg and friends...is this shit automated yet? Is there any command the install script can invoke, to do all this for you?...surely there is =) Anyhoo...you still need the desktop icon...lol.. if someone ever ports to android, they'll need this resource as well (and on my desktop using that logo.png as a desktop icon, it looks like this and I wonder if better contrast in the icon image might help it pop-out more visually)

...'logo.png' doesn't translate into a desktop icon well (1920x1080 display)...}shrug{...need for an emblem/icon image that's less cluttered, and stylized to represent part of the game/gameplay and says "that's nighthawk" -- to me, the droids as rendered to screen says this to me...like the eufloria icon centers on a single seedling ; the nighthawk icon could center on a single droid (make it a 6xx series to give ppl a midrange target ;) Up to you of course, I'm just tossing up ideas.

*still some grammar/punctuation off in README and manpage ....I might just proof them myself and toss you the diffs for review

during build, that cmake warning about not finding glut, the words 'Adding -lglut' ...I like this better 'Expected failure, adding -lglut' ...just because I'm like that ;) It looks* like a problem ; I like to make sure it looks like someone else's problem...not mine....haha.

I'm starting to get into the gameplay, understanding the challenges as it were ; it (the experience) reminds me of the learning curve these games put your brain through, as opposed to modern game concepts ; I'm going to munge together a USB dpad and remap inputs thru antimicrox when I get a spare moment or 10 to find the joypad...

jsno8192 commented 3 years ago

My response:

Noted about the desktop launcher and logo. I'm still a novice at cmake, but I'm betting there is a cmake feature that does this (or somebody has some code that will do this), for a specified set of operating systems.

That's interesting how the nighthawk executable isn't 755. On mine, cmake sets this file up correctly. On yours it doesn't ?. I'll have to look into that.

Yes, I agree with 606 droid would make a good icon. There are lots of them in the game :)

I would appreciate you proofing README for me. When you look at something 1000 times over 25 years, it's becomes oblivious :)

Thanks for the pickup with "refrain". Woopsy. Yes, I'm sure it's a Freudian skid :)

Regarding the -glut cmake warning, what is happening is cmake queries pkg-config for glut compiler flags (which seems to be the 'best practice' method that cmake developers implement), but for some unknown reason, most distributions bundled with freeglut don't have freeglut registered in it's pkg-config database (including two of my linux notebooks). When cmake throws this error, I've put some code into the cmake script to blindly specify -lglut ( regardless of operating system having this library) and It's a "leap of faith" that it compiles for the user. I'm still a novice with cmake, and it's the only thing I could come up with. Later on, I'll make something more robust (like an include file detector, or compile a small bit of code, like autoconfig does). At this stage, I think the warning message presents what is happening (even though the user may not understand the meaning of this message).

brickviking commented 3 years ago

Looks like I might need to cast another eye over the README too, they say "many eyes makes bugs shallow".

jsno8192 commented 3 years ago

When I am proofing documents at work, I have resort to printing them out. Otherwise I'm spelling blind LOL :)

Here is a new response from wotnot:

--$--------------------------------------------------------------- Nah I don't think it's just permissions ; if I back track and compare build binary versus installed binary, you see

$ ls -la /usr/local/bin/nighthawk -rwxr-xr-x 1 root root 592152 Oct 28 23:17 /usr/local/bin/nighthawk $ ls -la ~/build/nighthawk -rwxr-xr-x 1 gcb gcb 592152 Oct 28 23:17 /home/gcb/build/nighthawk

You have to read the verbiage of the warning very tersely (I was once a beta tester for XFCE yonks ago =)

'untrusted application launcher' ; it's talking about the file 'Nighthawk.desktop', which it itself is in the process of creating -- this is daft logic based on the fact I'm pretty damn sure you don't include one =)

Ergo: it's having a knee jerk about the fact the file doesn't exist...OR...it's pissed about the fact it's linking to an executable that is 'out of band/tree' in /usr/local

Me findee file...

$ find . -name Nighthawk.desktop ./Desktop/Nighthawk.desktop

$ ls -la ./Desktop/Nighthawk.desktop -rwxr-xr-x 1 gcb gcb 191 Oct 29 00:22 ./Desktop/Nighthawk.desktop

$ cat ./Desktop/Nighthawk.desktop [Desktop Entry] Version=1.0 Type=Application Name=Nighthawk Comment= Exec=/usr/local/bin/nighthawk Icon=/usr/local/share/nighthawk/Nighthawk/logo.png Path= Terminal=false StartupNotify=false

In the real world, install would copy said file to /usr/local/share/applications/Nighthawk.desktop with 0644 perms root.root .. et_voila

$ ls -la /usr/local/share/applications total 20 drwxr-xr-x 2 root root 4096 Oct 29 23:22 . drwxr-xr-x 10 root root 4096 Oct 28 23:17 .. -rwxr-xr-x 1 root root 516 May 29 17:46 appimagekit-balena-etcher-electron.desktop -rw-r--r-- 1 root root 13 Oct 26 15:58 mimeinfo.cache -rw-r--r-- 1 root root 191 Oct 29 00:22 Nighthawk.desktop

This is enough for things to build a clue, and associate the icon file with the executable, but as the mime-type is as yet undeclared for the application, the WM defaults to 'Other', and generates a desktop menu item accordingly....

C'est fantastique, n'est-ce pas? That'd actually be correct for alpha/beta -- at release, you include the line Categories=Game;ActionGame; in the Nighthawk.desktop file, and you get the Nighthawk entry/icon appearing in the Games menu item instead ; you can specify mime-type and a whole heap of stuff in a .desktop file like this, and with XFCE at least the background automation takes care of the rest.

Then you don't need to create a desktop icon/launcher, because you can drag a copy from menu to desktop.

It still pops the untrusted application warning dialog first time launch....hmmm...smells of policy, I set all the permissions correctly, the application launch is being intercepted by something else at user level...I bet this totally goes all away when one creates a .deb package...ahhh, m'kay....

Search google with the string 'untrusted application launcher'

In any event, need for Nighthawk.desktop file to be included with install data, to facilitate WM menu functions (in XFCE at least, gnome prolly uses the same hooks)

--$---------------------------------------------------------------

So, this is another thing to add to the list for 4.1dev :)

This is a bit new to me, as I've never bothered to integrate my programs into a desktop before. I'm going to have to research this. So it's going to be a more learning.