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

All Activity

This stream auto-updates     

  1. Yesterday
  2. * Agatemulator 1.29.2 [Agat] - https://sourceforge.net/projects/agatemulator/files/agatemulator/1.29.2/agatemulator-1.29.2.exe/download * Hatari 2.3.0 [Atari ST] - http://download.tuxfamily.org/hatari/2.3.0/ * Emulicious (2020-11-30) [Multisystem] - http://emulicious.net/news/ * PCem v17 [PC] - http://pcem-emulator.co.uk/ * EightyOne 1.19 [Sinclair] - https://sourceforge.net/projects/eightyone-sinclair-emulator/rss?path=/
  3. Last week
  4. Can confirm that the mameui I checked out last night and compiled with : PTR64=1 OSD=messui works when I reun mameui64.exe, including correctly reporting the comctl32.dll version. I'll try your above fixes tonight when I am at home. Cheers. Phill.
  5. 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 !
  6. It just occurred to me that you might be a victim of a changed compile script. These don't get uploaded until release time, so you wouldn't have seen it. Here's the new lines that you wouldn't know about for messui. The reason for the lines about messvers.rc and mameui.rc is to force that stuff to be recompiled, since changes to mameui.rc are not normally detected. Also, mess does not need most of the code and icons that exist in messui, so reducing code bloat. The reason for the lines about messui.txt , mess.bak and mess.flt, is because messui only includes systems that work, not everything in mess. When compiling mess for command-line, here's the new lines The "touch" command is a unix-based command to update the "last-updated" time on a file to the current time. This causes the compiler to think the file has been updated and needs to be recompiled. Touch comes with the msys2 package, so you probably have it somewhere. If you compare ui.rc against uicl.rc, you'll see that ui.rc has the full list of menus and icons used in messui, where uicl.rc only has the menus for the NewUI. These compile changes need to be rolled out to HBMAME as well, but it hasn't been done yet. Hope this helps.
  7. I'll checkout mameui and try that, and report back. Cheers. Phill.
  8. I'll have a look at that. Things were changed around in messui recently. However this particular change was not done with mameui or hbmame; are you able to build and run them?
  9. hi fumanchu, I'm really a biiig fan of X68k and i'm tired of using dim and hdm files... I'm really surprised by your announce " i have posted the full hdf set for the sharp x68000 computer" But when you said "you know where to get this." i'm lost... Please, help me to access this wonderful collection... Tyvm mf :)
  10. Additional information : Investiagting the working early Nov verses Non working Nov 20th, the windows manifest is different for the two versions the working version contains the lines : <dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" publicKeyToken="6595b64144ccf1df" language="*" processorArchitecture="*"/> </dependentAssembly> Which is I guess why it is loading the correct comctl32.dll, the later non working exe does not contain these lines. On investigation it appears that the manifest is not being included at build time, it was previously included from : src/osd/winui/mameui.rc putting the line to load it back in and rebuilding and when running it reports version 6 16 as for the working version but then bombs out saying "Win32UI_init: Error creating main dialog, aborting". I also notice that "build\mingw-gcc\obj\x64\Release\mess.res" is 9K in the non working version 495K in the working version so I suspect that the resources are not being built correctly. It's possible that you have not seen the probleb because there are old versions of the file that are being linked and therefore everything works. Have you tried checking out from the repository and building from there (or doing a make clean)? Cheers. Phill.
  11. Windows 10, 64 bit. It's a few months behind updates though. Not using 20H2 - I never use their bleeding-edge version, because of the bugs that they always seem to include. I'll most likely get the minimum of updates around end-of-year.
  12. You keep saying it's for system restores, that does not appear to be the case : https://en.wikipedia.org/wiki/Side-by-side_assembly Well it worked for me on a version checked out on nov 1st, and reports comctl version 6 16. $ ./messui64.exe MAMEUI starting Win32UI_init: About to init options OptionsInit: About to load MAMEUI.ini OptionsInit: About to load ini\ui.ini OptionsInit: About to load MAME_g.ini OptionsInit: About to load Global Options OptionsInit: Finished Win32UI_init: Options loaded Win32UI_init: Common controlversion 6 16 The next version checked out on 20th of Nov started exhibiting the above behavior. So something changed in that time period that has borked it. As for no one else experiencing this if they checked out before the latest changes the problem might not have shown up. Can I ask what is your exact build environment? Windows version, etc? Cheers. Phill.
  13. I can only repeat that WinSXS should not be accessible to users. It's for system restores only, and for the TrustedInstaller. If you add command-line arguments, it causes the command-line version to run, that is normal. There's nothing more I can say, since I have not encountered this problem, and up till now, nobody else has either.
  14. $ ./messui64.exe MAMEUI starting Win32UI_init: About to init options OptionsInit: About to load MESSUI.ini OptionsInit: About to load MESS_g.ini game_opts.h::load_file : Rebuilding cache game_opts.h::load_file : Finished Rebuilding cache OptionsInit: Finished emuOptsInit: About to load ini\ui.ini emuOptsInit: About to load Global Options emuOptsInit: Finished G:\EmulateDev\messui-2020-11-27\ Win32UI_init: Options loaded Win32UI_init: Common controlversion 4 7 On my normal Windows 10 machine. So 4.7, but as I said at the head of the post the comctl32.dll that is getting loaded is from the WinSXS (windows side by side, not for system restores apparently) folder, and is version 5.82 Product version 10.0.19041.488. I also tried compiling on a Windows 7 machine just to iliminate the windows version. That also says version 4.7 but this time loads from : C:\Windows\winsxs\amd64_microsoft.windows.common-controls_6595b64144ccf1df_5.82.7601.18837_none_a4d981ff711297b6\comctl32.dll and again is version 5.82 My build environment is : latest mame deveolpment environment from the mame website on Windows 10 X64, it is the Enterprise version, and has the latest 20H2 update on it. Oddly on both platforms if I do messui64 -v it runs though behaves like mess64. Cheers. Phill.
  15. 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)
  16. Hi, thanks for the reply! for integer scaling i use DXwind, DXwind make any fullscreen software work in a window, and do integer/nin integer scaling For example, in my 1280x800 laptop, neoragex GUI scale to a non integer 1.5x (640x480>960x720) but ingame in a 3x (320x240>960x720) For real play i use a CRT screen with real resolutions, but in my laptop, i preffer integer scaling, even if i lost some aspect ratio About Raine, i download the source from github, but I can only see build for linux, mingw win32 and djgpp MSDOS if i compile for windows, i will have the new style gui true? how i can compile in mingw but using the allegro gui? thanks
  17. HBMAME and HBMAMEUI 0.226a 32bit (Compatible with Xp). Download from: RETRODANUART GOOGLEDRIVE
  18. The code already says InitCommonControlsEx. (mui_util.cpp, line 427, current git). I'm not sure about "DllInstall", but since it works for me it can't be an issue. Do the following: From the command line, do >mameui64 > x When it has started up (or in your case failed), exit back to the command line. >type x | find "controlversion" In my case it says Win32UI_init: Common controlversion 6 16 what does it say for you?
  19. * HBMAME 0.226.A [Arcade homebrew] - https://hbmame.1emulation.com/ * ZEsarUX 9.1 [Multi-system] - https://github.com/chernandezba/zesarux/releases * Cemu 1.22.0k [Wii-U] - http://cemu.info/ * GameEx 16.72 [Frontend] - https://www.gameex.com/news/ * uCON64 2.2.1 [Frontend] - https://ucon64.sourceforge.io/index.php * RomVault 3.2.0 [Rom Manager] - https://www.romvault.com/
  20. Earlier
  21. I think the crux of the matter is that the init code *ASSUMES* that if "DllInstall" is not exported by comctl32.dll that it is 4.7 or below, however reading the documetation for comctl32.dll it seems that DllInstall only exists for versions 4.71 to 5.81. Versions higher than 5.82 don't have DllInstall, which means that the code in mui_util.cpp assumes it is 4.71 or below which is incorrect. Also during investigation I found that InitCommonControls() is effectively nop, and needs to be replaced with calls to InitCommonControlsEx() Documented by MS : https://docs.microsoft.com/en-us/windows/win32/api/commctrl/nf-commctrl-initcommoncontrols Cheers. Phill.
  22. 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 !).
  23. Hi, i love the DOS version, with the old nice GUI is possible to compile in windows? i still use 0.43.4 but i will love to have neogeo, etc I use raine32 with DXwind, then i can have a nice 3x integer stretch in my 1280x800 laptop, and still use low resolution GUI, here some screenshots Thanks!!
  24. https://hbmame.1emulation.com What's new in HBMAME ==================== 2020-11-25 0.226.A - HBMAMEUI received lots of updates. New Games --------------------------------- - [sf2cemix] Street Fighter II': Champion Edition (Mix 0.96)
  25. StHiryu

    MAME news

    That's the point, nothing is saved or changed. The only difference is using the Run GAME and the File, Play ... options. In the first case no game ini is created, in the second case the ini is always generated again and again.
  26. I can only support what I build. See the notice at https://messui.1emulation.com/ You should tell your windows to use the comctl32.dll that is in c:\windows\system32. You might need to register the dll. On my system it says File version 5.82.18362.1139 and Product version 10.0.18362.1139 The things that are in winsxs are for system restores, and should not be accessible to the normal user.
  27. Robert

    MAME news

    If you change any settings for a game, they have to be saved somewhere so that MAME can pick them up when you run the game. Real frontends send a long string of command-line options, but since MAMEUI is actually joined to MAME, the settings get saved in the ini file instead. writeconfig is only for MAME, not MAMEUI. So, if you were playing the game, and you used the tab menu to change something, it won't get saved unless writeconfig is 1. But changing something in the MAMEUI properties will save it every time.
  1. Load more activity
×
×
  • Create New...