7. Some kind of direct video support (games, etc...).
That's up to the Operating System, not to a desktop environment. And those solutions are available, it's called OpenGL and SDL, too bad only good game developers dare to use portable, industry standards instead of closed API's they don't even have full support for (take a look at the UT engine, Doom engine, Cube engine).
Sadly, OpenGL drivers on Linux aren't up to speed feature-wise. ATI's drivers are especially poor. For instance, you can't reliably create a buffer object on Linux without a fallback to the much slower PBuffer system.
Feature for feature, OpenGL 2.0 on Windows is sort of competing with DX9 and somewhat DX10, but on Linux you can't use any of the features required for a modern game engine. In order to ship a competitive title in 2007 you need multiple render targets, Shader model 3.0 support and floating-point buffers. UT and Doom are ancient games as far as rendering technology goes.
I tried it on my PowerMac G5 (the 2x2.7GHz flavor), but it keeps powering down because of overheating. Fedora Core 6 seems to has the same bug.
Apparently a lot of G5 boxes have problems because if the software doesn't correctly babysit the fan and pump levels (yes, some G5s are liquid cooled!), the hardware shuts down. After a few hours of kernel tweaking and fscking I gave up.
Hope they fix it before Apple discontinues OS X on PPC..:-)
The finally got around to fixing the bug where FF would consume 100% CPU on Mac OS X when you press and hold the left mouse button. This was a major issue for everyone with a laptop (it goes through battery much faster) and also annoying on the Mac Pros (the CPU fans spin up when you select text).
What's happening is that everyone's going crazy about the next-gen consoles and instead of porting games from the PC to the console, they're doing the reverse and it shows.
Even Red Storm has been bit by this, as is evident from RS:Lockdown. It's a straight port from the console to the PC and so watered down that they're losing their entire IP on the PC side.
I also work as a programmer with a large game studio and the team is about 50 people. Of those, about 15 is dedicated to programming and scheduling for programming tasks. The rest are mainly content creators, i.e. 3d modellers, animators and sound artists.
Everyone is still struggling with the project as a whole, but within your realm of expertise (in my case portability and core subsystems) you find fun challenges and new ways to think on a daily basis.
When it works, it's just as fun as the solo trip but the project as a whole moves so much faster compared to what you could ever hope to produce by yourself.
My company is in the fortunate position of owning and developing an in-house game engine and that's why we have all these programmers. It's also our ticket to producing original gameplay.
My guess is that with more technology licensing we'll see a 90%/10% split of content/code in the future because there's a lot of money to save by just licensing an existing engine. Management likes to cut risks; even if it means sacrificing orginality. How many Quake/Unreal-based games have been successful over the last few years without any new engine code? Plenty! All you need is content.
Maybe the guerilla developers will take over the day all large game studios all sit around and borrow each other's technology and produce nothing new.:-)
If you're using a single coil pickup guitar like a Fender Strat, the only thing you can do is place the 5-way selector in the neck+middle or middle+bridge positions to simulate a humbucking effect, that reduces the noise to acceptable levels.:)
For a humbucking guitar, try shaving off the top treble with the tone control if it's still a problem.
Also, turn off everything you don't need while recording.. You hardly need to sit infront of the TV when laying down a track?:)
As for sound cards, if you're serious about recording at home spend the $300 on a good sound card. It's worth it.
These come with better AD/DA and have the monitoring options you need. Also, you get much lower latencies in Cubase etc. with these cards, down to a few ms, and you won't need the hacked ASIO drivers.
Uncalled-for XML-RPC flames
on
DTD vs. XML Schema
·
· Score: 2, Insightful
I see a lot of replies here that flame XML as an RPC protocol. Using XML as a message format for RPC is just one small part of what you can do with it.
The real strength you get for free when using XML is that you can use standard parsers and transformers to handle different kinds of data in a uniform manner.
I'll give you an example..
Today I was working on my wxWindows application, and I needed to translate (i18n) a lot of windows, dialogs and menus to a few languages. The resources are specified in XRC which is an XML format.
Within XRC files labels for buttons and other widgets are written in the language they were created in, usually english.
What I did was write an XML catalog file for each language. I then ran an XSLT processor with the XRC files, using the catalogs as plugins with a simple pattern match rule -- and I didn't have to write one single line of customized code to do it.
Though for RPC I'll stick to CORBA with IIOP any day:-)
Gas here in Sweden is about $5.10 per gallon if my unit conversions are correct (9.60 SEK per liter). Of that, about 75% are taxes.
Even with these gas prices SUVs are getting more and more popular over here, though most people drive 10 year old japanese cars.
Most people use public transportation in the large cities (I live in Stockholm) because it's much cheaper (about $55 per month for unlimited use) and there are almost no parking places.
$ bc -l bc 1.06 Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. scale=50 a(1)*4 3.14159265358979323 8462643383279502884197169399375 08
I just tried timing OpenOffice writer startups on my AMD XP 1700 w/ U160 scsi. A cold startup took 10 seconds while a subsequent startup took 1 second.
I have a gig of ram, so disk I/O was not involved in the second startup. Whatever the problem is, it seems to be I/O bound.
Sure, load balancing of dynamic stuff is a lot harder than with static pages, but it's not rocket science.
If there's no need for the page to be up to date to the second, and you're dealing with a large server cluster, just place a few reverse proxies on front of the cluster that maps the URLs that can be subjected to caching. Then update the pages every minute or so.
This is even better because you only need to make sure the pages work in a dynamic fashion, and you can test the generation and caching separetly. Why bother with writing your own HTML to disk?
where the www is heading, IMHO. Seven years ago, anyone was hardly using dynamic stuff on the web, and IIRC back then it was mostly flat HTML.
But today, when 90% of the stuff served (besides images) by web servers are dynamic content, why does a web server like this get a headline?
Ok, I know it does CGI, but come on, CGI is as dead as Ultrix.
I'm not trying to let this project down. I'm sure there are plenty of happy users that don't need the "bloat" associated with Apache, IIS and other servers--but I'd be surprised if they did anything more advanced than the occasional photo album homepage.
We all use bash (mostly). Not because it's the smallest, but because it does everything we've come to expect from a shell.
To me, Boa seems a lot like the effort to rewrite the unix utilities in asm to reduce size. It's a challenging excersise, but in the long run it's going nowhere.
For the casual developer or admin, I think the new Sun-endorsed XML formats for webtrees and other configuration data is worthless. It's simply too verbose for me.
I recently played with Cocoon (which is a lovely publishing framework) but finally gave up with writing my own "mini-framework" with it because of the awkward XML configuration files.
Don't get me wrong, I love XML for what it is good at, data exchange and such applications, but the idea that _everything_ has to be in XML isn't a useful one (IMHO).
One popular hack here in europe was to put a switch on the motherboard jumper that controlled the PAL/NTSC frequency. That way, you could switch from the normal 50Hz generator for the video to the NTSC 60Hz generator, and the synced nature of the chips would make the CPU run faster as well.
It was really handy when making large compressed files on copy parties back in the day, or when pre-calculating large sets of 3d motion data for demos.
The TV set didn't show anything useful though, and it crashed about once an hour.:-)
In the future, I'd say less than 30% of the video memory will be used for textures.
Both OpenGL (via extensions) and DirextX allow you to allocate raw video memory today to stuff custom vertex data on the cards own memory and then use index streaming to render vertex buffers directly from the card by using DMA.
The speedup is _huge_, especially if the data doesn't change, such as for static stuff like terrain blocks of very high resolution, buildings.
Most games and demos currently use AGP memory for this, but as cards get more and more memory, they'll sure use every bit of it. The newer Unreal engines store their terrain geometry this way (Americas Army, UT2003..).
Using video memory for large 3d meshes is really the only way you can reach the theoretical limits of the graphic card, so it's not only about textures anymore.
Besides, 3d textures are also available, and they are very memory hungry:-)
I second this, with the emphasis on "developing" a computer character. This isn't anything like the real thing.
A Everquest or UO character is just a bunch of stats walking around in fullplate.
In other words, your character is only what other players envision him or her as; i.e. someone who has helped a lot with tough fights or a loot-grabber.
So a pregenerated high-level character would be.. what? An anonymous coward in fullplate?:-)
Here's an interesting tidbit. From the preface of "Compilers: Principles, Techniques and Tools" (Aho, Sethi and Ullman), ISBN 0-201-10194-7 the authors describe the process of typesetting the book.
Quote: This book was phototypeset by the authors using the excellent software available on the UNIX system. The typesetting command read
pic files | tbl | eqn | troff -ms End Quote
I work with commercial game engine for a living, and it along with others really seem to go for the idea of replaceable renderers instead of tying the finished game to one specific output target such as OpenGL or Direct3D.
Most games use their own data structures for things like animation, meshes, BSP trees and terrain anyway, so adding an pluggable rendering hook a bit further up the rendering pipeline that does the conversion to the actual rendering primivites and API data types seems like a smarter solution than relying on anything like the hack these guys have come up with.
As another poster mentioned, it will be more interesting to see how they'll tackle the COM problems than to see if they'll succeed with the emulation stuff.
I'm paying about USD $22 per month for 10 MBps bi-directional without any caps or restrictions on running servers. DHCP, but still exceptionally good value.
It's always nice to download the latest kernel source in a matter of seconds:-)
>When you only have 1 OS that you plan to sell
>your game on, why do you need something that is
>cross-platform?
Because in the game industry, you really can't tell if you are going to get a publishing deal for a certain platform. For most developer houses, a title is not locked to a certain platform from the start unless they are ABSOLUTELY SURE that they will ship the game for PC or a certain console.
And even then, most game developers use some kind of inline wrapper library or other toolkit to be able to make the switch should you get a publishing deal for say PS2.
The same process applies to art and 3D creation. In the beginning of the development, poly counts are usually held back a bit and textures are scaled down from higher-quality originals so the game can fit into a lot of possible configurations at first. Poly detail is then boosted again once you know what to concentrate on.
This is the reason many companies choose early one to license a complete engine with many rendering backends that simplifies delaying the platform choice, it's just the right way to go for most companies.
It's not about OpenGL vs. DirectX, it's about being able to deliver the title on schedule, for the platform you have a contract for. Use whatever works.
Slashdot Mirror
Sadly, OpenGL drivers on Linux aren't up to speed feature-wise. ATI's drivers are especially poor. For instance, you can't reliably create a buffer object on Linux without a fallback to the much slower PBuffer system.
Feature for feature, OpenGL 2.0 on Windows is sort of competing with DX9 and somewhat DX10, but on Linux you can't use any of the features required for a modern game engine. In order to ship a competitive title in 2007 you need multiple render targets, Shader model 3.0 support and floating-point buffers. UT and Doom are ancient games as far as rendering technology goes.
I tried it on my PowerMac G5 (the 2x2.7GHz flavor), but it keeps powering down because of overheating. Fedora Core 6 seems to has the same bug.
:-)
Apparently a lot of G5 boxes have problems because if the software doesn't correctly babysit the fan and pump levels (yes, some G5s are liquid cooled!), the hardware shuts down. After a few hours of kernel tweaking and fscking I gave up.
Hope they fix it before Apple discontinues OS X on PPC..
The finally got around to fixing the bug where FF would consume 100% CPU on Mac OS X when you press and hold the left mouse button. This was a major issue for everyone with a laptop (it goes through battery much faster) and also annoying on the Mac Pros (the CPU fans spin up when you select text).
1 0
See https://bugzilla.mozilla.org/show_bug.cgi?id=1417
What's happening is that everyone's going crazy about the next-gen consoles and instead of porting games from the PC to the console, they're doing the reverse and it shows.
Even Red Storm has been bit by this, as is evident from RS:Lockdown. It's a straight port from the console to the PC and so watered down that they're losing their entire IP on the PC side.
I also work as a programmer with a large game studio and the team is about 50 people. Of those, about 15 is dedicated to programming and scheduling for programming tasks. The rest are mainly content creators, i.e. 3d modellers, animators and sound artists.
:-)
Everyone is still struggling with the project as a whole, but within your realm of expertise (in my case portability and core subsystems) you find fun challenges and new ways to think on a daily basis.
When it works, it's just as fun as the solo trip but the project as a whole moves so much faster compared to what you could ever hope to produce by yourself.
My company is in the fortunate position of owning and developing an in-house game engine and that's why we have all these programmers. It's also our ticket to producing original gameplay.
My guess is that with more technology licensing we'll see a 90%/10% split of content/code in the future because there's a lot of money to save by just licensing an existing engine. Management likes to cut risks; even if it means sacrificing orginality. How many Quake/Unreal-based games have been successful over the last few years without any new engine code? Plenty! All you need is content.
Maybe the guerilla developers will take over the day all large game studios all sit around and borrow each other's technology and produce nothing new.
If you're using a single coil pickup guitar like a Fender Strat, the only thing you can do is place the 5-way selector in the neck+middle or middle+bridge positions to simulate a humbucking effect, that reduces the noise to acceptable levels. :)
:)
For a humbucking guitar, try shaving off the top treble with the tone control if it's still a problem.
Also, turn off everything you don't need while recording.. You hardly need to sit infront of the TV when laying down a track?
As for sound cards, if you're serious about recording at home spend the $300 on a good sound card. It's worth it.
These come with better AD/DA and have the monitoring options you need. Also, you get much lower latencies in Cubase etc. with these cards, down to a few ms, and you won't need the hacked ASIO drivers.
I see a lot of replies here that flame XML as an RPC protocol. Using XML as a message format for RPC is just one small part of what you can do with it.
:-)
The real strength you get for free when using XML is that you can use standard parsers and transformers to handle different kinds of data in a uniform manner.
I'll give you an example..
Today I was working on my wxWindows application, and I needed to translate (i18n) a lot of windows, dialogs and menus to a few languages. The resources are specified in XRC which is an XML format.
Within XRC files labels for buttons and other widgets are written in the language they were created in, usually english.
What I did was write an XML catalog file for each language. I then ran an XSLT processor with the XRC files, using the catalogs as plugins with a simple pattern match rule -- and I didn't have to write one single line of customized code to do it.
Though for RPC I'll stick to CORBA with IIOP any day
Gas here in Sweden is about $5.10 per gallon if my unit conversions are correct (9.60 SEK per liter). Of that, about 75% are taxes.
;-)
Even with these gas prices SUVs are getting more and more popular over here, though most people drive 10 year old japanese cars.
Most people use public transportation in the large cities (I live in Stockholm) because it's much cheaper (about $55 per month for unlimited use) and there are almost no parking places.
So don't whine about gas prices in the U.S
Floppies have always been this bad. The 5 1/4" disks were somewhat better IMO. But ten years ago people accepted it in another way.
:-)
I have a list in my head of stuff that almost never works, and I try to shy away from them:
1) Floppies, in particular pre-formatted
2) Modems.
3) Printers of suspicous brands.
4) Windows 9?.
5) your entry here
You can also use GNU bc for this:
3 8462643383279502884197169399375 08
$ bc -l
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
scale=50
a(1)*4
3.1415926535897932
I just tried timing OpenOffice writer startups on my AMD XP 1700 w/ U160 scsi. A cold startup took 10 seconds while a subsequent startup took 1 second.
I have a gig of ram, so disk I/O was not involved in the second startup. Whatever the problem is, it seems to be I/O bound.
Good thing the only stuff I sing was written in the twenties, and most of it has "Traditional" listed as the author.
It's a good day to have the blues.
Sure, load balancing of dynamic stuff is a lot harder than with static pages, but it's not rocket science.
If there's no need for the page to be up to date to the second, and you're dealing with a large server cluster, just place a few reverse proxies on front of the cluster that maps the URLs that can be subjected to caching. Then update the pages every minute or so.
This is even better because you only need to make sure the pages work in a dynamic fashion, and you can test the generation and caching separetly. Why bother with writing your own HTML to disk?
where the www is heading, IMHO. Seven years ago, anyone was hardly using dynamic stuff on the web, and IIRC back then it was mostly flat HTML.
But today, when 90% of the stuff served (besides images) by web servers are dynamic content, why does a web server like this get a headline?
Ok, I know it does CGI, but come on, CGI is as dead as Ultrix.
I'm not trying to let this project down. I'm sure there are plenty of happy users that don't need the "bloat" associated with Apache, IIS and other servers--but I'd be surprised if they did anything more advanced than the occasional photo album homepage.
We all use bash (mostly). Not because it's the smallest, but because it does everything we've come to expect from a shell.
To me, Boa seems a lot like the effort to rewrite the unix utilities in asm to reduce size. It's a challenging excersise, but in the long run it's going nowhere.
For the casual developer or admin, I think the new Sun-endorsed XML formats for webtrees and other configuration data is worthless. It's simply too verbose for me.
I recently played with Cocoon (which is a lovely publishing framework) but finally gave up with writing my own "mini-framework" with it because of the awkward XML configuration files.
Don't get me wrong, I love XML for what it is good at, data exchange and such applications, but the idea that _everything_ has to be in XML isn't a useful one (IMHO).
One popular hack here in europe was to put a switch on the motherboard jumper that controlled the PAL/NTSC frequency. That way, you could switch from the normal 50Hz generator for the video to the NTSC 60Hz generator, and the synced nature of the chips would make the CPU run faster as well.
:-)
It was really handy when making large compressed files on copy parties back in the day, or when pre-calculating large sets of 3d motion data for demos.
The TV set didn't show anything useful though, and it crashed about once an hour.
In the future, I'd say less than 30% of the video memory will be used for textures.
:-)
Both OpenGL (via extensions) and DirextX allow you to allocate raw video memory today to stuff custom vertex data on the cards own memory and then use index streaming to render vertex buffers directly from the card by using DMA.
The speedup is _huge_, especially if the data doesn't change, such as for static stuff like terrain blocks of very high resolution, buildings.
Most games and demos currently use AGP memory for this, but as cards get more and more memory, they'll sure use every bit of it. The newer Unreal engines store their terrain geometry this way (Americas Army, UT2003..).
Using video memory for large 3d meshes is really the only way you can reach the theoretical limits of the graphic card, so it's not only about textures anymore.
Besides, 3d textures are also available, and they are very memory hungry
I second this, with the emphasis on "developing" a computer character. This isn't anything like the real thing.
:-)
A Everquest or UO character is just a bunch of stats walking around in fullplate.
In other words, your character is only what other players envision him or her as; i.e. someone who has helped a lot with tough fights or a loot-grabber.
So a pregenerated high-level character would be.. what? An anonymous coward in fullplate?
Here's an interesting tidbit. From the preface of "Compilers: Principles, Techniques and Tools" (Aho, Sethi and Ullman), ISBN 0-201-10194-7 the authors describe the process of typesetting the book.
Quote:
This book was phototypeset by the authors using the excellent software available on the UNIX system. The typesetting command read
pic files | tbl | eqn | troff -ms
End Quote
:-)
I work with commercial game engine for a living, and it along with others really seem to go for the idea of replaceable renderers instead of tying the finished game to one specific output target such as OpenGL or Direct3D.
Most games use their own data structures for things like animation, meshes, BSP trees and terrain anyway, so adding an pluggable rendering hook a bit further up the rendering pipeline that does the conversion to the actual rendering primivites and API data types seems like a smarter solution than relying on anything like the hack these guys have come up with.
As another poster mentioned, it will be more interesting to see how they'll tackle the COM problems than to see if they'll succeed with the emulation stuff.
I live just outside Stockholm, Sweden.
:-)
I'm paying about USD $22 per month for 10 MBps bi-directional without any caps or restrictions on running servers. DHCP, but still exceptionally good value.
It's always nice to download the latest kernel source in a matter of seconds
Hey! That would mean that all internet servers are running Windows.
Oh wait, I forgot Solaris.
> I do have crashes, but they're all due to the > Radeon 8500 beta drivers(to be expected)
> - I'm sorry, sir. I don't do Windows.
Does anyone else see the the humor in this post considering the sig?
(Sorry, couldn't resist.)
>When you only have 1 OS that you plan to sell
>your game on, why do you need something that is
>cross-platform?
Because in the game industry, you really can't tell if you are going to get a publishing deal for a certain platform. For most developer houses, a title is not locked to a certain platform from the start unless they are ABSOLUTELY SURE that they will ship the game for PC or a certain console.
And even then, most game developers use some kind of inline wrapper library or other toolkit to be able to make the switch should you get a publishing deal for say PS2.
The same process applies to art and 3D creation. In the beginning of the development, poly counts are usually held back a bit and textures are scaled down from higher-quality originals so the game can fit into a lot of possible configurations at first. Poly detail is then boosted again once you know what to concentrate on.
This is the reason many companies choose early one to license a complete engine with many rendering backends that simplifies delaying the platform choice, it's just the right way to go for most companies.
It's not about OpenGL vs. DirectX, it's about being able to deliver the title on schedule, for the platform you have a contract for. Use whatever works.
Just my 0.1 SEK.