Thats fine if you have only one display, but for people like me using more than one display, is better having visual studio in one screen and Unity on a secondary screen (more room for Unity windows). Sorry, can’t those tiny script editors bundled in the engine, i need Visual Studio in full screen. ^^
I’m aware that DX11 won’t make your game look better, in fact any graphic API will automatically make your asset look better, but it gives you more flexibilities and posibilities, like for example, nice MSAA using defferred rendering, better hardware shadows filtering, tesselation, geometry shaders, etc.
I’m partly with you on that one, the problem isn’t DX9/DX11, is Unity not been pushed to the limits like CE3 does.
Thats provably why, no one is taking Unity serious for AAA titles. Any AAA engines offerts right out of the box lots of eye candy features.
Again, i do believe that DX11 wont make your current game looks better, but will gives you more posibilities as a shader programmer or 3D engine programmer to create some extra set of visual features to improve it, features not being posible on DX9, the rest is an art work job. And yes, CryEngine3 does some nasty stuff with their full defferred stuff, they have defferred projectors/decals, defferred lighting, deffered reflection and lots of deffered stuff thats avoid extra drawcalls. At its basis it is highly optimized, that even UnrealEngine can’t compete with. But i don’t believe Unity will follow CryEngine route (super optimized for real-time) and DX11 in Unity will bring new posibilities to improve the rendering power of Unity, that are almost imposible on DX9.
Cheers,
Ah, but .NET isn’t Bytecode. It’s JIT compiled; stands for Just In Time. That means that as soon as a method is called for the first time, it’s compiled into native code. So while a .NET application might take longer to start up and might be a little bit slow as it starts, overall it’s just about as fast as the same algorithms in C++*.
*C++ isn’t the “increase FPS” button that many people seem to think it is, but since it’s lower level, you can make more optimized (and more headache-inducing) algorithms than are possible with Java or .NET.
Interesting replies to what I had posted. Indeed I can see your point. It’s important to push forward early in order to keep up with the neighbours.
Will the big budget games happen? lets look at a case study for engines:
id software. They had to make a game for every major engine they released.
Unreal. They had to make a game for every major engine they released.
Crytek. They had to make a game for every major engine they released.
Unity. They haven’t made any games for every major engine they released. And until they do, competing on a feature level is moot as no big guns will touch unity until it happens. Indeed, none of the big players in the business would have touched the above companies unless there was a published successful game to show it off. Demos are everywhere, nobody takes notice of demos.
Unity gave it a good shot with boot camp demo, but it’s still a demo. I’d love to see an AAA unity game in the stores, and whats more its totally possible. MW2 could have been done with unity 3, and whats more - it would probably perform the same since AAA games use scripting and bytecode up to the wazoos and you’re not actually seeing better performance from them except perhaps just how much middleware and optimised graphics they use.
I haven’t found your final statement to be true for most x86-32 and x86-64 systems (and currently, pretty much all other systems are irrelivent) past a very basic OS level. The only really big increase I can think of is 16 bit code runs slow on x86-32 and x86-64, but legacy mode and registers are generally irrelevant. Also, you can do a JIT system (like LLVMs cough cough) that doesn’t give away your source code.
Well for 4.0 or earlier (the sooner the better!!!)
faster engine (renders etc) so the famous unity LAG will dissapear.
Speedtree, Bink support.
Matinee like (Unreal engine 3) cinematic editor.
Kismet like (unreal engine3) type of visual scripting build in
Material editor
Particle editor (like Unreal Engine3)
Physics editor (like unreal Engine 3)
Animation editor (like Unreal engine3)
as you can see, most of the Unreal Engine 3 toolsets/editors are needed (the reason why AAA companies use UE3 so often)
for easy game making. (more control per thing).
Epic games, knows how to do things professionally (and did years of research on what licensees needed/wanted in the workflow)
use that to improve Unity.
(e.g. Trinigy Vision etc. also use this approach, and that engine is also very popular in the industry)
I dont think you are looking from right perspective.
Unreal, Crytek and Id are all much bigger and more experianced team with long time engine development (at least twice as much as Unity devs). Unity team just probably doesnt have time to put team in game production too.
Also why did you put it they “had” to make game? I am sure that Epic games didnt had to make game becouse of finacial problems. They sold probably arround 100 licenses for UE2 and 3.
Just for the record, you can already do this. If you’re on Mac (I guess it’s similar in Windows, but I personally wouldn’t know), drill down to the Terminal and perform the following:
cd /Applications/Unity/Unity.app/Contents/MacOS
./Unity -projectPath <pathToYourOtherProjectHere>
An example of -projectPath would be:
./Unity -projectPath "/Volumes/Your Awesome External Drive/Unity Games/That Other Unity Project"
(the path to the project needs to be enclosed in quotes if there are spaces or any other sort of special characters in it.)
That will open up a new Unity editor instance focused on the other project that you passed as argument to the -projectPath flag. An alternate way that doesn’t require the -projectPath flag is to turn on the “Show Project Wizard at Startup” option in the Unity preferences and that will force Unity to always ask you what project you want to go to when you open up (any instance of) the editor.
Admittedly, there’s still a lot of room for your request because this whole thing could be made easier, more visible and more accessible for everybody, even for those like me who love and already spend a lot of time at the Terminal!
and you can do it on osx too, just be aware that the 2 instances at the same time from doc etc is no unity thing, that an osx thing.
if you want to start two of them with different projects (the same ones is a no go and not allowed happily in U3 as it breaks the whole project) you can do so from the command line. There is somewhere instruction on it.
I can offer a cast-iron guarantee that the following features WILL DEFINITELY be included in Unity 4.0:
An even number just to the left of the first decimal point in the version number!
An awesome new About… box!
Some new stuff and changes in the Editor!
Some new stuff and changes in the engine!
More stuff in the Asset Store than there is today!
Some stuff people will love!
Some other stuff people (like Taumel) won’t like—but the precise bits will vary from poster to poster!
A “Make MMORPG” button!*
A thread appearing in the forums shortly after its release demanding to know which features will appear in Unity 5.0!
Seriously, people: What in the name of Harold Camping is this thread even doing here?
Terms and conditions apply. User must purchase unadvertised “Unity MMORPG” license. Staggeringly expensive hardware, hosting, and bandwidth required. License fee will be greater than $NaN. Must have own development team consisting entirely of innocent teenaged wannabes with absolutely no interest in making their own MMORPGs: only yours**. Pricing is per server. Documentation extra. No sample code is supplied. Must add own graphics, audio, quests, clichés and other content, including scripts and code. “Make MMORPG” button is for illustrative use only.
