Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65
Posted on 19-04-17, 02:04 in Board feature requests/suggestions (revision 1)
Dinosaur

Post: #262 of 1285
Since: 10-30-18

Last post: 21 days
Last view: 6 hours
Is there a way for editing thread titles?

If you're the thread OP you should have this right, and it's a commonplace feature on pretty much every message board I've registered on (including the former bBoard). But... not here? This surprised me when I came back to my discless Xbone thread to edit the title since it's no longer a rumor but an actual retail product that it's coming to market, hence the need to change the title to reflect the new information.

UPDATE: Turns out I do have that option, but it's not where you would normally expect it, as part of the "Edit" link on the first post of the thread, but as a separate edit command next to the thread title! That completely caught me off-guard this time. The more you know~~~

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™
Posted on 19-04-17, 02:32 in MS is about to release a discless Xbone, this time for real! (revision 2)
Dinosaur

Post: #261 of 1285
Since: 10-30-18

Last post: 21 days
Last view: 6 hours
Introducing the Xbox One S All-Digital edition, or "Xbone SAD" for short:

https://www.youtube.com/watch?v=yBDSMNE3_oQ

Yes, it's now official: the discless Xbone is about to hit the stores. Forgoing the BD-ROM drive will save you $50, which sounds like a total ripoff considering that you can actually find a new Xbone S with a disc drive for less than the $250 that MS is charging for the Xbone SAD, if you know where to look (special deals, sales, etc.) Maybe at $150 it could have been a much better deal if you're willing to give up all of your rights as a conscious consumer because you're too lazy to embrace the PC Master Race™. SAD times ahead, indeed!

Oh, MS also introduced a $15/mo game pass which allows you "unlimited" access to a library of 100 games plus Xbox Live Gold included as part of the service.

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™
Dinosaur

Post: #263 of 1285
Since: 10-30-18

Last post: 21 days
Last view: 6 hours
Xbox Too

Or, since there is noone left at MS that can count properly, Xbox 10.

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™
Posted on 19-04-21, 03:15 in Board feature requests/suggestions (revision 1)
Dinosaur

Post: #265 of 1285
Since: 10-30-18

Last post: 21 days
Last view: 6 hours
Testing a Wayback Machine link:

http://web.archive.org/web/20190321093714/http://wiki.redump.org/index.php?title=Sega_Dreamcast_Japan_Missing_Games

Now, testing the same link through BBcode:

http://wiki.redump.org/index.php?title=Sega_Dreamcast_Japan_Missing_Games">clicky!

I BROKE THE BOARD!

EDIT: Oh, it was already reported.

But there is a easy workaround: remove the secondary http:// from the URL. It will still work.

clicky!

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™
Posted on 19-04-21, 03:16 in I have yet to have never seen it all. (revision 3)
Dinosaur

Post: #264 of 1285
Since: 10-30-18

Last post: 21 days
Last view: 6 hours
The Dreamcast not only was (according to Sega) "the ultimate gaming system", but also the ultimate marketing system too!

...at least in Japan, judging for the indeterminate amount of "not for sale" discs released there:

- Hitachi had to find a way to sell their SH-4 CPUs to customers other than Sega (spoilers: they mostly failed), and the cheapest way to get potential users on board was not to sell/give away evaluation boards, but instead make them buy a Dreamcast so they can run this demo disc, where you could run some tests, and nothing else.

- Horse race betting is big on pretty much every country with horse race tracks (as a citizen from one of such countries, I can affirm! And no, I haven't actually bet on a race since... what, 1994?). But in Japan, they go to the extreme, ensuring you have access to betting everywhere. And since Japan hates personal computers with a passion, they had to switch to the next best thing: game consoles! The Super Famicom was not alone on this: the DC had at least a few horse race betting discs shipped, and we must remember that each and every DC shipped from the production line with a built-in modem, so all you need is to plug it in and waste some hard-earned yens!

- Continuing with Japan's weird love for doing things involving money and stuff on devices that aren't personal computers, we have things like this. So, buy and sell stocks from your DC, or something. Or if you happened to have health insurance with a specific provider, they would kindly loan you a DC complete with a DreamEye camera, keyboard, and a custom application disc so you could talk to your doctor remotely! I guess all that stuff was cool in the early '90s (I can remember that the Mega Modem had at least a banking application cart in 1990) where PCs were rather primitive... but in the year 2000!??! FFS, Japan!!!

- Toyota really really loved the Dreamcast. Not only they used to give away Toyota-branded consoles in Japan (maybe as contest prizes, or maybe even you could get a new DC with your brand new sucky Yaris), they even used them as a promotional vehicle (no pun intended!) for their 1999/2000 model lineup: enter the "DoriCatch" series, showcasing select vehicle models, one model per disc (the '00 Estima had two discs for whatever reason). And then, we've got the weirdly named "Alabama meets Will VI", a special release for the Tokyo Motor Show. Not only this disc is on the "insanely rare" end of the availability scale, I've been unable to find any info about this disc, AT ALL! The only bit I've found is that "Alabama" is the name of the girl on the cover, which also is the protagonist of this PSX game... which was developed by Toyota too (?!?!?)


Needless to say, none of those discs seem to be preserved yet. No public rips exists for any of those. They're all absurdly rare, there are very few surviving copies, and all of them are in the hands of collectors that have next to no interest into preserving those rare pieces of Sega history (if they ever managed to rip their jewels, those rips are doomed to die with their HDDs when they fail, because they "risk" "devaluating their precious discs" or some hoarder BS). Ah well, it's suffering to be the Dreamcast :/

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™
Dinosaur

Post: #266 of 1285
Since: 10-30-18

Last post: 21 days
Last view: 6 hours
You can always add more madness to the mix.

Let me remind you that cart-based software CAN access the MCD side (Flux, region converter carts, Sonic Winter Adventures, and IIRC there was a CD-enhanced version of Pier Solar). Combined with the mushroom of doom, noone says you can't slap, say, a 21MHz ARM3 CPU on a cart to make a 6-CPU abomination :D

And if you're MAD ASS CRAZY, you can bring in your favorite FPGA, add some analog/overlay video mixer, and add two or three extra planes and a few spare polygons/s. Once again Sega does what Nintendon't.

But then, if Higan ever implements this unholy trainwreck of console/accessory "mating", I guess I'll play all four discs of Slam City like a NBA star.

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™
Posted on 19-04-24, 11:32 in How do I share between 2 games?
Dinosaur

Post: #267 of 1285
Since: 10-30-18

Last post: 21 days
Last view: 6 hours
Posted by CaptainJistuce
You... want to play two-player? Well, sit your friend down next to you and map the second controller.


I assume our user wants to play Gameboy games (trading Pokeymanz and stuff), hence requiring emulation of the link cable. What emulator are you using?

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™
Posted on 19-04-28, 02:18 in I still HATE smartdevices (revision 2)
Dinosaur

Post: #268 of 1285
Since: 10-30-18

Last post: 21 days
Last view: 6 hours
Just like everything in this country, I'm forced to coexist with stuff that actively pisses me off every day:
- banks
- public transportation
- other Venezuelans
- web browsers
- faulty basic services (water/power/Internet)
- smartdevices

But like everything in life, all turns out to be a learning experience, or something. So take this thread not as a rant (although it will be!), but more as a log of useful notes for others when the need to tinker with broken-by-design devices arise.

Mom's shitty noname Allloser craplet keeps breaking every now and then. The failure pattern is the same in all cases:
- After a fresh reflash and reinstall, everything works (mostly) smoothly
- After 3-4 months of light usage (basically Chrome and WhatsApp, nothing else), apps start crashing at random. Wiping cache often brings some quick relief
- After a few days of this, the condition of the firmware takes a deep nosedive: bootloops, sudden reboots, being unable to power down the thing because it will power up again on its own, inability to even enter recovery mode! At this point, blood is boiling and the tablet is about to hit escape velocity

For the good of our sanity, I've already devised a routine for this:
- Use PhoenixSuit (yes, those Chinatards™ intentionally missed the final "e" there because they're edgy or something) to reflash a stock ROM (doesn't really matter which one as you will NEVER find the original ROM for your specific noname tablet; just pick one that ships with the basic Google spyware framework and no Central Communist Party spyware other than the Allshitter services). When asked to do a "Normal format" (or whatever), say YES to properly wipe everything and start from scratch
- At the first boot of your brand new firmware, don't connect to WiFi just yet. Install Kingo Root and root the fucker, then take a look at my thread at the old board to follow that XDA thread on how to replace Kingo crap with a proper SuperSU setup (consider yourself EXTREMELY lucky if your specific hardware DOES have a port of TWRP you can flash to it - if that's you, simply use that to install SuperSU and completely ignore Kingo). Use SuperSU 2.79, not the latest 2.82 as it will not work properly and you will have to re-root again! (You can always upgrade to 2.82 through Play Store later)
- My app manager of choice is Apps2SD (the one by "GSTMaid", app ID: in.co.pricealert.apps2sd). Very easy to use, yet extremely powerful. Used to have really obnoxious and extremely intrusive ads, but apparently even the developer got fed up with this so he (?) made the Pro version completely free a few months ago. Go buy that guy a keg of beer, he deserves up to the last drop of it! Go find an APK (since you can't use Google Play just yet! And watch out for malware-laden repacks!) and sideload it. Take this chance to trim the fat (remove bloatware/useless preloads, do some cleanup), then reboot
- adb shell pm set-install-location 2, or you will quickly run out of the precious scarce internal memory for apps! (Whoever decided to leave <1GB for the internal storage partition while having a 4GB partition disguised as a "internal SD card" and a USELESS external microSD socket should be sent to the worst forced labor camp in the coldest part of China)
- Now you're ready to let this thing smell the rotten stench of the wide open Internet. Let it join your WiFi, logon with your Google credentials, and proceed to install updates and reinstall your apps. Google Play will be extremely stubborn when it comes to update preloaded Google crap, so it may need a helping hand...
- DISABLE AUTOMATIC UPDATES ONCE YOU'RE DONE INSTALLING SHIT! The last thing you want to listen is to Granny bitching and moaning because her Chrome rearranged all the icons ONCE AGAIN because some UXtarded Silly Valley art school dropout had yet another epiphany when drinking a bubble tea while driving his Tesla!
- Once all updates are done, use Apps2SD to merge all updates to stock apps back to the system partition, in order to free some space on the already critical internal storage partition. Be prepared to do this every now and then each time Google Play Services gets an update (because you can't disable automatic updates for this one). Don't rush, do it on stages, and leave the heavyweight ones (Google Play Store / Google Play Services) for last. It may help clearing data for those prior to the merge (whatever data Google uses there will be downloaded again anyway, so don't worry). Reboot several times just to be on the safe side
- This leaves us with the final challenge: reactivating WhatsApp on a device where you're not supposed to run WhatsApp (i.e. a tablet without a cell modem). This part is simple: they will send you a SMS to whatever phone number you've used to register. Except that this is Soviet Venezuela, and your cellphones have been without signal since the last blackout! Have fun~~~ [insert sinister laughter here]

Rinse and repeat every 3-4 months. I don't care why it breaks, now that I have my routine for dealing with the fallout when it happens.


And since being "the computer guy" on this family (the one that actually went to college, where we weren't taught about how to format computers, much less reflash cellphones), I've been forced to deal with broken smartshits. Here is another case I've just got: my cousin just bought a (hopefully non-flammable) Samturd Galaxy J-something (because her career as a dentist is one of the few ones in this hellhole where people can actually make some money to buy things other than food) to replace her highly abused Blu Dash X. She never treated well that poor phone: neglected backups/updates for years, and the phone finally died a few weeks ago after a "visit" to the "friendly cellphone chop shop" at the nearest mall for a reflash. Except that it didn't really died, it just got stuck on a bootloop because like every software piece made nowadays, these Android firmwares are of absolutely ZERO quality, fragile as fuck, and it only works because of sheer luck (and most likely whatever moron "serviced" her phone just scammed her instead of properly flashing this thing wile being aware of its flaws). So, let's get this brick out of my workbench ASAP!

First things first: this thing is based on a Mediatek chipset (MT6580). You know, the same Mediatek that has been "borrowing" IP making your favorite ODD chipsets since late '90s. They bought Ralink for their Linux-friendly WiFi chipsets, started making TERRIBLE dumbphone chipsets... but suddenly they're now a large player on the budget smartdevice arena. The "Linux-friendly" bit is somewhat relevant, because this is one of the rare OEMs that actually has official flashing tools for Linux! A rather nice (if very Engrishy, as expected) Qt4 app that works both on Linux and Windows (yes, XP included). In fact, it's actually much easier to flash under Linux since under Windows you have to deal with a messy device driver situation - under Linux all you need is already part of whatever kernel you're running.

- Forget about flashing this thing from Windows (driver install will be a waste of time, considering the brief time window where the device exposes the required serial port for the bootloader). Man up and install Linux on your Real Computer™! Not everyday you get a chipset maker that actually gives a damn on your OS of choice!
- Find the firmware for your phone. In the case of the Dash X, the situation is kinda tricky, as there are like 3 revisions of the same model (D010, D010U, D010L). Look at the barcode/IMEI label under the battery! (YES, THIS THING FEATURES A REMOVABLE BATTERY, JUST AS GOD INTENDED!!!!), because the firmwares are most likely not interchangeable! (all of them feature the same chipset so flashing with wrong firmware may not brick anything but you risk breaking stuff or getting stuck at a bootloop). This one turned out to be a D010U, and after a long search I ended with a ~1.7GiB (uncompressed) folder named BLU_D010U_V10_GENERIC (V10 is the last build available from Blu for the D010U, as this phone has been hopelessly abandoned by their OEM shortly after release)
- Run the flasher tool. Curiously enough, the Linux binary is dynamically linked to libpng12.so... which is the same lib required by lxdream! Good for me I still have that Jessie .DEB handy. Aside of that, the flasher works fine under Debian Stretch. I don't know if you have to be a sudoer, but I didn't had to run it with special privileges just to let it access the CDC ACM serial port exposed by the phone when it boots on the required bootloader mode
- You need to point the flasher to a "scatter file" on the Download tab. This is Mediatek-esque for "firmware flash layout file", a TXT that should be on the same folder of your firmware, and that describes how are those flash partitions laid out. Don't plug the phone yet (if it's already plugged in, unplug it now!), but hit "Download" on the Download tab. The flasher will sit there, patiently waiting for your phone to come up
- Pull the battery, then put it back. Now connect the phone to your PC. The flasher should recognize it and flashing will begin (if it doesn't, try holding up Vol+ when plugging in the data cable). Flashing will be reasonably quick - it will be done in 3 minutes or so. Nothing will display on screen during or after the process, so don't panic!
- Once you're finished flashing, unplug the phone and power it up. Yay, bootloop is gone~!
- OPTIONAL (but highly recommended if you're planning to debloat the ROM): Rooting this thing is way easier than dealing with those Allcrapper tablets, because we DO have the luxury of having a native TWRP recovery ROM for it!. You will also need the flashable SueprSU - once again, 2.79 is the suitable one as the 2.82 package will cause the phone to "optimize apps" on each and every boot due to some bug on the installer scripts that break things that aren't supposed to break!. To flash TWRP, repeat the procedure to flash the phone, but prior to the firmware download, deselect all partitions but "recovery", then doubleclick the file name for the recovery partition and replace it with your TWRP build (very handy feature, thanks Mediatek!). Follow the usual procedures on how to flash SuperSU from within TWRP afterwards.
- Refrain from ever doing a factory wipe on this thing. Seriously, DON'T: the firmware is so fragile that most likely you will get sent straight to a bootloop after wiping the data partition (not only it happened to my cousin, I actually managed to replicate it by myself after a fresh flash, TWICE). If you're ever going to sell your Dash X (or whatever other Blu phone built on the same chipset), just reflash it. You were going to do it anyway no matter what.


Nothing beats flashing a good ol' Motorola phone, though: pick suitable firmware, boot phone in bootloader (#+*+END), connect, hit Start,
, done.

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™
Posted on 19-04-28, 13:37 in I still HATE smartdevices
Dinosaur

Post: #269 of 1285
Since: 10-30-18

Last post: 21 days
Last view: 6 hours
Gotta love sureanem's non-solutions just because...

1) I don't care about non-Google Play replacements/app stores. This tablet only uses the Google search app, Chrome and Whatsapp. $MOM is NOT INTERESTED into learning replacements, so neither I.

2) Ever been here, really? If you were, you would learn that VoIP is NOT AN OPTION, just like everything else.

Look, the only reason I've endured dealing with broken smartdevices is because I have a family where everybody stopped using Real Computers™ years ago (some of them never did in first place). I still don't want those pieces of carcinogen shit in my personal life, and it's pretty much obvious that the way of working for those devices is not compatible with 3rd-world shitholes, but that's what we have. I AM NOT INTERESTED INTO LEARNING ABOUT THOSE THINGS AT ALL, yet I've been pretty much forced to! As comparison, my Real Computers™ obey me (almost always), and I've been in total control of them (Microsoft/Google spyware notwithstanding... and even then I don't use non-Mozilla browsers or Windows 10)


> Magisk
Will investigate about that one, thanks for the suggestion.

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™
Posted on 19-04-28, 15:38 in I still HATE smartdevices
Dinosaur

Post: #270 of 1285
Since: 10-30-18

Last post: 21 days
Last view: 6 hours
SuperSU 2.82 definitely breaks shit on this Blu thing. Updating it through Google Play then letting it updating the su binaries will cause the phone to "optimize apps" on each and every boot, delaying boot forever. So I decided to start over and try Magisk.

...except that this time I couldn't skip the "Select WiFi network" display on the initial setup wizard because of this security theater bullshittery just because I had activated the phone with a throwaway Google account (otherwise no updates for your apps!). Gee, thanks for nothing, Google! Not only a factory reset would not help (surprisingly I didn't got a bootloop this time), the lock even survived a full reflash because Google and Mediatek believes I have stolen the device (I didn't!).

The proper way to dispose of an used Android phone nowadays is to delete all Google accounts from the device prior to a factory wipe (a procedure that it is anything but straightforward: you have to turn off all sync first, THEN figure out where the "Delete account" option is!) - othewrise you will be forced to logon to the last Google account used on the thing, which means no way to bypass the WiFi select display (unless if you somehow can reflash a custom recovery thing where you can edit a pref on whatever .prop file is it). This also means that if you're far from a WiFi network (or without Internet access in general), your phone is effectively bricked for all and any purposes.

Look, I understand that phone theft is a serious problem (much more in hellholes like this one, where you can't own nice things), but this does absolutely NOTHING to curb the problem (your phone is still good for spares, after all). Kill switches have to be strictly OPT-IN, with all sorts of disclaimers and user controls! But hey, I am of the understanding that I'm not the target for the "smarter-than-you-phone" generation.

FUCK GOOGLE FOREVER. And anyone that is on the "smart bullshit" business too.

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™
Posted on 19-04-28, 16:10 in I still HATE smartdevices
Dinosaur

Post: #271 of 1285
Since: 10-30-18

Last post: 21 days
Last view: 6 hours
Oooooh, so Apps2SD didn't became free out of a plain goodwill gesture, but more as a "fuck you Google" move: Google banned the application from the Play store just because the app description had instructions on how to root your device! (which considering the purpose of the app is completely expected - it's like a bank telling you that in order to make a withdrawal you have to deposit funds on your account first. But Google knows what's best for you, dear citizen)

This had the following consequences:
- The pro version became free for everybody. Yay~!
- FUCK YOU IT'S CANCELLED. Yes, the app is now officially discontinued. Boo!

Google did relisted the app on the Play store after this mamadrama, but the damage is now done. I would not blame this guy/gal if (s)he never ever codes stuff for Android (or smarturds in general)

My total inconvenience is your satisfaction. Thanks Google!

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™
Posted on 19-04-28, 16:50 in I still HATE smartdevices
Dinosaur

Post: #272 of 1285
Since: 10-30-18

Last post: 21 days
Last view: 6 hours
FWIW I'm liking Magisk.

Too bad there are no CWM/TWRP recovery mods for most Allshitter tablets (the other way would be figuring out how to craft and flash a custom boot partition as explained on the setup instructions), otherwise I would switch to it on Mom's tablet in a heartbeat. On this Blu it's working seamlessly. The systemless part is nice, but then you have to modify /system anyway for debloating purposes :/ (not related with rooting BTW, it's just a reason of why you would want to root in first place)

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™
Posted on 19-04-28, 22:10 in Building Dolphin on Debian Stable: problems! (revision 1)
Dinosaur

Post: #273 of 1285
Since: 10-30-18

Last post: 21 days
Last view: 6 hours
I decided it was that time of the year where I have to update my local Dolphin build, for the few GC/Wii games I don't play anymore. Last time I successfully did it was in January 21th (commit 3627ef8a0489765eb10ab29a7988866b52493239 according to the .DEB version as packaged by cpack). Aside of having to install a newer Qt5 version than the one available on Stretch (thankfully Qt does offer a GUI-based installer for that - just stash it somewhere in /opt and you're golden), it builds and works just fine with only stock Debian stable packages.

Today... I'm getting this vomit:
[ 64%] Building CXX object Source/Core/Core/CMakeFiles/core.dir/HW/WiimoteEmu/Camera.cpp.o
/home/tomman/workbench/dolphin-emu/Source/Core/Core/HW/WiimoteEmu/Camera.cpp: In member function ‘void WiimoteEmu::CameraLogic::Update(const Common::Matrix44&, bool)’:
/home/tomman/workbench/dolphin-emu/Source/Core/Core/HW/WiimoteEmu/Camera.cpp:105:36: error: call to non-constexpr function ‘constexpr std::array<_Tp, _Nm>::size_type std::array<_Tp, _Nm>::size() const [with _Tp = Common::TVec3<float>; long unsigned int _Nm = 2ul; std::array<_Tp, _Nm>::size_type = long unsigned int]’
std::array<CameraPoint, leds.size()> camera_points;
~~~~~~~~~^~
In file included from /home/tomman/workbench/dolphin-emu/Source/Core/Common/ChunkFile.h:16:0,
from /home/tomman/workbench/dolphin-emu/Source/Core/Core/HW/WiimoteEmu/Camera.h:7,
from /home/tomman/workbench/dolphin-emu/Source/Core/Core/HW/WiimoteEmu/Camera.cpp:5:
/usr/include/c++/6/array:171:7: note: ‘constexpr std::array<_Tp, _Nm>::size_type std::array<_Tp, _Nm>::size() const [with _Tp = Common::TVec3<float>; long unsigned int _Nm = 2ul; std::array<_Tp, _Nm>::size_type = long unsigned int]’ is not usable as a constexpr function because:
size() const noexcept { return _Nm; }
^~~~
/usr/include/c++/6/array:171:7: error: enclosing class of constexpr non-static member function ‘constexpr std::array<_Tp, _Nm>::size_type std::array<_Tp, _Nm>::size() const [with _Tp = Common::TVec3<float>; long unsigned int _Nm = 2ul; std::array<_Tp, _Nm>::size_type = long unsigned int]’ is not a literal type
/usr/include/c++/6/array:90:12: note: ‘std::array<Common::TVec3<float>, 2ul>’ is not literal because:
struct array
^~~~~
/usr/include/c++/6/array:106:56: note: non-static data member ‘std::array<Common::TVec3<float>, 2ul>::_M_elems’ has non-literal type
typename _AT_Type::_Type _M_elems;
^~~~~~~~
/home/tomman/workbench/dolphin-emu/Source/Core/Core/HW/WiimoteEmu/Camera.cpp:105:36: error: call to non-constexpr function ‘constexpr std::array<_Tp, _Nm>::size_type std::array<_Tp, _Nm>::size() const [with _Tp = Common::TVec3<float>; long unsigned int _Nm = 2ul; std::array<_Tp, _Nm>::size_type = long unsigned int]’
std::array<CameraPoint, leds.size()> camera_points;
~~~~~~~~~^~
/home/tomman/workbench/dolphin-emu/Source/Core/Core/HW/WiimoteEmu/Camera.cpp:105:38: note: in template argument for type ‘long unsigned int’
std::array<CameraPoint, leds.size()> camera_points;
^
/home/tomman/workbench/dolphin-emu/Source/Core/Core/HW/WiimoteEmu/Camera.cpp:107:58: error: request for member ‘begin’ in ‘camera_points’, which is of non-class type ‘int’
std::transform(leds.begin(), leds.end(), camera_points.begin(), [&](auto& v) {
^~~~~
/home/tomman/workbench/dolphin-emu/Source/Core/Core/HW/WiimoteEmu/Camera.cpp:137:50: error: request for member ‘size’ in ‘camera_points’, which is of non-class type ‘int’
for (std::size_t i = 0; i != camera_points.size() / 2; ++i)
^~~~
/home/tomman/workbench/dolphin-emu/Source/Core/Core/HW/WiimoteEmu/Camera.cpp:141:45: error: invalid types ‘int[std::size_t {aka long unsigned int}]’ for array subscript
const auto& p1 = camera_points[i * 2];
^
/home/tomman/workbench/dolphin-emu/Source/Core/Core/HW/WiimoteEmu/Camera.cpp:147:49: error: invalid types ‘int[std::size_t {aka long unsigned int}]’ for array subscript
const auto& p2 = camera_points[i * 2 + 1];
^
/home/tomman/workbench/dolphin-emu/Source/Core/Core/HW/WiimoteEmu/Camera.cpp:157:50: error: request for member ‘size’ in ‘camera_points’, which is of non-class type ‘int’
for (std::size_t i = 0; i != camera_points.size(); ++i)
^~~~
/home/tomman/workbench/dolphin-emu/Source/Core/Core/HW/WiimoteEmu/Camera.cpp:159:40: error: invalid types ‘int[std::size_t {aka long unsigned int}]’ for array subscript
const auto& p = camera_points[i];
^
/home/tomman/workbench/dolphin-emu/Source/Core/Core/HW/WiimoteEmu/Camera.cpp:178:50: error: request for member ‘size’ in ‘camera_points’, which is of non-class type ‘int’
for (std::size_t i = 0; i != camera_points.size(); ++i)
^~~~
/home/tomman/workbench/dolphin-emu/Source/Core/Core/HW/WiimoteEmu/Camera.cpp:180:40: error: invalid types ‘int[std::size_t {aka long unsigned int}]’ for array subscript
const auto& p = camera_points[i];
^
Source/Core/Core/CMakeFiles/core.dir/build.make:1830: fallo en las instrucciones para el objetivo 'Source/Core/Core/CMakeFiles/core.dir/HW/WiimoteEmu/Camera.cpp.o'
make[2]: *** [Source/Core/Core/CMakeFiles/core.dir/HW/WiimoteEmu/Camera.cpp.o] Error 1
make[2]: *** Se espera a que terminen otras tareas....
CMakeFiles/Makefile2:1099: fallo en las instrucciones para el objetivo 'Source/Core/Core/CMakeFiles/core.dir/all'
make[1]: *** [Source/Core/Core/CMakeFiles/core.dir/all] Error 2
Makefile:151: fallo en las instrucciones para el objetivo 'all'
make: *** [all] Error 2


Looks like the GCC version on Debian stable (6.3) doesn't like something, and compilation dies there. Fun.

The offending commit seens to be this one, although if I revert to the commit just prior to that, GCC dies with an internal compiler error (!!!!). Does anyone well versed in C++ and GCC know what the hell is happening here?
I HOPE the answer is not "upgrade your GCC you dummy~" (in fact Dolphin wiki doesn't even recommend any specific GCC version for building, but then the dependencies list hasn't been updated in ages), as this would lead me to two paths I'm actively trying to avoid right now:
- Move to Debian Buster/testing: it has GCC7 and 8, but I'm not upgrading to it yet. Maybe later this year, after it becomes "stable". MAYBE.
- Build GCC from source. Been there, done that, and said "nope, my Fedora Core 6 era is long gone NEVAR AGAIN!"

YES I KNOW that this isn't the Dolphin bugtracker/forum, but I decided to give it a shot here first before tinkering more and filing a issue/ticket or whatever on their bugtrackers.

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™
Posted on 19-04-29, 04:35 in Building Dolphin on Debian Stable: problems!
Dinosaur

Post: #274 of 1285
Since: 10-30-18

Last post: 21 days
Last view: 6 hours
Before getting interrupted by the daily "rolling" blackout (and subsequent loss of connection), I managed to have this interaction over the Dolphin IRC channel:

[18:29]       tomman  hi there
[18:29] tomman what's the current required GCC version for building Dolphin from source?
[18:30] tomman I'm having some trouble with GCC 6.3 (the one from the current Debian Stable)
[18:31] Billiard cmake should warn you if you don't meet the reqs
[18:31] Billiard what error are you getting?
[18:33] tomman https://gist.github.com/dilworks/a7a0e4aafcf072328f6f5019a8bfb58d
[18:33] tomman Last time I successfully built Dolphin on Debian stable was like 3 months ago
[18:34] tomman (aside of having to install a newer Qt5 release, everything else works with stock packages, or using the internal libraries)
[18:36] tomman I get no warnings this time
[18:36] tomman (no warnings from cmake, that is)
[18:36] Billiard stdlib looks broken if std::array::size is not constexpr
[18:38] Billiard actually my usage of .size9) there might be questionable..
[18:43] Billiard naw. looks like a gcc and/or stdlib bug
[18:46] Billiard tomman: you could try clang if upgrading gcc is not feasible
[18:48] Billiard tomman: or you could hack fix that line of code
[18:49] Billiard just change leds.size() to 2


Hmmm, I wasn't aware you could now use clang for building Dolphin, so I'll figure it out later.

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™
Posted on 19-04-29, 15:24 in Building Dolphin on Debian Stable: problems! (revision 3)
Dinosaur

Post: #275 of 1285
Since: 10-30-18

Last post: 21 days
Last view: 6 hours
Switching compilers require to start over with a new build directory, so I setup a separate directory for building with Clang.

Hello brick wall:
[ 15%] Building CXX object Source/Core/Common/CMakeFiles/common.dir/GL/GLInterface/EGL.cpp.o
/home/tomman/workbench/dolphin-emu/Source/Core/Common/GL/GLInterface/EGL.cpp:292:10: error: no viable conversion from returned value of type
'unique_ptr<GLContextEGL>' to function return type 'unique_ptr<GLContext>'
return new_context;
^~~~~~~~~~~
/usr/include/c++/v1/memory:2459:29: note: candidate constructor (the implicit copy constructor) not viable: no known conversion from
'std::unique_ptr<GLContextEGL>' to 'const std::__1::unique_ptr<GLContext, std::__1::default_delete<GLContext> > &' for 1st argument
class _LIBCPP_TYPE_VIS_ONLY unique_ptr
^
/usr/include/c++/v1/memory:2488:49: note: candidate constructor not viable: no known conversion from 'std::unique_ptr<GLContextEGL>' to
'nullptr_t' for 1st argument
_LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR unique_ptr(nullptr_t) _NOEXCEPT
^
/usr/include/c++/v1/memory:2515:31: note: candidate constructor not viable: no known conversion from 'std::unique_ptr<GLContextEGL>' to
'std::__1::unique_ptr<GLContext, std::__1::default_delete<GLContext> > &&' for 1st argument
_LIBCPP_INLINE_VISIBILITY unique_ptr(unique_ptr&& __u) _NOEXCEPT
^
/usr/include/c++/v1/memory:2519:9: note: candidate constructor [with _Up = GLContextEGL, _Ep = std::__1::default_delete<GLContextEGL>] not
viable: no known conversion from 'std::unique_ptr<GLContextEGL>' to 'unique_ptr<GLContextEGL, std::__1::default_delete<GLContextEGL> > &&'
for 1st argument
unique_ptr(unique_ptr<_Up, _Ep>&& __u,
^
/usr/include/c++/v1/memory:2534:35: note: candidate template ignored: could not match 'auto_ptr' against 'unique_ptr'
_LIBCPP_INLINE_VISIBILITY unique_ptr(auto_ptr<_Up>&& __p,
^
1 error generated.
Source/Core/Common/CMakeFiles/common.dir/build.make:777: fallo en las instrucciones para el objetivo 'Source/Core/Common/CMakeFiles/common.dir/GL/GLInterface/EGL.cpp.o'
make[2]: *** [Source/Core/Common/CMakeFiles/common.dir/GL/GLInterface/EGL.cpp.o] Error 1
CMakeFiles/Makefile2:1006: fallo en las instrucciones para el objetivo 'Source/Core/Common/CMakeFiles/common.dir/all'
make[1]: *** [Source/Core/Common/CMakeFiles/common.dir/all] Error 2
Makefile:151: fallo en las instrucciones para el objetivo 'all'
make: *** [all] Error 2

Stretch's clang (3.8) is ancient, as expected. Luckily there are newer versions through backports, so let's try that. The latest one is clang-6.0, so let's go with it:
[ 12%] Building CXX object Source/Core/AudioCommon/CMakeFiles/audiocommon.dir/AudioCommon.cpp.o
In file included from /home/tomman/workbench/dolphin-emu/Source/Core/AudioCommon/AudioCommon.cpp:19:
In file included from /home/tomman/workbench/dolphin-emu/Source/Core/Core/ConfigManager.h:17:
In file included from /home/tomman/workbench/dolphin-emu/Source/Core/Core/TitleDatabase.h:8:
In file included from /usr/include/c++/v1/unordered_map:350:
/usr/include/c++/v1/__hash_table:1169:43: error: conflicting types for '__hash_table<_Tp, _Hash, _Equal, _Alloc>'
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__hash_table()
^
/usr/include/c++/v1/__hash_table:856:5: note: previous declaration is here
__hash_table()
^
/usr/include/c++/v1/__hash_table:1237:43: error: conflicting types for '__hash_table<_Tp, _Hash, _Equal, _Alloc>'
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__hash_table(__hash_table&& __u)
^
/usr/include/c++/v1/__hash_table:870:5: note: previous declaration is here
__hash_table(__hash_table&& __u)
^
2 errors generated.
Source/Core/AudioCommon/CMakeFiles/audiocommon.dir/build.make:62: fallo en las instrucciones para el objetivo 'Source/Core/AudioCommon/CMakeFiles/audiocommon.dir/AudioCommon.cpp.o'
make[2]: *** [Source/Core/AudioCommon/CMakeFiles/audiocommon.dir/AudioCommon.cpp.o] Error 1
CMakeFiles/Makefile2:949: fallo en las instrucciones para el objetivo 'Source/Core/AudioCommon/CMakeFiles/audiocommon.dir/all'
make[1]: *** [Source/Core/AudioCommon/CMakeFiles/audiocommon.dir/all] Error 2
Makefile:151: fallo en las instrucciones para el objetivo 'all'
make: *** [all] Error 2

...nope. Lovely compiler error messages.
(Updating libc++-dev is not an option: there are no backported versions for Stretch, and on Buster, the Debian packagers changed the packaging structure a bit: this one no longer comes from a standalone source package, but from llvm-toolchain itself)

Anyway, let's go back to GCC. I decided to start over with a clean build directory, just in case. Let's redo the failing build without applying any hacks:
[ 64%] Building CXX object Source/Core/Core/CMakeFiles/core.dir/HW/WiimoteReal/WiimoteReal.cpp.o
/home/tomman/workbench/dolphin-emu/Source/Core/Core/HW/WiimoteReal/WiimoteReal.cpp: In member function ‘bool WiimoteReal::Wiimote::CheckForButtonPress()’:
/home/tomman/workbench/dolphin-emu/Source/Core/Core/HW/WiimoteReal/WiimoteReal.cpp:385:29: internal compiler error: in process_init_constructor_union, at cp/typeck2.c:1555
ButtonData buttons = {};
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-6/README.Bugs> for instructions.
Source/Core/Core/CMakeFiles/core.dir/build.make:2012: fallo en las instrucciones para el objetivo 'Source/Core/Core/CMakeFiles/core.dir/HW/WiimoteReal/WiimoteReal.cpp.o'
make[2]: *** [Source/Core/Core/CMakeFiles/core.dir/HW/WiimoteReal/WiimoteReal.cpp.o] Error 1
CMakeFiles/Makefile2:1099: fallo en las instrucciones para el objetivo 'Source/Core/Core/CMakeFiles/core.dir/all'
make[1]: *** [Source/Core/Core/CMakeFiles/core.dir/all] Error 2
Makefile:151: fallo en las instrucciones para el objetivo 'all'
make: *** [all] Error 2

What. The. FUCK!?

Not only the original code is compiling fine WITHOUT ANY MODIFICATIONS, the compiler now dies with an ICE when parsing an... empty array. Apparently I had not properly reset the repository to the latest commits. After playing some git command enchantments, I'm now at the tip of the head of master (i.e. the latest commit). I still need to apply Billiard's hack... and seconds later, GCC still dies with the exact same ICE (ButtonData is actually an union, not an array).

I guess I've just found something I hate more than smartdevices: C.

Ah well, I suppose all paths eventually lead to the same outcome: "update your distro, buddy~".

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™
Posted on 19-04-29, 18:09 in Building Dolphin on Debian Stable: problems!
Dinosaur

Post: #276 of 1285
Since: 10-30-18

Last post: 21 days
Last view: 6 hours
My best bet -right now, short of upgrading my distro or building GCC from source- would be to figure out how to install GCC 8 .DEBs from Buster on Stretch.

...after looking at the respective source and binary package lists, looks like if I want the newer clang 7, I would also need to pick some GCC 8 dependencies.

In the case of GCC, things doesn't look THAT bad: traditionally older GCC versions keep working fine with newer Debian releases (in fact you usually have to end purging your old GCC versions after a successful dist-upgrade), and there are documented cases of people pulling GCC .DEBs from testing down to stable without secondary effects. The only problem with GCC is the sheer number of packages provided by its source package you may need for a base install. Mixing stable with testing is never a good idea, aside of very specific cases.

To make it clear: I WILL eventually update this laptop to Buster, but after enduring the breakages train of the two prior Debian releases during Testing, I had decided this time to stay away from the kitchen while Buster brews its way into Stable.

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™
Posted on 19-04-29, 19:46 in Building Dolphin on Debian Stable: problems! (revision 1)
Dinosaur

Post: #277 of 1285
Since: 10-30-18

Last post: 21 days
Last view: 6 hours
Decided to give another try to clang-3.8 after finding a workaround here: https://stackoverflow.com/questions/32742741/clang-error-with-stdunique-ptr

Now the brick wall du jour is this:
[ 23%] Linking CXX executable ../../../Binaries/traversal_server
/usr/bin/ld: CMakeFiles/common.dir/Random.cpp.o: referencia sin definir al símbolo '__cxa_thread_atexit@@CXXABI_1.3.7'
//usr/lib/x86_64-linux-gnu/libstdc++.so.6: error adding symbols: DSO missing from command line
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Source/Core/Common/CMakeFiles/traversal_server.dir/build.make:94: fallo en las instrucciones para el objetivo 'Binaries/traversal_server'
make[2]: *** [Binaries/traversal_server] Error 1
CMakeFiles/Makefile2:971: fallo en las instrucciones para el objetivo 'Source/Core/Common/CMakeFiles/traversal_server.dir/all'
make[1]: *** [Source/Core/Common/CMakeFiles/traversal_server.dir/all] Error 2
Makefile:151: fallo en las instrucciones para el objetivo 'all'
make: *** [all] Error 2

Oh joy, a LINKER error.

Tried adding -lstdc++ to LDFLAGS/CMAKE_whatever_LINKER_FLAGS, without avail.

FUN FUN FUN.


UPDATE: Replacing "-stdlib=libc++" with "-stdlib=libstdc++" and switching -lc++ with -lstdc++ fixes this.

BUT! Now build dies near the end:
[ 80%] Building CXX object Source/Core/DolphinQt/CMakeFiles/dolphin-emu.dir/Config/VerifyWidget.cpp.o
In file included from /home/tomman/workbench/dolphin-emu/Source/Core/DolphinQt/Config/VerifyWidget.cpp:19:
In file included from /home/tomman/workbench/dolphin-emu/Source/Core/DiscIO/Volume.h:18:
In file included from /home/tomman/workbench/dolphin-emu/Source/Core/Core/IOS/ES/Formats.h:19:
In file included from /home/tomman/workbench/dolphin-emu/Source/Core/Core/IOS/Device.h:14:
In file included from /home/tomman/workbench/dolphin-emu/Source/Core/Core/IOS/IOS.h:18:
In file included from /home/tomman/workbench/dolphin-emu/Source/Core/Core/IOS/IOSC.h:16:
/home/tomman/workbench/dolphin-emu/Source/Core/Common/Crypto/ec.h:11:17: warning: nested namespace definition is a C++1z extension; define each
namespace separately [-Wc++1z-extensions]
namespace Common::ec
^~~~
In file included from /home/tomman/workbench/dolphin-emu/Source/Core/DolphinQt/Config/VerifyWidget.cpp:19:
In file included from /home/tomman/workbench/dolphin-emu/Source/Core/DiscIO/Volume.h:18:
In file included from /home/tomman/workbench/dolphin-emu/Source/Core/Core/IOS/ES/Formats.h:19:
/home/tomman/workbench/dolphin-emu/Source/Core/Core/IOS/Device.h:16:14: warning: nested namespace definition is a C++1z extension; define each
namespace separately [-Wc++1z-extensions]
namespace IOS::HLE
^~~~~
In file included from /home/tomman/workbench/dolphin-emu/Source/Core/DolphinQt/Config/VerifyWidget.cpp:19:
In file included from /home/tomman/workbench/dolphin-emu/Source/Core/DiscIO/Volume.h:18:
/home/tomman/workbench/dolphin-emu/Source/Core/Core/IOS/ES/Formats.h:27:14: warning: nested namespace definition is a C++1z extension; define
each namespace separately [-Wc++1z-extensions]
namespace HLE::FS
^~~~
In file included from /home/tomman/workbench/dolphin-emu/Source/Core/DolphinQt/Config/VerifyWidget.cpp:20:
/home/tomman/workbench/dolphin-emu/Source/Core/DiscIO/VolumeVerifier.h:32:14: warning: nested namespace definition is a C++1z extension; define
each namespace separately [-Wc++1z-extensions]
namespace IOS::ES
^~~~
/home/tomman/workbench/dolphin-emu/Source/Core/DolphinQt/Config/VerifyWidget.cpp:77:15: error: cannot refer to class template 'pair' without a
template argument list
return std::pair(checkbox, line_edit);
~~~~~^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/../../../../include/c++/6.3.0/bits/stl_pair.h:194:12: note: template is declared here
struct pair
^
/home/tomman/workbench/dolphin-emu/Source/Core/DolphinQt/Config/VerifyWidget.cpp:130:13: warning: enumeration value 'None' not handled in switch
[-Wswitch]
switch (problem.severity)
^
5 warnings and 1 error generated.
Source/Core/DolphinQt/CMakeFiles/dolphin-emu.dir/build.make:1127: fallo en las instrucciones para el objetivo 'Source/Core/DolphinQt/CMakeFiles/dolphin-emu.dir/Config/VerifyWidget.cpp.o'
make[2]: *** [Source/Core/DolphinQt/CMakeFiles/dolphin-emu.dir/Config/VerifyWidget.cpp.o] Error 1
CMakeFiles/Makefile2:1763: fallo en las instrucciones para el objetivo 'Source/Core/DolphinQt/CMakeFiles/dolphin-emu.dir/all'
make[1]: *** [Source/Core/DolphinQt/CMakeFiles/dolphin-emu.dir/all] Error 2
Makefile:151: fallo en las instrucciones para el objetivo 'all'
make: *** [all] Error 2


Awesomest. I love you too, C++.

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™
Posted on 19-04-29, 21:27 in Building Dolphin on Debian Stable: problems!
Dinosaur

Post: #278 of 1285
Since: 10-30-18

Last post: 21 days
Last view: 6 hours
FLAWLESS VICTORY



Step 1) Use this patch: https://gist.github.com/dilworks/6dd7caf8d70d46e98ba39dd808a66b05
Step 2) Invoke cmake with:
CC=clang CXX=clang++ CXXFLAGS+=-stdlib=libstdc++ LDFLAGS+=-lstdc++ cmake -DCMAKE_PREFIX_PATH=/opt/Qt/5.11.1/gcc_64/ ..

(adjust your Qt5 directory accordingly to your setup)
Step 3) make
Step 4) Go play videogames

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™
Dinosaur

Post: #279 of 1285
Since: 10-30-18

Last post: 21 days
Last view: 6 hours
The (Sad) State of Sega 32X nVidia Optimus under Linux, 2019 edition

tl;dr: It still sucks. AVOID. Stick to Intel IGPs or, if you're willing to endure ATi driver hell, wait for those Ryzen laptops to arrive. I guess you can also spend some serious cash on a gaming-grade or workstation-class laptop where you are guaranteed to get one and only ONE GPU, of the discrete variety. Hopefully.

I bought this Optimus-enabled dual-GPU laptop in late 2012. Back then, nVidia was refusing to support Optimus under anything that is not Windows, Nouveau support was simply not there, but the community still fought on and came up with a few hacky workarounds so we can at least use the hardware we've paid our hard earned money for.

Pick your poison:

- PRIME: This is "the way it is meant to be played™", that is, proper support for GPU offloading on hybrid graphics platforms under Linux. Except that nVidia still doesn't support PRIME for anything other than "run your desktop through the discrete GPU" (this may work for anyone that doesn't care about the heavy impact on battery life and excess heat on those designer laptops). Oh, and it's only available on some distros, mainly Ubuntu-based ones. Supposedly complete support is "coming soon™", but for anyone of us still stuck at Fermi GPUs, it's too late already (as our GPUs were moved to the legacy blob very recently). On the Nouveau front you can already enjoy proper GPU offloading... but then you might as well play on the Intel IGP and pretend there is no secondary GPU because reclocking support is not there (except for Maxwell GPUs; Fermi support is "still being worked on", and thanks to the signed firmware bullshittery by nVidia, there is little hope for Pascal and beyond)

- Bumblebee: The most popular hack out there. It mostly works, but it comes with a rather high performance hit (still better than your Intel IGP, tho), lag is a concern for any serious player, there are several display backends (VirtualGL, primus) that are all them terrible in its own ways, it can be very fragile at times (from failures to turn off the discrete GPU when not being used, to outright refusing to work at all on some setups). On top of that, Bumblebee will never support Vulkan, and the project is essentially dead as upstream has not received a single commit in 6 years (!!!)

- nvidia-xrun: The new kid on the block, this hack comes from a guy that noticed the big waste on performance of the Bumblebee way. Supposedly this way you can get full performance from your discrete GPU (making it very similar to PRIME, in principle), but then this relies on "let's run a secondary X server for all apps you want to run on the discrete GPU". It HAS to be invoked from a good ol' TTY console. Running Steam (the most popular use case) is not straightforward; instead you have to bring your own window manager so Steam doesn't lose its mind, and then you've effectively replicated PRIME the long way (it's nice for playing Euro Truck Simulator 2, but do you really want to run a lag-sensitive game like Super Hexagon too!?). Might as well use that way permanently and forget about power saving.

Believe me: I tried my best to avoid Optimus laptops back then, but all AMD-based laptops in the local market were pure basement tier APU garbage. Looks like things haven't improved that much since then, because even nowadays I still hear tales from people having a hard time looking for laptops with discrete GPUs without having to go through the Optimus way since nVidia still dominates the mobile discrete GPU market.



Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™
Posted on 19-04-30, 16:27 in Building Dolphin on Debian Stable: problems!
Dinosaur

Post: #281 of 1285
Since: 10-30-18

Last post: 21 days
Last view: 6 hours
Muramasa was the very reason of why I got into Wii/GC emulation, and that's only because I played it on a roommate's Wii back at my college dorm era.

I really loved the game. But... it was a Wii exclusive.

But that was at mid '10. There was this promising GameCube emulator named "Dolphin", and the rage at the time was its just-implemented Wii emulation. Not many games ran, and unfortunately Muramasa was one of those that were unplayable beyond a certain point (that I never reached back then), plus it was plagued with graphic glitches all the way. But hey, there was I, sending patches to the Dolphin team because keyboard input on X11 was a mess back then ("I came to play Muramasa: The Demon Blade, not Hackamasa: the X11Input Blade!"). My name is referenced in a lone commit that has been long buried with the years elapsed since then.

And yes, Dolphin ran at a respectable 60% with Muramasa on my T5500 with the proprietary ATi blob back then (nowadays Dolphin wouldn't even boot on such a setup). Muramasa was actually PLAYABLE, albeit laggy at times. I didn't cared, I was playing that damn good game on my laptop, back when the Wii was still a hot seller! I even bought a real Wiimote solely for that game! (although I ended using it for Zelda OoT not long after that)

Years later I would finish the game once with Momohime on my Steamlaptop, this time at a solid 60FPS all the way, albeit with minor graphic glitches that have been fixed since then.

I still wish Muramasa would get a PC port someday. Back then, a good friend of mine (the owner of the Wii where I played the very same PAL rip of the game I play today on Dolphin, solely because it was actually localized to Spanish... unlike the NTSC-U version) told me that "butbutbut Nintendo paid for the exclusive!!!". Years later, it got a enhanced Vita port out of nowhere. But then, the Vita is dead, and it is not a PC.
Come on, Marvelous! It would sell like hotcakes on Steam, just ask Bayonetta!

Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65
    Main » tomman » List of posts
    Get an ad blocker.