Quote:Original post by Antheus
Shaders - text format usually as source. You will not want to be forced to use some editor to edit them.
Future proofing - binary formats are often based on current architecture. Several years ago, it was not at all uncommon to have bit-packed fields, 4,8 and 16 bit indexes and bit-juggling compression schemes to make files small.
Many formats include meta data - You will want your chair model to contain name, description, tags, attributes, all text data. Editing them in a simple notepad will make it considerably easier to toy around with when debugging, testing and modding when you do not want to install whole SDK
The above are just some pro-text points, they are by no means definitive. Just trying to point out, there's other ways to look at data rather than just through engine/3DS point of view.
Excellent points. I'll think about writing a text file format in future.
EDIT: I've decided against writing a text file format. COLLADA seems to fill that niche nicely, I see no reason to reinvent the wheel of text based extensible file formats as it were.
Quote:Very true. But what is RAD and why do such tools apear? They are used in areas, where topics and domains are simple, repetitive and defined on meta levels. There's tons of DB management RAD tools, tons of CRUD application RAD tools. But RAD tools do not allow going beyond the borders of what they were designed for.
Unreal engine is a RAD tool. Can you make a MMORTS with it? Gamebuilder is a RAD tool. Can you make a web based multi-user card/poker/slots casino with it? And development of RAD tools inevitably responds to the needs of developers, hence it lags behind cutting edge by 6 months or over a year in most cases.
I'm not a fan of RAD tools either (they often live up to their reputation of being poorly programmed, badly thought out and buggy), but I will concede that they can reduce development time considerably in most cases.
Quote:Standards succeed only if they are standardized. Any standardized format can succeed only, and only if it is unambiguosly supported by all parties. As soon as divergence occurs, disasters happen. Just look at HTML and its evolution. And that was even a proper standard.
I would cite for you the development of Unix and other open source programs. I will not go into arguing the validity and modification of open source code. I will however point out that it is beyond my financial means to develop and support a real standard. However, if a company wants to develop a real industry standard based on the .leo file format and invest the time and money to provide support for it, by all means.
Quote:Sad reality is, future-proofing is impossible. You may make it either incredibly generic, which makes it too broad for immediate practical use, or settle for a set of requirements, only realizing things change in a way you never imagined. XML was designed as an extensible data format. And look what's going on, you have XML programming languages, meta-meta-relation-abstraction layer frameworks defined in XML and operating over XML for description of relation tables, you have 26 flavors of HTML trying to comply with XML.
I would cite the IFF file format. It was developed ages ago by EA and is still being used today in the form of AIFF, WAV, etc files. What I'm going to provide is a set base functionality for the file data. This can be thought of as similar to OpenGL, in that there are standard functions in OpenGL and extensions provide extra functionality on top of the base function set.
Quote:The most practical solution you could do (study and all), would be to define a meta format. Examine different formats used, then work out a meta format, which would serve as convenient translation tool between them. This might give you a nice academic topic, and give you broad understanding of formats, their strengths and weaknesses, and their specific uses.
.leo is similar to a meta-format, however, it provides a base set of functionality. You'll see what I mean when I release the file format specification soon.
Quote:A few years back, I worked on a similar hobby project on a meta language, which used an intermediate language to be able to freely translate between several languages (C, Java, Pascal, Oberon). It was useless for practical purposes, but I learned a great deal about intricate details of various languages, and what makes them unique. The greatest benefit that came from there was why "one size fits all" solution is inevitably doomed, and why finding the right tool for the job is critical.
You're in the exactly same situation here.
I certainly hope not. :)
EDIT: How many of you would be bothered if I used British English instead of American English for this file format?
EDIT: I'm wondering about little-endian and big-endian systems. Could they pose a problem for my file format? (there is a little bit of bit flagging in the format) If so, how could I deal with these problems?
[Edited by - Leo_E_49 on April 4, 2006 1:14:19 AM]