the fact that carbon apps are a second class citizen on osx (despite all handwaving claims to the contrary). there are many OSX features simply not available under carbon that are available under cocoa -- not because it is unfeasible to do so but because apple deliberately chooses not to provide them.
the choice to armtwist developers into using objc is a huge mistake, (that decision alone nearly killed NeXT). so apple provided carbon, but it is halfheartedly supported. its sorta like a punishment for the insolence of developers who dare to use c/c++, who do not follow the one true steve jobs path to developer enlightenment.
lots of standard development tools like cvs/svn are simply not available on osx without having to jump through the hurdles of fink. and even then a lot of critical tools are only available in the unstable branch -- a pita to enable in fink. osx is shipping with a halfassed selection of development tools -- simply not acceptable.
without fink i dont think i'd be developing on osx at all. but why the fuck is it up to third parties to have to shore up osx in order to make it a usable development platform? apple should be doing this, and they completely dropped the ball.
xcode is a crashy fragile pos which explodes with internal errors at the slightest provocation. i can't explain the immense joy that comes from having xcode spontaneously explode from merely twiddling project compiler settings in the gui. thats not even counting that xcode has the worst interface ever.
apple managed to break even the simplest tools like pico, so serious developers are forced to go out and recompile these tools from source in order to repair the damage apple did to them.
many of apple's development tools (packagemaker is a good example) have no concept of cwd, which makes them a pain in the ass to script. and there's no good reason for it either other than apple laziness.
and then there's the supremely retarded stuff like some of non-gui-related OSX API being linked at the hip with the GUI for no good reason -- some lowlevel os calls fail unless someone is logged in to the desktop, being logged in via ssh even as administrator is not sufficient. So you need vnc as well as ssh in order to run some character-only-applications. It's pretty obvious apple has no clue about headless servers.
i could go on and on, suffice to say i have to jump through NONE of these hurdles to develop on win32 or linux.
the only "simply not used to" was bundles, but that's easily scripted at least. it is however poorly documented as apple expects you to be exclusively using the GUI tools to manually build stuff, and never scripting it.
a huge percentage of apple's revenue comes from OSX and itunes sales, which most definitely makes apple a software company. in fact itunes sales is growing so fast that apple may become mostly an 'itunes company'.
haw. bottom of quality barrel is not exclusive to PCs. just google for 'ibook class action' and such.
microchannel and os/2 were blunders on IBM's part not related to cloning at all. if you believe otherwise then you really know nothing about the history of either.
Now, if there were three or four cloners making Macs, and Apple wanted to (say), change CPUs, and the other guys were perfectly happy to continue shipping PPC machines running OS 9 for the next 20 years, Apple loses the ability to improve the product and win customers away from the Dark Side.
yeah sure, just like all the PC vendors are still shiping Win95 and preventing microsoft from improving the product. gotcha.
a mini is an underpowered piece of crapola with buggy hardware (I have one). a used powerbook is expensive. i can think of nothing better to deter people from ever wanting to try out OSX than forcing them to buy expensive or underpowered apple hardware in order to do so.
haw. osx is nearly nextstep verbatim. they just made the gui cuter. all the base libraries are still there, all the classes are even under their old nextstep names.
apple got their OS for a song from steve, compared to what it would have cost them to write everything from scratch. not to mention what they nicked from opensource.
osx cost apple next to nothing to develop, compared to everything else.
iTunes sales are driving apple revenues, not ipod hardware sales. and that most definitely makes apple a software vendor -- a huge chunk of apple revenue is purely software now, and that chunk is projected to grow.
apple is slowly learning the margins on software are much greater than hardware.
you're making the same flawed assumption the RIAA and MPAA are, which is that you would have paid for it if you couldn't have pirated it.
problem is the facts simply dont back this up. people who pirate either never would have bought it in the first place, or end up buying more legitimate related product. you can't lose money from a sale that would have never have happened anyway.
what it does do (and what microsoft correctly understands) is that piracy grows a userbase, which in turn grows demand for legitimate product. once your userbase is significantly large, then you can start playing 900lb gorilla with vendors.
2% margin on $2000 or 60% (or more) on $129? pretty clear to me at least. thats nearly 2 macs vs 1 OSX CD.
the big downside of restricting osx to only running on apple's hardware is that there simply isn't much hardware to choose from. it's very annoying all the hardware which won't run on a mac, but linux and doze work fine.
you're assuming there's no profit from stamping OSX on a circular piece of polycarbonate plastic and putting it in a cardboard box and selling it for $129.
i'm pretty sure the margins on software are a lot better than the margins on hardware.
I have to wonder how long this project will last, before microsoft swoops in with lawyers and salespeople and demands it be dismantled.
The usual threats would be "ohsnoes who will guarantee it against IP lawsuits" (just don't read the microsoft eula kthx) and "what about terrorists omgwtfbbq".
I don't see this project lasting long, its mere existence is an affront to everything microsoft stands for.
I am sure Steve jobs will be licking his lips in anticipation of 1000 odd users foraging through his stores.
Really? These are G3/300 ibooks. They won't be running anything even close to current software. I don't think they can even run OSX without major upgrades.
I don't consider anything QVM/DLL as "part of the engine netcode" any more than I consider Firefox/Mozilla as "part of the linux kernel".
It still strikes me as a lower level transport protocol... You can still send whatever information you want over that link, and mess with what information the engine sends, no?
No. You can only send what the engine will let you send. Which is actually quite limited.
The addition of "antiwarp" and latency correction would seem to indicate greatly improved netcode. Improved means not the same:)
The antiwarp is for etpro, not et 2.60 stock.
Is latency correction and prediction/extrapolation/antiwarp/whatever progress? Damn straight! Latency correction alone is enormous progress... With most games if I could improve the netcode in one way, it would be to add latency correction;)
And still you have yet to mention an engine which does latency correction better than ET or q3/unlagged... !
Your original claim was that unlagged 'brings q3 up to modern netcode'. Well, where is this other modern netcode you speak of then?
That's ok then, since Q3 does in fact have "proper" prediction.:-)
Proper being player;)
As I keep saying, player prediction is a very bad thing and you don't want it.
Ever played tribes2? See all the players warping around all the time? That's why you don't want player prediction.
The lack of player movement prediction admittedly isn't really an issue anymore. Newer games have world updates as frequently as 60 to 100hz (The NS server I frequent does). Considering my laptop's LCD has a 60hz refresh rate, there isn't going to be any noticeable lack of smoothness in player movement if the server is sending me 100 updates per second. At this point I guess only taking packetloss into account matters.
actually 60/100fps is totally overkill. (and most clients are set to accept less snaps than that anyway.)
20fps is quite a convenient number (50ms). note that most modern engines use much lower serverside frame rates than 60-100. partly because the amount of data being sent is much greater, and the games are much more complex. running at higher frame rates means much more server cpu is required. also much more bandwidth. you don't want each player to have to have a T3 in order to play... 20-30fps is pretty ideal tradeoff between latency, bandwidth, and performance.
If only it were so cut and dry! If the last update I got from a player is from 100ms ago, where I see him frozen and where I'm shooting, that's not really where he is... Unless the engine is going to pretend he was there, at which point it's just as unfair to him that you managed to hit him as it was to you that you would have missed him. Either way it's not fair. Either the game is cheating you for showing you a position that will make you miss, or the game is cheating him for letting you hit him someplace that he wasn't even in at the time. Stationary targets are rather easy to hit, though repeated freezing sort of blows that statement out of the water;)
On the other hand, I suppose if you did the movement correction server-side, it'd be more fair to you; the predicted position that actually counted for hits would be closer to the true position than his last known position is, so it's fairer to him, and you still get to see him in a more correct position.
Err, you really should go back and re-read what unlagged does...;-)
It really is that cut and dry. You simply do not want to do player extrapolation, period. Interpolation is fine, because you're displaying where the player really was,
UT has its pluses and minuses. It's a decent engine but you are locked into the umod system (and their scripting language). With q3 you have a choice of QVM or native DLL. Without the option of DLL you are prevented from doing many useful things (and using a real compiler).
As for renderers, I would say the Q3 renderer is more advanced than UT.
As for gameplay, imo UT's gameplay is more fun than Q3. But that's subjective:-)
It depends how you define "engine". If you strictly mean the 3D engine, you'd be right. But in Quake 3's case, a lot of the code that I would call the engine (as in game engine) is contained in what you call the mod source. For example, the Q3 AI system is entirely contained within the "mod source".
Ah... No.
The Q3 AI system is most definitely not entirely contained within the mod source. The ai code in the mod source is very high level bot and game-specific behavior (basically, game-specific rulesets). However, BSP route finding and bot movement is still handled entirely within the engine and is still a closely guarded secret. It will be interesting if id does indeed release the engine bot code when they GPL quake3, given how paranoid they've been in the past.
The same applies to the higher level netcode; it's not in the executable, it's in the QVMs/DLLs. But netcode is undeniably part of the engine.
I'll try to make this clearer. The QVM/DLL has no control whatsoever regarding the protocol on the wire. All the QVM/DLL can do is change the interpretation of what it receives from the engine. Want to expand the entitystate struct? Want to increase the number of configstrings? Want to increase the number of entities beyond 1024? Tough. You can't. It's hardcoded into the engine.
I don't consider anything QVM/DLL as "part of the engine netcode" any more than I consider Firefox/Mozilla as "part of the linux kernel".
If you consider Quake 3 to be complex and HL2 to be simple, well, you'll certainly have an easy time coding in the future. But I disagree with you; Quake 3 doesn't pump nearly as entities down the pipe as HL2, or even some HL1 mods (Natural-Selection anyone?), and without Unlagged it's missing stuff from newer games like client-side movement prediction and latency correction.
Er.. yes, q3 most definitely does have client-side movement prediction. Anything with a simple trajectory (rockets, grenades, etc) is predicted.
What is not predicted in q3 is player movement. And fwiw it's not predicted in ET or UT or many other games either. prediction for player movmeent is generally considered very bad because for games where players have air control, it means your predicted position will usually be wrong and your players will warp around.
You really, really, really, really do not want player movement prediction in general. Tribes2 had it, and the result was the horrible jerky movement for players -- especially players on fast movers (vehicles).
Unlagged does add serverside 'predicted' player movement in the case where players drop user movement commands, but I don't really like the method unlagged uses (it can predict players warping into walls, for example). It is also an option and defaults to off, because of the bad side effects.
ETPro doesn't have player movement prediction either... we deal with the problem in a different way -- we call the code "antiwarp". And IMO it works far better than unlagged's method.
Are you referring to Q3 now, or ET? ET doesn't feature the same netcode. For one thing it DOES have latency correction and IIRC, client-side movement prediction. The game (Q3) might play fine for YOU when you have 80% packetloss and a ping of 500, but without client-side movement prediction, the other players will see you teleporting from point to point as your packets come in sporadically.
Er, ET most definitely does have the same netcode. The only difference between Q3 and ET is that ET has latency correction for shots -- and the original 2.5x releases of ET had massively buggy latency correction based on a flawed understanding of neil toronto's unlagged 1.x code. I rewrote the latency correction from scratch for id/activision for the ET 2.60 release based on techniques neil toronto used
Ok, um. HL1 and HL2 have "excellent" netcode? Now I know for certain you're not a modder.:-)
I think you should understand what exactly moding entails. It is not an addition, it is a modification, of whatever sections of the engine source the company has chosen to make available.
Er, no. Companies never make _engine source_ available. Otherwise you'd be able to easily circumvent copy protection, cheat detection, etc.
What companies make available is _mod source_, eg modules which the engine loads and runs the mod code. Different engines handle this in different ways. For instance UT uses a VM similar to java. quake3 offers VM as well as machine-native DLLs.
In essence the engine is the linux kernel and mods are linux executables.
HL1 and HL2 are based off of _quake1_ engine code. HL2 still has a lot of icky quake SDK cruft in it, if you bother to look. It simply is not better than quake3. The only reason why it might "appear" to be good is that it is a very simple engine running very simple mods -- the amount of traffic traveling over the link is very small.
But give it a complex game to run, with tons of complex entities and complex gamestates, and it will not do as well as q3 engine games.
quake3 works _excellent_ in high packetloss and high latency situations. i've tested it to eg 80% packetloss and 500ms latency and it was still playable.
and er... unlagged doesnt change player movement prediction. it does make a change to serverside extrapolation if clients drop command packets, but that's a different thing entirely.
it sure isn't in hl or hl2. it isnt in ut2k(3|4) either. it isnt in painkiller nor is it in farcry. it most definitely isnt in bf or bf2.
when i speak of netcode i speak of _engine_ netcode. unlagged isnt engine. you can fix a lot of engine ills through modding, but it helps to have a decent netcode base to start with.
Thing is, this is the second scheme in a row that scott been involved in. The first time he avoided prison time and his company got fined. He's not avoiding prison this time though.
I don't think prison will stop him. He'll just find some other scheme when he gets out.
Slashdot Mirror
You're assuming there will ever be the possibility of "forced to pay for it or forced to do without".
apple made the same mistake as you are making.
there is _always_ the option of not paying. there is nothing you or apple or anyone else can do to change that.
you make the same flawed assumption the MPAA and RIAA make: that they would have bought it in the first place.
how can you lose a sale that would never have happened anyway?
mostly things which are far worse.
the fact that carbon apps are a second class citizen on osx (despite all handwaving claims to the contrary). there are many OSX features simply not available under carbon that are available under cocoa -- not because it is unfeasible to do so but because apple deliberately chooses not to provide them.
the choice to armtwist developers into using objc is a huge mistake, (that decision alone nearly killed NeXT). so apple provided carbon, but it is halfheartedly supported. its sorta like a punishment for the insolence of developers who dare to use c/c++, who do not follow the one true steve jobs path to developer enlightenment.
lots of standard development tools like cvs/svn are simply not available on osx without having to jump through the hurdles of fink. and even then a lot of critical tools are only available in the unstable branch -- a pita to enable in fink. osx is shipping with a halfassed selection of development tools -- simply not acceptable.
without fink i dont think i'd be developing on osx at all. but why the fuck is it up to third parties to have to shore up osx in order to make it a usable development platform? apple should be doing this, and they completely dropped the ball.
xcode is a crashy fragile pos which explodes with internal errors at the slightest provocation. i can't explain the immense joy that comes from having xcode spontaneously explode from merely twiddling project compiler settings in the gui. thats not even counting that xcode has the worst interface ever.
apple managed to break even the simplest tools like pico, so serious developers are forced to go out and recompile these tools from source in order to repair the damage apple did to them.
many of apple's development tools (packagemaker is a good example) have no concept of cwd, which makes them a pain in the ass to script. and there's no good reason for it either other than apple laziness.
and then there's the supremely retarded stuff like some of non-gui-related OSX API being linked at the hip with the GUI for no good reason -- some lowlevel os calls fail unless someone is logged in to the desktop, being logged in via ssh even as administrator is not sufficient. So you need vnc as well as ssh in order to run some character-only-applications. It's pretty obvious apple has no clue about headless servers.
i could go on and on, suffice to say i have to jump through NONE of these hurdles to develop on win32 or linux.
the only "simply not used to" was bundles, but that's easily scripted at least. it is however poorly documented as apple expects you to be exclusively using the GUI tools to manually build stuff, and never scripting it.
only in the apple universe is choice a bad thing.
a huge percentage of apple's revenue comes from OSX and itunes sales, which most definitely makes apple a software company. in fact itunes sales is growing so fast that apple may become mostly an 'itunes company'.
yeah because doing so was obviously so detrimental to linux. riiiiiiight.
microchannel and os/2 were blunders on IBM's part not related to cloning at all. if you believe otherwise then you really know nothing about the history of either.
yeah sure, just like all the PC vendors are still shiping Win95 and preventing microsoft from improving the product. gotcha.
a mini is an underpowered piece of crapola with buggy hardware (I have one). a used powerbook is expensive. i can think of nothing better to deter people from ever wanting to try out OSX than forcing them to buy expensive or underpowered apple hardware in order to do so.
haw. osx is nearly nextstep verbatim. they just made the gui cuter. all the base libraries are still there, all the classes are even under their old nextstep names.
apple got their OS for a song from steve, compared to what it would have cost them to write everything from scratch. not to mention what they nicked from opensource.
osx cost apple next to nothing to develop, compared to everything else.
iTunes sales are driving apple revenues, not ipod hardware sales. and that most definitely makes apple a software vendor -- a huge chunk of apple revenue is purely software now, and that chunk is projected to grow.
apple is slowly learning the margins on software are much greater than hardware.
you're making the same flawed assumption the RIAA and MPAA are, which is that you would have paid for it if you couldn't have pirated it.
problem is the facts simply dont back this up. people who pirate either never would have bought it in the first place, or end up buying more legitimate related product. you can't lose money from a sale that would have never have happened anyway.
what it does do (and what microsoft correctly understands) is that piracy grows a userbase, which in turn grows demand for legitimate product. once your userbase is significantly large, then you can start playing 900lb gorilla with vendors.
then why are they charging $130 for people to upgrade to tiger? why is apple stating a significant amount of their revenue comes from OSX upgrades?
it sure would be nice if I could upgrade to tiger for free.
the margins on hardware are paper thin.
2% margin on $2000 or 60% (or more) on $129? pretty clear to me at least. thats nearly 2 macs vs 1 OSX CD.
the big downside of restricting osx to only running on apple's hardware is that there simply isn't much hardware to choose from. it's very annoying all the hardware which won't run on a mac, but linux and doze work fine.
as a software developer I find myself having to jump hurdles and roadblocks in OSX far more often than I do in win32 or linux.
with osx you do things steve jobs' way or you don't do it at all.
for daily use my mac mainly sits idle while all the productive stuff is in linux and doze. i use the mac for osx development, but man is it painful.
its also very frustrating all the hardware out there which simply wont work on macs, but will work fine with linux or doze.
you're assuming there's no profit from stamping OSX on a circular piece of polycarbonate plastic and putting it in a cardboard box and selling it for $129.
i'm pretty sure the margins on software are a lot better than the margins on hardware.
Heh just thought of a good way for microsoft to sabotage this project.
"shut it down and replace it with 100% microsoft products... or else we will audit your microsoft licenses."
unless you're 0% microsoft already, almost everyone will capitulate.
I have to wonder how long this project will last, before microsoft swoops in with lawyers and salespeople and demands it be dismantled.
The usual threats would be "ohsnoes who will guarantee it against IP lawsuits" (just don't read the microsoft eula kthx) and "what about terrorists omgwtfbbq".
I don't see this project lasting long, its mere existence is an affront to everything microsoft stands for.
I am sure Steve jobs will be licking his lips in anticipation of 1000 odd users foraging through his stores.
Really? These are G3/300 ibooks. They won't be running anything even close to current software. I don't think they can even run OSX without major upgrades.
You didn't miss anything.
These were G3/300 ibooks. Uses PC66 ram. Yes, PC66 . This powerful combination of hardware is the equivalent of a K6/400.
A whopping 4mb of VRAM gives you a glorious max of 800x600.
They aren't worth even $50.
that kind of trick is actually pretty old. almost all existing physics engines use similar tricks to speed up calculations.
No. You can only send what the engine will let you send. Which is actually quite limited.
The antiwarp is for etpro, not et 2.60 stock.
And still you have yet to mention an engine which does latency correction better than ET or q3/unlagged... !
Your original claim was that unlagged 'brings q3 up to modern netcode'. Well, where is this other modern netcode you speak of then?
As I keep saying, player prediction is a very bad thing and you don't want it.
Ever played tribes2? See all the players warping around all the time? That's why you don't want player prediction.
actually 60/100fps is totally overkill. (and most clients are set to accept less snaps than that anyway.)
20fps is quite a convenient number (50ms). note that most modern engines use much lower serverside frame rates than 60-100. partly because the amount of data being sent is much greater, and the games are much more complex. running at higher frame rates means much more server cpu is required. also much more bandwidth. you don't want each player to have to have a T3 in order to play... 20-30fps is pretty ideal tradeoff between latency, bandwidth, and performance.
Err, you really should go back and re-read what unlagged does... ;-)
It really is that cut and dry. You simply do not want to do player extrapolation, period. Interpolation is fine, because you're displaying where the player really was,
UT has its pluses and minuses. It's a decent engine but you are locked into the umod system (and their scripting language). With q3 you have a choice of QVM or native DLL. Without the option of DLL you are prevented from doing many useful things (and using a real compiler).
:-)
As for renderers, I would say the Q3 renderer is more advanced than UT.
As for gameplay, imo UT's gameplay is more fun than Q3. But that's subjective
Ah... No.
The Q3 AI system is most definitely not entirely contained within the mod source. The ai code in the mod source is very high level bot and game-specific behavior (basically, game-specific rulesets). However, BSP route finding and bot movement is still handled entirely within the engine and is still a closely guarded secret. It will be interesting if id does indeed release the engine bot code when they GPL quake3, given how paranoid they've been in the past.
I'll try to make this clearer. The QVM/DLL has no control whatsoever regarding the protocol on the wire. All the QVM/DLL can do is change the interpretation of what it receives from the engine. Want to expand the entitystate struct? Want to increase the number of configstrings? Want to increase the number of entities beyond 1024? Tough. You can't. It's hardcoded into the engine.
I don't consider anything QVM/DLL as "part of the engine netcode" any more than I consider Firefox/Mozilla as "part of the linux kernel".
Er.. yes, q3 most definitely does have client-side movement prediction. Anything with a simple trajectory (rockets, grenades, etc) is predicted.
What is not predicted in q3 is player movement. And fwiw it's not predicted in ET or UT or many other games either. prediction for player movmeent is generally considered very bad because for games where players have air control, it means your predicted position will usually be wrong and your players will warp around.
You really, really, really, really do not want player movement prediction in general. Tribes2 had it, and the result was the horrible jerky movement for players -- especially players on fast movers (vehicles).
Unlagged does add serverside 'predicted' player movement in the case where players drop user movement commands, but I don't really like the method unlagged uses (it can predict players warping into walls, for example). It is also an option and defaults to off, because of the bad side effects.
ETPro doesn't have player movement prediction either... we deal with the problem in a different way -- we call the code "antiwarp". And IMO it works far better than unlagged's method.
Er, ET most definitely does have the same netcode. The only difference between Q3 and ET is that ET has latency correction for shots -- and the original 2.5x releases of ET had massively buggy latency correction based on a flawed understanding of neil toronto's unlagged 1.x code. I rewrote the latency correction from scratch for id/activision for the ET 2.60 release based on techniques neil toronto used
Er, no. Companies never make _engine source_ available. Otherwise you'd be able to easily circumvent copy protection, cheat detection, etc.
What companies make available is _mod source_, eg modules which the engine loads and runs the mod code. Different engines handle this in different ways. For instance UT uses a VM similar to java. quake3 offers VM as well as machine-native DLLs.
In essence the engine is the linux kernel and mods are linux executables.
HL1 and HL2 are based off of _quake1_ engine code. HL2 still has a lot of icky quake SDK cruft in it, if you bother to look. It simply is not better than quake3. The only reason why it might "appear" to be good is that it is a very simple engine running very simple mods -- the amount of traffic traveling over the link is very small.
But give it a complex game to run, with tons of complex entities and complex gamestates, and it will not do as well as q3 engine games.
quake3 works _excellent_ in high packetloss and high latency situations. i've tested it to eg 80% packetloss and 500ms latency and it was still playable.
and er... unlagged doesnt change player movement prediction. it does make a change to serverside extrapolation if clients drop command packets, but that's a different thing entirely.
Disclaimer: I wrote etpro and ettv.
where is this 'good modern netcode' you speak of?
it sure isn't in hl or hl2. it isnt in ut2k(3|4) either. it isnt in painkiller nor is it in farcry. it most definitely isnt in bf or bf2.
when i speak of netcode i speak of _engine_ netcode. unlagged isnt engine. you can fix a lot of engine ills through modding, but it helps to have a decent netcode base to start with.
Thing is, this is the second scheme in a row that scott been involved in. The first time he avoided prison time and his company got fined. He's not avoiding prison this time though.
I don't think prison will stop him. He'll just find some other scheme when he gets out.