The review referred to in the original post seems to be somewhat unreachable (it can't be slashdotted yet, can it?), so you may want to try Loki's page for the game
here.
what about us jaded and burnt out programmers?
who is creating a program for us to turn to a
life of crime and hit the streets popping caps
and offing rival members and shit so that we can
have some excitement in our lives?
Try GTA2 (warning: massively Flash-bloated but official site).
For Amiga music, I'd recommend DeliPlayer, which plays tons of old Amiga formats (190 according to the home page) very accurately. Newer PC formats (such as Impulse Tracker) are best handled by the ModPlug player.
Whether an emulator works well or not depends entirely on what you're emulating. My old P120 handled lots of mid-eighties sprite-based games perfectly in MAME, but had major problems running e.g. Mortal Kombat and other more recent games in MAME.
PS/2 users will probably be able to run most of the golden oldies, but I doubt it'll emulate modern hardware (recent arcade machines, consoles, whatever) very well. Luckily, the PS/2 doesn't need PlayStation emulation. B-)
> Actually, most of the games I know are enthusiastic about Linux. Whether they have the skills to administer a Linux system is another story, of course.
> Actually, I ported it, while working for Loki.
> I have since added support for TV output.
Before this gets modded down as a troll, I'd like to point out that according to the comments in the source code, the PS2 code in SDL is written by Sam Lantinga (slouken@devolution.com), which is who the poster of the parent says he is. This is just to avoid rampant confusion like in the Tux Racer discussion yesterday, with people ignoring Patry's attempt to bring sanity into the discussion. B-)
For further info on new features (such as the TV output feature (currently only in CVS)), see the ChangeLog.
Excluding graphic work/rendering and games, obviously, has anyone ever sat at their PC and said "Oh my, the window redraw rate in this is slowing me down..."?
Yes. I once tried to run an animated double-buffered Swing-based Java app in a maximized window remotely over a 56 kbps modem... The window redraw rate was too slow for a usable slide show, let alone smooth animation.
If the new system isn't a lot better than the old one but fully backwards compatible (like the C128 and the C64), nobody will bother to write native applications. On the other hand, if the new system is a lot better in some important aspect, people will start writing for it to make better products even if the new system is backwards compatible (e.g. Spectrum 128 and 48, VGA and EGA, Sound Blaster and Adlib).
What Linux needs to provide in order for native ports to be made is added value, really. If Linux runs Windows games well enough, there is no point in writing Linux games, unless a native Linux game is noticably better than the Windows game.
Seriously, can anyone think of a way Linux games could be better than Windows games (aside from not having to reboot to Windows?).
> Anyone know if it is even possible to write a language which can do this???
Actually, such a beast already exists. For example ANSI/ISO standard C compiles nicely on Windows, Linux, BeOS, MacOS and whatever, and the only real problem is finding a graphics and sound API that works on all the operating systems you want to use. SDL together with OpenGL provides practically all of the features needed for modern games (it doesn't appear to support 3D sound and suchlike).
If you write a game using standard C (or C++ for that matter) using only the SDL and OpenGL APIs, it should recompile without changes on tons of operating systems, including Win9x, NT, BeOS and most Unix-like systems.
As most games are written in C or C++, making the transition should be hard, especially if the programmer is familiar with OpenGL.
Probably for the same reason a lot of people here want to run their games under Linux; many people object to being forced to sit through several minutes of rebooting.
Furthermore, supplying each game with its own OS distribution would require that each game's OS be separately configured for the hardware in each computer, just like with all those good old MS-DOS games. Of course, the installer could try to steal this info from the OS under which it is run, but this may be difficult in some cases (new graphics card and old game; how do you work out which driver to use?). In the worst case, the poor gamer ends up having to get patches for each game's OS separately.
Essentially, human colour perception is based on the following:
The eye has three types of colour receptors, each with different sensitivity to different wavelengths. In other words, for any incoming combination of wavelengths, the eye measures three colour intensity values.
RGB monitors work on the principle that each of the primary colours (red, green, blue) stimulate one type of receptor much more than the others. By combining these colours suitably, we can produce the same result in the (normal) human eye (and thus the same subjective colour) as any possible wavelength distribution.
Of course, for tetrachromats, an RGB monitor is likely to generate a totally incorrect fourth colour component, so TV must look pretty weird to tetrachromats.
Interesting research topic: have tetrachromats study works of art to try to trace ancient tetrachromat artists (we can assume that the 4th component is wrong for artists with RGB vision).
Actually, the Bible states that Pi=3. Check 1 Kings 7:23. Apparently, some Americans once tried to implement Pi=3, but the hexagonal wheels (circumference=distance between opposite corners*3 on a hexagon) turned them off...
I'm aware that several solutions exist for these problems - what's causing trouble is the fact that there are several incompatible solutions out there!
Red Hat also seems to have a program that's supposed to update menu items on supported WMs (KDE, Gnome and FVWM at least), but few people seem to take the necessary steps to make their RPM packages take advantage of this.
This is entirely wrong. The PC keyboard can easily be read from directly by a program running under real mode, or a protected mode program with rights to access the port (usually the operating system's keyboard driver).
In practice, only some DOS-based programs use the BIOS for keyboard access; DOS games usually read the hardware directly to be able to handle multiple simultaneous keypresses, and stuff under Windows/Linux/BeOS/whatever has to ask the operating system.
The last point here is really the important one; what Linux, and Unix in general, really needs is a quick and easy _standard_ way to install software. Compiling from source, while tolerable when it works without modifications, is not really user friendly. If something goes wrong during compilation (say, you don't have a header file expected by the source), most users probably won't have a clue what to do, and those who have can easily lose hours fixing something like this. Package managers like RPM, especially when a graphical front-end is available, make installation easy enough in most cases, but have a few problems:
a) Different distributions use different formats. Is it too hard to agree on a unified package format, instead of having different package managers for Red Hat, Debian, et.c.? Correcting this would help a lot.
b) We really need a way to tell _any_ desktop environment that a new program has been installed, and that it should update its start menus or whatever accordingly. The current system where a user has to dig out a freshly installed program by hand from somewhere on his/her hard disk is horrible.
c) Precompiled binaries tend to rely on very specific library versions. In many cases, I've tried to install one package, only to find that I have to update or install another to get it to work, only to find that the second package needs a third to work, and so on. Most Windows apps solve this by bunching together all the required shared libraries with the program; this may be a bloated solution, but at least it's simple. A more efficient idea, of course, would be to give the package managing program the ability to find and install dependencies by itself (does Debian do this?) instead of complaining and leaving it up to the user to hunt for updates (like RPM).
As with the BSA, the Free Software people have to work together.
The BSA gets anonymous notifications from people who believe it's wrong that their company uses pirated software. Surely the FSF (for example) would be happy to accept anonymous reports of misuse of Free Software. And isn't it reasonable to expect more programmers to be willing to report their company for sake of the Free Software movement than for mere money? I assume that the FSF can't afford to bribe people like the BSA, so they'll have to try to appeal to people's sense of right and wrong and/or GNUistic convictions.
Spies. Good, old-fashioned spies. Basically, all you have to do is find one employee with access to the source willing to tell you whether it contains GPL:ed code or not. If it does, (IANAL) the same laws that allow raids on supected users of pirated software should allow checking of GPL compliancy even against a corporation's will.
In other words, use the same tactics the Business Software Alliance uses to hunt down pirated software.
Can't one compensate for the effects of inductance with a suitable amount of capacitance? I seem to recall that this is a commonly-used technique in long-distance power transmission.
This can be derived from Z^2=R^2+(X_L-X_C)^2, where X_L=2*pi*f*L and X_C=1/(2*pi*f*C) - just adjust C until X_L-X_C is zero. You should be able to find this in any decent physics book.
Maybe this could be used to cure the Slashdot effect - for a few hours after an article is posted, leave all the pages referenced in the article floating around on the network. Instead of slashdotting an unsuspecting server, readers get a copy from the nearest router.
As usual, this article only covers American law. For the sake of comparison, under Finnish law, fair use apparently (IANAL, I may have misunderstood something) takes priority over license agreements (especially ones that pop up in installers). In practice, this means that a company can't prevent you from making backup copies, transferring to other media, quoting, et.c.. Fair use also allows you to reverse engineer anything you're licensed to use.
Slashdot Mirror
It probably means that when you chop the polygonal head of a monster off, all the little polygons in its head die.
The review referred to in the original post seems to be somewhat unreachable (it can't be slashdotted yet, can it?), so you may want to try Loki's page for the game
here.
what about us jaded and burnt out programmers? who is creating a program for us to turn to a life of crime and hit the streets popping caps and offing rival members and shit so that we can have some excitement in our lives? Try GTA2 (warning: massively Flash-bloated but official site).
Quoting from the specs PDF:
-
Now you can share media within and outside the home, access videos over the Internet and manage your home entertainment.
-
Video sharing inside and outside the home.
- Video sharing with friends and family owning ReplayTV 4000 units
I'd say that makes it clear that you can send video over the Internet to another one of these gizmos.For Amiga music, I'd recommend DeliPlayer, which plays tons of old Amiga formats (190 according to the home page) very accurately. Newer PC formats (such as Impulse Tracker) are best handled by the ModPlug player.
Whether an emulator works well or not depends entirely on what you're emulating. My old P120 handled lots of mid-eighties sprite-based games perfectly in MAME, but had major problems running e.g. Mortal Kombat and other more recent games in MAME.
PS/2 users will probably be able to run most of the golden oldies, but I doubt it'll emulate modern hardware (recent arcade machines, consoles, whatever) very well. Luckily, the PS/2 doesn't need PlayStation emulation. B-)
> Actually, most of the games I know are enthusiastic about Linux. Whether they have the skills to administer a Linux system is another story, of course.
How about this little administration tool?
> Actually, I ported it, while working for Loki.
> I have since added support for TV output.
Before this gets modded down as a troll, I'd like to point out that according to the comments in the source code, the PS2 code in SDL is written by Sam Lantinga (slouken@devolution.com), which is who the poster of the parent says he is. This is just to avoid rampant confusion like in the Tux Racer discussion yesterday, with people ignoring Patry's attempt to bring sanity into the discussion. B-)
For further info on new features (such as the TV output feature (currently only in CVS)), see the ChangeLog.
> > I am a senior at Brandeis University and we do have a real turing machine there.
;-)
> Really? Where do you keep the infinitely-long paper tape?
This sort of problem is easily solved by one of these paper machines, a small army with chainsaws and a large forest.
Yes. I once tried to run an animated double-buffered Swing-based Java app in a maximized window remotely over a 56 kbps modem... The window redraw rate was too slow for a usable slide show, let alone smooth animation.
If the new system isn't a lot better than the old one but fully backwards compatible (like the C128 and the C64), nobody will bother to write native applications. On the other hand, if the new system is a lot better in some important aspect, people will start writing for it to make better products even if the new system is backwards compatible (e.g. Spectrum 128 and 48, VGA and EGA, Sound Blaster and Adlib).
What Linux needs to provide in order for native ports to be made is added value, really. If Linux runs Windows games well enough, there is no point in writing Linux games, unless a native Linux game is noticably better than the Windows game.
Seriously, can anyone think of a way Linux games could be better than Windows games (aside from not having to reboot to Windows?).
> Anyone know if it is even possible to write a language which can do this???
Actually, such a beast already exists. For example ANSI/ISO standard C compiles nicely on Windows, Linux, BeOS, MacOS and whatever, and the only real problem is finding a graphics and sound API that works on all the operating systems you want to use. SDL together with OpenGL provides practically all of the features needed for modern games (it doesn't appear to support 3D sound and suchlike).
If you write a game using standard C (or C++ for that matter) using only the SDL and OpenGL APIs, it should recompile without changes on tons of operating systems, including Win9x, NT, BeOS and most Unix-like systems.
As most games are written in C or C++, making the transition should be hard, especially if the programmer is familiar with OpenGL.
> So why isn't anyone doing this?
Probably for the same reason a lot of people here want to run their games under Linux; many people object to being forced to sit through several minutes of rebooting.
Furthermore, supplying each game with its own OS distribution would require that each game's OS be separately configured for the hardware in each computer, just like with all those good old MS-DOS games. Of course, the installer could try to steal this info from the OS under which it is run, but this may be difficult in some cases (new graphics card and old game; how do you work out which driver to use?). In the worst case, the poor gamer ends up having to get patches for each game's OS separately.
Disclaimer: I am not an eye expert.
Essentially, human colour perception is based on the following:
The eye has three types of colour receptors, each with different sensitivity to different wavelengths. In other words, for any incoming combination of wavelengths, the eye measures three colour intensity values.
RGB monitors work on the principle that each of the primary colours (red, green, blue) stimulate one type of receptor much more than the others. By combining these colours suitably, we can produce the same result in the (normal) human eye (and thus the same subjective colour) as any possible wavelength distribution.
Of course, for tetrachromats, an RGB monitor is likely to generate a totally incorrect fourth colour component, so TV must look pretty weird to tetrachromats.
Interesting research topic: have tetrachromats study works of art to try to trace ancient tetrachromat artists (we can assume that the 4th component is wrong for artists with RGB vision).
The grammatical errors are there to confuse any attempt at parsing the sentences in order to compensate for the odd spelings.
Example: "All your base are belong to us.". Probably crashes most automatic parsers that expect English. B-)
Actually, the Bible states that Pi=3. Check 1 Kings 7:23. Apparently, some Americans once tried to implement Pi=3, but the hexagonal wheels (circumference=distance between opposite corners*3 on a hexagon) turned them off...
I'm aware that several solutions exist for these problems - what's causing trouble is the fact that there are several incompatible solutions out there!
Red Hat also seems to have a program that's supposed to update menu items on supported WMs (KDE, Gnome and FVWM at least), but few people seem to take the necessary steps to make their RPM packages take advantage of this.
This is entirely wrong. The PC keyboard can easily be read from directly by a program running under real mode, or a protected mode program with rights to access the port (usually the operating system's keyboard driver).
Specifics at PC Games Programmer's Encyclopedia - Programming the Keyboard.
In practice, only some DOS-based programs use the BIOS for keyboard access; DOS games usually read the hardware directly to be able to handle multiple simultaneous keypresses, and stuff under Windows/Linux/BeOS/whatever has to ask the operating system.
The last point here is really the important one; what Linux, and Unix in general, really needs is a quick and easy _standard_ way to install software. Compiling from source, while tolerable when it works without modifications, is not really user friendly. If something goes wrong during compilation (say, you don't have a header file expected by the source), most users probably won't have a clue what to do, and those who have can easily lose hours fixing something like this. Package managers like RPM, especially when a graphical front-end is available, make installation easy enough in most cases, but have a few problems:
a) Different distributions use different formats. Is it too hard to agree on a unified package format, instead of having different package managers for Red Hat, Debian, et.c.? Correcting this would help a lot.
b) We really need a way to tell _any_ desktop environment that a new program has been installed, and that it should update its start menus or whatever accordingly. The current system where a user has to dig out a freshly installed program by hand from somewhere on his/her hard disk is horrible.
c) Precompiled binaries tend to rely on very specific library versions. In many cases, I've tried to install one package, only to find that I have to update or install another to get it to work, only to find that the second package needs a third to work, and so on. Most Windows apps solve this by bunching together all the required shared libraries with the program; this may be a bloated solution, but at least it's simple. A more efficient idea, of course, would be to give the package managing program the ability to find and install dependencies by itself (does Debian do this?) instead of complaining and leaving it up to the user to hunt for updates (like RPM).
As with the BSA, the Free Software people have to work together.
The BSA gets anonymous notifications from people who believe it's wrong that their company uses pirated software. Surely the FSF (for example) would be happy to accept anonymous reports of misuse of Free Software. And isn't it reasonable to expect more programmers to be willing to report their company for sake of the Free Software movement than for mere money? I assume that the FSF can't afford to bribe people like the BSA, so they'll have to try to appeal to people's sense of right and wrong and/or GNUistic convictions.
Spies. Good, old-fashioned spies. Basically, all you have to do is find one employee with access to the source willing to tell you whether it contains GPL:ed code or not. If it does, (IANAL) the same laws that allow raids on supected users of pirated software should allow checking of GPL compliancy even against a corporation's will.
In other words, use the same tactics the Business Software Alliance uses to hunt down pirated software.
Can't one compensate for the effects of inductance with a suitable amount of capacitance? I seem to recall that this is a commonly-used technique in long-distance power transmission.
This can be derived from Z^2=R^2+(X_L-X_C)^2, where X_L=2*pi*f*L and X_C=1/(2*pi*f*C) - just adjust C until X_L-X_C is zero. You should be able to find this in any decent physics book.
> Going AC->DC->AC is getting fairly cheap these days with power electronics. Of course it would be much nicer if we just got rid of AC.
Getting rid of AC would improve Slashdot a lot, at least. B-)
Maybe this could be used to cure the Slashdot effect - for a few hours after an article is posted, leave all the pages referenced in the article floating around on the network. Instead of slashdotting an unsuspecting server, readers get a copy from the nearest router.
The relevant law is available here (in Finnish).
In other words, this article hardly applies to most of Europe - as far as I can tell DeCSS is protected by law here!