iPhone OS4 today

Haha. OOP is a non point. C# and Java are OK languages. C# is getting better especially in regard to it's DLR aspects. Both of them are bloated beyond control full of different ways to do the same task in 12 different namespaces. They both seem like their base frameworks need to reprobate themselves and start over but it would never happen.

Program in Python or Obj-C using Cocoa for a couple years and you will see what I mean.

 

Omg, did you see the starring names? ^^ hilarious, thumbs up!

Back on topic, Unity still kicking asses on the App Store! Keep working hard guys!
Cheers,

 

It's been a while. I just tried it again and it does work.

Set a breakpoint in the Objective-C or C++ code. In the Xcode editor I just clicked to the left of the line I wanted the breakpoint on. A Solid Blue arrow appears. If it's not solid blue, then there's a problem. Let me know if this is what's happening.

Then from the Run menu I chose Go. Make sure you're choosing Go (Debug) and not "Run" or you're not debugging the app and breakpoints won't be triggered.

Also, make sure you're building Debug and not Ad Hoc or Release.

I'm explaining everything since I have no idea whether you have 10 minutes or 10 years of programming experience, so please don't be offended if I'm covering things that are obvious to you.

I hope this helps. 8)

 

After 2 months it's time to say goodbye to this thread.

Bye, thread!

 

Bye, Schplurg!

 

Someone has way too much time on their hands

 

Hahaha, awesome. I think I'm done reading this thread too, though.

Bye, thread!

 

Bye, Earl!

 

we need more
P A N I C

 

Thanks for the info -

I am able to successfully debug a non Unity Xcode project. I can build a release version of a Unity project but not a debug build.

I get a pile of warnings like

warning: (armv7) /Users/.../Libraries/libiPhone-lib.a(mono-mlist.o) object file '/Users/.../Libraries/libiPhone-lib.a(mono-mlist.o)' doesn't contain architecture information for armv7.

followed by a fatal - Command /Developer/usr/bin/dsymutil failed with exit code 2

Probably some setting in my Unity project - i currently set the base SDK version to unknown (which defaults to 3.1.3 (for me) in the xcode project) and I then change it to SDK version 4. This seems to work for release builds but not debug.

I will open a thread in the iPhone forum for further discussion.

Thanks

 

Yup. People need to support Unity one way or another: wallet or logo. Pick your poison. I upgraded to iPhone Pro a few days ago.

And I agree with the guys above who said goodbye to this thread. Goodbye, longest Unity thread ever.

 

I have something to say before leaving this monster thread. ^^
You will remain safe on the App Store, as long as you send good quality/polished apps.
Cheers and happy Unity dev!

 

Indeed.

Karnival for iPad got accepted today by Apple. It was built with Unity 3.0 Beta 1. The binary was originally uploaded a couple weeks ago, but got rejected due to an accident on my part. So it got re-uploaded last week and was approved today no problem.

http://itunes.apple.com/app/karnival-for-ipad/id377744924?mt=8

 

Yup..Pro version should solve that.

In the end...if they removed the logo in standard iphone...then who would buy pro?


What you could do is..release the game if it sells $1500 worth then buy pro upgrade the app using pro version.

-P

 

We have already bought the Pro version but we still kept a smaller "Powered by Unity" Logo in the corner.

1. To give credit to the hard working people at Unity.
2. As there are so many nice games on the App Store made with Unity some people will get an extra smile on their face when they see that this new game they just downloaded are also made with their favorite 3D engine.

 

New blog entry: http://blogs.unity3d.com/2010/07/02/unity-and-ios-4-0-update-iii/

C++ 'scripting' integration as a Plan B. Hopefully it's not required, but at least Unity has things covered if Apple does start enforcing their new terms.

Having C++ as an option anyway would be kind of cool if they develop it to completion. I doubt most people would use it, but it's another bullet point and if it could be made to compile to native code for all platforms then it'd be a good one.

 

Having the option would be pretty epic.

 

I would LOVE the option to use C++. No more Mono runtime means ~9 - 11MB RAM freed up for the runtime alone. All scripts would more than likely see a significant speed boost as well.

 

C++ would rock. Cheers all around in the office today from that.

 

This is the best news regarding Unity 3.0

Great Job Unity Team!

btw. did anyone tried native C++ in U3 beta or is this feature still in progress?

 

I'd rather use ObjC than C++ but UT can't please everyone. Hope they don't need plan b as I want to continue with UnityScript.

On a side note, I see that any submissions (new apps or upgrades to existing apps) now have to be built with OS4 SDK and they won't accept apps targeting OS2 anymore. So now I have to upgrade to Snow Leopard too. Hope I don't hit any problems with that...

 

Would it be possible to mix C# and C++ (not in the same script, but in the same project)?

Also, they said telling us could jeopardize their plans. If this was that plan, I don't see why they couldn't tell us before. So is there a Plan C?

 

Man, right after so many folks bid adieu to this thread out comes the most informative of the blogs!

I think the blog says outright what most of us were sort of expecting the contingency plan to be. I was thinking it was going to be ObjC though. I'm SO happy it's not. ObjC makes my head hurt just looking at it. C++ isn't all that different from what I'm used to. But the way things are going RE submissions still getting approved it might be moot anyway.

 

Yeah, I was really sad about that.

 

Aw, Thread is lonely

We need more trolls to keep Thread company...

 

the "we work together with big brands" part that caithlin mentioned was likely the jeopardize part

this here is the atomic bomb worst case fallback


what I don't like is the "difference is even smaller". Cause .NET solves the major problem that all other languages have: beginners are just not capable to handle object allocation and deallocation from OS in an optimized way. So even if C++ would be twice as fast (which it is not nearly) they will near granted kill that through the alloc - dealloc locks against the OS. And that without considering the joy of null ref crashes that with GDBs superb way of not giving any meaningfull information are ugly to debug

 

David said they were making a .net C++ compiler for in the editor, so you'd still have editor testing...

 

corrected above, overread that.


the only benefit the C++ usage to me has is that we can get rid of the 8mb ram usage from mono but thats really is.
I'm not sure if it weights up against losing the GC and seing much more * than I do in iOS4 ObjC already thanks to blocks etc.

one thing though will likely byte back: with it being run through an own compiler I doubt we will have full C++ power (either that or it will take till Q2 / Q3 2011 to happen).

and what out of my view is much worse and which I expect to happen: the very moment this new layer is there, apple will likely start to reject all mono driven unity games cause they then can get unity games without accepting the mono exception for the tech

 

It's possible Apple won't reject anything. Overtime, more and more Unity apps will be made using the new C++ and the problem just goes away.

 

Don't fear the C++ dreamora. It's really not that much harder than .NET.

Yes, .NET does manage memory for you which is wonderful when you have lots of it (desktop apps) or you are a beginner. On a mobile device I'll take managing memory myself any day without GC freezes and slow-as-dirt managed memory allocs. Give me function pointers (fast) over delegates (slow) and I'll be a happy camper.

Now that's just silliness. Do you really think that unmanaged alloc/dealloc is slower than managed alloc/GC? Totally ludicrous to anyone who has watched GC freeze a 16 core/64GB RAM machine.

GDB isn't the greatest...I'll give you that. We have LLVM/LLDB now/soon though and it is looking really nice. Don't forget to null check and you're good to go!

 

@uprise78 as usual, very well said...

We would probably use Unity if an option to remove MONO and work in c/cpp became a reality.

 

I'm Mike D. too. You stole my name

 

AWESOME!!! and I would bet you've also been hacking since the 8080 / 8086 days 8)

 

OK, so I am the mouse who just got a cookie and is now going to ask for a glass of milk.

The thing that would put the big "WIN" all over this new announcement would be a conversion utility (based on something like ANTLR or the like) that would take existing Unity JavaScript or C# and move it to the C++. This would help anyone embarking on a large project feel 120% comfortable with the current engine. Granted I suppose we could band together and build such a beast ourselves, but that would require seeing the full API for this new C++ incarnation of Unity.

 

I bet the source code to this( http://www.m2h.nl/files/js_to_c.php) would be a good start. It shouldn't be too hard to make a rough converter than just manually "fix" the output. Totally worth it IMHO.

 

Unity is not going to be able to make this thing. It's a translator and that's a no-no for Apple. Somebody else is going to need to make it.

 

A very good tutorial and notes on the differences in the different languages, and how to convert code would be in order.

Looking at the code in the blog, I think code changes to the new language it could be done in a reasonable timeframe given the right knowledge.

 

Unity,
Should continue to implement Plan B(C++ support). Cause we can maybe be fine now, but what make you think that Apple will never add more ToS restrictions?
To be honest, even if Unity app are now being accepted on the App Store, theses apps are not ToS compliant. Unity should continue to implement C++ support, no matter what, there’s a lot of reasons why:
- Avoid any conflict with new ToS in the future. Or simply avoid any future rejection from Apple.
- More speed, less memory eat.
I think that plan B is not an option, it is a requirement and a very safe move made by Unity to stay on track!

 

more speed and less memory usage is a dream. I don't see how it should use that much less RAM for the actual stuff you do, all you save is the 8mb and its loading time for the mono layer itself (so agreed if you meant that)

But that at a high price: for 95% of all unity users, it actually means less to significantly less speed as optimizing code to do as little memory alloc dealloc as possible (fundamental on iphone, it will kill your whole performance if you alloc and dealloc objects and brainless and stupid as you can do with the mono layer below.) is not trivial and not creating null pointer problems is neither trivial.

People seem to forget that many that use unity do it cause they don't have the background for more and do not even want to learn it cause lower level programming is just ugly and much harder.
Already the pointer arithmetic can easily drive people nuts especially as errors on that end lead to totally useless errors in gdb etc (at least they did when I was last forced to work with C++ under GCC 4.2 on linux quite some while ago and with GDB which I thought was the largest joke of a debugger I've ever seen since VC++ 6 was already more advanced a decade ago)


But yes it will surely help those professional devs that know their way around with C++ etc and it makes tight integration of iOS features easier than the DLLImport layer.

My concern is that once this plan b goes live, apple will auto reject all "plan a" solutions relying on mono directly which would be more than just a horrible as the majority of projects will definitely not be converted to C++ just for the sake of crapples world dominance dreams and thus hurt the end users.

Apple at the time likely only lets unity apps go through cause some big players use it and because they prefer "present on iOS and Android" over "exclusive to Android".

 

Honestly, it wouldn't bother me if Apple did only allow C++ Unity games but in reality do you really think Apple is sitting around looking at Unity with such detail? They have FAR bigger things to deal with then the more than likely less than 0.1% of apps they review that are made with Unity.

 

Looking at it with detail? in which way?
The moment the C++ access is in the can just add mono detection to their automatic checks and really reject automatic.

And yes I think they keep a very close eye on any middleware that has a that large top 100 portfolio as Unity due to the potential "power" they might be able to build up "against" apple.
Also, they had behind closed door meetings with UT, as such I expect them to be pretty much up to date with such stuff, if not even informed upfront for example to allow mono driven Unity project as a "grace time solution"

 

Unity engine / Api and c++? surely this is the stuff dreams are made of! This should be plan A!

 

I understand your point of view there, but then if Apple was actually concerned enough about the original language used to force Unity users to use C++ if the option became available then I think in that case it would be very likely that Apple would eventually crack down anyway (perhaps with further restrictive ToS as tatoforever suggests above). Having the C++ option would at least allow Unity to remain compliant in that case.

Also, I think you're overplaying the difficulties of memory handling in C++. Honestly if there are developers creating commercial products with Unity that can't get their heads around one of the most fundamental aspects of games programming then I'd rather they didn't produce anything. These are probably the people giving Unity and other engines a bad name through poor performing applications.

 

Matt, while I agree to those stuff as a programmer, I have done enough contract work to tell you that a major amount of Unity "developers" are really designers and artists primarily with little to no lower level programming knowledge at all and with no interest to learn about the dirty secrets under the hood or to learn C-ugly-ugly ^

 

C++ isn't all the much "lower level" than C#. It's not like you have to write ARM VFP code or assembly or even ANSI C. I don't think you give Unity devs enough credit. Anyone who can make a decent game in C# most certainly has the skillset to remember to dealloc what they alloced. It's not that hard.

Removing the Mono runtime along with it's garbage collector should turn out to be a nice performance boost at the very low expense of simple C++ memory management. Throw into the mix direct access to ALL the iOS 4 features (Game Center, GameKit, iAd, Bonjour, camera, video, etc) and it just seems like a win, win, win situation. Yet another benefit is direct access to OpenAL for playing sounds/music (or AVFoundation if you don't need spatial sound). It sounds too good to be true.

 

Right, thats another problem. Anyone who can ...
Its no strange coincidence that Unity docs at the time are JS focused, really.
For non programmers, C# is the "other thing", its not the main thing it should be with JS being the other thing.

OAL is really of no interest cause Unity 3 does not use OpenAL anymore to trash its output. You can naturally use it at the joy of F***ing up your whole playback I would guess

as for "performance boost": We will see, understanding the importance of pooling, factoring and reusing is not something commonly understood and that lack of understanding can heavily hit a program. Thats also one of the things I meant with low level.
It might all sound simple to you, but believe me, for the average "scripter", its a major hurdle to understand such types of optimization and for those users the GC easily outperforms their code. (especially then with mono 2.6, at which point C++ even with professionals writting code, only has a few percents performance benefit)

I have done tutoring in programming and advanced math for years and I can really assure you that it is hell a lot easy to forget how complex all this stuff is till you have someone in front of you who knows about the basic syntax and that syntax only and has no technical background nor too much technical background. Cause at latest at that point you will realize that your interests and background might make something trivial thats totally "uncatchable" to them.

 

@everybody uprise78 Knows what he is talking about, there is no magic it's just code, it all get's converted to ARM in this case "iPhone" the language we program in is really just syntax.

There was Assembly Language

There was C

Then there was everything else, it's that simple, all other languages are abstractions / libraries and frameworks PERIOD.

...with every abstraction comes a performance hit...

 

I was telling a friend at work about finally having heard some news on Unity's strategy for handling the terms restrictions and he mentioned something else back to me that i was wondering if anyone could comment on.

Basically he thought that some of the earlier interpretations of the terms understood that it forbid anything forming a framework between the developer and the apple libraries.. He said that this caused the openfeint folks to release their source code so that they weren't providing a library that would form this wrapper, as you were able to compile their code yourself.

Does this still mean that unity's base code that we link with in library form is still potentially a problem, or has this part of the terms been clarified since to not be a problem?!

Such great news to hear of plan B though.. as someone who codes C++ in his day job I'd probably definitely switch to it. We were all expecting it as the only real solution to combat the current terms.. what's kind of cool is I think most of us expected perhaps a C++ script coupled to an xml file or similar for the interface that connects up with the variables in the editor and is then serialised by the C++ code somehow. That the proposal will allow just the C++ and still allow for the live editing and variable linking is rather ambitious and impressive.

Can't wait to hear more on it all, and am very close to upgrading to Unity 3 now.. especially as there were other statements released that should any problems ever occur with anyone who brought unity since the terms were announced there would be some come back/refund potential. I've got that right haven't i? In that case with plan B in the works, Unity games being accepted anyways, and a fallback for any current/future investment it all of a sudden doesn't seem as risky as it has for me for the past few months.

Thanks team Unity!

 

I'm with dreamora on this one.

a) unity currently has minimal c# documentation, and for c++? water is already pretty muddy.
b) will unity offer a decent debugging environment? crashes are going to be rife.
c) will c++ become mandatory for the average scripter? bar is raised on skill/experience.

c++ was the obvious choice tho, since has no tie ins to a particular platform etc.
The "codes C++ in his day job" type people will certainly be pleased.

 

Well can some of you who hate Plan B speak up and suggest what Unity ought to have done? I think it's a pretty good solution given the restrictions.