First time since '09, I took a quick look at SDL-Ball, the awesome people maintaining the AUR package had made patches and a .desktop file, and I decided it was time to include those into the main release. I took the opportunity to also tweak the settings..
Unknown to most, SDL-Ball comes with background-images, and particle-system collision/response, but those features were turned off in the previous releases, to reduce cpu and gpu load and make SDL-Ball more playable on low-end systems), however, I think it's okay to include them now.
If anyone should be annoyed by these things being turned on as default, enter the game, go to settings, toggle the eye-candy setting off-on to produce a .config/sdl-ball/settings.ini file and turn off the background/collision detection from there.
There is no new content in SDL-Ball 1.02, so if you already have 1.01, you won't find anything of interest there. But now the "official" upstream package compiles again ;)
Wednesday, October 1, 2014
Thursday, September 25, 2014
Carmageddon 1, 2, 4: My thoughts - A pre/re/view
I recently acquired the early-access version of Carmageddon 4 (Carmageddon : Reincarnation) and as this is the newest addition in a family of games close to my (admittedly, weird, sick, psychotic) heart, I decided to write some of my thoughts about it, so this could be considered a sort of review/preview.
The early-access version included both the original carmageddon + splatpack + 3dfx patch + glide wrapper AND carmageddon 2 + glide wrapper, allowing both games to run at higher resolutions than they natively support. Therefore, let's have a short drive through memory-lane, back to the happy days of dos, and the controversy that was Carmageddon!
Running the game in DOSbox with 3dFX was not quite authentic, and there seemed to be "smoothness" trouble, however, the game is very visually pleasing in this mode. Driving the cars feels the same, and I seriously consider another playthrough.
The first Carmageddon was technologically advanced, it featured fast-paced fluid motion in a full 3D environment with 3D car models and gigantic maps at a time where we were still getting used to Quake. The game was packed with pop-culture references, and had the right kind of "grit", bright colors and good contrasts, it felt dirty and it was!
The humor in the game excellent and allows you to indulge completely in the mayhem.
The strongest points for this game is absolutely the car-handling, while being quite special and nothing like any other driving game, it is what makes Carmageddon so unique, it feels extremely solid once you get used to it. The cars react instantly to your input and feels very arcade, in a good way! Ramming opponents is very satisfying, and you get a good sense of force when hitting them.
Both Max Damage and Die Anna got upgraded cars, and they rocked, but gone was the Prat-cam from the previous game, and gone were the satisfying comments (both could be turned on/off with P, but why would anyone turn them off?), this might have been necessary to cram the graphics into the (usually) 4 MiB available texture-memory of early 3D cards, a problem that the first game did not have to deal with. While the Prat-cam view was missed, several new features were happily greeted, such as pedestrians being able to lose individual libs.
Where Carmageddon 1 had basically introduced deformable car-models, the successor introduced several tweaks to this feature, such as cars splitting in half, which, for obvious reasons, is awesome!
The game handles extremely well, and even at low-fps (I played this on a 100 MHz Pentium with a 4 MiB voodoo and 32 MiB memory), physics and cars worked very well. Environments were vary large, easy to navigate and the bright graphics made it easy to find your way around.
As with the first game, crashing into peds and cars felt extremely satisfying, there was a definite "umph" there, and I still catch myself moving my head when crashing hard into something (better not be a corner though, those will cut your car in half!) Everything about Carmageddon 2 is excellent, the game is great, and it set up the next game, Carmageddon 3 to be such a disappointment that I do not feel the need to include it in this brief story.
Another extremely important factor in both Carmageddon 1 and 2, is the open-world feel, there is no invisible walls, there is no angles that are "impossible" for your car (given the right starting angle and velocity, of cause), basically, it never feels like the game is trying to limit you or help you. Good example is the loop from costal-carnage from the first game, where you will simply fall off and land on your roof if you're too slow and the mission from the second game where you have to kill the escaped mental-patients.
A single patient is trapped on top of a small hill that looks impossible to climb, but with the right angle, it's quite easy. This is something extremely important to the series, feeling like you're in control, and nothing is stopping or helping you roam the world.
Even with the (by modern standards) modest selection of textures, all levels feel unique and extremely large, yet easy to navigate.
So, Carmageddon 1 and 2 are near perfect games in their own rights, difficult games to live up to.
My first impression of the game is that there's a legacy, and it's being used for good. The classic lineup screen is awesome.
I'm sure you'll be able to challenge your opponents and switch places using ordinary controls later in the development. For now, it serves as a reminder of good things to come.
The graphics are gorgeous, even at this stage, and they're no doubt going to be even more eye-tasty once the thing is finished. Shadows and lights are stunning, and I've spent a lot of time in the excellent replay mode, just looking around (there's a free-cam mode which I pray (and I'm not religious) will stay in the final version). I suspect that an in-car view view is on the way, and currently there is chase-cam and a cam "mounted" on the hood of your ve-H-icle.
The over-the-top lightening effects fit the theme well, and while I don't particularly like the dim/bleak colours and general lack of contrast of some of the environments, they do serve as a nice showoff of the light effects. Carmageddon is not all about visuals, but it is indeed much about visuals, and have always been. There is a nice gore-system in place, which I am sure will be limited only by the amount of bad-taste on my behalf and avaiable system-resources (as the former will have no limiting effect at all).
At this point, the game is not nearly gory enough, this is likely just content not yet produced, and I'm sure it will be vomit-inducing when it's done, I do believe that good things are in store for us. :) I imagine gibs merging with the surrounding environment. Carmageddon brings out the sickest in me, and I like it!
Right at this stage in development, what I await with most anticipation is how the car-handling will develop, as of now, it does feel a bit arcady (good), and it's clear that a very hefty physics simulation is underpinning these virtual vehicular slaughter-grounds, and that, in itself, is irrelevant to me, from a SW-engineer perspective, it is intriguing, it's awesome, it's interesting and something I'd also want to get my hands dirty on, were I to have the skills and chance. However, as a (granted, slightly disturbed) gamer, I care how many libs and blood-splatters will fill the air, and how awesomely they will paint the town red, and not much else. And oh boy am I certain they will!
This brings me to the current state of car-handling, something which I acknowledge is highly subjective, and therefore the following should be read with that in mind; They don't feel "Carma" enough right now. Certainly the wheel-spin action has been improved somewhat during actual drifting, but wheels don't spin or much influence the car during straight driving (which I for some reason want it to), the brake (space key) is not very attractive right now, it kind of just.. brakes your car, which I guess sounds obvious enough, but for some reason is not.. I'd expect it to bring the car into sideways drift if used together with turning, but this mechanic is now entirely reliant on wheel-spin. This is however minor, and something which is very likely to change in the future. I do appreciate that this game is target for the next generation of gamers, many of whom never played the first game upon release and might be put off by the unique handling, however, it might be something that "Classic Carma" mode can bring back. I mentioned it earlier, that the first Carmageddon games did not try to help you or limit you, and I do have the feeling that this is unfortunately no longer true. It might be due to physics that needs tweaking, but on several occasions, I've found geometry which looked traversable, but ended up completely blocking the car, instead of sending it into the insane-spinning-loop-whatever that I'd expect it to. However, that might also just be a glitch, and in such case, that observation should be loudly ignored (however one does something that ironic).
There's no doubt about it, Carmageddon: Reincarnation is a beautiful game, and the use of legacy cars is just awesome. Bringing the eagle back to its original design is in my opinion a good decision, and now we hopefully have the CPU cycles to make that sharp blade cut through steel and flesh! :)
The map is beautiful, and the maps are large, which is great! Maybe too large or too detailed? Right now, it is a bit difficult to quickly navigate, and the mini-view from the previous games have not (yet?) been implemented. However, again, it is an indication that good things are indeed coming. The minimap however is nearly useless to me, I've tweaked the settings to rotate it with the car (which is awesome), but the level of detail might be too high. While cursors indicating checkpoints and opponents are a big improvement, the actual graphics are right now a bit too muddy, or maybe the map is too small. I figure this is one of those things that can easily be made into an option (how damn large you want it? A secondary screen? Fine, we'll throw it on your secondary screen!).
Right now, what is grinding my gears a bit, is the feel of the car itself, and a lack of "umph" when driving into people, there's some intangible "bump" missing to the experience, something missing that makes brutally terminating these virtual lives feel a bit less brutal, less morbid and a bit less violent and disturbing than it should really be.
This brings me to the next thing I'm looking forward to, the pretty damn cool collision system. Right now, it is clear that the technology is solid, it works really well, making scratches and dents where you'd expect them to show up, and I figure that one of the things left to tweak is the "softness" of the cars. Having observed several car crashes in both the previous game that had good crash deformation (Carmageddon 2, I'm drooling at you), and youtube, it seems that cars are quite soft, and we are therefore presented with 3 conflicting interests:
This is what we like, it's beautiful and completely crumbled, however, it's also one step further damaged than the previous image, which in my opinion is too big a change, I'd like many more intermediate degrees of damage.
This brings me to the feel of wasting opponents, it is highly subjective, but again it lacks brutality, and it is likely just a matter of opinion and tweaking. But it does seem promising. The technology is no doubt there, and I believe the engine allow the developers a wide degree of freedom when it comes to these, most important parameters.
The crashes themselves are nothing short of spectacular, lots of particles, sparks and fire everywhere, and it is truly beautiful. Once again, the replay function is great, and single-stepping through the frames to find the perfect point in time, and then navigating around the scene to find the perfect angle is a major point. I do hope that intermediate frames will be possible in the future, and I suspect it shouldn't prove any technical challenge to allow smaller time-steps.
Finally, there is the vehicular combat system, which feels different, and maybe not in a good way, but I guess it is still open to tweaking. Cars seem heavy, very very heavy.. So do phone boxes, by the way, even if they are mostly air, they will slow down your car to the degree you'd expect from a massive block of concrete, unless you're playing as the "Gotcha" dumptruck, in which case, it's really awesome! :D But back to the cars.. It is no longer very possible (aka, it's extremely difficult)to "push" your opponents in head-on-head combat, which was previously one of the most enjoyable parts of combat. If there was one place where Carma might have helped the player, it was during combat, there was always an advantage of being the guy with most speed, or the guy ramming into someone who was stationary or up against a solid object, which, granted is unrealistic, but made the game more fun. I hope these mechanics will be brought back.
All in all, Carmageddon: Reincarnation seems on a the track to greatness, it is going to be solid, and I hope to see Die Anna and Max Damage rock it out on the Prat-Cam again.
It will also be very interesting to see what kind of modding we will be allowed to do, I already plan on doing a "violence extrêmement brutale" mod if the tools will allow it, let the streets overflow with the blood of the innocent! :)
So, in short, my modest wishlist for Carmageddon:Reincarnation
To Stainless Games: Amazing work, keep it up, we have high expectations of you, and it's your own fault for previously making awesome stuff and our expectation are high only because we know you're able to do it.
The early-access version included both the original carmageddon + splatpack + 3dfx patch + glide wrapper AND carmageddon 2 + glide wrapper, allowing both games to run at higher resolutions than they natively support. Therefore, let's have a short drive through memory-lane, back to the happy days of dos, and the controversy that was Carmageddon!
Carmageddon 1
For myself, this was the first driving game I found entertaining. There's something to be said against the physics, it just feels off, chunky, everything has a weird inertial feel to it, like every time you get airtime, it feels a bit like slow-motion.. And it is absolutely wonderful! This lack of "realism" may have been a result of limited processing power, but whatever it was, it was what made the game for me. For example, in order to stabilize your car when driving off an edge, set it to spin first, and it won't flip, the spinning (in my head) worked as a gyroscopic stabilizer, and is just one of the many small lovable quirks of the first two games. I do not know how much code was shared between Carmageddon 1 and 2, but they had a very similar feel. | |
| Carmageddon 1 3dFX with nGlide in DOSbox |
 | |||||
| Die Anna knows how to make sports interesting |
 | |
| "Sorry!" |
The strongest points for this game is absolutely the car-handling, while being quite special and nothing like any other driving game, it is what makes Carmageddon so unique, it feels extremely solid once you get used to it. The cars react instantly to your input and feels very arcade, in a good way! Ramming opponents is very satisfying, and you get a good sense of force when hitting them.
 |
| Crashes in Carmageddon feel brutal! |
There is nothing much else to say about the first Carmageddon game, it
is an excellent game, and to this date, one of my favorite games.
Carmageddon 2: Carpocalypse Now!
Highly anticipated, and not letting anyone down, Carmageddon 2 brought high-resolution, hardware-accelerated 3D carnage to the next level, while the graphics were more "cartoony", due to the texture filtering and higher resolution, it did not fail to deliver on gore and great fun. | ||
| Carma 2 was nice and gory like its predecessor |
The game handles extremely well, and even at low-fps (I played this on a 100 MHz Pentium with a 4 MiB voodoo and 32 MiB memory), physics and cars worked very well. Environments were vary large, easy to navigate and the bright graphics made it easy to find your way around.
As with the first game, crashing into peds and cars felt extremely satisfying, there was a definite "umph" there, and I still catch myself moving my head when crashing hard into something (better not be a corner though, those will cut your car in half!) Everything about Carmageddon 2 is excellent, the game is great, and it set up the next game, Carmageddon 3 to be such a disappointment that I do not feel the need to include it in this brief story.
Another extremely important factor in both Carmageddon 1 and 2, is the open-world feel, there is no invisible walls, there is no angles that are "impossible" for your car (given the right starting angle and velocity, of cause), basically, it never feels like the game is trying to limit you or help you. Good example is the loop from costal-carnage from the first game, where you will simply fall off and land on your roof if you're too slow and the mission from the second game where you have to kill the escaped mental-patients.
Even with the (by modern standards) modest selection of textures, all levels feel unique and extremely large, yet easy to navigate.
So, Carmageddon 1 and 2 are near perfect games in their own rights, difficult games to live up to.
Carmageddon: Reincarnation (It's carmageddon 4..)
These observations are from the early-access, pre-alpha version, and there's no clear indication of how far into the development progress it really is. I have this in mind when writing these observations, and so should you. I have no included any bugs, graphical glitches, missing features or performance issues into my considerations, these are all apparent for obvious reasons (it's not done yet), and therefore I will concentrate only on the positive improvements over the previous games, and on the current "feel" of the game, ignoring any issues. As a game developer (of much lesser scale/class/proficiency) and to a winder-degree, a software engineer, I can appreciate how tremendous a task this must be, and how seemingly gigantic issues might be a trivial on-liner fix, so there.. I'm not going to comment on those tings, that'd be unfair. Kudos for releasing this at all! It's a great privileged to get to see a bit of the "behind the scenes" stuff, where's the development console? | ||
| Let's start with the obvious, it's a got a classy loading screen. |
 |
| Will there be a "Max Damage or Die Anna" screen before this one in the final game? |
 |
| Good things are in store for us! |
Right at this stage in development, what I await with most anticipation is how the car-handling will develop, as of now, it does feel a bit arcady (good), and it's clear that a very hefty physics simulation is underpinning these virtual vehicular slaughter-grounds, and that, in itself, is irrelevant to me, from a SW-engineer perspective, it is intriguing, it's awesome, it's interesting and something I'd also want to get my hands dirty on, were I to have the skills and chance. However, as a (granted, slightly disturbed) gamer, I care how many libs and blood-splatters will fill the air, and how awesomely they will paint the town red, and not much else. And oh boy am I certain they will!
This brings me to the current state of car-handling, something which I acknowledge is highly subjective, and therefore the following should be read with that in mind; They don't feel "Carma" enough right now. Certainly the wheel-spin action has been improved somewhat during actual drifting, but wheels don't spin or much influence the car during straight driving (which I for some reason want it to), the brake (space key) is not very attractive right now, it kind of just.. brakes your car, which I guess sounds obvious enough, but for some reason is not.. I'd expect it to bring the car into sideways drift if used together with turning, but this mechanic is now entirely reliant on wheel-spin. This is however minor, and something which is very likely to change in the future. I do appreciate that this game is target for the next generation of gamers, many of whom never played the first game upon release and might be put off by the unique handling, however, it might be something that "Classic Carma" mode can bring back. I mentioned it earlier, that the first Carmageddon games did not try to help you or limit you, and I do have the feeling that this is unfortunately no longer true. It might be due to physics that needs tweaking, but on several occasions, I've found geometry which looked traversable, but ended up completely blocking the car, instead of sending it into the insane-spinning-loop-whatever that I'd expect it to. However, that might also just be a glitch, and in such case, that observation should be loudly ignored (however one does something that ironic).
 | ||
| Doesn't that blade just make you wanna divide pedestrians by 2 ? |
 | ||
| You're next after I'm finished turning this fine lad into mist. |
 | ||
| Beautiful deformation deforms beautifully. |
- Realistic looking deformation (the visual amount of damage correlates with handling)
- Awesome looking deformation (we want things to be pretty damn trashed)
- Cars that do not become un-driveable after minor crashes
This brings me to the feel of wasting opponents, it is highly subjective, but again it lacks brutality, and it is likely just a matter of opinion and tweaking. But it does seem promising. The technology is no doubt there, and I believe the engine allow the developers a wide degree of freedom when it comes to these, most important parameters.
It will also be very interesting to see what kind of modding we will be allowed to do, I already plan on doing a "violence extrêmement brutale" mod if the tools will allow it, let the streets overflow with the blood of the innocent! :)
So, in short, my modest wishlist for Carmageddon:Reincarnation
- Linux version - It's coming, wohoo!
- Deal more damage when crushing opponent/pedestrian against other objects.
- More blood/brutality on impact with pedestrians and opponents
- Not just camera shake
- Brake tweak (Spacebar)
- More arcade-like car handling/response
- Prat-cam!
- As much exposed api as possible for modding, we wanna hook into everything! ;)
 |
| Max is as charming as ever! |
To Stainless Games: Amazing work, keep it up, we have high expectations of you, and it's your own fault for previously making awesome stuff and our expectation are high only because we know you're able to do it.
Tuesday, September 9, 2014
A word of caution: MSI H97 PC MATE
First time since forever, I purcase a new system, and decide on a midrange system consisting of an I7-4790 with 32 GiB ram on an MSI h97 PC MATE motherboard assisted by a GeForce GTX 780 and powered by a 700 watt PSU from CoolerMaster.
The system booted perfectly, and I decided to venture away from my strict Linux-ways and do a dual-boot with Windows 7.
Installation goes smooth, and as a last, finishing touch, I decide to make sure the firmware on the motherboard is as new as shiny as it can be. This is where everything went south.
I have a look around in the BIOS, taking notice of the "M-Flash" utility, which surely must be the safest bet.
I jump to MSI's website, and download the latest BIOS, ,my old version was 7850v50, and I download 7850v3, extract it to the root of a fat32 formattet usb disk attached to one of the USB3 ports.
After rebooting to BIOS, I first save the old BIOS, just in case, the file saved is called E7850IMS.500.
Good, everything seems fine, I'm now choosing to upgrade with E7850IMS.530. I'm confronted by a screen telling me the obvious: "Don't turn off the power, restart or unplug anything while the upgrade is in progress, the system will reboot to continue"
I accept, and the system does indeed a reset, to darkness. Forever.
After useless advice from MSI (Clear CMOS, rip out battery, try again and again), I admit defeat. I tried booting the system with the usb disk in every possible USB port, I tried 3 different USB keys, it is dead, fans runs, but nothing else, no beep, no power led, nothing.
I continue my investigation as to what might have gone wrong:
I redownload the file and compare sha512 sums of both the file on the USB disk, and they unsurprisingly match.
I download the old version of the bios, also called E7850IMS.500, this should be the same software as I had on the board to begin with. I compare this with the backup that I did from the BIOS, well, first of all, the file from the website is 16777216 bytes (all versions from there are the same length), but the file written by the BIOS backup function is 6815744 bytes long.
Opening the files in a hex editor shows that the content of the file written by the BIOS is only a subset of the file from their website.. The content that the board wrote corresponds with what appears inside the file from the website at offset 0x9d0000.
So here's my question... (which MSI would not answer, even though I phrased it quite politely in my corrospondance with support): Why the FUCK does the BIOS write different files than it's supposed to read? Would it read both? or could the "M-Flesh" be so badly written that it just writes whatever file to the flash without checking as an absolute minimum the following conditions: "Does this file contain firmware for this board model?", "Does this file contain firmware in a format compatible with the current version of M-Flash?", "Is this firmware the expected size?" - I guess stuff like that is not important for a board which comes with no jtag, no schematic, no NOTHING that could possibly allow me to recover it?
Could it be that MSI ships their boards with a flash utility which is not able to flash their own updates ?
MSI has no documentation on how to update their BIOS, they state "use the provided utility", well, I did, it was provided by my motherboard, and if the onboard version can't handle the file format, it shouldn't fucking try, now should it ?
And how to flash the board correctly.. MSI is not able to give me any instructions, the README that comes with the updater tells nothing at all, the utility that comes with the board will not run under windows (which was why I resorted to M-Flash to begin with), and MSI is unable to tell me which version of DOS I should use with it..
Support finally told me this, in more broken English:
Flash the board by extracting the files into the root of an USB-Drive and using the M-Flash utility.
They told me this AFTER I told them exactly how I bricked the board.
They told me to do the exact same thing that I did, that's as close to a canned answer as it can be.
I'm done with MSI.
The system booted perfectly, and I decided to venture away from my strict Linux-ways and do a dual-boot with Windows 7.
Installation goes smooth, and as a last, finishing touch, I decide to make sure the firmware on the motherboard is as new as shiny as it can be. This is where everything went south.
I have a look around in the BIOS, taking notice of the "M-Flash" utility, which surely must be the safest bet.
I jump to MSI's website, and download the latest BIOS, ,my old version was 7850v50, and I download 7850v3, extract it to the root of a fat32 formattet usb disk attached to one of the USB3 ports.
After rebooting to BIOS, I first save the old BIOS, just in case, the file saved is called E7850IMS.500.
Good, everything seems fine, I'm now choosing to upgrade with E7850IMS.530. I'm confronted by a screen telling me the obvious: "Don't turn off the power, restart or unplug anything while the upgrade is in progress, the system will reboot to continue"
I accept, and the system does indeed a reset, to darkness. Forever.
After useless advice from MSI (Clear CMOS, rip out battery, try again and again), I admit defeat. I tried booting the system with the usb disk in every possible USB port, I tried 3 different USB keys, it is dead, fans runs, but nothing else, no beep, no power led, nothing.
I continue my investigation as to what might have gone wrong:
I redownload the file and compare sha512 sums of both the file on the USB disk, and they unsurprisingly match.
I download the old version of the bios, also called E7850IMS.500, this should be the same software as I had on the board to begin with. I compare this with the backup that I did from the BIOS, well, first of all, the file from the website is 16777216 bytes (all versions from there are the same length), but the file written by the BIOS backup function is 6815744 bytes long.
Opening the files in a hex editor shows that the content of the file written by the BIOS is only a subset of the file from their website.. The content that the board wrote corresponds with what appears inside the file from the website at offset 0x9d0000.
So here's my question... (which MSI would not answer, even though I phrased it quite politely in my corrospondance with support): Why the FUCK does the BIOS write different files than it's supposed to read? Would it read both? or could the "M-Flesh" be so badly written that it just writes whatever file to the flash without checking as an absolute minimum the following conditions: "Does this file contain firmware for this board model?", "Does this file contain firmware in a format compatible with the current version of M-Flash?", "Is this firmware the expected size?" - I guess stuff like that is not important for a board which comes with no jtag, no schematic, no NOTHING that could possibly allow me to recover it?
Could it be that MSI ships their boards with a flash utility which is not able to flash their own updates ?
MSI has no documentation on how to update their BIOS, they state "use the provided utility", well, I did, it was provided by my motherboard, and if the onboard version can't handle the file format, it shouldn't fucking try, now should it ?
And how to flash the board correctly.. MSI is not able to give me any instructions, the README that comes with the updater tells nothing at all, the utility that comes with the board will not run under windows (which was why I resorted to M-Flash to begin with), and MSI is unable to tell me which version of DOS I should use with it..
Support finally told me this, in more broken English:
Flash the board by extracting the files into the root of an USB-Drive and using the M-Flash utility.
They told me this AFTER I told them exactly how I bricked the board.
They told me to do the exact same thing that I did, that's as close to a canned answer as it can be.
I'm done with MSI.
Sunday, August 31, 2014
0d:00.0 System peripheral: Ricoh Co Ltd PCIe SDXC/MMC Host Controller
If you're running Archlinux and have trouble getting SD-Cards to work with a Rioch PCIe SDX/MMC reader, the following series of commands will work.
I found these via launchpad.
sudo rmmod sdhci
sudo modprobe sdhci
sudo modprobe sdhci_pci
I found these via launchpad.
sudo setpci -v -d 1180:e823 f9.B=fc
sudo setpci -v -d 1180:e823 150.B=10
sudo setpci -v -d 1180:e823 f9.B=00
sudo setpci -v -d 1180:e823 fc.B=01
sudo setpci -v -d 1180:e823 e1.B=32
sudo setpci -v -d 1180:e823 fc.B=00
sudo rmmod sdhci_pcisudo setpci -v -d 1180:e823 150.B=10
sudo setpci -v -d 1180:e823 f9.B=00
sudo setpci -v -d 1180:e823 fc.B=01
sudo setpci -v -d 1180:e823 e1.B=32
sudo setpci -v -d 1180:e823 fc.B=00
sudo rmmod sdhci
sudo modprobe sdhci
sudo modprobe sdhci_pci
Tuesday, June 24, 2014
Howto: Play RollerCoaster Tycoon 1 & 2 on wine
My current computing setup does not allow me to easily change resolution or depth on my display. Therefore, I was in quite a lot of trouble when I wanted to play RollerCoaster Tycoon.
When doing wine Rct2.exe I would get a solid black screen with the audio playing fine. My fix to this problem is installing the Xephyr server.
I'm on ArchLinux so packagenames and packagemanager commands may be specific.
First, install Xephyr and Wine (and whatever else you need)
$ sudo pacman -S xorg-server-xephyr wine
The original installer works fine in wine, so just install the game.
$ cd /path/to/rollercoasterdisc
$ wine Setup.exe
Now to the "tricky" part, you need two terminals, in the first one, start Xephyr:
$ Xephyr :1 -ac -screen 1280x1024x16
A black window appears, you're now running another X-Server in 16 bpp mode on display :1.
On the other terminal, go to wherever you installed RCT1 or 2
$ cd .wine/drive_c/blabha/RollerCoasterTycoon2/
Defining the DISPLAY variable will tell wine to start on screen :1 instead of :0.
$ DISPLAY=:1 wine ./Rct2.exe
Woho!
An interesting note is that I tried starting Xephyr in 8 bpp mode, but then I'd get the same black screen as with the standard method, don't ask.
When doing wine Rct2.exe I would get a solid black screen with the audio playing fine. My fix to this problem is installing the Xephyr server.
I'm on ArchLinux so packagenames and packagemanager commands may be specific.
First, install Xephyr and Wine (and whatever else you need)
$ sudo pacman -S xorg-server-xephyr wine
The original installer works fine in wine, so just install the game.
$ cd /path/to/rollercoasterdisc
$ wine Setup.exe
Now to the "tricky" part, you need two terminals, in the first one, start Xephyr:
$ Xephyr :1 -ac -screen 1280x1024x16
A black window appears, you're now running another X-Server in 16 bpp mode on display :1.
On the other terminal, go to wherever you installed RCT1 or 2
$ cd .wine/drive_c/blabha/RollerCoasterTycoon2/
Defining the DISPLAY variable will tell wine to start on screen :1 instead of :0.
$ DISPLAY=:1 wine ./Rct2.exe
Woho!
An interesting note is that I tried starting Xephyr in 8 bpp mode, but then I'd get the same black screen as with the standard method, don't ask.
 |
| RollerCoaster Tycoon 2 on Wine on Xephyr on ArchLinux |
Sunday, May 18, 2014
Installing Apache OpenOffice in Arch Linux
After trying and failing to get Libreoffice to work with Danish spellcheck, I gave up and decidede to install Apache OpenOffice, which by all accounts, seem like a more solid piece of software. However, this was not available in the official repositories, and I could not find any up to date, Danish versions on AUR, so I decided to give it a shot.
The only reason I've not submitted a PKGBUILD to AUR is that I can not find a direct link to the openoffice tarball. Anyway, here's how to install it:
$ makepkg
$ sudo pacman -U apache-openoffice-blablabla.tar.xz
Done, this does not include .desktop files and such, you can add these if you want, I don't care for them.
One thing that might be convenient though, is to add a symlink /usr/bin/soffice -> /opt/openoffice4/program/soffice so that office can be started with the "soffice" command and documents opened with the "soffice" binary, this will automatically open the writer, calc, draw, applications depending on the argument file.
$ ln -s /opt/openoffice4/program/soffice /usr/bin/soffice
That's it.
The only reason I've not submitted a PKGBUILD to AUR is that I can not find a direct link to the openoffice tarball. Anyway, here's how to install it:
- Install rpmextract ( sudo pacman -S rpmextract )
- Download the RPM bundle of OpenOffice for your architecture and language and extract it (tar xf Apacheblabla.tar.gz)
- When the bundle is unpacked you get a directory like en_US or da_DK or whichever language you downloaded.
- I'll use en-US as an example in the commands below, substitute as needed.
- Then move the RPMS directory into a newly created oooarch/src dir as shown:
$ mkdir -p oooarch/src/
$ mv en-US/RPMS oooarch/src - Now create a new file inside oooarch called PKGBUILD, and put the following text into it:
pkgname=apache-openoffice
pkgver=4.1.1 #or something
pkgrel=1
pkgdesc="Danish openoffice from Apache"
arch=('x86_64')
license=('GPL')
depends=('libidn')
makedepends=('rpmextract')
build() { - Then execute:
$ cd oooarch/src/
$ find *.rpm -exec echo rpmextract.sh {} \; >> ../PKGBUILD - Now open the PKGBUILD file again, and add the following text:
}
package() {
mv opt ${pkgdir}
}
$ makepkg
$ sudo pacman -U apache-openoffice-blablabla.tar.xz
Done, this does not include .desktop files and such, you can add these if you want, I don't care for them.
One thing that might be convenient though, is to add a symlink /usr/bin/soffice -> /opt/openoffice4/program/soffice so that office can be started with the "soffice" command and documents opened with the "soffice" binary, this will automatically open the writer, calc, draw, applications depending on the argument file.
$ ln -s /opt/openoffice4/program/soffice /usr/bin/soffice
That's it.
Subscribe to:
Posts (Atom)