Package Details: xnp2 0.86-3

Git Clone URL: (read-only, click to copy)
Package Base: xnp2
Description: X Neko Project II, a PC-9801 emulator
Upstream URL:
Licenses: BSD
Submitter: linkmauve
Maintainer: sl1pkn07
Last Packager: sl1pkn07
Votes: 11
Popularity: 0.001036
First Submitted: 2012-08-18 09:11 (UTC)
Last Updated: 2021-11-05 22:24 (UTC)

Latest Comments

0b100100 commented on 2021-11-04 22:19 (UTC) (edited on 2021-11-04 22:49 (UTC) by 0b100100)

@NoSuck: Can confirm that there is no sound with sdl2_mixer >= 2.0.2

@sl1pkn07: Please add the following patch to be compatible with the latest sdl2_mixer package: sha256sum=e5b69952624995e2653c0bf47f2613bb751c351507d04f8194098bbe7a462075

The patch is necessary because of the following commit to SDL_mixer:

Reden commented on 2018-07-02 17:31 (UTC) (edited on 2018-07-10 17:29 (UTC) by Reden)

Most curiously, the update did not cause the program to compile with IA32 support. After applying the patch.patch on my own, and compiling with ./, ./configure --enable-ia32, and make (I make cleaned to do it with make -j4 just in case) it worked.

The title of both xnp2 and np2kai should say "Neko Project II + IA32".

EDIT: I'm sorry. I thought that there was an issue, but really what I had to do is to execute "xnp21", not "xnp2".

Reden commented on 2018-06-29 23:58 (UTC)

There are SDL and X11 ports of NP2Kai, a constantly updated fork, which is at

Reden commented on 2018-06-29 23:53 (UTC) (edited on 2018-06-29 23:54 (UTC) by Reden)

Please compile in ia32 support. Apparently it's necessary for Touhou games.

NoSuck commented on 2017-12-22 16:37 (UTC)

A recent sdl2_mixer update (2.0.1-1 -> 2.0.2-2) seems to prevent xnp2 from outputting any sound. Downgrading sdl2_mixer to 2.0.1-1 resolves the issue. Other packages that rely on sdl2_mixer do not seem affected. Can anyone confirm?

NoSuck commented on 2017-07-12 10:08 (UTC)

I'm confused. What do you think is worth talking with upstream about? Has anyone got Policenauts working?

sl1pkn07 commented on 2017-07-02 00:01 (UTC)

you can talk with upstream

NoSuck commented on 2017-07-01 23:37 (UTC)

Adding to a previous comment concerning full-screen mode: Setting the fullscrn (ignore_fullscreen_mode) variable of ~/.np2/np21rc to 1 results in xnp matching its window's resolution to system resolution, not the other way around. I think most people running full-screen will want this setting at 1.

sl1pkn07 commented on 2016-07-05 22:14 (UTC)

thanks for the patch

tegularius commented on 2016-07-05 22:04 (UTC)

New version: The fix-alignment.patch is now included and no longer necessary. It does not compile however, you'd need (or a similar hack): --- xnp2-0.86/x11/compiler.h.old 2016-03-08 18:25:50.000000000 +0100 +++ xnp2-0.86/x11/compiler.h 2016-07-05 23:48:04.507937827 +0200 @@ -117,12 +117,14 @@ #define MAX_PATH MAXPATHLEN #endif +#ifndef __cplusplus #ifndef max #define max(a,b) (((a) > (b)) ? (a) : (b)) #endif #ifndef min #define min(a,b) (((a) < (b)) ? (a) : (b)) #endif +#endif /* __cplusplus */ #ifndef ZeroMemory #define ZeroMemory(d,n) memset((d), 0, (n))

sl1pkn07 commented on 2015-12-31 01:33 (UTC)

new version!

linkmauve commented on 2015-11-04 11:43 (UTC)

Hi maz-1, I just built this package without having unzip installed and it worked fine. The archive is a tarball, which makepkg extracts using bsdtar from libarchive. Do you have any idea why it would be required for you?

maz-1 commented on 2015-11-04 05:09 (UTC)

please add unzip as makedepends.

NoSuck commented on 2015-02-01 09:56 (UTC)

Full-screen mode is also buggy, at least on Openbox.

NoSuck commented on 2015-02-01 08:43 (UTC)

Here's an audio capture: I have sound issues on an i7 @ 3.10GHz. I've tried buffer lengths from 50 all the way to 500 ms. I tried setting SDL_AUDIODRIVER and fiddling with every audio-related option xnp2 has to offer. I also tried cranking up the PC-98's memory and using 20x (and 32x) CPU multipliers: Nothing seems to work. Any ideas?

protosphere commented on 2014-12-01 07:55 (UTC)

The sound stutter seems to be related to SDL's pulseaudio driver. You can force SDL to use a different driver (eg. alsa) by setting SDL_AUDIODRIVER in your environment to work around the issue

linkmauve commented on 2014-11-04 17:12 (UTC)

Here sound doesn’t slutter, during slowdowns (I’m on a 1.3GHz Sandy Bridge i3) it will stretch instead. Still, it sounds pretty bad compared to pmdwin ( or to a recording from a real PC-9801. You may want to look at this project, which aims at rewriting those games’ engine, function by function:

Score_Under commented on 2014-11-04 17:00 (UTC)

A couple of other things of note: It seemed like when I disabled the stack protector without the patch, it failed to draw any graphics (text was fine). Could have been human error though as this was pretty early in the debug process. And as I'm 90% sure you're using this for touhou: have you found a way around the sound stutters? (Or is that just my computer?)

linkmauve commented on 2014-11-04 16:51 (UTC)

I came to the same conclusion while fiddling with gdb, thanks for the report. :)

Score_Under commented on 2014-11-04 16:35 (UTC)

It's not a gcc bug. These structures aren't packed so they're subject to the usual alignment rules. If you exclude the very last member of the structs, sizeof(XF86VidModeModeLine without last member) = 8*sizeof(short) + 2*sizeof(int) = 24 sizeof(XF86VidModeModeInfo without last member) = 8*sizeof(short) + 3*sizeof(int) = 28 On 64 bit machines the last member is 8 bytes long and needs 8 byte alignment. 24 is a multiple of 8 so it needs no padding, but 28 is not so it gets 4 bytes of padding inserted - meaning that in one of these structs there is an invisible 4 bytes that prevents them from being similar to each other. The type punning used here is exactly the kind that leads to undefined behaviour. Also see

linkmauve commented on 2014-11-04 16:14 (UTC)

It’s apparently the -fstack-protector-strong default parameter for gcc, set by makepkg, that is creating this crash. I don’t see any obvious issue with the current code, aside from potential alignment issue in gcc. To me this looks much more like a gcc bug than a bug in this code.

Score_Under commented on 2014-11-04 15:40 (UTC)

Explanation: The developer has assumed that XF86VidModeModeInfo can be turned into an XF86VidModeModeLine through pointer arithmetic, not realizing that the alignment differences prevent this on x86_64

Score_Under commented on 2014-11-04 15:34 (UTC)

Doesn't work on 64 bit. Patch:

sl1pkn07 commented on 2014-07-13 23:06 (UTC)

new version