But if you're a text-editing geek then you might not mind learning a few paradigms. It doesn't matter how well your editor matches everything else if you plan to become an expert.
ZDNet's measurements are very far from what I get (and yes, I have measured). Windows and Linux actually take roughly the same amount of time to boot on my computers, except Linux doesn't make me wait for the system to become usable.
I think everyone just started using Acme. I never quite got the idea behind rc myself. I can't imagine why a port of an existing shell wouldn't have been a better choice.
And another big one: DirectX contains pretty much everything you need to write a game. It's got graphics, sound, and input APIs. OpenGL is just a 3d API. DirectX's counterpart in the oss world would more properly be SDL.
With recent software ALSA should automatically use software mixing. I don't think it will do it with its OSS emulation though. It's still a little screwy, but not so much that problems are constant.
You might want to give the latest version of DOSBox (came out yesterday or so) a shot. From what I've tested so far, it's a lot better than the last, which wasn't even that bad. Especially in the speed department.
Sure, and I agree that it's easy to make a lousy linear game. I just don't think that linearity necessarily makes a game bad, or that there's any reason that games are "meant to be" free-form. Myst 3 and Halo were fairly linear, but both were pretty good games. In the end, many games boil down to doing things in the "right" order.
I think I lost my train of thought and responded to something you didn't say. What I originally intended to say is that games have another dimension along which they can diversify, ranging from linear to free-form. The former can be nearly a movie (like Star Trek: Klingon for instance, and many works of interactive fiction), or it can be more in the style of Doom 3. I don't see any reason that a game tending towards this end of the freedom spectrum is necessarily inferior, any more than a movie is inferior to a game. Gamers often get so hung up on linearity (after suffering through snooze-fests like Doom 3) that they consider it completely a bad thing, but no one minds it when they don't decide where a movie goes. Perhaps "interactive movies" is a better term for games which adopt a linear storytelling approach, but interactivity still gives them an essential claim to gamehood.
I think you're overlooking the fact that there's room for more than one type of game, just like there's more than one type of movie. Not just stylistic genres, but some movies aim to be profound while others just aim to be exciting. I don't see any reason games can't do the same thing. Just like there's art music and there is hardcore punk.
(eq eyesight visual-ability). "Visual ability" happens to be pretty much the definition of the word, encompassing both ability to detect light and ability to interpret it.
Or anything which supports dragging a widget. I believe you could even do it fairly easily in gtk. Any widget seems able to serve as a drag source or destination. Just set up the proper callbacks (with a data transfer mechanism) and you can remove and add widgets with a drag all you like. Of course your application would still have to provide some way to decide what a new widget would do (when I drag a search box from my address book to my media player does it keep listing addresses or search my music library?). If you want to be able to drag non-standard widgets then you probably do want a dynamic language, or at least a shared environment that programs will run in.
I think you've got those turned around. Dragging a widget from one application to another would not be especially difficult to make happen. They would have to have some way to communicate the change (good luck getting that picked up... drag-and-drop file saving isn't even common yet), but assuming that each programs considers its windows to be reconfigurable, you've got a common pool of widgets, and a way for your programs to communicate, the problem is more one of actually writing a bunch of programs that agree to work together than a technical challenge. Making metadata out of an mp3 file or image strikes me as pretty tricky, and knowing what to do with that data as even trickier.
Of all the horrible examples you might have chosen... a Lisp program can't even be guaranteed to run the same in different Lisps on the *same* platform.
Slashdot Mirror
I think that screenshot was an example of multiple paned views in one window. It's not the configuration a user would normally see.
It would be nice for people who are stuck on Windows to have a more functional desktop available.
It's better than stamp collecting.
But if you're a text-editing geek then you might not mind learning a few paradigms. It doesn't matter how well your editor matches everything else if you plan to become an expert.
ZDNet's measurements are very far from what I get (and yes, I have measured). Windows and Linux actually take roughly the same amount of time to boot on my computers, except Linux doesn't make me wait for the system to become usable.
I think everyone just started using Acme. I never quite got the idea behind rc myself. I can't imagine why a port of an existing shell wouldn't have been a better choice.
You make it sound like arguing isn't worth doing for its own sake.
And another big one: DirectX contains pretty much everything you need to write a game. It's got graphics, sound, and input APIs. OpenGL is just a 3d API. DirectX's counterpart in the oss world would more properly be SDL.
Dense textures as well. Metal is often harmonically simpler (not always), but distorted guitars, basses, and cymbals have a very thick spectrum.
What are you recovering from? Head-banging related injuries?
AND THEY ALL TYPE IN BOLD LETTERS.
Lameness filter, yadda, yadda, yadda.
He caught it in only four minutes....
With recent software ALSA should automatically use software mixing. I don't think it will do it with its OSS emulation though. It's still a little screwy, but not so much that problems are constant.
You might want to give the latest version of DOSBox (came out yesterday or so) a shot. From what I've tested so far, it's a lot better than the last, which wasn't even that bad. Especially in the speed department.
There shouldn't be a question mark. You're just reading selectively in a pathetic attempt to find more errors?
IIRC, the atmosphere is so thin that by the time you were going fast enough to get off the ground you wouldn't be able to actually maneuver.
Sure, and I agree that it's easy to make a lousy linear game. I just don't think that linearity necessarily makes a game bad, or that there's any reason that games are "meant to be" free-form. Myst 3 and Halo were fairly linear, but both were pretty good games. In the end, many games boil down to doing things in the "right" order.
I think I lost my train of thought and responded to something you didn't say. What I originally intended to say is that games have another dimension along which they can diversify, ranging from linear to free-form. The former can be nearly a movie (like Star Trek: Klingon for instance, and many works of interactive fiction), or it can be more in the style of Doom 3. I don't see any reason that a game tending towards this end of the freedom spectrum is necessarily inferior, any more than a movie is inferior to a game. Gamers often get so hung up on linearity (after suffering through snooze-fests like Doom 3) that they consider it completely a bad thing, but no one minds it when they don't decide where a movie goes. Perhaps "interactive movies" is a better term for games which adopt a linear storytelling approach, but interactivity still gives them an essential claim to gamehood.
I think you're overlooking the fact that there's room for more than one type of game, just like there's more than one type of movie. Not just stylistic genres, but some movies aim to be profound while others just aim to be exciting. I don't see any reason games can't do the same thing. Just like there's art music and there is hardcore punk.
(eq eyesight visual-ability). "Visual ability" happens to be pretty much the definition of the word, encompassing both ability to detect light and ability to interpret it.
Or anything which supports dragging a widget. I believe you could even do it fairly easily in gtk. Any widget seems able to serve as a drag source or destination. Just set up the proper callbacks (with a data transfer mechanism) and you can remove and add widgets with a drag all you like. Of course your application would still have to provide some way to decide what a new widget would do (when I drag a search box from my address book to my media player does it keep listing addresses or search my music library?). If you want to be able to drag non-standard widgets then you probably do want a dynamic language, or at least a shared environment that programs will run in.
I think you've got those turned around. Dragging a widget from one application to another would not be especially difficult to make happen. They would have to have some way to communicate the change (good luck getting that picked up... drag-and-drop file saving isn't even common yet), but assuming that each programs considers its windows to be reconfigurable, you've got a common pool of widgets, and a way for your programs to communicate, the problem is more one of actually writing a bunch of programs that agree to work together than a technical challenge. Making metadata out of an mp3 file or image strikes me as pretty tricky, and knowing what to do with that data as even trickier.
Try the jeans at Old Navy.
Of all the horrible examples you might have chosen... a Lisp program can't even be guaranteed to run the same in different Lisps on the *same* platform.
It's a good thing we've got you here to clear everything up.
I wonder if there's a gene for believing you have all the answers.