Timetable of, like, 5 years or so is quite a good idea if it is to be a GOOD game. Just in the planning phase make it match hardware as it will be in 5 years, start with rough, simple engine and build the whole world, all the datafiles, then by the very end release the final engine to run that in final quality, on target hardware.
Maybe instead of giving cash, donate some of your old SUNs, SGIs etc, and help building it on a distributed architecture with really deep redundancy, where each component by itself isn't very reliable, but all together form a really strong cluster?
Asking for money is always the easiest way, and because of the number of people asking (Just look at all those PayPal Donate banners!) the chance of success is nearly null. What about taking a different path?
Typical outcome of sending 1.000.000 spam messages is 100 happy (though dumb) customers, 10.000 really pissed off people and mostly indifferent but rather hostile rest. The profit is no loss from those 10.000 and profit from those 100.
But if you send out spam to your voters, divided fifty-fifty for and against, the outcome is 50 votes gained (the other 50 would vote for you anyway) and 5.000 votes lost (people who decide they won't vote on a party that uses spam)
So... feel free to send. Just remember: Winners don't use spam!
If a company can casually replace GPL'ed code with something proprietary by SP1, good for them: they probably didn't need the GPL'ed code in the first place.
If they can, until SP1 or SP2, but not until the 1.0, just because time limits on 1.0 are so tight? And sure they didn't need GPL code, they just needed any cheap kludge to fill the hole until they can catch a breath and write it as it should be.
If management claims they didn't know it just means that management violated their duty to know what's going on. Firing the employee will not shield the company from liability.
That's GPL and FSF, not EULA and Microsoft! These guys have completely different approach to enforcing the agreement - they aren't into loud lawsuits and multimillion compensations, they just want the matters settled and GPL complied to. A few heads in the company may fall, the PR people will give a few speeches, an apologising article will appear, maybe some useful patch to the "accidentially implemented" code will be published, a donation made, infriging code removed and you'll see Slashdot crowds cheering, rejoicing and praising the violator's name, because "a lost lamb returned to the herd".
Sure it IS risky. But what better way to cut down on development cost and time while keeping all the rights to the code? Give the employees a murderous deadline and gently hint them that you don't care about how legal their solution is, as long as it works and they keep it secret. And replace GPL code with your own later, say, with service pack 1, when the product is already deployed three weeks before the competition could do it, when you already have the money, paid your debts and can take your time to "clean up" your code. And if anything goes wrong - it's the programmers' fault, you never knew it, they get fired and your hands are clean. Besides, by replacing GPL'ed with your own, you make your company even more "clean" - admit that "by mistake/misunderstanding" some GPL code got into your product but you are fixing that already, plus make a small donation to FSF as a compensation for your "mistake" and then you will appear to be the Good Guy instead!
I personally wonder, how many "close source" companies secretly and illegally include GNU-copyrighted code in their products, and sell it without source, violating GPL, but nobody knows they do, just because nobody ever sees the source.
Of course if the source was to be ever revealed, that is some serious risk, but if the company plans to keep it always secret - why not?
[environment-friendly post, contains recycled material]
95% success ratio... does that mean that 1 in 20 programs I run segfaults or what? What do they mean by "failure"? Not finishing given task in predefined time? Getting the results wrong? Hanging?
Sorry but that means nothing. Even if there -was- a comparison to other systems, it would still mean nothing. 95% success ratio, 78% happiness factor and 93% user satisfaction.
I'm not quite sure what's your point (though you sound wise and are probably right)
Thing is, with modern hardware you can afford two things: 1) Sloppy programming. Perform the same task you did 10 years ago in the same time as 10 years ago, but write it in 5 minutes in Perl instead of in a week in ASM. 2) Really good performance. And in serious applications it's often a serious difference between 5 and 6 minute coffee break (1 minute before the competition), and -especially- between 0,01s and 0,000001s. Is this project profitable? Instead of analysing 50 available pros and cons that take 0,01 s on old hardware and 0,000001s on new, you feed the new hardware with database of a billion past similar cases, get a 5-min coffee break and get a much more reliable answer. On old hardware this would take a week and simple analysis had to suffice.
And concerning games... 3D is where -lack- of optimisation shows through most. If your GUI draws for 0.5s because of sloppy programming, it's ok, but if you get 2FPS in a game, it sucks. And despite well optimised engine, a nice curved door with 300 polygons will mean some load and corridor of them - a real challenge to every GFX card. But this is where we allow the designer to place that corridor of doors, assuming "Good hardware will handle that" and continue to build another section of land instead of worrying about reducing the number of polygons or optimising the game engine.
Everything looked mostly reasonable (except that the registration gives choice only for Canada and US and I'm from Poland and it was never mentioned on the site it's limited to Canada and US) until I stumbled upon the last point of their TOC.
14.7. AMENDMENT. 1&1 may without advance notice amend this Agreement from time to time, and will do so by posting the new Agreement on the 1&1 website in place of the old. Each and every such amendment shall be become effective immediately for all pre-existing and future accounts. It is your responsibility to periodically check the 1&1 website for updates of this Agreement.
So they are free to post "All previous agreements are void and changed as follows. All customers are charged $1 per byte transferred. They can terminate the service at any time for $1000 fee" and all I can do is bite my fingers?
Don't limit your imagination to bounds of i386-compatibile architecture!
Ever thought about writing interpreter or VM in VHDL and implementing it on a FPGA board? That would be pretty similar.
>if it supports things like procedures Stacks substituted for local variables, CALL, RET, what a problem?
>nested complex arithmetic expressions, Can be un-nested at compile time, not really going far from assembly. Just remember that each +, ( or % is a separate call. Can be RPN, why not? That's very close to assembly.
>and named varables Is it a big problem in assembly? Just pick a register or memory cell and give it a name.
>and no sane high-level language can be without those things. Implementing some of those in compiler (ASM needs compiler too!) and the rest in hardware is far from impossible:)
Simply start the design not like with modern languages "We need commands that do this, that and that" and then try to fit them into existing hardware through compilers, but build a hardware that can perform your basic commands directly. So if I call fork(), I don't get a ton of system commands launched, just a single CPU cycle gives me a nice copy of the process and it runs _really_ simultaneously, not by time-sharing. If I want to send signal to some other process, it doesn't go through several levels of OS indirection, it's handled by the hardware, like a hardware interrupt. To perform write() and consider it done in one cycle, or at most as many cycles as many characters i'm writing(). by having my Of course I'm limited by the hardware on how much I can do, but isn't that the case always? Just that next to limits on RAM and CPU speed I get limits on number of variables, number of processes etc? (especially if I can make those dynamic limits, buy better chip, get more processes) The problem with C is that it's -a bit- too far from the hardware. A bit too much goes on without programmer's knowledge. How do I know ++ operator is 1-cycle CPU INC command or a 300-cycle call to math library to perform addition? I want to be able to select a chunk of code and see CPU cycle count. To have granted command execution time.
What 'bout getting a small revenge? Can't result in anything bad.
1. Install the game. On two or more boxes. 2. Set it up for multiplayer on LAN 3. Get your mom to play it with you. Just make her to! "But mom, it's no fun playing it alone! Why don't you give it a try? I'll teach you everything!" 4. ??? 5. Profit!!!
Quite insighful... but it isn't as bad as it looks. 1) Nobody forces you to write in Java for PIII. Write hand-optimised asm sniplets for PIII and include them in bigger Java or C app for time-critical pieces. You get real PIII performance. 2) The software quality drops, but slower than CPU speed rises. That means your Java app for PIII will still work -slightly- faster than hand-coded ASM for 486. 3) Development cost. You can spend a week to write a really fast small piece of code in ASM. Or you can spend that week on writing quite a big, though slow app. Most visible in games. Things like Morrowind, where crossing the map without stop takes a hour or more, and exploring all the corners is months of play, were plainly impossible when it all required hand-coding. Now for a developer it takes shorter to create a mountain in game than for a player to climb it. Of course the player needs better CPU to be able to display the mountain which wasn't hand-optimised, just created in an artificial high-level language defining the game world, but if you're going to enjoy the experience - why not?
Why? 1) Learn the new language well. 2) Find some sucker who will employ you, or other ??? 3) Profit!!! 4) For money earned, employ programmers from India to write your neural network in assembly for performance.
a language that feels like medium-to-high level (like, say ANSI C) but is in fact assembly - for certain new CPU. Can be run over VMs like Java or other cross-platform languages, can have other "metalanguages" built on top of it (like C++ or Perl on top of C) and is crossplatform for 'generic' platforms - but there exists a platform which is native for it, so bytecode can be run on it without any VM. Just perfect for embedded applications etc, while not leaving PCs and other "desktop boxes" out. (plus you can plug a "dedicated CPU" as a booster card in PCI and have it run its native apps at full speed without any load on your "main" CPU, just like the MPEG2 encoder cards did)
What I would like to see - "If I'm going to overclock, which one pays better"?
First they give overclocking capablities and then non-overclocked price/performance ratio. We know Intel CPUs are overclockable better but more expensive than AMD. So, say, I can buy a 2GHZ AMD and overclock it by 300MHZ, getting 2.3GHZ. For the same money I can get a slower Intel and overclock it more. Now, if it was that I can get i.e. 1.7GHZ Inter and overclock it by 600MHZ, it would mean the CPUs are pretty much equivalent for me. Means - about the same price per megahertz overclocked. But if I can buy P4 1.6G overclockable by 500MHZ, giving total 2.1GHZ, it just pays better to buy the AMD.
Drive works. The card - well, you have something to hack at least:) Now the MP3 player: First try installing it as a generic USB drive (you may have to hack the kernel a little for that, add USB ID entry for it). If it can't be done, you can try running its native upload program through WINE.
Slashdot Mirror
Timetable of, like, 5 years or so is quite a good idea if it is to be a GOOD game. Just in the planning phase make it match hardware as it will be in 5 years, start with rough, simple engine and build the whole world, all the datafiles, then by the very end release the final engine to run that in final quality, on target hardware.
:)
Remember "Another World"?
Recycling this.
Vote the third, may be outsider but certainly not asshole.
Maybe instead of giving cash, donate some of your old SUNs, SGIs etc, and help building it on a distributed architecture with really deep redundancy, where each component by itself isn't very reliable, but all together form a really strong cluster?
Asking for money is always the easiest way, and because of the number of people asking (Just look at all those PayPal Donate banners!) the chance of success is nearly null. What about taking a different path?
How serious are you on that?
I'm not good at languages useful in writing games, my art sucks, but I'm quite good at design/storytelling.
Somebody post that troll?
...and get blown to pieces by first strike of martian storm.
Spam is not the way.
Typical outcome of sending 1.000.000 spam messages is 100 happy (though dumb) customers, 10.000 really pissed off people and mostly indifferent but rather hostile rest. The profit is no loss from those 10.000 and profit from those 100.
But if you send out spam to your voters, divided fifty-fifty for and against, the outcome is 50 votes gained (the other 50 would vote for you anyway) and 5.000 votes lost (people who decide they won't vote on a party that uses spam)
So... feel free to send. Just remember: Winners don't use spam!
If a company can casually replace GPL'ed code with something proprietary by SP1, good for them: they probably didn't need the GPL'ed code in the first place.
If they can, until SP1 or SP2, but not until the 1.0, just because time limits on 1.0 are so tight? And sure they didn't need GPL code, they just needed any cheap kludge to fill the hole until they can catch a breath and write it as it should be.
If management claims they didn't know it just means that management violated their duty to know what's going on. Firing the employee will not shield the company from liability.
That's GPL and FSF, not EULA and Microsoft! These guys have completely different approach to enforcing the agreement - they aren't into loud lawsuits and multimillion compensations, they just want the matters settled and GPL complied to. A few heads in the company may fall, the PR people will give a few speeches, an apologising article will appear, maybe some useful patch to the "accidentially implemented" code will be published, a donation made, infriging code removed and you'll see Slashdot crowds cheering, rejoicing and praising the violator's name, because "a lost lamb returned to the herd".
how much Linux code is in WindowsXP?
:)
That's not as interesting as: How much Linux code is in SCO UNIX?!
Sure it IS risky. But what better way to cut down on development cost and time while keeping all the rights to the code? Give the employees a murderous deadline and gently hint them that you don't care about how legal their solution is, as long as it works and they keep it secret. And replace GPL code with your own later, say, with service pack 1, when the product is already deployed three weeks before the competition could do it, when you already have the money, paid your debts and can take your time to "clean up" your code. And if anything goes wrong - it's the programmers' fault, you never knew it, they get fired and your hands are clean. Besides, by replacing GPL'ed with your own, you make your company even more "clean" - admit that "by mistake/misunderstanding" some GPL code got into your product but you are fixing that already, plus make a small donation to FSF as a compensation for your "mistake" and then you will appear to be the Good Guy instead!
I personally wonder, how many "close source" companies secretly and illegally include GNU-copyrighted code in their products, and sell it without source, violating GPL, but nobody knows they do, just because nobody ever sees the source.
Of course if the source was to be ever revealed, that is some serious risk, but if the company plans to keep it always secret - why not?
[environment-friendly post, contains recycled material]
95% success ratio... does that mean that 1 in 20 programs I run segfaults or what? What do they mean by "failure"? Not finishing given task in predefined time? Getting the results wrong? Hanging?
Sorry but that means nothing. Even if there -was- a comparison to other systems, it would still mean nothing. 95% success ratio, 78% happiness factor and 93% user satisfaction.
I'm not quite sure what's your point (though you sound wise and are probably right)
Thing is, with modern hardware you can afford two things:
1) Sloppy programming. Perform the same task you did 10 years ago in the same time as 10 years ago, but write it in 5 minutes in Perl instead of in a week in ASM.
2) Really good performance. And in serious applications it's often a serious difference between 5 and 6 minute coffee break (1 minute before the competition), and -especially- between 0,01s and 0,000001s. Is this project profitable? Instead of analysing 50 available pros and cons that take 0,01 s on old hardware and 0,000001s on new, you feed the new hardware with database of a billion past similar cases, get a 5-min coffee break and get a much more reliable answer. On old hardware this would take a week and simple analysis had to suffice.
And concerning games... 3D is where -lack- of optimisation shows through most. If your GUI draws for 0.5s because of sloppy programming, it's ok, but if you get 2FPS in a game, it sucks. And despite well optimised engine, a nice curved door with 300 polygons will mean some load and corridor of them - a real challenge to every GFX card. But this is where we allow the designer to place that corridor of doors, assuming "Good hardware will handle that" and continue to build another section of land instead of worrying about reducing the number of polygons or optimising the game engine.
Everything looked mostly reasonable (except that the registration gives choice only for Canada and US and I'm from Poland and it was never mentioned on the site it's limited to Canada and US) until I stumbled upon the last point of their TOC.
14.7. AMENDMENT. 1&1 may without advance notice amend this Agreement from time to time, and will do so by posting the new Agreement on the 1&1 website in place of the old. Each and every such amendment shall be become effective immediately for all pre-existing and future accounts. It is your responsibility to periodically check the 1&1 website for updates of this Agreement.
So they are free to post "All previous agreements are void and changed as follows. All customers are charged $1 per byte transferred. They can terminate the service at any time for $1000 fee" and all I can do is bite my fingers?
*sigh*. Too good to be true.
Don't limit your imagination to bounds of i386-compatibile architecture!
:)
Ever thought about writing interpreter or VM in VHDL and implementing it on a FPGA board? That would be pretty similar.
>if it supports things like procedures
Stacks substituted for local variables, CALL, RET, what a problem?
>nested complex arithmetic expressions,
Can be un-nested at compile time, not really going far from assembly. Just remember that each +, ( or % is a separate call. Can be RPN, why not? That's very close to assembly.
>and named varables
Is it a big problem in assembly? Just pick a register or memory cell and give it a name.
>and no sane high-level language can be without those things.
Implementing some of those in compiler (ASM needs compiler too!) and the rest in hardware is far from impossible
Simply start the design not like with modern languages "We need commands that do this, that and that" and then try to fit them into existing hardware through compilers, but build a hardware that can perform your basic commands directly. So if I call fork(), I don't get a ton of system commands launched, just a single CPU cycle gives me a nice copy of the process and it runs _really_ simultaneously, not by time-sharing. If I want to send signal to some other process, it doesn't go through several levels of OS indirection, it's handled by the hardware, like a hardware interrupt. To perform write() and consider it done in one cycle, or at most as many cycles as many characters i'm writing(). by having my Of course I'm limited by the hardware on how much I can do, but isn't that the case always? Just that next to limits on RAM and CPU speed I get limits on number of variables, number of processes etc? (especially if I can make those dynamic limits, buy better chip, get more processes)
The problem with C is that it's -a bit- too far from the hardware. A bit too much goes on without programmer's knowledge. How do I know ++ operator is 1-cycle CPU INC command or a 300-cycle call to math library to perform addition? I want to be able to select a chunk of code and see CPU cycle count. To have granted command execution time.
Now I have a TI-82...
And it seems I will finally be able to write a few games I always wanted but lacked a few CPU cycles!
Thanks!
Z80 no, but 8052-based microcontroller, why not? :)
What about bandwidth/transfer limitations and content limitations?
What 'bout getting a small revenge?
Can't result in anything bad.
1. Install the game. On two or more boxes.
2. Set it up for multiplayer on LAN
3. Get your mom to play it with you. Just make her to! "But mom, it's no fun playing it alone! Why don't you give it a try? I'll teach you everything!"
4. ???
5. Profit!!!
Quite insighful... but it isn't as bad as it looks.
1) Nobody forces you to write in Java for PIII. Write hand-optimised asm sniplets for PIII and include them in bigger Java or C app for time-critical pieces. You get real PIII performance.
2) The software quality drops, but slower than CPU speed rises. That means your Java app for PIII will still work -slightly- faster than hand-coded ASM for 486.
3) Development cost. You can spend a week to write a really fast small piece of code in ASM. Or you can spend that week on writing quite a big, though slow app.
Most visible in games. Things like Morrowind, where crossing the map without stop takes a hour or more, and exploring all the corners is months of play, were plainly impossible when it all required hand-coding. Now for a developer it takes shorter to create a mountain in game than for a player to climb it. Of course the player needs better CPU to be able to display the mountain which wasn't hand-optimised, just created in an artificial high-level language defining the game world, but if you're going to enjoy the experience - why not?
Why?
1) Learn the new language well.
2) Find some sucker who will employ you, or other ???
3) Profit!!!
4) For money earned, employ programmers from India to write your neural network in assembly for performance.
a language that feels like medium-to-high level (like, say ANSI C) but is in fact assembly - for certain new CPU. Can be run over VMs like Java or other cross-platform languages, can have other "metalanguages" built on top of it (like C++ or Perl on top of C) and is crossplatform for 'generic' platforms - but there exists a platform which is native for it, so bytecode can be run on it without any VM. Just perfect for embedded applications etc, while not leaving PCs and other "desktop boxes" out. (plus you can plug a "dedicated CPU" as a booster card in PCI and have it run its native apps at full speed without any load on your "main" CPU, just like the MPEG2 encoder cards did)
What I would like to see - "If I'm going to overclock, which one pays better"?
First they give overclocking capablities and then non-overclocked price/performance ratio.
We know Intel CPUs are overclockable better but more expensive than AMD.
So, say, I can buy a 2GHZ AMD and overclock it by 300MHZ, getting 2.3GHZ. For the same money I can get a slower Intel and overclock it more. Now, if it was that I can get i.e. 1.7GHZ Inter and overclock it by 600MHZ, it would mean the CPUs are pretty much equivalent for me. Means - about the same price per megahertz overclocked. But if I can buy P4 1.6G overclockable by 500MHZ, giving total 2.1GHZ, it just pays better to buy the AMD.
Drive works. The card - well, you have something to hack at least :)
Now the MP3 player: First try installing it as a generic USB drive (you may have to hack the kernel a little for that, add USB ID entry for it). If it can't be done, you can try running its native upload program through WINE.