The Windows updater is dead - moving to bundled Windows builds

RetroArch General
#10

Forgot about those, ye. :V EDIT: Snuck in the ini files into the zip :3

About joyconfig. Did anyone actually read the README?


=======
Input
=======

If you have an xinput-supported gamepad, you should not need to configure input at all. It should work as expected.
If you want to configure input for obscure systems which don't map well to the RetroPad,
it is recommended you create an autoconfig for your device.

    retroarch-joyconfig.exe -a autoconfig/yourpad.cfg

Follow the instructions on-screen.
You can also configure input directly and update retroarch.cfg, but this is not recommended.

   retroarch-joyconfig.exe -i retroarch.cfg -o retroarch.cfg

To configure some of the most relevant hotkeys (save state/load state/RGUI menu toggle), add --misc.
If you don't want to configure certain binds, there is no way to "skip" a config. A workaround for this is to use the --timeout option.
See retroarch-joyconfig.exe --help for more information.
#11

Sure did. Got all the hotkeys configured on my Xbox 360 controller using the right command switches. Dead easy once you get the hang of it (not used to CLI to be honest), but I’m acclimating to it and what commands need to be used, etc. :stuck_out_tongue:

Typed in : C:RetroArch\retroarch-joyconfig -m -t 10 -o C:\RetroArch\configs ame.cfg then copied and pasted the output to the appropriate file. Works perfectly :smiley:

Edit: For some reason the fast forward key never takes effect even after mapping it…WTF?

#12

I’m going to miss the updater. How often will the megapacks be updated with new cores?

#13

Dang, the fast forward key never works despite being mapped to the 360 controller :confused:

#14

hello

i’m french user and i’m talking about retroarch on board french . http://forum.shmup.com/viewtopic.php?f=7&t=17720

phoenix is a good gui , and now retroarch is not user friendly :frowning: specially for input gamepad …

I keep phoenix with a newbuild for configuration input pad because the “retroarch-joyconfig” is not practice … L3 an R3 not supported my gamepad … (hori fighting pad) i don’t understand how to configure for each system (genesis,snes, …)

On my PC , i use several folder retroarch for each system because it is really convenient :slight_smile:

We need two interface or configure the input in the R-GUI (two interface is better). thank you for the work accomplished and sorry for my bad english .

#15

I’m sick of Phoenix. It needs to die. Yes, we’re in a transition phase where some functionality is missing from RGUI (joypad config is the big thing here). Please give it time.

#16

i understand , I don’t pressed . thanks for explication :slight_smile:

#17

As far as I know, dosbox does not work in Win64. Mednafen GBA does not work at all.

They shouldn’t be included.

#18

The next megapack should include MAME 0.150 and Picodrive. Those are harder to compile; I can’t do either with the portable mingw64 from the dev board.

#19

For those wanting to play on the bleeding edge, here are my compiles of MAME 0.150 and Picodrive, these are Win 7 x64, and please don’t ask for Win32 builds: http://www.filefactory.com/file/o13mqahlz11/n/mame_libretro.dll http://www.filefactory.com/file/2lybvx489319/n/picodrive_retro.dll

#20

Great news. Great decision to let Phoenix die :cool:

#21

Those should be added and/or fixed in libretro-super then.

#22

Awakened , i build mame for win64 with the last toolschain released by maister and it works fine. but be sure to have python2 installed and in the path else build will failed. i use this one http://www.python.org/ftp/python/2.7.5/python-2.7.5.amd64.msi

After with the maister toolchain , launch gitbash.vbs export PATH=$PATH:/C/Python27 (if you choose default install) and then go the mame2013_libretro/0150/ and just do a : make -f Makefile.libretro “PTR64=1” -j4

#23

Thanks for the instructions. I’ll see if I can get that working with a portable version of Python since I don’t like installing things I’m probably only going to use a few times.

Edit: Tried a portable version and the one from your link. Couldn’t get it to compile with either. Seemed like it was failing at the part that needed Python even though I defined the path it was installed in properly.

I can just use hunterk’s builds though.

#24

I’m sure there is a good reason for everything but as an end user I didn’t see what was so bad about Phoenix, I never had input issues at all with my Logitech f310 controller which is xinput compatible and honestly if you have a folder full of hundreds of roms like I do, it’s ALOT faster to quickly change cores and load a game from within windows with a mouse than scrolling through hundreds of titles with RGUI on my controller. I’ve just always preferred launchers to in-program GUIs unless they serve a purpose like hyperspin or Mala for showing artwork and preview videos. Anyway just my 2 cents.

#25

@Awakened ! i remember now , square change makefile to point python2 (because it’s python 2 script) so i had to copy python.exe to python2.exe for building works !

#26

Both mednafen_gba_libretro.dll and vba_next_libretro.dll don’t really work properly in the pack you provided (Win7, x64 version used).

Mednafen GBA core just crashes the emulator on ROM load, VBA Next has terrible graphic glitches in the tiled graphics.

Please let me know if you need more detailed information, disregard this message if this is a known issue.

#27

Yes, I know there are several cores which are basically broken and very WIP on Windows. As I said, I included the dlls which built successfully, nothing more, nothing less. I don’t test every single core before I release a zip or anything. Anyone is free to repack the zip with more up-to-date libretro cores and stuff.

VBA Next tiled rendering should be fixed on Git I think (thanks to OV2).

#28

VBA Next tiled rendering being bugged was a Win32-ism that didn’t occur on any Unix/BSD-based platform (including things like PS3 and Wii).

Anyway, I can confirm that it also fixed the same issues on Xbox 1/360 as well (both Win32 boxes in disguise).

#29

With that I was able to get the core to compile using portable Python :smiley: