Slashdot Mirror
Is .NET Relevant to Game Developers?
andrew stuart asks: "We've heard an awful lot about how .NET is the future and how .NET signals the end for COM based Windows development, but how far does this go? Is it really the end of COM? Will ALL Windows programming be done with .NET? What about games development? Will games be developed with .NET? If games aren't developed with .NET and Microsoft is killing COM, then what future for games development on Windows? Will there be DirectX for .NET?"
Well, it's pretty much the same thing. (And before that was UCSD Pascal and P-code) Interpreters don't have brute strength speed that assembler, or even earlier C++ had. Sure, they're quick for instantiating a zillion objects from an already loaded class, but are awful for anything doing heavy calculations. For heavy math/memory moving you'll need tighter native compiled code libraries, which I'm already finding to be a headache. That and unless your game runs in a browser, your players will have to have the .net Framework (~20 meg, of which
I note 1.1 is now downloading on Microsoft update.)
So what else does .net have to offer? This whole XML thing? Can't say I've ever considered that
a necessity for game play. Maybe it'll allow the player to enjoy games which are Office compatible
or such, doesn't seem relevant. I feel .net is not for game programmers, at least action games.
Probably fine for strategy games which don't have to do a lot of iterating potential moves.
Then again, maybe this explains the long delays for Star Wars: Galaxies and Duke Nukem Forever...
A feeling of having made the same mistake before: Deja Foobar
At work I've used dotnet for the past year and half full time.
I've built websites with it, I've build desktop apps with it,
I've even built auto-updating distributed apps with it.
Dotnet has some good things to it and some bad things just like
any other technology. Before dotnet, most of my work solutions
were written in VB *shudder*, but when dotnet was released I
switched immediately to C#. C# does some things right that Java
didn't do too well on, but those are honestly pretty rare. IMO,
C# is very much like an immature version of Java. That being
said, Microsoft is pushing dotnet pretty hard.
When it comes to dotnet for game development, it is a
possibility. Mainly because Microsoft is putting so much
emphasis on it. With good native integration into DirectX, they
could push a lot of DirectX developers into using C# or Managed
C++, maybe. It will only happnen if MS can make the integration
fast and tight, and even then I don't think everyone doing
DirectX will use dotnet, it imposes too many rules on you as the
developer and really hides the low level details that are so
critical to many high performance games (yes even using unsafe code). On the other hand it
could be a good language for someone to learn to write games in,
for just that reason.
Of course, that really only applies to people who want to use a
Microsoft product for building games. The ubiquity of dotnet
within the MS world will have little to no effect on the OpenGL
programmers, except that they may need to find a different
editor *if* they have been using Visual Studio.
In reality I think dotnet is what everyone thinks, a competitor
to Java. How many highgrade professional games are written in
Java currently?
Doug Tolton
"The destruction of a value which is, will not bring value to that which isn't." -John Galt
DirectX 9.0 for Managed Code
.NET .NET
= /library/en-us/directx9_m/directx/directx9m.asp?fr ame=true
(its out already)
With DirectX 9.0, developers can take advantage of DirectX multimedia functionality and hardware acceleration while using managed code. Managed DirectX enables access to most of the original unmanaged DirectX functionality. The following are the managed code languages supported by DirectX 9.0 and documented in the software development kit (SDK).
Microsoft Visual C#(TM)
Microsoft Visual Basic®
Microsoft Visual C++®
Microsoft JScript®
http://msdn.microsoft.com/library/default.asp?url
The developers of AC2, developed by another company for microsoft, where given authencation code and chat server code developed by microsoft. The addition of this code has made the game unplayable. Here is a quote about the problem from the microsoft head of the game: " Right now the Chat and Authentication System (the Microsoft technology that handles this entire sort of chat) relies on system calls to another system--one that is not related to the Chat and Authentication System or to AC2--to send out the packets that contain your chat. What is happening is that under high CPU usage (that is, when the game starts reaching its peak), this third system starts to throttle the packets and queue up the game server messages (not to be confused with messages/chat to players)." From what is know about the authentication server and chat they are based on .net technologies. So since microsoft cannot produce its own reliable stuff using .net what is the chance of someone else?
Will games be written with .NET?
.NET?
.NET than are written for Linux?
Yes
Will all games be written with
No
Will games be written with SDL and OpenGL?
Yes
Will all games be written with SDL and OpenGL?
No
Will more games be written with
Yes
Will it really be any different from the way it is now?
No
Was this article posted just to give zealots a chance to yammer about MS world conquest and other conspiracy theories?
Yes
I don't need no instructions to know how to rock!!!!
XML is great for game development. Would I ever distribute a game that uses XML at run time? Probably not. Will I use it for development, and "compile" things down later? Heck yes. A lot of developers forget how nice it is to be able to let your artists play with all sorts of settings and make things dynamically, XML isn't the nicest interface, but easier than bugging a programmer to tweak something for you. However, you really don't need .NET for XML. It's easy to use, sure. However, Xerces C++ interface isn't that bad, and just about anyone can stick a simpler interface on it.
I tend to agree that the CLR is slower than compiling down to machine code. However, I've also seen some pretty cool Java based game development. I think it comes down to the game itself...if it's pushing hardware limits, then .NET is a no go. If it doesn't push the hardware, why not?
- Sighuh?
... at least for now. .NET is a "good" idea in theory. But it's performance is just not up to par compared to the execution times of applications using .NET vs C++.
.NET for the applications. .NET is fairly easy to code many types of applications, but when performance of the final executable is your major goal, then .NET is really not the language for you.
It is the equivelent of placing another abstraction layer on the executable code before it is executed. This inherently decreses performance of the application (its something like the equivelent of writing a game in perl... it relies on the perl interpreter to create the actual executable code which is why something written in perl takes longer to execute then something written in C++ (I know there is a debate on this, but for the majority of cases this is true, however, it is also true that it may be 1000x easier to "code" the application in perl vs C++))
If MS optimizes their interpreter, then in theory, it will eventually become almost as fast as C++, and at that time, it may be worth the benefits of coding in
We were all warned a long time ago that MS products sucked, remember the Magic 8 Ball said, "Outlook not so good"
The parent article seems to have a vague concept of what .NET is. (Perhaps this is more MS propaganda's fault.)
MS released C#, and that's what they're toting when they talk about ending COM-based windows development, I think.
If you knew what COM was, you might have a better understanding of what Microsoft is phasing out. COM is the Component Object Model. It allows programs to invoke special versions of other software (which has a COM written for it) and call routines out of that software. For example, I could call the spellchecker for MS Word from my email-writing program, assuming the user had Word installed, of course.
I used COM in writing an application meant to automate customer response letters (the user wanted to have Word-compatible documents when the program was finished - a perfect example of COM) and let me tell you: COM is hairy. You have to pass pointers to functions, call functions with nasty parameters... it's a good idea, it just doesn't work inside the C/C++ syntax very well.
Unless you're looking for your game to be able to read and write MS Word files, or print through Excel, games probably wouldn't have used the Component Object Model.
C# apparently has the same functionality that COM did, but probably does it a little more elegantly.
In any case, game developers didn't use COM, and they're probably not using C#. They WILL, however, be using .NET. Because Visual Studio .NET is Microsoft's latest incarnation of their programming IDE and compiler package.
And the later versions (hopefully) contain more and more code optimization. And Microsoft HAS good code optimization: they bought all of Watcom's optimizing people a few generations back (when game programming was done almost exclusively in Watcom).
In short: Visual Studio .NET is probably phasing out COM. This has absolutely no bearing on game programming.
--
Disclaimer: The above statement probably includes half-truths, because real truth is too complicated.
I think you were thinking of fortune cookies, not chopsticks. I can assure you, coming from South-East Asia, that the Chinese, Japanese and Koreans all have been using chopsticks for millenias.
Which is why there was much backslapping when a Chinese archaeologist claimed to have found a fork in a cave in China dated to about 3000 BC - it's not that they have not discovered forks, it's that they have "moved on".
And no, my chopstick handling is still rather poor. I can use it to eat rice though :p
Michel
Fedora Project Contribut
way back when .net was still beta and machines were at least 1/2 to 1/4 the speed they are today I saw a demo of Quake 2 models being rendered in .net flawlessly - and this was using OpenGL and an ultra craptastic laptop.
... but I think many games in the future (maybe 3-5 years) will be using .net simply because it makes developing that much easier.
.NET it actually ran slightly faster than my C++ code (probably because of being able to instantiate and destroy objects better). I am a big believer in .net and can't want for better cross platform support
Fast forward two years with Managed DirectX and you have a pretty decent system for writing games with fewer bugs because you are not likely to encounter certain errors (memory leaks for one). Games like Unreal Tournament 2003 and Doom 3 will obviously be tuned using assmebler and written primarily in C/C++
I have benchmarked some encryption routines I wrote in school back in the day, and they were originally done in Java. The Java code started much slower (stupid JVM - big issues) but once everything was in ram and cruising along it wasn't much slower than C++... with
It's not like Microsoft developers will have much choice in the matter. The new Visual Studio is bult around .NET, the title gives it away: "Visual Studio .NET 2003."
.NET because they overused it to the point that the term became essentially meaningless. With the newest VS, it boils down to you can use the .NET Framework (think object-oriented, component-based API), try mixing code from different lanaguages with CLI, and run C#. Oh, and it makes easier to use the still betaish ActiveX.
.NET Framework means wrapping your mind around what, for many programmers will be a new way of developing programs. Simply knowing objects by way of C++ won't cut it. Because of that aspect, I don't see that using old languages via CLI will help that much to get killer performance. And, as for C#, I've never liked it that nuch, and while I know lots of folks who will argue over its functionality, especially over Java, and vice-versa, I seldom hear anyone comparing it performance numbers to those of C or C++.
.NET will be the only tools they have for Microsoft OSs. But, will it lend itself to producing killer games? Maybe someday, but I don't see it happening for another couple of years myself. For now, were I a game programmer, I'd be sticking to C and C++.
But, what does that really mean? Good question, Microsoft is backing off from calling everything
Does any of that make sense for a game programmer? Maybe, but since performance is everything to gamers, I suspect it will be a while before we'll see such games. Learning how to exploit
Bottom line, yes, it will get used because for some developers VS
Steven
Hi,
Where did you get that information on chopsticks? It sounded like interesting story to have on hand, so I took a look at Enclopedia Brittanica, which said:
"Chopsticks of bamboo or wood, and subsequently of ivory and precious metals, originated in China as early as the Shang dynasty (c. 1766-c. 1122 BC) and from there spread throughout East Asia. In China, the substitution of chopsticks for knives at the table reflected the ascendancy of the scholar over the warrior as a cultural hero."
Which would seem to indicate that chopsticks were around for several millenia, and also gives some basis for the pretension associated with them. Do you have any further references on the use of chopsticks in mining restaurants in the U.S.?
The rest of the questions asked have already been answered, so I am going to tackle "Is it really the end of COM?"
.NET under the hood...
Uh... Was Windows 95 the end of MS/DOS? Was COM the end of DDE? Microsoft has a tendancy to wrap up stale old code in fresh new interfaces and let their Marketing people slap a new name on it. Sometimes those interfaces aren't all that fresh; ActiveX was mostly just a rename of COM with a couple of extra methods.
So the answer is no. At least not right away. Maybe ten years from now, but by that time Microsoft will be pushing some new technology without admitting that their new thing has
- -
Are you an SF Fan? Are you a Tru-Fan?
Here's one data point: When the SDK came out I compared the framerate of the DirectX samples in C with the framerate of the equivalent samples in C# (most of the samples are available for both, as examples).
.NET code lost some benchmarks, but it won a few and on the vast majority, they were within a few percent.
.NET to write games.
.NET, then they don't have to.
The framerates were very similar - the
There doesn't appear to be any huge disadvantage to using
One big advantage, however, is CPU portability - with two flavours of 64 bit CPUs just around the corner, plus different optimization strategies for P4 vs Athlon, having bytecode that gets compiled for your CPU when the game is run will be a big advantage if you happen to own anything but a P4.
It's doubtful that anyone's going to ship a game CD with an Itanium build of the binaries, but if it's
- Steve
This is great. So many "NO WAY! .NET IS TOO SLOW!" reminds me of assembly programmers saying "C++? Its slow and a memory hog! Games will NEVER be programmed in C++!!"
.Net, or even play some games that were made with directX and .net.
Well, you can read some books on using DirectX9 for
While computers gain more powerful hardware (faster CPUs, bigger memory, etc...) the coding for games will go forward to the newer languages that makes coding easier. You may not like it, but don't worry. There's always jobs for those with assembly knowledge.
And, for what its worth, I think game coding in Java will start becoming a reality in the next five years (and not just on PDAs and mobile phones)...
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
While you might not be aware of this, cross-platform solutions have been used, are used and will continue to be used to develop games.
.NET? .NET gaming. Those who use DirectX because there is specific things in DirectX that they can't find elsewhere will move on to .NET. Others will realize that OpenGL is better than DirectX as an API for mostly anything (Don't flame me for the exceptions).
.NET and Microsoft is killing COM, then what future for games development on Windows?
.NET and COM programming in one step.
Will ALL Windows programming be done with
no. A whole bunch of DirectX developers that use it because they don't know any better will probably move on to
If games aren't developed with
For christ's sake... is developing games and DirectX now linked by some kind of godly power? Most of the good games out there (quake anyone?) have been built on multiple platforms and released on multiple platforms because their developers had a clue, which most developers don't. Having used Microsoft stuff for the past years is not a good point while trying to choose which library to base a project on. Finding the most portable and easy to use one is.
There was a discussion earlier this week about writing portable games here on slashdot. I believe you haven't read it so here it the main idea:
* If you decide to write a game from scratch, pick portable libraries right at the beginning of the project
* test that the project compiles and works on both platforms as it grows.
* keep bad code and unportable code out of the source.
That way you can probably get rid of DirectX,
I think that's probably the most easily-disproved wild assertion I've ever read, even on
There should be a special prize or something.
Whence? Hence. Whither? Thither.
.NET is the future, but it's not here yet. It's great for writing small applications quickly, like those corporations use internally. The earliest Microsoft would switch over large applications like Office to fully managed code will be around 2007, because only then will most PCs be able to handle it. 3D games will wait at least a few more years. Right now 95%+ of professional game development is done in C++. COM interfaces aren't going anywhere.
.NET evangelist, would answer with "a resounding no".
In 2010 when we might see a serious move to managed code even in games, then COM might start to quietly go away. But thanks to COM interop via COM-callable wrappers, there will continue to be options for C++ developers for the forseeable future.
And if you utter the words "COM is dead" to any Microsoft-employed programmer, they'll tell you to stop being spoon fed by their awesome marketing division. Even Don Box, father of COM and star
The .NET framework on Windows is entirely dependent on existing Win32 APIs and COM technology. Although Microsoft is encouring people to drop the use of COM and Win32 APIs, they themselves heavily depend on these technologies. As it is now, the .NET framework is just a wrapper around existing APIs (COM and Win32). The C# comipler has been implemented using COM, csc.exe being a wrapper around this COM C# compiler. The VS.NET IDE depends heavily on COM. The .NET framework is huge (more than 3000 classes) but only 15-20% of APIs have been covered by these classes. Apparantly, that is enough to write usual application.
.NET where in I argue if there was a real need for MS to come up with .NET. The statements I made above have been backed up in the article by providing links to the comments that MS employees have made about this.
<plug class="shameless" >
I have written an article called Whats the need for
</plug >
Jalil Vaidya
Rember how many years before game programmers moved away from dos booting games to windows games (for performance reasons) the same thing will happen with dot net. Ask me again in 5 years.
love is just extroverted narcissism
> they were invented by a Japanese American in this century.
Whoa, I could have sworn I saw them as far back as 1998.
As a game developer, I am/will use the heck out of C# and .NET to develop software - just not the runtime portions of my games.
.NET allows me to use or not use various parts of the run time (assuming that we architected the interfaces correctly!) in a way that can both maximize usefulness (it looks like it will in the game!), and unit test the game code in a better environment.
.NET are robust enough for these - the .NET IDE proves that.
.NET are better for windows app development - either you have done it, and understand why MFC and C++ blow chunks, or you are in for quite a pleasent suprise when you write that first tool.
Tool development takes up an increasing amount of my team's time. We have custom tools for art manipulation, sound manipulation, and data warehousing. Not to mention our tool for level creation, which we hope to release with the game. All of these tools need to be robust, have clean interfaces, and be developed and changed quickly, and grow with the run time modules.
Remember that C# and
I won't go into why C# and
-Donut
Which is why there was much backslapping when a Chinese archaeologist claimed to have found a fork in a cave in China dated to about 3000 BC - it's not that they have not discovered forks, it's that they have moved on.
How do you know if the Chinese inventor of the fork just didn't market his or her idea well enough for it to catch on? Either that or maybe people resisted the change since they didn't want to give up the simplicity of braking twigs off trees to eat? Just because a technology is superior doesn't make it the popular choice.
I have been using .NET since September 2001. I wrote an open source 3D engine using C#. It makes use of BSP tree visibility culling, it uses WorldCraft as a level editor, it supports OpenGL and it did support NVIDIA's Cg until they changed their interface. When I released this engine open source back in February 2002 I stated clearly that I thought that .NET would be useful for game development.
.NET 3D Engine
ExoEngine - A C#, OpenGL
PS. Some people notice that in the screen shots the engine is only getting about 10fps or less. This is because it was running without 3D hardware accelleration.
Seriously? I doubt many people will actually pay any attention to the answers.
While it may be slightly slower (and I mean slightly) the problem is easily solved and/or irrelevant. because your calling the highly optimized stuff in DirectX for most of the graphics work your speed issues are minimal and any core routing that is really slowing you down can be coded in something else without forcing the whole project into a less useful environment.
For most developers the issue of cross platform is irrelevant. In general I can support most biz needs via a web service anyway or in Windows. The rest of the world is Mac (and there WILL be a Mac implementation because Office on the Mac is a good cash source) or Linux - and Linux is irrelevant for this type of thing.
Then you haven't looked very hard. The Web controls, event model and code behind features are light years ahead of CF and PHP. mod_perl isn't even a player.
The enterprise level apps I have been involved with are either Intranet based (and this .NET is perfect) or Windows based. In both cases .NET is a great
environment and has strong advantages over Java. Besides, given how much Sun is
throwing their weight around with Java most firms see java as a single source
tool and Sun is a much less attractive partner.
You can cut the framework down for custom applications.
It's as good or better than Java, runs as fast as C++ and is much easier to code for than Win32. The web event model rocks and the ability to mix languages kicks ass.
In short, it's good.
--> Fight tyranny and repression.... read
By naming their new framework .Net and focusing marketing on XML, MS has taken advantage of the hype that everyone's eyes are currently on to produce a radically improved API. I'd say
The truth is that Visual Studio 7 is the most comprehensively advanced programming environment I've ever seen and it easily supports a 10 fold increase in programmer productivity versus VS97 due to the quadruple whammy of what I see as Microsoft's first truly pro editing environment, a near complete elimination of language wars by forcing all to be equal in capability and to share objects, a far more comprehensive and easy to use object oriented API than Win32, and the end of the registry and associated DLL hell.
While everyone's watching the bouncing hype ball, 95% of what's good in the framework has been ignored. I believe this is Microsoft's intent.
Where will they go? In two to three years I think we'll start hearing about an OS release that has a CLR interpreter that doesn't run on Win32, but has everything needed natively present to run directly on a kernel. Suddenly, all of the .Net code will be vastly faster and Win32 will be scheduled for deprecation. .Net has nothing to do with the net or with XML, it has to do with replacing the Win32 framework with a new framework. For now, its a framework running on a framework and will thus be slow. Eventually, it will be THE framework doing nothing except what IT needs to do and will cook.
As much as they seem to gripe and make noise about other .Net framework implementation efforts, I think they are really hoping that its done and everyone converts to it. A .Net application running on top of a .Net framework running on top of any of Win32, Linux, or OSX will never be as fast as a .Net application running on a .Net OS. If done with enough slight of hand, its a perfect recipe for a complete coup.
A while ago our MS rep came in for his bi-monthly visit. And he let something slip.
.NET datatypes.
...
.NET server which would pass the 'package' on to the reciepient. [This is all out of memory, which is fuzzy .. so who knows if im getting it all EXACT.]
.NET server (which our REP said would make it a lot more secure than it is now .. har-har) then WHO is going to be making those servers ?
.NET now .. because simply - if it DOESNT get widely adopted than Stage II(tm): Take over the server market by making the desktops REQUIRE MS.NET routing servers, will be as successful as Licence 6.0.
.NET [or Dot-Nyet as my russian friends call it.] is kinda neat. Once you get used to the 10-15% loss of speed. And the higher memory requirements on your servers.
The next desktop version of windows is supposed to be a database structured OS. SO basically everything from word documents, to e-mail, to images are essentially
Sounds kinda cool actually. Now walk with me
Any file could be shared with another computer, by basically sending it to a 'routing' computer.
So e-mail wouldn't be like it is now, nor would web pages, they would be sent to a
What I do remember with shocking clairity was having the epiphany that if everything has to be routed through a
MS is pushing SOOO very hard for
Whats the easiest way to get rid of Apache ? make windows not play with it. They can't control the *nix OS's out there, and they cant put the genie back in the bottle, but they CAN alter their OS to ignore the genie, and maybe make it look like he is wearing a dunce cap.
That being said.
I'm just afraid that this innovation in programming languages is more about gaining control, than improving computer science.
After all - most of our cars still run on gasoline WHY ?
--Ne auderis delere orbem rigidum meum, non erravi pernicose!
Most definitely, in fact there already is DirectX for .NET -- it is called Managed DirectX. Microsoft developed version 9 to have an entire set of "Managed" components. These are used by the .NET Framework. I have been using the .NET Framework, C# and ASP.NET since October of 2000 (ASP+ at the time and Beta1). I have been using DirectX since version 5 and was involved with the beta testing of the Managed DirectX since June of last year. It was released in December. I am currently writing a 3D level editor and game using C# and Managed DirectX. The code is much more cleaner than typical C++ code. Since memory is managed there aren't any memory leaks and I have found that most things are just fine with that. However, if there is a part of the program that needs to be sped up (which isn't as much as you might think) then it can be done with "unsafe" code within C#, or even talk directly to unmanaged C++ code.
Either way, the point is COM programming will be going away -- BUT -- it isn't going to immediate, nor does it need to be. The interops in place allow any COM object to be easily used as a .NET assembly. Don't worry, game development on the Windows OS will not be going anywhere any time soon. .NET will help make more robust games, not hinder.
That's a very misleading statement. Yes, you use Visual Studio .NET, but the XBox does not run CLR code, it runs ordinary native binaries.
That's like saying "I'm running Java!" because you used a Java-to-native compiler and produced an ordinary native EXE, and then ran it without any trace of Java on the system.
ZFS: because love is never having to say fsck
For those systems, the interactive basic interpreter would probably be considered what most people thought of as the OS.
If I remember correctly, a number of C64 games were launched directly from the basic interpreter.
LOAD "MYPROGRAM, 8, 1"
or something like that.
As far as the Atari, the reason you directly booted into games was that with only 64k of memory in the system, you *needed* to displace the basic interpreter and free up 16k of RAM that it occupied. It still loaded a stub of the DOS (for disk access) and then would autoload any file named AUTORUN.SYS
Additionally, since the OS was ROM based, the systems were "instant on" (or very close). So shutting down the system to play a game (and vice versa) wasn't a huge deal.
Nowadays, I have a computer with 512Mb ram, and it takes a little bit to boot into the OS, so shutting down the system just to play a game seems stupid. As another poster pointed out, thats what consoles are for. For a general purpose computer, not being able to launch games alongside with other apps would be annoying.
Anyone used Visual Studio .NET lately? It's touted as being an amazing piece of work, written mostly in .NET compatible languages and for the .NET platform. And guess what - it's slow. It's noticeably slower than the previous Visual Studios, even the bubblegum version for web and VB developers. In comparison to the previous Visual C++, it's practically standing still.
.NET does. Visual Studio is not a zippy application.
.NET enhancements you say? Managed C++ is a bloody nightmare. It's really not practical to use it for anything other than tying native C++ code to .NET components. It's also not much easier than using COM components directly, plus you have to limit yourself to .NET management of memory, objects, exceptions, which all add extra cycles you could avoid going totally native.
.NET very quickly, and there's jobs to be had. Just don't buy into the hype we've been force-fed for the past two years about .NET taking over the world.
Furthermore, it's even noticeably slower than, say, Eclipse, a comparable IDE for Java that uses a platform-independent API to native UI widgets, much like
So keep it C++ but with
We're continually fedd technologies from Microsoft that are supposed to be "the next big thing". Look at COM+. Look at ActiveX. The big thing has become old news year after year while other technologies with fewer hard corporate ties expand and proliferate. It's certainly worth learning--Microsoft is pouring the money bucket into
No, Virginia, there is no Santa Claus. The emperor is naked.