Amazing Demo Scene Guy (bit techy)

[gumboot]

Wasn't the argument in the past that drawing the sky would save explicitly clearing the buffers? Whereas now you'd want to draw occluders to fill the z cache. It's a good example of a design decision that goes from being just right to totally wrong as the hardware evolves.

Certainly in the days before 3D hardware, I had a graphics card with faster memory than my system memory (but only for writes). It was almost certainly faster to write the whole framebuffer than to fiddle about with z-buffers or calculate which areas still had sky.

[Firefox]

They were doing all that MISRA crap, and using peculiar strategies for reliability auditing... it all sounded like somebody there had less of an idea about software reliability than your average demo coder.

Fucking MISRA! Their standards are a *huge* step *backwards* in quality compared to the standards I normally adhere to. I don't know who makes up MISRA standards, but it feels like a committee of PHBs.

Some of my clients insist that all their code has to be MISRA-compliant, because they think if they can claim MISRA compliance it'll magically confer quality and reliability on their products. Which is bollocks; meticulous engineering and thorough testing are where quality and reliability come from.

[arron]

...and if you could build a mathematical model to texture, build and augment a entire city without needing to open a graphics editor, then this would help solve the "exponential content crisis" I could see looming.

Introversion are doing some interesting things in this field for the Subversion game.

See the It's all in your head entries.
http://www.introversion.co.uk/blog/index.php

Hmm, that's really interesting. It's good to see stuff like this take shape. I wonder what they're going to do with it?

[arron]

http://www.gamasutra.com/view/feature/3 ... php?page=1

Now this is a bit nuts. I once did a Tetris game in Excel using the cell colours and VBA once..but a 3D engine? Blimey.

[gravy]

There's a tendency for the inept to over-generalise their code, and to use faddish constructs that aren't really appropriate, and to use the latest libraries and languages and things like XML (a universal wrong), because that's what it's cool to do.

What's wrong with XML?

[PaulCunningham]

There's a tendency for the inept to over-generalise their code, and to use faddish constructs that aren't really appropriate, and to use the latest libraries and languages and things like XML (a universal wrong), because that's what it's cool to do.

What's wrong with XML?

I really love inventing new file formats - it's so much fun.

[gravy]

Yeah I'm getting a whiff of that

For certain things I got a lot of time for XML. Just a few days ago I had a Vis Studio project with a load of files in but a heck of a lot more in the actual project directory. I had a look at the VS project file and it's XML. Writing some Ruby to run through the XML to figure out what files are actually needed and remove the redundant ones took 5 mins. In the old pre-XML days it'd be done by hand or I'd have to reverse engineer the project file format.

Calling it a "universal wrong" seems to be missing the point a bit.

[Darkflame]

If something is universaly wrong, then at least its a standard, and thus good in some ways

[gumboot]

There's a tendency for the inept to over-generalise their code, and to use faddish constructs that aren't really appropriate, and to use the latest libraries and languages and things like XML (a universal wrong), because that's what it's cool to do.

What's wrong with XML?

The witlessness of subsequent responses suggests that I shouldn't bother, but I might give it a brief go just on the off chance...

First a basic semantic observation. It rarely, if ever, marks anything up. In the cases where there really is text outside of the angle brackets it's almost entirely meaningless, which means that the markup is essential and not an abstract layer. So the basic premise itself is false.

On top of that it's a heavy burden for machines to process. XML parsers are enormous, complex, and oftentimes unreasonably memory hungry (although that may all be well hidden from you if you use high-level languages). That's all well and good for a desktop PC where no operation is to be performed without a small irritating pause beforehand, but in embedded land or in a place where people are having a discussion about modern inefficiency and bloat it's well out of place. Moreover, the heirarchical structure tends to add more burden to consistency checking than benefit to structure, and allows malicious data to execute effective DoS attacks much more easily.

Much of the structure exists because of its derivation from being markup, which in turn was meant to be human-readable, but XML itself is rarely that. It's mark-up being used for serialisation of data, which can obviously work, but it does not come out easy to read. You need dedicated tools for it, and in that case you should be free to use a format that's better suited to machine-parsers.

[_TinOmen_]

You do have some points there gumboot. I can understand xml-parsing can be a performance problem in embedded applications. But for desktop (and server) applications, using xml for configuration-files and user-documents at least is a much better choice than having a custom binary format imo. Lightweight xml-parsers do exist.

The thing that bugs me about xml is that many developer seems to think you need a xml-engine to create xml-data. So when they need to generate a little snippet of xml they statically link to a big xml-engine. Instead of just doing some simple string concatenations which is really all that is needed in most cases.

[gravy]

It sucks for embedded applications if used real time, it doesn't necessarily suck for embedded completely.

Games on consoles are essentially embedded applications and when creating content for games it's very useful to have data held in a way that's easily edited and can be validated. XML is pretty good on that front, there are good tools for editing it and schemas can be used to validate the XML's correctness.

It can work really well if you use XML for parameters that can fluctuate a lot during development allowing you to easily edit and change key data. For the final build the XML is ideally compiled down to a binary format that can be loaded in and be ready to use after some minor pointer fix up. You get the best of both worlds.

I don't get your complaints about data being intrinsically hierarchical. That's dependent on what you put in your XML file, it's easy to create an XML file that's practically flat. Same goes for quickness of interpreting XML data. If you create the data it's up to you how you parse it. I had to do some work interpreting an MS Project file and I found the usual XML libs too slow so I rolled my own solution using regular expressions that was plenty fast enough and worked within the bounds I needed. Just because you can make ridiculously complicated hard to parse XML files it doesn't mean you have an obligation to do so.

It is useful. It's been useful to me and I've seen it in use on a number of projects as an intermediary format with great success. I'm with you that embedded apps shouldn't have libxml or xpath linked in at run time but calling it a universal wrong is off beam.

[korruptor]

The only thing wrong with XML is the decision to re-engineer SGML, HyTime, etc. but do so in a completely ballsed up fashion. Perfectly good standards for all of this stuff have existed since the 70s, most of which are generally more powerful and had very robust toolchains. The one benefit to XML, at least, is more software jumping on the markup bandwagon, but tbh, I'd much prefer to have had proper SGML support from the get go, and companies chasing down a full and flexible HyTime implementation, for example. Man, YouTube could be so much more useful

[Dio]

My major argument against XML is it's ludicrous entropy. It's hard to beat about 30% efficiency with it. I'll freely admit I'm woolly on the fundamentals of why it might be useful though, so I'm more likely to see it's negatives than its positives.

[Dio]

Five years ago I honestly thought that I'd never see another game being so utterly daft as to draw the sky first, but I couldn't have been more wrong - the games that do it right are still in the minority (and those are usually ones where the graphics companies have had some engineering input). Similar problems are endemic.

Wasn't the argument in the past that drawing the sky would save explicitly clearing the buffers? Whereas now you'd want to draw occluders to fill the z cache. It's a good example of a design decision that goes from being just right to totally wrong as the hardware evolves.

I suspect that it's that they simply don't even think about it. These are bright people who can write hundred-instruction pixel shaders (and use them on the sky, gnnnggh) and arrange the 3D engine to work in rough front-to-back order - but still put the sky first.

That's the problem in the games industry - too little common sense or not enough time to apply what they have.

[teamonkey]

My major argument against XML is it's ludicrous entropy. It's hard to beat about 30% efficiency with it.

It compresses very well though.