iPhone OS4 today

I'm not sure what will be possible whilst in the editor but pushed to the simulator or on device surely XCode will be able to be used to debug the C++. I've not done much actual XCode dev but i presume its pretty good at this?

 

I tend to agree with Dreamora, albeit that I think that plan b will be fine for the c guys - memory management isn't that big a deal - if you can't do it you're not really a programmer - and that includes you java boys too - but the javascript guys will not likely move to c++. So unity user base (and income) is likely to dramatically shrink.

When I read the blog, my immediate thought was that now Unity have given Apple a reason to deny Unity apps/games as they currently stand (the rope to hang themselves with) - but I imagine that the reality is probably closer to UT and Apple both knowing that plan b is in reality the only plan - and that it's just a matter of time.

I think I'll try to finish up my current project (when I can) but if I get weeks or months of work done and then have to rewrite it all in C++ I will not be a happy bunny.

 

btw, out of interest, I haven't been paying absolute attention to all this recently so does anyone know if anyone anywhere tried submitting an app authored in Flash and got it rejected yet?

if Apple aren't even rejecting Flash apps yet, then Unity might still get the boot at the same time... Hopefully someone was daft enough to try submitting a Flash authored app and got rejected?

 

I think that is why UT haven't said this before. Now they can say to Apple that they were happy enough to accept Unity apps for iOS 4 and even feature them, so Apple's stated reasons for the ToS changes are not appropriate in this case.

 

Currently 10 extra megs of RAM is a too good offer to pass. That being said, C++ instead of C# may not offer any speed benefits at all, depending on where your bottlenecks are. And even if your bottleneck are in the script part, C++ is no guarantee of extra speed just by itself.

But those 10 extra megs... that's 5 extra 1024 x 1024 RGBA16 textures... yummy , at least for the type of game I'm doing.

In the near future, as first/second generation devices become obsolete, an extra 10Mb of RAM usage will become a non-issue for most games.

 

The free RAM is a guarantee and I can't imagine a world where C# code running in top of the Mono runtime will be the same speed. Mono is just C/C++ under the covers is it not? How can running through the memory manager and garbage collector be as fast as direct C/C++?

 

It can happen, although if the platform is always the same (in this case the iPhone/iPod), it's unlikely that C# will ever win performance wise over C/C++.

What I meant by "speed benefits" is that if your bottlenecks are not on the script part (e.g. high poly game, where bottlenecks are mostly on the graphics part), your "benefits" will be reduced.

For instance, if 10% of your game is spent on scripting, even if you get a 100% speed increase by using C++, you'd only improve your game's speed by 5%. To me this is not worth loosing such niceties as GC and Coroutines for instance (you can do coroutines in C++, but it's a fairly complex task).

 

The lose of coroutines will impose some serious problem actually, cause there is no comparable thing outside of virtual environments.

and the performance gain from C++ over C# for equally optimized code is in the 3-5% range from last benchmarks of the language against each other in .NET 3.5 days. Thats not exactly a lot given the extra work you have to do, thats something that benchmark also has shown: you get those 5% at 200-500% of the time required to implement it compared to C#

 

I understand Mono is slower than .NET though. However, trying to code in Unity without coroutines would be a nightmare, I must say. Also I use a fair bit of .NET functionality; it's not like those libraries are just taking up space for no reason....

--Eric

 

Aside of exceptions like system.xml thats really just blowing out a meg for primarily hot air ... NSDictionary are not really much harder to work with and need 0.0mb

but yeah there are cases where the required size is adequate.

 

Personally, I think "Plan B" is a very good solution
given the circumstances. And the potential to make
iPhone apps that take up less memory is very appealing.
I suspect that its only a matter of time before
Apple ends their "grace period" on their new TOS,
and starts getting tougher with their approvals.
But if Apple changes their mind, and decides to
become more generous with their TOS, that's great too!


Congratulations to David and Unity for proposing
"Plan B"!
:-D

 

I had to rewrite some math for “Crash Course” title. Typically c++ vs c# (using Unity Math) speed increase is 200% to 670%.
For example cross product is 2x faster, but lets try to use the same c++ code compiled in c#.

 

I wouldn't entirely trust those benchmarks, similar ones stated that Java was as fast or faster than C++. Practical experience says that's very very wide of the mark.

As for claiming it takes 200-500% more work to do something in C++, sorry but that just sounds like the view of someone not well versed in the language. Having spent time with many so called RAD languages as well as C++ I'd say that the only real differences in speed of implementation between most mid/high level languages comes down to how well versed the user is in that language. The one real difference is that RAD languages tend to be easier to learn and because you learn them faster and get up to speed in less time that can leave you imagining that development in them is faster.

Each language has it's pro's and cons, but "speed of development" is a relative and somewhat meaningless marketing term IMO.

With regards co-routines, actually yes they can exist in C/C++, check out Boost.Coroutine for example. You could always implement your own library if you prefer.

One thing that would be interesting to know about the C++ implementation Unity is planning is whether it's going to allow asm calls. I realize that's a bit hardcore and platform specific stuff but sometimes it's damn useful.

 

Those 200 to 500% include the time required to get it working right, opted and clean, not just "to do it".

And the benchmarks were done in so called "critical and C beneficial" areas like math and other "low level" things, which are neither complex to implement nor require to be over the edge versed.

Its important to keep in mind: VC++ runs on MS.NET through the same end compiler as C# does.
Doing the benchmark on that platform seems fine as it compares the actual language, not the borked / undersupported compiler platforms.
Also, Microsofts compilers are after Intels the ones that generate the most optimized x86 code.

Might be that the difference on mono is larger due to gcc vs mono ( or better "I'm a tuxy, why would I not use c hack hack), but its nowhere in the "dozens of percents" faster anymore as quite some C++ would like to believe to justify the masses of extra work he has to do to get the same result.
On the math end its especially ugly for GCC to come out as winner since Mono 2.2, when Mono got Mono.SIMD, which makes a fair difference if you know how to work with the stuff a bit and the syntax definitely wins against the regular MMX SSE syntax you need to use to get control over those optimizations.


Boost: Thats where my dislike about C++ comes from. Its 2010, not 1990 anymore. PCs are able to do practical parallelism, not only theoretical one and its time that all so called modern languages take their responsibility for that, not only Java, ObjC(++) and C# / MC++. Even the Linux world at one point will have to enter the 21st century with their languages.

As for ASM: Given that Unity iPhone was mentioned to be the only platform to really compile the C++ code to platform code with the rest going through a custom .NET compiler for it, I would assume the answer is a clear no.

 

What I find truly amusing is that UT's Plan B is the exact same thing StoneTrip is doing with Shiva 1.9. Yet when some of us brought it up before Mr. Unity Marketing and a few members said it was pointless, useless, a marketing ploy, had no real world value, etc. I guess memories really are short...

 

The difference is for Shiva it really is pointless.
They still didn't cut iphone authoring outside of OSX and that might be going to break their neck as they actively support developers in breaking their contract (their "unsupported" conversion tool etc just add up to that blatant ignorance towards the set and agreed path to iphone)

The other reason it was useless there is that they don't use any pseudo platform, they area really on lua, not some java / mono intermediate layer.

so if they get cut from the store then because they give a S*** about the contracts they signed with apple upon dev account creation and would get cut due to that as technology, not due to other reasons

 

Dreamora explain it really well, why Shiva solution is pointless,
and beside, you can always go back to their place if you're not treated well in Unity forum Mr. Shiva Fanboy :? (i doubt anyone gonna miss you)

 

@Dreamora, they'e doing the exact same thing as UT. Allowing coding in C++ and ObjC instead of Lua. The only difference is they allow for PC and Linux development. How does that get a user banned? Does the Dev Agreement say you must only use a Mac?

I'm not on any side, silly child. I just use the best tools for the project at hand. Maybe you should look in the mirror when the word 'fanboy' pops in your head.

 

Exactly. It makes it clear that you must use XCode and OSX

Thats why I never got all the fuzz about Flash, cause Apple could just have rejected all applications for breaking the dev contract.

 

I will not feed the troll. I will not feed the troll. I will not feed the troll...

 

@Dreamora, you do have to use XCode and OSX to build iTouch apps with Shiva.

 

Potentially but they provide authoring of the same on any platform through a converter and even offer an "unsupported" tool to work around the original 3.3.2 through lua conversion.

So if Apple were going to kill middleware, shiva would definitely stand above Unity as a target.

in the end, likely neither will be killed though. Unity for nearly granted not and shiva even though it can't offer any strong portfolio, is just not "violating enough" for them to make a lot of fuzz cause its "just lua" so devs using it can get written permission to use lua in their game as per the new 3.3.2

 

I won't say I hate Plan B, but I'm worried...again. Now it's another if/waiting game. Will I finish my app before the changes take affect? Should I not bother and just wait until it does? IF it does?

I just dumped $2400 on 3.0 and I'm wondering if I should have.

My other outlook is that I knew nothing about Unity a year ago, so I guess I could learn from scratch a second time. I'm a mediocre programmer so I don't know how easily I can learn C++. But learning it could be beneficial outside of Unity too.

Hello, thread, my old hated friend...I'm back

 

Hmm, the conspiracy deepens. See here's the thing... there is no Plan B and there doesn't need to be. It just so happens that Mr. Helgason is a huge fan of The Thread. This supposed Plan B is only a ploy to keep The Thread alive and active.

 

then I am sure it's going to be a success

 

the C++ blog post has me relieved, in some ways...

technically, given that the (non-Unity)competition are also working on their "solutions" to this issue, it looks like PlanB has a very high-likelihood of needing to happen if those with far-less "legitimate solutions" continue to claim (ad-hoc) iOS compatibility, thus possibly triggering the "apple-wrath"

which leads me to think that PlanB is(and will stay) full steam ahead, especially given the public announcement. Since Unity has chosen to make the announcement, and even mentioned it being the contingency plan if Unity apps begin to be rejected, this option would best be ready the day the apps begin to be rejected(if ever the day arises).

seems its time to start learning c++, I do enjoy the features that c# brings to the table(time saving for solitary devs), and as has been stated, the ram overhead for c# will become a non-issue for anyone with a device purchased in the last year or so, and with the iPhone 4 having something like 512megs of ram, a paltry 10megs for c# overhead wont really matter IMO.

*************
now for something I haven't read anyone else mentioning:

One question I have regarding this announcement, actually relates to the unity player running in chrome without plugins(as unity recently demoed). With the announcement of Unity running in chrome without the need for plugin installation, would going with c++ also allow for an 8-10 meg smaller download for unity web-player games/apps that are coded in C++? It seems that might be a very good reason to consider PlanB mandatory IMO. If of course it would save on the download size as I mentioned. Does anyone have any insight on this?

it would also be interesting to know how many Unity developers are working on this solution.

 

Nah... Mr Hegelson's secret plan is, actually, to make everybody start studying C++, as a semi-final attempt to fade THE TRHEAD out.

(His final attempt will be Assembly support in Unity!)

 

I should hope not. Though it would be hilarious.

 

Option B. Yes, and please. Thank you, UT.

 

in case some miss the blog and to keep things in context >>

from David Helgason

wait and see...

 

As long as C++ is only an option, it is welcome, otherwise it's just bad business... if people wanted to code in c++ or objective C only, Unity wouldnt have sold has much units as it has already , you can be sure of that...!

 

Sure, but at least is better than being rejected because of ToS, don't you think? ^^
iPhone platform still a very good way to make money, if i have to code in C++, surely i will do. I have done C++ in the past with crappier compilers/tools, so why not now? Go Unity, plan B!
Cheers,

 

Agreed.

I like C#. It's a fun language to program in, but for some games, the performance of C++ makes the difference.

50% better performance means we create better AI, better physics, and in most cases have more objects in the scene.

Losing 8+MB of memory usages is also nice.

I would imagine that Unity wants Apple to allow scripting with C# and Javacript, and doesn't want Apple to think that since Unity supports C++, they can disallow Mono.

BTW: If Objective-C is supported, then C and C++ are as well, since Objective-C is a superset of C and C++ (.m and .mm files).

I hope Unity does introduce C++, while keeping C# and javascript. Unity just keeps getting better and better.

 

@upgrise: If the alloc really happens on the OS then there is no difference.
Difference is that dotnet often does not require to request it from the OS but only from its pool and thats indeed faster.

Apple knows about the performance of their alloc / dealloc, they have not removed ObjCs GC for fun

In the end though for both sides the same optimization holds: pool objects, don't trash - recreate unless the timeframe between trash and recreate is long enough to justify the overhead of dealloc and alloc

And I don't fear C++, used it for long and as user of Torque still use it heavily. But I just don't like it. Looking at C++ when you have ObjC and C# is like looking at a rocket if a ferrari and lamborghini are next to it Its fast, yeah. But hell impractical if not just ugly

 

8 MB of RAM is a huge savings!

I agree though. I don't want to see Apple reject plan A of continuing to use C# and javascript.

The thought of using C++ and having it be compiled by Xcode is awesome.

I would like to suggest to Unity though to expose Accessors using Noun first, verb last naming convention. It sorts better in help files, etc...

So:
Transform:ositionGet();
Transform:ositionSet(float x, float y, float z);

instead of:
Transform::GetPosition();
Transform::SetPosition(float x, float y, float z);

The reason being that if you have 10 accessors in a class, when listing them in the help file, intellisense, etc... all of the functions dealing with Position will be together, and all dealing with Rotation will be together, etc... instead of all 10 Getters followed by all 10 Setters.

Just something I've been doing for about 15 years.

 

I don't see that they will require either of the two.

as positions, rotations etc are structs, they could remain to be just that or if we are funny classes.

Its not like we at the time have such functions within unity either.

 

The short answer is that I would guess that C++ native compliation could be available everywhere except Web browsers because the processor is unknown until runtime.

The Long answer:
If Unity is going to support browser plugins for machines with various processors, they'll need to keep Mono and "Just in Time" complile the scripts for the platform at runtime for the reason above.

The only alternative would be to compile the script at build time for every processor the game could possibly run on.

So, native C++ compliation can only be available for targeted builds: Windows or Mac or Xbox or Android, etc...

Just my opinion.

 

from what mentioned on the blog, C++ native build is an iphone thing with the other platforms getting it as .net compilation.

though I would assume that wii - x360 - ps3 due to their aot requirement nature might get it too, android will have to be seen I guess

but all others can use JIT and work with it through .net pretty well ... especially on win - mac - web I definitely don't see it happening, as the amount of stuff people will want to get exposed (like lower level access etc) just won't happen out of my view thus making it far less usefull as native compile

aside of the common blub war on the "right" and "wrong" compiler etc with all just mono its clear

 

If you'd like, In C++ you can create your own heap and heap management. This happens all the time in video game development for consoles and arcade machines.
I like Unity and C#, and as long as the code is managed, I'd stick with C#. But if I can have native C++ on iPhone, having the extra performance and memory would be fantastic for some games (Like the last 2 I worked on).
8MB would have saved me a week of trying to dynamically load textures and audio without stuttering.

 

I should potentially be more precise on what I mean:

1. The majority of stuff is highly optimized C++ code out of the box, cause thats what unity is. Only the gameplay functions are C# and that can obviously not be that slow as long as even LUA gets away performatn

2. the loading does not stutter because of just memory. texture load will continue to stutter if you try it mid game, cause these are just of locking nature. There is no way to background load it on Unity iPhone.

3. If you do calculation heavy script stuff then C++ might definitely be a good thing for the game

4. With iOS4 being offered for 3G and itouch 2nd gen, yeah the 8mb of RAM become vital.
Question on the other end is if I will target 3G at all anymore. I might just put a fat disclaimer on the page that 2nd gen users were left out cause apple F***ed up os4 for them

 

Item 2) I found that out after the fact. Our game was using too much memory and dynamically loading textures and audio would have been great, if it worked asynchronously. The 8 MB would have been enough to not have to mess around with dynamic loading.

Item 4) We are currently doing games for kids, and that means hand me down iPhones, and iPod Touches, so we don't want to exclude a big part of the market. We need to support even 1st gen users if possible.

It's mainly the 8MB I'm after with using native C++. We could possibly create some games under 10MB that could be downloaded over a 3G network.

I don't have it yet, but I'm impressed by the changes for Unity 3. They are kicking butt!

 

3g has had 20mb border since feb (ipad announcement and 3.2 beta)

but I now understand in which relation you brought up the ram part. yeah if it would have allowed you to not dynamically load then it naturally would have made a difference

I normally tend to use "non interactive" parts if I am required to integrate such things like info windows etc ... they don't change for a few moments, enough to load stuff

 

The download limit over 3G was raised to 20MB awhile back.

 

Coolness!

 

Time to make this thread "unsticky"?

 

Yeah, probably a good time to let the "longest thread in the history of the Unity forums" dissolve into the past. ;-)

 

If so should have happened one page back. Now we gotta wait until page 512.

 

ah, yeah ... true ... we missed it ;-)

 

And for some more hijinks, a fresh game industry biz article:


gamesindustry.biz
"Matmi: Unity "looks like it could be banned" from iPhone"

http://www.gamesindustry.biz/articles/matmi-unity-looks-like-it-could-be-banned-from-iphone

 

Yeah, I saw that. Not very pleasing considering I've just laid out $1000 for the upgrade to U3 Pro, and ALL I use it for is iPhone dev!!!