Package Details: xnp2 0.86-1

Git Clone URL: (read-only)
Package Base: xnp2
Description: X Neko Project II, a PC-9801 emulator
Upstream URL:
Licenses: BSD
Submitter: linkmauve
Maintainer: sl1pkn07
Last Packager: sl1pkn07
Votes: 8
Popularity: 0.000000
First Submitted: 2012-08-18 09:11
Last Updated: 2016-07-05 22:19

Latest Comments

sl1pkn07 commented on 2016-07-05 22:14

thanks for the patch

tegularius commented on 2016-07-05 22:04

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 @@

+#ifndef __cplusplus
#ifndef max
#define max(a,b) (((a) > (b)) ? (a) : (b))
#ifndef min
#define min(a,b) (((a) < (b)) ? (a) : (b))
+#endif /* __cplusplus */

#ifndef ZeroMemory
#define ZeroMemory(d,n) memset((d), 0, (n))

sl1pkn07 commented on 2015-12-31 01:33

new version!

linkmauve commented on 2015-11-04 11:43

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

please add unzip as makedepends.

NoSuck commented on 2015-02-01 09:56

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

NoSuck commented on 2015-02-01 08:43

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

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

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

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

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

Score_Under commented on 2014-11-04 16:37

No I didn't, ignore me

Score_Under commented on 2014-11-04 16:36

Whoops, meant to say "exclude the very last member of the structs and exclude dotclock"

Score_Under commented on 2014-11-04 16:35

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

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

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

Doesn't work on 64 bit. Patch:

sl1pkn07 commented on 2014-07-13 23:06

new version