Jump to content

Tux

Emulator Author
  • Content Count

    434
  • Joined

  • Last visited

  • Days Won

    69

Everything posted by Tux

  1. Just restored the scripts to handle the 2 binaries + the dlls for versions >= 0.90, it's mainly for the old versions page, but the latest page (main download page) is handled by them now again. Next time : the linux binary, oh yeah... (well maybe then, but no hurry !).
  2. Ok, thanks for the info about the saveram. The file is not directly readable if I remember correctly, something about words accessed strangely, but it's good to know. Notice that if you are right, then this info can be lost very easily, it's enough to play a few neogeo games until your kof99 becomes the oldest and it's then overwritten. If you have a .hi file then you have a hiscore.dat, and an old one, the latest one (2.11) doesn't have any info about kof99, and normally it should be enough to make it survive a region switch. edit : after checking in the code, 8 games only fit on the memo
  3. Hola, big mess here. The hiscore support is mainly for games which don't save anthing anywhere, it's done at the emu level and is not in the hardware at all, and it saves only hiscores of course. Now the neogeo hardware has a memory card (where it saves the progression, but I don't think scores are saved here), and a permanent ram area, called "save ram", shared by all neogeo games (64 Ko), the bios allocates automatically slots for games here, when it's full the oldest one gets overwritten. I don't know exactly where the scores are saved actually... Some arcade games like cps1/cps2 also hav
  4. I took a while longer to look into this : the fact is that some time in the past, we had some hiscore support for some of these games, actually I think I edited the hiscore.dat myself to have these scores for the neocd games, but it should work also for most of the neogeo ones (not all of them, some have a different memory map). Anyway if you add back this data in the hiscore;dat, it will save you from the eeprom erased, because the hiscores will be reloaded after the game has rebooted (I just tested it with kof96, and it works - I edited the hiscores directly in ram, made sure they were
  5. Ah ah, yeah well still thinking about fixing this page for now taking a little break ! Raine takes a lot more care about the hiscores than most emus I am sure, I have some code in place to survive a reset (f1 key), and even survive loading a save state, but I guess maybe I missed this one, if the bios reads its eeprom and overwrites the hiscores from the eeprom content, this time the scores are lost, yeah ! If you don't have a backup, the scores are lost. The error message in the old version is "normal", there were lots of bugs related to cheats fixed, if you go back, you hit them again.
  6. ... and uploaded 0.91.4, aka the return of emudx ! the bug fixes are generic but it's really mainly for emudx, not sure they could be triggered elsewhere... on the todo list : - update the linux build, but it won't be on debian this time, it will be arch, and since I never made any arch package it takes time to find the motivation... it shouldn't be hard anyway, it seems to be easier than for debian ! (and the result is a tar.xz, so other distribs can extract it directly and try to run the binary, it should work on most distribs this way). - the old versions page is stuck on
  7. Ok, I confirm there is a crash, specific to windows again... sigh, sometimes I wonder why I still try to make this work in windows... ah yes , because most people keep on using it ! Ok, I'll look into it later... edit : it's fixed, both problems, the crash was because this version of sdl-1.2 in windows doesn't behave like the one used in 0.64.16, I guess a patch has probably been lost somewhere, but it's easy to workaround the bug. Then the broken ratio is because of a very old bug in the way the geometry of the screen to display is decided.By the way if you wonder what Mike DX and h
  8. Oh well, search that in a search engine, there are some pages about this weird code, but at this point, it's your system... if you unpacked the raine package to a directory, then the dlls in the same directory and then launched from there and got this error, then you should check your system, read the pages about that. Hint : raine doesn't use any visual c++ redist files, nor microsoft .net, so you don't have to check that ! Good luck !
  9. Thanks for the info, yeah hopefully these shouldn't affect me here ! They were quite crazy to choose something like that, I don't like utf8, but compared to this it's paradise !
  10. Ok, I'll start by what took me the biggest amount of time, even if it's very specific, the unicode filenames in windows ! So to see the problem you need some non-standard characters in a folder or filename, it's easier if it's on a folder containing some neocd game. I visited the wikipedia page about "the king of fighters", and got the japanese name of the game from there : (ザ・キング・オブ・ファイターズ 京). So just copy and paste this at the end of the name of such a directory. Then run any previous version of raine : the directory will be impossible to find ! It might be possible to do that with just
  11. Tux

    EmulationStation

    Sigh. It's used like this : raine -geometry 800x600+10+10 -n 1944 (for a 800x600 window placed at 10,10) As I already said, passing a zip, or a 7z is to read neocd games, not standard roms, this message makes sense in neocd only ! I added a few command line options, -rp to set the 1st rom path assuming you never ever use the gui to do that, which is rather weird, -nb to have no border, and -wb to have a normal window with border, useful since -geometry removes the border (better like that when you want to place precisely a gaming area on a tv where the borders of the i
  12. There is a problem with windows that I discovered lately, but usually it doesn't happen with a simple character such as ' but you never know with them... The trick is that when you have a character which can't be represented with an 8-bits representation, then you must access it with some utf16 representation specific to windows only and absolutely not portable. On the other hand such characters are usually represented as utf8 in other OSes, but it's just impossible in windows, no utf8 support (or almost none, there is a very basic one for the console only, but nothing internal). So.
  13. Tux

    EmulationStation

    Probably because you passed a zip file on the command line, so it assumed it was a zip containing files for a neocd game, ipl.txt being the main one if it doesn't find it, it stops here. You are going to have to learn at least the basic, I can't answer all the basic questions !
  14. Tux

    EmulationStation

    Yeah yuv overlays are disabled in 64 bits because the color conversion is done in mmx asm, very fast, but 32 bits only. You can also try the windowed mode. -fs 0 with -geometry. Reminds me that I should add a command line option for "no border"...
  15. Tux

    EmulationStation

    -g is optional but is not followed by a path, but by a game name. If the game is the last parameter then you can forget -g A path is used only when passing a neocd cue or iso file. Now you are out of luck there seems to be a bug with opengl when using -n Meanwhile you can use -video 1 which is working with -n, or wait, but I don't plan to fix it just now, sorry, or try to patch it yourself... !
  16. Ok, reuploaded the 0.91.2 windows binaries just for this fix, it's the only thing changed inside, not worth increasing the version number, but worth releasing it anyway. Make sure your browser cache is cleared (by restarting it since last time you downloaded it, it should be enough), and download it again, it should be ok this time.
  17. Yeah it's not a font problem, at least I don't think so, it happens only in windows, encoding problem probably but not obvious. I avoid the french version and use the english one, but I guess I should look into it... Ok, it's "fixed", that is, apparently windows doesn't support any utf8, I am so used that mingw brings compatibility with linux that I didn't notice, they convert utf8 strings to latin1 so that they can be displayed by this nonsense of an os ! So I just removed utf8 support for windows, and it fixes this bug ! Windows is just too stupid, ad-ridden and barely us
  18. Tux

    EmulationStation

    yeah and you can even use raine -h to get the command line options (assuming you have a real terminal, not cmd.exe). If you have cmd.exe then do something like raine -h > log.txt and look inside log.txt then !
  19. Tux

    EmulationStation

    Wrong forum, you should post to emulationstation, I don't know this frontend... Or you could try raine directly eventually !
  20. well normally there is no directory in the cue file, all the files are supposed to be in the same directory. And I just checked by renaming my kof95 to "kof '95", and it still works flawlessly... Anyway glad that it works for you now !
  21. The dlls package above the binaries for versions >= 0.90 maybe ?
  22. No idea ? There are messages everywhere to help against syntax errors in the cue files, but it doesn't complain if it can't find a file. So maybe try without the cue file, move it out of the dir or rename it, then select the iso in raine, if it suddenly works it means to really have a problem with this cue file ! Here is the beginning of my cue file for kof95, notice that in my case I re-encoded the wav files to ogg before deleting them which takes a lot less space, without touching anything in the cue file, raine knows how to look for many type of audio tracks. Anyway the cue file looks
  23. And 0.91.2 is posted : - the cheats about the audio cpu didn't work, it's fixed. - Another fix for some scripts which were incorrectly identified as "Set" scripts, like for mslug "Hit Anywhere" (it has an "off" part, and so these cheats didn't work, executing only their "Off" part when you tried to activate them). - and the gui bug which wasn't showing an updated joystick control for some inputs It's a small update compared to 0.91.1, maybe the last for this 0.91 version ?
  24. Yeah dependent on blend files, and it's normal the blend files just affect some transparency to some sprites, if the sprites are used more than once you run this kind of risk, and it's clearly the case here.
  25. Are u sure there's something wrong ? Maybe it's just a way to make sure the subtitles stay readable even with a white background ! It's not the blend files, they add transparency for some sprites, that's all, they wouldn't hide anything. Hum, there is a slight change in the intro when disabling the blend files, you can just rename the directory to do that fast, or there is an option in the gui to disable them. I am not convinced your save states show a real bug though... By the way did you know save states are also dependent on the bios used apparently ? Using the universal bios
×
×
  • Create New...