Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Tux

Emulator Author
  • Content Count

    375
  • Joined

  • Last visited

  • Days Won

    60

Everything posted by Tux

  1. To be more precise, you actually loose a lot of things if doing that, assuming you succeed : the gui is linked to the graphics engine used by raine, so you loose the opengl driver, and yuv overlays, you keep only the normal blits, what made the dos days. Also even if I admit the old gui was nicer, the new one has a lot of advantages : - it's usable with a joystick only (or a gamepad) a keyboard or of course a mouse, for the old one you mainly needed a mouse although you could succeed to use it with a keyboard by tracking the keyboard shortcuts, not easy but possible, but impossible to use with a joystick only - it's incredibly easier to program, that was my main concern while making it, I wanted something where it's easy to add new dialogs and to update them. There are no coordinates in the new one making everything a lot easier. - it adapts to any resolution using the ttf fonts. The old one was made for a low resolution, but only for a low resolution, if using a high resolution it becomes really small which can create readability problems Also you of course loose all the new dialogs which were created for the new gui only, all these options for negeo/neocd and so on, you loose sdl_sound, so no music for the neocd games. That's about it, but that's quite huge !
  2. Oh, so you would want a windows binary but using the old allegro gui ?!! Well, there is a define in the makefile for SDL, there is SDL = 1 in each section (mingw32, linux...), so comment the one for you for mingw32 and it *should* try to use the allegro gui. In this case you should also comment out HAS_CONSOLE, because it can't build the console in allegro, which means you will loose all the modern cheats, you'll need the old cheat.cfg file. If you use allegro you should use allegro 4.x, allegro is famous to be incompatible between its versions and I strongly doubt you could compile a working version of raine with allegro 5, never tried it, but I am sure it's full of incompatibilities. (and I don't even want to hear about bugs in allegro 5 !) Good luck, you can post about your success here ! Notice that you can do this integer scaling by hand in raine by editing raine.cfg (raine32_sdl.cfg for the windows sdl version) and setting yourself the screen_x and screen_y, that's if you want a precise scaling while still using opengl. Otherwise you can use the "normal blits", then in renderer option choose a scaler (hq2x/3x or scale2x/3x and then in set video mode change to either game resolution, or 2x game resolution. I didn't put 3x here, that's mainly because it's rare in most configs to have a mode matching 3x the game resolution, but it could easily be added. After testing this myself, I find that modern video cards have such good scalers that it's mostly useless to stick to integer scaling for most games at least. That's my taste at least, but of course it should theoretically be better if using integer scaling, even if it's not obvious usually ! (especially if combined with a shader which improves the image quality)
  3. There were quite a few dos binaries released since then. Of course you can compile one yourself if you want, you just need to be patient because afaik djgpp was never integrated in any visual something from microsoft (surprise, surprise !), so you need to get it + all the libs, there are less libs for dos than for linux & windows of course, it does less things too. I cross compile it from linux, there are a few howtos on the web on how to crosscompile for dos from linux, and there is probably something for windows too... I am not sure the famous 3x modes were released as a binary so I can make a new binary for that if you want, I had planned to test this first on a real hardware, but since the old pc here has lost its hard disk, it's much harder than what I had anticipated and I had to give up on this. At least it works when run in a virtual machine ! Nice custom video modes by the way, it's a windows driver which allows to define some modes like this one, or you did it differently ? I did that too in linux back in the day, but since 0.50 it's more about stretching the screens in opengl, it's not the same, but it's not bad too (and you get the shaders too !).
  4. Tux

    Raine 0.91.9

    Sorry went too fast to make the binaries, forgot to update the version number for the 64 bits, but if you have the 0.91.10 archive with the exe inside dated october 26th, then you have the right one. I can't tell you about hawk and animal because I don't know the game, but testing with hulk hogan as player 1 (I can recognize him at least !), and animal as player 2 works. I'll try to re-upload the 64 bits exe later, but as I said, it's the right one, just a problem with the version number. (with hh and animal the cheats produce this : poke 1c0607, 0 poke 1c0713, 5 where before they produced poke 1c0607, 5 poke 1c0713, 5 So for me the problem is fixed, now having these chars in the selection is still a hack and so I can't be sure everything works as expected). edit: reuploaded, I didn't bother to change the filename of the archive.
  5. Yes it means the driver has a problem, rubyTexture is the base of this shader, it contains the game bitmap, it's sent for all the frames. I don't get any warning about rubyTexture with my nvidia, so there is definitely something wrong with the way the shader is interpreted by your video driver. 2 choices : just ignore the shaders, you can live without them after all, or find a better video driver... ! And the reason you don't see the message on screen is because it's said it's a warning, the validation succeeds in the end, but if it misses rubyTexture, it misses the main point, the crash could very well be a divide by 0 at this point !
  6. Well it's worth trying a driver update, it shouldn't crash normally even if the video card can't handle it if the driver is well done it just returns an error message which is displayed by raine. 2nd solution : it just doesn't work, doing nothing noticeable on screen. 3rd : yours, never seen before, it crashes -> something is probably wrong somewhere, try to update your driver.
  7. Tux

    Raine 0.91.9

    The mails are not rejected, they go to spam. It's very hard to make them accepted nowdays yeah, but the bright side is that almost no spam goes through. Ok don't worry too much, he didn't describe very well what happened, and didn't come back so you can't do too much about it, but thanks for trying !
  8. That's a good one... You forgot the video card ? I never saw shaders crashing the program so far, usually it works or it doesn't that's all, it's a 1st time here. Well it works here of course, but it's very likely something related to your video card. I'll check later in windows, but since it works in linux here it should also in windows. Also you can try to run the emu from the command line and redirect the output, like this : raine > log when it has closed because of your shader check the log file to see if there is something interesting in it, at the end. edit : yeah no problem for me in windows fullscreen with the crt shader, as expected.
  9. Tux

    A dos version in 2020... !

    Finally I can't test this on real hardware for now, the old computer doesn't have any hard disk anymore and it seems I don't have any working ata hard disk anymore neither ! So game over here, oh well it should work at least, even if it's useful only for these very wide games.
  10. Tux

    Raine 0.91.9

    And the linux binaries are updated, I had forgotten that I had done a nice little script which does everything for me for that, you just launch it from the 32 bits or 64 bits directory, give it the version number you want, and it does all the rest (get the sources from git, compile, update the sha256sum and the version number in the PKGBUILD, upload the binary package and the PKGBUILD file, and finally update the html page !), so it's quite fast to do it finally !
  11. Tux

    Raine 0.91.9

    No problem, I understood you were pissed by the technical pb in the forum, it's ok !
  12. Tux

    Raine 0.91.9

    ok 0.91.10 released with these fixes for windows, I'll try a linux binary tomorrow
  13. Tux

    Raine 0.91.9

    Ah I found the forum was very quiet lately, so it was because of a technical error ?!!! Sorry to learn that... Oh well no wonder there are still things to fix about all these shiny new cheats, too much to test, I'll have a look, but I don't know when, it shouldn't take 10 days though ! ok bug confirmed, I hadn't thought about multiple scripts using a choice from a list like that running at the same time, I'll have to find something, it will take a little time... edit again : it's fixed, I'll have to make a new binary for that, and maybe a linux binary too, the biggest change since 0.91.9 except this one is for linux to be able to run its asm code with the recent change which makes the stack not executable by default. Oh well, not an ideal setup to make a binary right now, it will wait until tomorrow. Thanks for the bug report at least !
  14. Tux

    A dos version in 2020... !

    Yeah I plan to do that too when I get access again to an old 1Ghz pc I have, but for now it's quite far, it will be later. I plan to test with univbe too to check if there are some modes where triple buffer can be enabled, for now the only mode which can work for sure is mode-x 256x240, I am almost sure it's possible in vesa, but maybe univbe is required and I can't test this in an emulator...
  15. I don't know launchbox, what I can say : if you pass the rom file on the command line, it will be seen as a zip file for neocd, which you don't want here. The correct way is to pass the game name on the command line, not the zip file. for aes/mvs, notice you can switch most neogeo games between the 2 if you use something like the unibios, there is a shortcut when you boot the game to decide if you want to boot it in aes or mvs, but anyway... !
  16. This was a hack for version 0.28 but which was not fully understood at the time and which was totally forgotten for all this time, it allows to switch to a given video mode and then make it to display only 1/3 of its lines on screen, excellent for extra wide games like darius. These modes were impossible to select since the vesa modes display only the supported video modes now, and they are not directly supported, it's like a virtual video mode, you need to switch first to a mode with 3x the number of lines you want for it to work... ! So... ! I found this by looking in the code how the triple buffer worked in dos, and found this instead. So I added them back, but I had some trouble to test of course, I wanted to wait until I have access to an old pc to test this on a real screen, but I don't have it available right now. Well I just found that dosemu in linux emulates this perfectly, here is a screenshot : And ingame : Oh yeah cut a part of the title bar on this one, testing a new screenshot tool... Anyway it works great, and it would work on any pc able to switch to 1024x768, so all normal pcs then ! I just added the 3 most standard modes at the end of the list of the standard supported modes, they appear with a "dark " prefix in the list, and are used automatically when loading a game if "auto mode change" is selected, and it's the default. (these standard modes being 640x160, 800x200, and 1024x256, used here by darius). Quite amazing to see such a come back !
  17. Tux

    Graphical Glitch

    There is a post elsewhere in the forum about that, apparently the issue was fixed by a driver update, look for the post for details, it shouldn't be too hard to find there was a picture posted...
  18. Tux

    A dos version in 2020... !

    And finally some "dark modes" as they are called, I added some because I was curious to see if worked in the virtual machine : it doesn't ! I added the 3 most "standard" ones, 640x160 (which uses 640x480), 800x200 (for 800x600), and 1024x256 (for 1024x768), the 3 appear with a prefix "dark " in the list of vesa modes if you already have the corresponding standard vesa mode. For me the screen is changed indeed I see only the upper half of it, so it's not usable, but it was worth testing. I'll leave it for others to test eventually, trying to load darius in there with "auto mode change" selected automatically takes 1024x256. I suppose that when it works the modes are darkened because of the video hacks used to display them. For me it's stretched but not dark... too bad !
  19. Tux

    A dos version in 2020... !

    About the crash when out of memory : it's because of a swap problem with djgpp/cwsdpmi, for some reason it should swap when going over the physical memory, but instead of that it crashes, no idea why, it's specific to djgpp. I investigated about that using the virtual machine, crashes just mean to restart it here, so it's quite quick to test. If you are interested, there is a workaround : download the cwsdpmi distribution from there : http://sandmann.dotster.com/cwsdpmi/ then run cwsparam in the same directory as cwsdpmi, and when it asks for the swap file, type "" to disable it (really the double quotes, not just return). Then when it quits, copy the cwsdpmi.exe to the raine directory, and now you should get a nice error message instead of a crash. I remember seeing djgpp swapping a very long time ago, so it worked at a time, no idea why here it doesn't work, but anyway you really don't want any swap with raine, very very bad idea !
  20. For me at least, the data segment suddenly stopped being executable, which crashed all the asm in raine. That's with the latest binutils update, 2.35, it's very likely related even if I didn't find any info about it. You won't see any problem as long as you don't recompile the code with a linker from this 2.35 binutils release, so the released binaries will be ok. For the new ones, I just committed a patch to git, it was easier to make than what I had feared, just call mprotect on the data segment of 1 of these functions, and since all the asm functions are grouped in the same segment by the linker, there is just 1 mprotect call to make. It's very linux specific, but afaik no other os did that, except osx, but I don't care about osx anymore, and this patching wouldn't work in osx (unless they have /proc/pid/mappings, which I doubt !). It took me a big part of the day to find this, I just wanted to test something else this morning and stumbled on this... it was a bad day starting ! Anyway, back to normal now ! Oh, by the way this new linker also emits some warnings about relocations, but they are just harmless warnings, so they will stay for now. I patched only 1 function with the problem because that makes it shorter and more readable, it's the contrary for all the other functions, so they will stay as they are for now ! Warning looks like that : /usr/bin/ld: linux-gnu-sdl/objectd/68000/s68000.o: warning: relocation in read-only section `.text' /usr/bin/ld: warning: creating DT_TEXTREL in a PIE
  21. Tux

    A dos version in 2020... !

    I'd say return to the seal one which gives you less problems then. The dos version had a mixer built-in, you could display it while a game is running, but it's mostly when some specific sound is too weak/too loud, not to tune the whole volume. Max mixer volume does what it says, it just pushes the output to the max, but it's usually already the case. The problems might be because it's a weird brand, I don't know. I can't help you more on that I am afraid ! I liked working a little bit on this too, it brings some memories, and it's fun to have quite a lot of the recent stuff to be at least loadable in dos !
  22. Tux

    A dos version in 2020... !

    Hum, not here, but the sound is regularly interrupted by silences here in the virtual machine when using allegro, so it's really not ideal. Maybe try a different sample rate, but otherwise out of ideas ! On my side I checked the triple buffer, in fact maybe you can do it with this good old display doctor to get some very special vesa modes, but with my setup in a virtual machine, no vesa mode can work with triple buffer. It actually requires to allocate 3 times the mode and switch the active page between the 3 buffers. There are some very specific modes which work with mode-x : 240x256 (and I confirm this one works, although it's not very convenient), 320x256. Then there is a serie of modes which divide their vertical lines, for those very wide games : 640x100 !, 400x150, 640x150, 640x200, 640x120, 640x160, 640x240, 800x150, 800x200, 800x300... For all these modes, it setups a vesa mode with 3 times the vertical lines before dividing the displayed lines by 3, but they would probably never appear in the mode selection list since it would require that the final mode is supported (640x100 !!! never seen something like that !). So these triple buffer modes were very rare actually ! It would be possible to painfully update the list displayed to add these weird modes, but it's not worth the trouble, too few of these games, and they always look very strange with these impossibly wide screens... So to sum up : more problems with the allegro sound version, and triple video modes work, but are a pain to setup and so very rarely used in reality ! Oh well, these were hard times !
  23. Tux

    A dos version in 2020... !

    Yeah that's what I was going to propose too, it was to be expected, this seal is too old to be reliable now... The download page is not used to having 2 dos versions so they show both as "Dos binary", the new one is 1.8 Mb (almost the same size, just a little shorter), and is named rainead-0.91.9.7z (a like allegro). Good luck and thanks for testing ! Annoying for the triple buffer, not a big surprise too, this triple buffer worked because of some old hacks from Antiriad, we tried to maintain them with new versions of allegro, but something clearly broke somewhere, and it's going to be very hard to find where exactly since I didn't make these and I don't really know how it's supposed to work ! I might eventually test later with some binary which has a working triple buffer, I guess 0.34 worked with triple buffer then ? But it's very old... ! Oh well... ! Maybe later, at least it's good to know !
  24. Tux

    A dos version in 2020... !

    Should be ok, 32 bits versions are optimized for pentium3, but not the dos version which is still optimized for pentium in case of old hardware like this one so there should be no trouble. Maybe the sound ? I'll wait for news from you then !
  25. Tux

    A dos version in 2020... !

    Oops sorry I hadn't updated the old versions page, and it's 0.91.8. There were some very minor tweaks in 0.91.9 for the dos version, it now restores the dos screen when leaving, and fixes the web site name displayed in dos, but they are not worth building a new binary alone, but maybe you would be interested by the fixes anyway... ! Ok, I just built a 0.91.9 version for dos and uploaded it, you can find it in the latest version page : http://raine.1emulation.com/download/latest.html The only question I have is for the sound, in dos there is the choice between seal which is dead since 1999 if I am not mistaken, or allegro which is a little more recent. Seal seems to work a little better in dos emulators like dosemu, so it's the one used in this build. But I suspect the allegro version is better when you have the real hardware. So test this and report if you have problems with the sound. Notice that with 32 Mb of ram you won't be able to load all the games, some are really big for dos standards !
×
×
  • Create New...