Author Topic: FCEUX 2.2.3 - UPDATE 2016-08-23  (Read 44125 times)

Seph817

  • *
  • Posts: 121
Re: FCEUX 2.2.2
« Reply #15 on: November 18, 2013, 03:11:02 am »
I still can not get FDS games to god damn work.  I have a good disksys.rom file.  It is in .fceux folder.  My *.fds files are zipped and on the external card.  When I try to select an FDS ROM from Rom Browser, the screen goes black and I am taken back to the Emulators section of OD.

I guess I can try a full uninstall and reinstall (completely delete the .fceux folder and the opk)...
Update: that didn't help

I have my FDS roms in a separate folder from the NES ones. They're not zipped and I open them from the GUI in FCEUX. They work fine for me. Yeah, I have to browse to that folder every time I want to play one but, it works.

dmitry_smagin (OP)

  • *
  • Posts: 395
Re: FCEUX 2.2.2
« Reply #16 on: November 18, 2013, 04:18:12 am »
So, about the grainy sound.  For whatever reason, the dingoo author(s) apparently made FCEU output in stereo instead of mono by copying samples to both channels.  Unfortunately, they didn't consider sign extension as int16 is promoted to int32, so that's the cause of the grainy sound--you can verify this with headphones and notice that the left sounds fine and the right sound grainy.  So, the solution is to either (a) revert to mono sound (since there's little point in duplicating the sample manually) or (b) mask out the bottom 16-bits when doing the sample copying.  Anyways, here's a patch to do the former.

Code: [Select]
--- fceu320-rzx50/src/drivers/dingux-sdl/dingoo-sound.cpp 2013-11-17 15:33:00.779739255 -0500
+++ fceu320-rzx50.new/src/drivers/dingux-sdl/dingoo-sound.cpp 2013-11-17 14:33:51.503796108 -0500
@@ -46,20 +46,20 @@
  */
 static void fillaudio(void *udata, uint8 *stream, int len) // len == spec.samples * 4
 {
-    int32 *tmps = (int32 *)stream;
-    len >>= 2;
+    int16 *tmps = (int16 *)stream;
+    len >>= 1;
 
     // debug code
     //printf("s_BufferIn: %i s_BufferWrite = %i s_BufferRead = %i s_BufferSize = %i\n",
     //    s_BufferIn, s_BufferWrite, s_BufferRead, s_BufferSize);
 
     while (len) {
-        int32 sample = 0;
+        int16 sample = 0;
         if (s_BufferIn) {
             sample = s_Buffer[s_BufferRead];
             s_BufferRead = (s_BufferRead + 1) % s_BufferSize;
             s_BufferIn--;
-            sample |= (sample << 16);
+//          sample = (sample&0xffff) | (sample<<16);
         } else {
             sample = 0;
         }
@@ -110,7 +110,8 @@
 
     spec.freq = soundrate;
     spec.format = AUDIO_S16;
-    spec.channels = 2;
+//    spec.channels = 2;
+    spec.channels = 1;
     spec.samples = 512;
     spec.callback = fillaudio;
     spec.userdata = 0;

PS - The reason I don't release a binary is the github apparently did some clean up that has left the GUI non-functional, and I don't readily know enough about git to use an earlier revision. :/

Damn, I forgot about sign extension int16 -> int32; fixed and opk reuploaded.
The reason of doubling mono to stereo is to allow working on legacy dingux, on which mono streaming doesn't work (it silently sets itself to stereo).
However, fceux core renders sound in mono, but uses int32 for optimizing. You can see in original sdl driver that it simply discards upper part of sample before sending it. :)
GCW-Zero prototype, Dingoo a320, Ritmix rzx-50, Dingoo a380, Xperia Play

kuwanger

Re: FCEUX 2.2.2
« Reply #17 on: November 18, 2013, 06:41:18 am »
Well, I figured out that it wasn't that the GUI is non-functional...it just externalized all the numbers/font. :)  So, after copying that over it all worked.  So, I decided to toy around with the fullscreen scaler.  It's a mixture of Scale2x and a smooth downscaler.  It's not really exactly what I want, but it looks a little better to me than the current fullscreen scaler.  Anyways, here it is.

fceux.opk /w different fullscreen scaler

PS - Thanks d_smagin.  I figured it might be something like that.

Edit - And here's another scaler that uses subpixel rendering based on cleartext type scaling.  Since FCEU actually uses a 256x240 screen buffer and clipping the sides is common (although seemingly hard-coded one way or the other for various scale modes), I went with this 240x240 -> 320x240 upscale.  At least the results are more crisp, now. :)

fceux.opk /w subpixel scaler (rename to fceux.opk in use)
« Last Edit: November 18, 2013, 04:35:50 pm by kuwanger »

segakiki

  • *
  • Posts: 88
Re: FCEUX 2.2.2
« Reply #18 on: November 18, 2013, 05:43:15 pm »
Thanks guys for your work! this emu is perfection for me!
Tried a few games and the sound is crisp and the new scaler looks great!

dmitry_smagin (OP)

  • *
  • Posts: 395
Re: FCEUX 2.2.2
« Reply #19 on: November 18, 2013, 05:51:21 pm »
Well, I figured out that it wasn't that the GUI is non-functional...it just externalized all the numbers/font. :)  So, after copying that over it all worked.  So, I decided to toy around with the fullscreen scaler.  It's a mixture of Scale2x and a smooth downscaler.  It's not really exactly what I want, but it looks a little better to me than the current fullscreen scaler.  Anyways, here it is.

fceux.opk /w different fullscreen scaler

PS - Thanks d_smagin.  I figured it might be something like that.

Edit - And here's another scaler that uses subpixel rendering based on cleartext type scaling.  Since FCEU actually uses a 256x240 screen buffer and clipping the sides is common (although seemingly hard-coded one way or the other for various scale modes), I went with this 240x240 -> 320x240 upscale.  At least the results are more crisp, now. :)

fceux.opk /w subpixel scaler (rename to fceux.opk in use)

Could you share your code, please? I'll integrate it into my sourcetree.
GCW-Zero prototype, Dingoo a320, Ritmix rzx-50, Dingoo a380, Xperia Play

kuwanger

Re: FCEUX 2.2.2
« Reply #20 on: November 18, 2013, 06:49:40 pm »
Code for the first scaler:

Code: [Select]
#define SX 256
#define SY 224
#define DX 320
#define DY 240

#define P(X) (palettetranslate[X])
#define COLORMIX16(A,B,C,D) (((P(A) >> 2) & 0x39E7) + ((P(B) >> 2) & 0x39E7) + ((P(C) >> 2) & 0x39E7) + ((P(D) >> 2) & 0x39E7))

void upscale_320x240(uint32 *dst, uint8 *src)
{
uint16 *buffer = (uint16 *) alloca(sizeof(uint16) * SX * SY * 2 * 2), *buf;
uint16 *dest = (uint16 *) dst;
uint8 *src_old;
int mix = 0;
int x,y;
int dx, dy;
int sx, sy;

uint16 color, a, b, c, d;

// Scale2x 256x224 -> 512x448
buf = buffer;
for (x = 0; x < SX; x++) {
color = P(*src++);
buf[0] = color;
buf[1] = color;
buf[SX*2] = color;
buf[SX*2+1] = color;
buf+=2;
}
for (y = 1; y < SY - 1; y++) {
color = P(*src++);
buf[0] = color;
buf[1] = color;
buf[SX*2] = color;
buf[SX*2+1] = color;
buf+=2;
for (x = 1; x < SX - 1; x++) {
a = P(src[-SX]); b = P(src[1]); c = P(src[-1]); d = P(src[SX]);
color = P(*src++);
buf[0]      = (c == a && c != d && a != b) ? a : color;
buf[1]      = (a == b && a != c && b != d) ? b : color;
buf[SX*2]   = (d == c && d != b && c != a) ? c : color;
buf[SX*2+1] = (b == d && b != a && d != c) ? d : color;
buf+=2;
}
color = P(*src++);
buf[0] = color;
buf[1] = color;
buf[SX*2] = color;
buf[SX*2+1] = color;
buf+=(2+SX*2);
}
for (x = 0; x < SX; x++) {
color = P(*src++);
buf[0] = color;
buf[1] = color;
buf[SX*2] = color;
buf[SX*2+1] = color;
buf+=2;
}

//Downscale to 320x240
dy = 0;
for(y = 0; y < DY; y++) {
dx = 0;
dy += (SY*2-1);
buf = buffer;
for(x = 0; x < DX; x++) {
color = COLORMIX16(buffer[0], buffer[1], buffer[SX*2], buffer[SX*2+1]);
*dest++ = color | ((color>>3) & 0x1803) | ((color>>4) & 0x60);
dx += (SX*2-1);
while (dx >= DX) {
dx -= DX;
buffer++;
}
}
buffer = buf;
while (dy >= DY) {
dy -= DY;
buffer += (SX*2);
}
}
}

Second scaler:

Code: [Select]
#define SX 256
#define SY 224
#define DX 320
#define DY 240

#define P(X) (palettetranslate[X])

void upscale_320x240(uint32 *dst, uint8 *src)
{
uint16 *dest = (uint16 *) dst, a, b, c;
uint8 *src_old;
int x,y;
int dy;
dy = 0;
src -= 8*SX;
for(y = 0; y < DY; y++) {
dy += SY;
src_old = src;
src += 8;
for(x = 0; x < (SX-16)/3; x++) {
a = P(*src++); b = P(*src++); c = P(*src++);
*dest++ = a;
*dest++ = (a & 0xf800) | (b & 0x07ff);
*dest++ = (b & 0xffe0) | (c & 0x001f);
*dest++ = c;
}
src += 8;
}
}
« Last Edit: November 18, 2013, 06:54:26 pm by kuwanger »

lithium210

  • *
  • Posts: 31
Re: FCEUX 2.2.2
« Reply #21 on: November 18, 2013, 08:04:33 pm »
Huge difference in sound and scaler is looking great.  Been waiting on an update for this emu and here it is! Appreciate the work and thanks a lot!!

opt2not

  • *
  • Posts: 143
Re: FCEUX 2.2.2
« Reply #22 on: November 20, 2013, 05:50:07 pm »
I haven't been able to get the first scaler version to load up any ROMS for me, but the second one with the sub-pixel scaling works like a charm!
Looks great and sounds great! Thank you so much for your work on this Kuwanger!

Gab1975

  • ***
  • Posts: 1165
Re: FCEUX 2.2.2
« Reply #23 on: November 20, 2013, 10:28:11 pm »
Thanks! The improvements are very nice! ;)
I noticed that games like Duck Hunt are unplayable, the "ideal" could be a virtual gun sight which simulates the light gun, but I know this is no easy to add inside the code...

zear

  • * Moderator
  • Posts: 2378
Re: FCEUX 2.2.2
« Reply #24 on: November 21, 2013, 10:48:50 am »
Thanks! The improvements are very nice! ;)
I noticed that games like Duck Hunt are unplayable, the "ideal" could be a virtual gun sight which simulates the light gun, but I know this is no easy to add inside the code...
Well, we have no touchscreen to make lightgun games useful.

Vato

  • *
  • Posts: 71
Re: FCEUX 2.2.2
« Reply #25 on: November 21, 2013, 01:25:32 pm »
Thanks! The improvements are very nice! ;)
I noticed that games like Duck Hunt are unplayable, the "ideal" could be a virtual gun sight which simulates the light gun, but I know this is no easy to add inside the code...
Well, we have no touchscreen to make lightgun games useful.

maybe the lightgun could be set to use the analog?

Ive played some DuckHunt on nesDS, and using the touch screen actually makes the game waaaay too easy, lol.

Gab1975

  • ***
  • Posts: 1165
Re: FCEUX 2.2.2
« Reply #26 on: November 21, 2013, 02:19:11 pm »

maybe the lightgun could be set to use the analog?

Ive played some DuckHunt on nesDS, and using the touch screen actually makes the game waaaay too easy, lol.

I think that it isn't so easy... with the touch screen is possible to simulate the light-sensor input, while to use the analog stick and/or the d-pad, as virtual gunsight, is needed an heavy implementation/change to the code...

Nebuleon

  • Guest
Re: FCEUX 2.2.2
« Reply #27 on: November 21, 2013, 07:55:45 pm »

maybe the lightgun could be set to use the analog?

Ive played some DuckHunt on nesDS, and using the touch screen actually makes the game waaaay too easy, lol.

I think that it isn't so easy... with the touch screen is possible to simulate the light-sensor input, while to use the analog stick and/or the d-pad, as virtual gunsight, is needed an heavy implementation/change to the code...
Not to mention that inputting an absolute position on a screen, as opposed to a slow or fast movement, with an analog stick is very awkward ;)

trisoret

  • *
  • Posts: 27
Re: FCEUX 2.2.2
« Reply #28 on: November 28, 2013, 05:46:33 am »
Question though, are the controls remappable? I prefer to remap B/A to X/B whenever possible, not just because the A button on my GCW Zero is unresponsive.

I like to play with that button mapping too. You can change to that by editing the config file in /.fceux

Code: [Select]
SDL.Input.GamePad.0A = 308
SDL.Input.GamePad.0B = 304

I tried that and the emulator would just crash every time I launch a game, then I tried editing the .cfg of each game using the mentioned settings, nothing would change, any help?

133794m3r

Re: FCEUX 2.2.2
« Reply #29 on: November 28, 2013, 06:14:46 pm »
Why is there no option to set "default" folder to look for games? It currently just throws that away after each and every load of the emulator. It should at the very least save it's last folder, or even better say "hey would you like to make this default?"

 

Post a new topic