Is XML something required to use in modern games? Sense I'm trying to make game that will be programmed like a professional programmer did it, So should i use XML in my game or it is just an optional thing, Why and Why not?
There's nothing wrong with using XML if it solves your problem. There's nothing wrong with not using XML if it isn't the best option for solving your problem.
If you want to store data in an a format which is easy to query, then XML is not a bad option. If you're look for space efficiency, XML is not a good option. If you are looking for cross-platform features, XML is a no-brainer compared to binary formats.
JSON is another option which is very simple and very lightweight.
In short, it depends on your requirements. If you want more direction you'll have to give more information.
Use whatever works for you. Don't judge your tools based on whether something is considered "uncool". If it works for you and helps you create maintainable and flexible code and data, use it.
Now specifically for XML - that's definitely a format that is widely used and has libraries for virtually every platform. I've worked on a recent Xbox 360 and PlayStation 3 title that made use of XML.
Related
I was looking at MeVisLab and I wondered if anyone knows a good framework for making a user interface similar to the one they use. I like the designing flow with boxes and arrows thing.
What I would really like is to able to integrate with C++ using Qt, and perhaps export the graph to xml of something like that.
There is another example of the interface here:
I hope someone knows something
Qt's Graphics View is a "framework" which does a good bit of the handling for the kind of scenario you describe. It doesn't take much code to get off the ground and within striking range of what you're looking for:
http://doc.qt.nokia.com/latest/graphicsview-diagramscene.html
http://doc.qt.nokia.com/latest/graphicsview-elasticnodes.html
I'm not aware of any open-source Qt-based programs that offer exactly what you want already written. Just noticed IBM did open source "DataExplorer", which is interesting to me...I might go take a look at that myself:
http://www.research.ibm.com/dx/
I think there should be a tool to do so ? is anyone here aware of any ?
I saw other posts related to this but found none for C++, I am aware that I can do that with JAVA and C#.
If you use XML Spy or oXygen, you can generate sample XML files based on a schema. Both tools accept commandline options and can be run in batch mode so that'll probably fit in your unit tests, if that's what you're after. Wrap your own C++ code around it and you're in business.
If you need quality XML, with tons of tweakable options, you might want to check out http://www.code-generator.com/XML-Sample-Generator.aspx. No C++ here, just a tool that works, and rises beyond the default "lorem ipsum..." output.
HTH,
~Rob
okay i'm making a game using c++ (for the engine) and openGL, now i've had lots of trouble using cal3d library for importing my 3d max models into my c++ project,
as a matter of fact i dunno where to even start, i can't find any decent guide and their documentation is pure shit really. i've been searching and trying stuff in this for over a month, but i don't even understand the file structure it uses so far :S
i really need some help, r there any other libraries? any decent guide i can use? i'm stuck
thnx alot
Rather than write your own exporter, consider using one of the built-in exporters for FBX, COLLADA, Crosswalk (.XSI), the Quake/Doom3 .MD3/.MD4 format, or even OBJ. It'll be much easier to parse the resulting file format on your end than to write and maintain a brand-new exporter.
Max is a complete pain for any kind of scripting or plugin. I'd suggest using maya instead if at all possible. You'll get better results for animation and rigging, too. I know it's not a direct answer to your question but part of the problem is the info for stuff like this is not easy to come by.
So I understand that there are a few options available as far as parsing straight XML goes: NSXMLParser, TouchXML from TouchCode, etc. That's all fine, and seems to work fine for me.
The real problem here is that there are dozens of small variations in RSS feeds (and Atom feeds too), so supporting all possible permutations of feeds available out on the Internet gets very difficult to manage. I searched around for a library that would handle all of these low-level details for me, but came out without anything.
Since one could link to an external C/C++ library in Objective-C, I was wondering if there is a library out there that would be best suited for this task? Someone must have already created something like this, it's just difficult to find the "right" option from the thousands of results in Google.
Anyway, what's the best way to parse RSS/Atom feeds in an iPhone application?
I've just released an open source RSS/Atom Parser for iPhone and hopefully it might be of some use.
I'd love to hear your thoughts on it too!
"Best" is relative. The best performance you'll need to go the SAX route and implement the handlers. I don't know of anything out there open source available (start a google code project and release it for the rest of us to use!)
Whatever you do, it's probably a really bad idea to try and load the whole XML file into memory and act on it like a DOM. Chances are you'll get feeds that are much larger than you can handle on the device leading to frequent memory warnings and crashes.
I'm currently trying out the MWFeedParser #Michael Waterfall is developing.
Quite easy to set up and use (I'm a beginner iPhone developer).
His sample code for using MWFeedParser to populate a UITableViewController implementation is helpful as well.
take a look at apple's XML Performance sample -- which points to using libXML directly -- for performance and quicker updates to the display. Which may be important if you are working with very large feeds.
Check out my library for parsing Atom feeds, (BSAtomParser) at GitHub. It doesn't care about validating the feed, it does its best at returning whatever is valid. The parser covers most of RFC 4287, even extensions.
Here's my solution: a really simple yet powerful RSS parsing library: https://github.com/H2CO3/RSSKit
Have you looked at TouchCode yet? I don't think it has an RSS processor, but it might give you a start.
http://code.google.com/p/touchcode/
I came accross igasus project on sourceforge today. I haven't used it or really checked it, but perhaps it might help.
From their site:
igagus is a web service for the iPhone that allows aggregation of RSS to be delivered in an iPhone friendly format.
Actually, I was trying to suggest you ask on the TouchCode discussion board, because I remember someone was trying to expand it to support RSS. That might be a decent starting point. But I was being rushed by my wife.
But I see now that TouchCode doesn't have a discussion board. I'd still ask the author, though, he might know what came of that effort.
This might be a reasonable starting point for you. Atom support isn't there yet, but you could help out?
I am in the preliminary stages of planning a project with a client to redo their current website. I took a look at their current site to see what issues they are currently dealing with and upon inspection I noticed that every page is being rendered entirely using XSLT. I am familiar with XSLT, I have used it to render custom controls that need to be refreshed often on the client-side, but never to render an entire page.
Help me become less ignorant, what could be the reasoning behind this? What benefits or disadvantages does this bring to the table?
Server-side:
Advantages:
Clean, concise templates
An easy way to process XML data into HTML
Reasonably fast
Disadvantages:
Programming model unfamiliar and uncomfortable for many procedural-language programmers
Awkward if some or all source data is not in XML
Can be very slow when not used carefully (small changes can have large repercussions)
Client-side:
Advantages:
A convenient way to off-load processing onto client code, where scripts can potentially have much better knowledge of how best to format the resulting HTML.
Disadvantages:
Browser support is all over the map.
Google won't thank you.
Sounds like they did it because they knew XSL-T very well and already had XML data on hand.
I wouldn't like the solution myself. XSL-T isn't the easiest thing to read or write. It doesn't lend itself well to visualizing how a page will look. It cuts designers and web developers out of the process. And it doesn't internationalize well. There's nothing equivalent to Java resource bundles that can pull out locale specific information. I don't consider cut & paste a good solution.
XSLT on client side
Disables progressive rendering. User won't see anything at all until entire stylesheet and data is loaded completely.
Not supported by search engines and other crawlers. They'll see raw XML.
Not supported by older/less advanced browsers.
XSLT in general
Unless you carefully design your stylesheets, they may quickly become difficult to maintain:
with numerous templates it may be very difficult to figure out which templates are applied.
verbosity of XSLT and XML syntax make it hard to understand anything at glance.
XPath tricks are tempting, but nightmare to modify later.
I think XSLT is great when built the right way(We use a framework of templates at work).
Sounds like the All-singing-all-dancing XML fetish.
Since you can do anything with XSLT, might as well do everything. I've had people ask why a data warehouse isn't just XSLT transforms between input, data mart and reports.
Advantage. Everything's in XML.
Disadvantages.
Not very readable. Your page templates are bound up as XSLT transformations with confusing looping and conditional processing features.
Any change to page templates requires an XSLT expert, in addition to the graphic designer who created (and debugged) the HTML and CSS.
Biggest benefit: platform neutral way to render xml
Biggest disadvantage xsl is difficult to maintain
I've once had to work with an xsl over 4,000 lines long that also includes several other xsl templates. Now that was hard to work with!
The answers above provide a good survey of some of the advantages and disadvantages of XSLT. I'd like to add another disadvantage. We have found that you pretty quickly run into scalability issues when using XSLT for moderately large datasets.
When processing XML files, XSLT must load the entire document into memory. With Xalan, this consumes roughly 10x the size of the input file (saxon has an alternative DOM implementation that uses less memory). If any of your input datasets grow beyond a couple of hundred megabytes, your XSLT processor might just flake out.