Did I say he should buy it? Did I? Because I don't remember saying that. In fact, I didn't say that. No comment on the Vista thing, but only because any arguments I give will be drowned out by a flood of bullshit about how Vista is full of useless bloat that you obviously can't turn off, and was totally not included in Windows XP, the amazing, glitch-less, ultra fast and super stable operating system that has only crashed once since release and that was due to a USB cable being pulled out while the planets were aligned causing a one-in-a-million failure to occur within the bowels of your perfect operating system. But this is a thread about Gens/GS, and not an operating system war thread.
Wow, all these complaints over me saying I don't support Vista. Maybe I should add an artificial version lock to Gens/GS that prevents it from running on Vista at all. (Of course, Gens/GS is open-source, so that could be removed rather easily, but how many Windows users have a clue how to compile source code?)
Keep the Vista nonsense out of this thread, even if Gerbil wanted to support it he doesn't have Vista to test it on.
Fixed for m5.2. The command line parser was only checking for absolute paths using Unix conventions (I.e. pathname starts with '/'). I fixed it so the Windows build will check for Win32 absolute paths (e.g. starts with "C:\" [or another drive letter] or "\\" [UNC path]).
Awesome, thanks for fixing it dude. And yeah, I was referring to the Windows version - sorry for not making it clearer to begin with.
My joypad inputs are scrambled. I've got a Logitech Dual-Action and a RetroPad hooked up and I have the RetroPad configured as a three-button gamepad (port 1). Left is A or B or C (I only have Sonic games) right is down, down is start, C (button 3) is either correct or A or B, and the rest of the buttons do nothing. If I reconfigure to use the Logitech, it works fine.
Milestone 5.2 version bump, with improved 32-bit color performance! Dr. Kylstien: I'm not sure why that would happen. I don't have a RetroPad, so I can't test that myself.
Code (Text): gens_core/misc/cpuflags.c: In function ‘getCPUFlags’: gens_core/misc/cpuflags.c:76: error: PIC register ‘ebx’ clobbered in ‘asm’ gens_core/misc/cpuflags.c:116: error: PIC register ‘ebx’ clobbered in ‘asm’ gens_core/misc/cpuflags.c:145: error: PIC register ‘ebx’ clobbered in ‘asm’ —I'm stupid—enable-x86-asm=false solves this problem, but that's not an ideal solution. (I could remove the clobber declarations, but for the very first one it's complaining about, does look to me like ebx wouldn't get restored.) There are a bunch of places where you #include <gdk/gdkx.h>, but the only place you use a GDK function is in v_draw_sdl.cpp. I would suggest removing this unused include if possible. Code (Text): gens_core/vdp/vdp_rend.asm:1837: error: short jump is out of range gens_core/vdp/vdp_rend.asm:1861: error: short jump is out of range gens_core/vdp/vdp_rend.asm:2005: error: short jump is out of range gens_core/vdp/vdp_rend.asm:2008: error: short jump is out of range gens_core/vdp/vdp_rend.asm:2014: error: short jump is out of range gens_core/vdp/vdp_rend.asm:2017: error: short jump is out of range gens_core/vdp/vdp_rend.asm:2052: error: phase error detected at end of assembly. Does your NASM automatically fix that or something? Because mine doesn't. Some of the lines it's erroring on aren't jumps at all, but actually declared macros, so I'm not sure how well I'd be able to figure this out.
All of my controllers are standard USB HIDs. These are the gamepads I have, as they appear in the Windows "Game Controllers" applet: "Logitech Dual Action" "Retr" (NES) "Retr" (MasterSystem) I tested some different combination of controllers plugged in and configured: Logitech = fine NES = fine Logitech (configured) + NES = fine Logitech + NES (configured) = C is B, Down is Start, Left is C, Right is Down, others do not work Logitech + MasterSystem = Up is B, Down is C, Right is Down, others do not work. (Start and A have been assigned to the keyboard, and work fine.) NES (configured) + MasterSystem = fine NES + MasterSystem (configured) = Up is B, Down is C, Right is Down, others do not work. (Start and A have been assigned to the keyboard, and work fine.) Logitech (configured) + NES + MasterSystem = fine Logitech + NES (configured) + MasterSystem = C is B, Down is Start, Left is C, Right is Down, others do not work Logitech + NES + MasterSystem (configured) = Up is B, Down is C, Right is Down, others do not work. (Start and A have been assigned to the keyboard, and work fine.) Bindings (on Genesis player 1): Logitech: +X = right, -X = left, +Y = down, -Y= up, button 1 = A, button 2 = B, button 3 = C, button 10 = Start NES = +X = right, -X = left, +Y = down, -Y= up, button 1 = B , button 2 = A , button 3 = C, button 4 = Start MasterSystem = +X = right, -X = left, +Y = down, -Y= up, Keyboard [Z] = A, button 1 = B, button 2 = C, Keyboard [ENTER] = Start It appears that in order to work the controller must be first in the Windows Game Controller settings list. This does not affect DebuGens.
You're compiling it as PIC. I didn't compile as PIC, so I didn't notice this. I'll fix it and release an m5.3. Will fix this in m5.3 too. I'm guessing this is because I enabled super-optimizations in nasm on everything instead of just starscream. I'll change it back to the m5.1 behavior.
Milestone 5.3 version bump, which fixes PIC compilation and the other problems mentioned by sonicblur. sonicblur: I've noticed that some versions of nasm segfault if the "-g" (debugging information) flag is specified. The configure script currently always specifies "-g", so if nasm ends up segfaulting, try upgrading. I'm using nasm 2.05.1, and it works fine. (My Ubuntu 8.04 VM has nasm 0.99.06, which segfaults with "-g".)
So I've received a request by some people to discontinue Gens/GS and work on modifying Kega Fusion instead. Discuss.
Keep on working on Gens/GS. Kega is closed source anyway. Besides, I like an emulator with shitloads of features that can go fullscreen without a BSoD. :P
If you could get the source code for Kega Fusion and make it multi-platform, then that would be awesome. But seeing as Steve Snake keeps Kega Fusion closed source (which is his choice after all, since he wrote it all), it would be far better to continue with Gens/GS. I am very anxious to see where this project will go (and see if Mac Users can finally get a good emulator that runs Mega CD and 32X games). The improvements already look impressive (just from reading; I can't test it at the moment) and I am eager to see more. On a side note (and probably offtopic slightly), can anyone help me with GTK+ installation on OS X? If so, please PM me.
I think it would benefit others if this was public knowledge. Code (Text): Here's an easy quick guide to compiling Gens GS for OS X: (X11 GTK version) 1. Download and install XCode from developer.apple.com. It comes with GCC and the other tools you need to compile things. 1a. Install X11 if it's not already installed. It's installed by default in Leopard. You can also get it here: http://xquartz.macosforge.org/ 2. Download and install port from macports.org 3. Download Gens GS, extract the source somewhere 3a. Learn how to use the unix command prompt 4. Open the Terminal, navigate to the directory you extracted GensGS source code to. 5. Do: 'sudo su' from the terminal, enter your password. This switches you into the root account so you can install shit. 6. Do: 'port install gtk2' 7. Do: 'port install libsdl' 8. Do: 'port install libsdl_mixer' ... I think that's all you need. If I'm missing something, PM me and I'll update this guide. 9. Do: './configure —enable-cdrom=false' 10. Do: 'make' The binary is located in src/gens. You can launch it from the terminal with './gens' from inside X11. If you'd like an .App that you can double click on, download the binary release I posted a few pages ago. Right click on the App->Show package contents. In Contents/MacOS/ you'll find a gens binary. Replace it with the one you built. Optional installs that may help: port install autoconf port install automake Hope this helps. Sorry for cluttering your thread Gerbil. :-P (To compile GTK without X11 required, which I don't recommend at this time, add +no_x11 +quartz to the port install gtk2 command. When you build Gens GS, comment out the lines of code it errors on. There should only be 2. The controller config window, and 32x emulation won't work if you build without X11.)
That helps quite a bit, seeing as I was trying to install GTK+ native through jhbuild and failing miserably. GTK+ through X11 is installing itself as I type this. It seems the native GTK+ port still has a long way to go before it's more usable. Thank you sonicblur for leading me to a simpler and less buggy way of installing GTK+. Now I can begin testing Gens/GS...
