How to compile for 32bit? #1296
Comments
|
it should be possible, though we recommend switching to a 64-bit operating system as chances are fairly low that you have a system which isn't capable of running one but melonDS. |
|
well i guess my question gave my intentions clearly that i dont plan to downgrade my OS to 64bit But as i dont see a need or even any performance problems from it being 32bit... i know theres the tiny part about using 64bit integers somewhere altough the processor is 32bit so thats irrelevant (maybe DSi corprocessor but theres still SSE for that)... the only thing that i agree is that the dynamic recompiler would need to be implemented for 32bit, and thats indeed a problem (and i wouldnt expect one to do that) ... as for that (64bit being closer to RISC (wasting more registers) probabily help for the dynarec, or even the interpreter if you guys would do an ASM version of the interpreter, because it would be possible to almost MAP 1:1 the registers like i did with GB for DOS. But thats not the case here, so it really does not matter... at some point i will finish my "W32OW" that will allow to run 64bit software on my 32bit windows just like NTVDM does for 16bit... but until that i wont have a way to run 64bit (except for VMs which would have problems with GFX) but so meanwhile i would like to see then if i can compile and test this for 32bit... thanks for the answer :) |
|
what's the gripe with 64bit OSes, anyway? I mean, any modern-ish CPU is 64bit capable anyway. it's a bit like if you got a standard car and decided you would never drive it above 30km/h. |
|
well i already said the point is that 64bit overrated and its totally not like driving a car at 30km vs 80km... but more likely that the car with 32bit can go at the speed limit... if you take care of it well and change gears properly... while the 64bit one may have some extra features that nobody uses... because the car is mostly on auto pilot... but weights twice the size... and uses twice as much fuel... to work at the same max speed limit of the road anyway... so its more marketing than reality imo... and it isnt much different than why nocash guy is still using a win98 PC... and i totally one day will make a newer html5 browser that work even on win32s just to help him :) so imo theres too much criticism against 32bit... while the only thing that 64bit is... is NEWER... but my grip with that is usually only for desktops... where it does matter more, but its a bit sad that they allowed to use 32bit from 16bit but not 64bit from 32bit... (because that would not make 32bit look bad, and then people would not pointlessy want to upgrade anyway hehe) so its not really about 64bit... but about newer things that are now lazy and lazy with compatibility, to release faster... but in the end with less quality and more abuse... someone blind by being on first world could miss the point... but people on poor countries really still try to make the best of the hardware they have... and that if dedicated enough (learning time) can actually still do as good... you how it is... where you only see people doing amazing feats on old computers... long years late... (by those that ACTUALLY value... not the money masses :P), but ok lets not talk about that here... as that is not the point of the issue request. |
|
i usually hate to use msys2... but i will try to install the newest 32bit one that i can grab... to see if that "pacman" will work... so far even they broke their own thing... so much for simple package manager... |
|
thing is, your Core i5 is 64bit compatible, so there is little point to running a 32bit compatibility layer to finally run 64bit software on a 32bit OS on... a 64bit capable CPU. 64bit software doesn't use more resources. it may consume more RAM because of bigger pointers, but that's it. unless you're constrained by RAM, this shouldn't be a big problem. |
|
well the paragidm of the 64bit era causes more ram to be used... if it was possible to have win10 working on 256mb of ram like i can have XP... (even if it was 512mb for the extras...) then i would not be complaining... but thats not what it is... and frankly any requirements that increase resource usage should be optional not enforced... but things is people have much power and dont optimize... and that plagues the whole 64bit ecosystem... not to mention i would lose NTVDM that i use a lot... because i have some awesome win16 programs that the only way to replace would me remaking them myself... but i can't remake/fix the whole world hehe And so the thing is EVERYTHING would still be 32bit (even with W64OW) and 64bit is just for the TEMPORARY programs that were too stubborn to have a 32bit version... or that i dont care enough to grab a 32bit version... because its one time only... or just to test... or just to help somebody else... (altough now i have a notebook with 64bit win10... that is a junk for temporary purposes instead of my trusty 32bit desktop)... But on my desktop i only have performant well done... very well tough... and effort provided software which automatically excludes almost all 64bit software... all .net , python , java , etc... software which will never be part of my clean ecosystem. (i'm even remaking the AMD gpu control panel... because thats .net aberration is not acceptable... however AMD drivers at least work on 32bit with >4gb of ram... so the least of the evils i did choose, one that i can actually fix unlike nvidia drivers) hehe |
|
sorry but it looks like you're here to argue with us, not to compile melonDS for x86, which should be trivial for you as you seem to be the absolute authority on the topic of x86. |
|
melonDS itself should compile fine on 32bit platforms, you will just need to port or disable the JIT. dependencies might be problematic, tho. |
well i didnt had the intention but i wouldnt refrain from explain my reasons... :) so i was just replying to Arisotura hehe |
|
yeah ok i will battle my way against msys... that is pure garbage... probabily would worth more to just download the packages and use make from native command prompt without all this nonsense... but i dont know if melonDS have simple makefiles not depending on crazy linux exclusive stuff to compile... like many many many projects that dont really value windows tend to do (and MS just accepted and made that concrete with VS, so gameover on expecting things to compile with a simple batch) |
|
cmake is not "crazy linux exclusive stuff", iirc even VS has official support for it now and we do value Windows, both me and Arisotura use it to develope melonDS. How far have you come just following the instructions in the readme? When installing the packages instead of mingw-w64-x86_64 the mingw-w64-i686 needs to be used, otherwise I don't see why everything shouldn't just work out of the box. The cmake script checks the architecture, so the JIT should be disabled automatically. |
|
i was not talking about you guys... i was talking about "linux people in general" and yes i know that VS has official support for that but VS is pure garbage nowadays as well now... along all the linux stuff they make... but thats a lost battle anyway... i will have to accept that projects that are not my own wont be as easy to compile as an easy makefile or an alternative batch file... so nevermind that... carrying on... well first they changed the PGP keyserver in 2021 so the i686 does not work... so i changed pacman.conf to never do any PGP useless security checks, and then i update pacman it says to close the window without going back to shell... and then it fails to opén again... so i have to reinstall from scratch :) so apparently i can't do the -u part... |
|
oh lord you guys use qt5 i think i dont want to try this anymore... |
|
I don't think MSYS2 supports 32-bit hosts anymore. You'll have to either piece the dependencies together yourself or cross-compile from a 64-bit machine. As for why we do this, melonDS is cross platform between Windows, macOS, Linux and some BSDs, and there are even poets for Android and the Nintendo Switch. We also have dependencies on several other projects. At that point using a hand written Makefile becomes highly confusing and unsustainable, as supporting every configuration we might encounter on people's systems just isn't feasible without a more sophisticated build system, and we don't want people to have to modify scripts by hand to compile melonDS. A simple batch/bash script would be even worse as that lacks any sort of dependency tracking, making incremental builds not an option...and melonDS can take minutes to compile, which for development would get pretty annoying real quick. |
|
if Qt is a problem, you can try building melonDS 0.8.3 or older releases. |
|
and do what live forever on a older release? nah i was hoping too much with this project... but i tought you guys valued windows... and qt5 on windows is a sin... maybe i should force you guys to use wine to compile all my projects to see if you guys would like that :) but now i'm starting to think that this project is based on terrible OOP designs as no one sane would be using a garbage like QT5... so thats where the laziness of having a simple and clean winapi output for windows... becomes a giant mess... and where it ends requiring 64bit in the end... because it was all misplanned since the begin... but ok... i dont want to waste your guys time on something that i dont want to be near... sorry for the trouble. |
|
oops forgot to close... |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Please do explain how we could make the project adhere to what you think it should, while still supporting all the target platforms we have now I'm curious. |
Software using more resources is not caused by the shift to 64 bit. If you switch to 64 bit, all the 32 bit software that you use right now would continue to work and be just as lean.
oh, yeah. Guess you can blame microsoft for that. Something like NTVDM could work on 64 bit windows, but ms didn't want to do the work. win16 programs do work on linux with Wine though, if you're open to trying that. |
you're either on drugs or a troll. can't decide which. |
|
with target specifics backends like mupen64 did would be a good start... so you can have a C compatible API, then i would be able to make the winapi backend for windows myself... and the only mutual requirement would be ofcourse mesa/OpenGL or equivalent which also would require multiple backends because mac wont have OpenGL for long...(would need to check how much actual intregration with SDL2 the emulator needs, as that would just be for the GL layer and sound output probabily) but makefiles do work natively on windows, unless they are requiring linux specific tools like sed and all that... so in theory i could maybe use native cmake (not msys) and then it would just work... but requiring package managers that can stop working is a nono to me... and if cmake is all that powerful why it can't generate a .bat file? so that then it would be good for the "one full compile" that most people that are not actually doing dev would just need (ofcourse they would download binaries... but thats not possible for me) also normally on i would keep the dependencies as part of the project (except those are built-in to the target ofcourse)... because i can't trust they wont turn into garbage... then it wouldnt matter if their upgrade breaks stuff... altough less dependencies on such unstable stuff is better and normally i dont keep too much .c files because that actually slowdown compile instead of increase one as for other problems that might arise i dont know what they are so i can't have an opinion :) |
|
What the fuck even is this thread? You want something from people, try asking nicely.
|
What GUI library do you propose? |
I hope synesthesia isn't a sin |
You know C++ code can be called from C, right? Check out I don't really see the point of all this though. Qt is bloated, but it allows cross-platform UIs which are much easier to maintain than platform-specific UIs. DeSmuME does the platform-specific approach, and the Linux port is still missing features that have been in the Windows UI for years. It's not that the devs don't "value Windows"; they value supporting all platforms equally. The downside is you get an executable with a few extra MBs, and a bit more RAM usage. Practically that makes no difference at all, unless you're on a machine that could never hope to run a DS emulator anyway. Also, I find it funny that you bash 64-bit OSes because they're "newer", but then the suggestion of using an older melonDS build is unacceptable. You can't have both, lol. |
those are different things... melonDS 0.8 is UNFINISHED... while windows XP and windows 7 ... are FINISHED software... and if MS had used NT the way it was designed they would never had needed to force people to use win10 to have newer features... (many of those features are not new features... but wrongly positioned compatibility layers... but even them became targets of the polution that happened with high level software paradigms) so i can get 32bit windows to do everything that i need so far but that wouldnt be true with MelonDS (luckly i dont like much newer games as i would get crazy checking how bad they abuse of resource)... |
|
melonDS is still not finished. that means you can't use it? |
|
without being the latest version... i basically can't (thats what i said) specially since my interest is on Wifi :P and i see you guys use slirp to have it without needing a driver like qemu does... which is way less invasive compared to the the hack that desmume had (unnoficially?). (altough both have their merits like a driver would probabily be required to interface with PC wireless (not wifi) to real NDS wireless i suppose.) |
|
If you really hate melonDS that much, why don't you go and use no$gba on Windows 95 or something? |
|
Is there any productive discussion left in this issue? It doesn't seem like it. |
|
Ah yes, "finished" software... except, no software is ever really finished. Using older versions of Windows is actually quite risky, since they aren't getting security patches anymore. It's not because they're finished, it's because they're no longer being supported. Don't get me wrong, modern Windows sucks. But if you care about this stuff so much, I'm honestly surprised you haven't switched to Linux. |
|
you can always try retrofitting the 0.8 UI to 0.9 I guess. |
I'm on 7 because 10 is complete shit and still get regular updates. |
No you don't. https://support.microsoft.com/en-us/windows/windows-7-support-ended-on-january-14-2020-b75d4580-2cc7-895a-2c9c-1466d9a53962
|
|
anyway after downloading and installing insanes over 10gb for qt crap... i compiled it indeed... but it does not work on win7 because of the QT garbage i get a winsxs error (it works on win10) but the static compilation is anything but static (maybe my fault for not cleaning up properly or whatever)... but it does not matter as removing QT would remove enough garbage that i would be hired by GreenPeace for that... |
Yeah I do. Microsoft is lying to you. I get security updates every few weeks. |
|
ok so something seems to be adding a manifest that says amd64 and ofcourse that fails without checking who (i suspect its qt) i used reshack and changed the "amd" to "x86" and now it works... one more reason to get rid of that garbage (ms have extended paid special support for win7 till 2023 at least... but thats useless, support is overrated in majority of cases, and useless to the point they wouldnt even force drivers manufacturers to be compliant with your version even when it was supported... so support on windows is just for clowns and sissies mostly, as its a plain joke.) thanks for the chat... and making me say the same things again and again for 100th time... but really if you guys put everything required for the UI as a C callable interface (or like a "melonDS-UI.dll") with stuff required (even if you woud use QT to grab camera make that as a wrapper from melonDS-UI.dll) then i will gladly make a native, nice and fast win32 friendly UI for melonDS... and if you make like "mupen/desmume" did for android version that to get the JIT working is just required to have the dynamic recompiler tables... then i could support a 32bit dynarect as well for you guys... (or for me) whatever... |
|
I taste sound sorry this is all I can think of as a reply |
Microsoft support is usually pretty good, never had any problems. I can see why you would though.. |
|
Windows 7 ESUs are for paying enterprises. Support for Windows 7 has still ended for everyone who doesn't pay a ridiculous amount of money per year (that increases) until 2023. And support also isn't overrated. The patch updates given to supported systems every month (Patch Tuesday) are critical to keep a system secure.
Beautiful Also I agree with @RidgewayPlus MS Support has helped me to much and the only issues I've had are delays because of COVID-19 |
|
bahahahahahh |
|
ok... so it works fine... isnt that slow (it looks faster than desmume interpreter) the ONLY thing is that "firmware settings" crashes... but its irrelevant to me... the DSi title manager can write to the eMMC? :O |
|
I'm taking note of the firmware settings thing, there might be an issue there... other than that, well... it should not be terribly difficult to port melonDS to anything other than Qt (like Win32 if you so want). we just have only so much time on our hands. |
|
this is the most unhinged github issue i have ever read |
|
ok i tested the x64 version on the work notebook... it was about 10% faster than the 32bit version (in DSI mode, in DS mode it was even less than that) (barely compensating the extra syscall time for WOW64) but ofcourse with the JIT its more than twice faster than interpreter, hopefully i will be able to port the JIT to 32bit :) but GUI first. using multithreaded video seems to make 0 difference on speed maybe it will do more with JIT and... using a heavy 3D game |
|
I wish I had popcorn ready before I started reading this |
Did you notice any difference in speed when using different screen sizes? i.e. 0 difference at 1x but also at 4x?
|
|
oh right right with 2x or more theres a way bigger diference indeed :) , i didnt knew the emulator would also render the softrender at that res instead of just scale, but thats good to know... and what it uses to display when its not GL... its whtever SDL uses? |
|
lol |
i would like to try this emulator but my i5... will never use 64bit crap, so i wanted to try to compile this for 32bit, is it possible?
The text was updated successfully, but these errors were encountered: