HTTPObject in iTGB? Does it work on iPhone?

#1 Ah ha! Yes, it does work. Figured out the problem. ;)

#2 What was the problem?

#3 We actually had disabled HTTPObject a long time ago (around July) to increase engine performance. Had been so long it slipped our minds when we actually needed it, lol. Ended up keeping it disabled, and creating a pair of ConsoleFunctions to enable/disable it as we need it to keep its memory usage at a minimum.

#4 hehe
Well yeah thats a great way to break it ;)

I think the HTTP and TCP Object are the only things I've not killed out so far.

My common targets are the 3d shape that I kill right after unpacking iTGB and naturally the unused gui elements once I'm done with that part

#5 Out of curiosity, if you're working a lot with 3D shapes in iTGB, have you built in any kind of shadowing system or OpenGL shader system (for iTGB or TGB...)

#6 Just FYI guys, we've killed all TS shape support in the updated version of iT2D. They are just not implemented well at all in the engine, are a memory bloat, are a performance issue, and confuse the heck out of people.

#7 Dave: I never use them in TGB nor iTGB. If I want 3D I would use TGEA / T3D and use an ortographic camera (Iso for example until TGB / T2D finally learns that on the tile layer level)

I've never found any good nor even stupid acceptable reason to waste performance on them especially given their restrictions.

Thats why the TSShape related stuff and the 3d shape are the first things that are cut on my source base on each TGB / iTGB project.


@Luke: Much appreciated. Requested more than once that that part finally would be cut.
The support was halfbaken and broken at best. I remember the long time on TGB where they just didn't work on DX at all (unsure if they do now actually) due to the nature of the call redirection DX present in TGE

#8 If the HTTPObject is a performance issue, maybe you can get away with a rewritten CocoaTouch version?

#9 @Ronny: The HTTPObject is a performance issue only if you don't shut off the network async when it's not needed - then it sits resident in memory and eats up what other processes could be using. In our case, we didn't need network activity constantly, so we just turn it on and off as we need it, keeping the memory available for "right now" more than "all over".

@Marc: I've come up with a number of excellent reasons to use 3D objects in TGB. NOT iTGB, however, as then it's a huge waste of resource. For TGB, on the other hand, however... I realize this is the iTGB forum, however I had thought you were working on a TGB game with 3D shapes, which is why I had originally asked.

#10 Well I don't see a good reason for TSShapes in either, be it iTGB or TGB.
If I want 3D I use a 3D engine and add 2D overlays, that gives me significantly more power, performance and control, due to the restrictions in TGBs implementation as well as due to the TGE rendering backend of TGB which is a troublemaker anyway, so my target is to get it as safe and performant as possible so I don't have to fight it to support (performant enough) Intel GPU users too.

With T2D that might potentially change if it finally has a modern rendering backend, but for the time beeing, I can only recommend against them commonly.

#11 @Dave:

I'll have to agree with Marc here. If I want 3D stuff in a game, I'll use Torque 3D and then add 2D elements where necessary. If I want a 2D game, then I'll use a 2D engine... although, funny enough, we're just about to finish an iPhone game built in iTGE that takes place entirely in the Menu system with 2D graphics only (a few 3D shapes too, but not many at all), and no mission / level is ever loaded... lol

Also Dave, we didn't see *any* performance drop in having the networking async thread running all of the time once the usleep() fix that I posted about (too lazy to find the link for you :)) was implemented. We just enabled networking as normal with proper sleeping on the processing thread in Flipt, and we did quite a bit of testing, and didn't see any performance drop in the gameplay. I'm sure if we were constantly doing networking during gameplay there would be a drop (as that thread would actually be doing *something* other than waiting), but for standard HTTP/TCP networking when necessary, there was no drop at all that we could see.


@Marc:

The plan for iT2D is to have it properly feature complete with stock T2D, so if the 3D support in T2D is up to scratch, then it should work much better in iT2D than the "tacked on" TS 3D code in TGB / iTGB.

#12 Hehe yeah T2D and the real iT2D (as it is already called iT2D at the time basically but as long as it is TGB based, I'll use iTGB) should have some serious benefits. Especially an optimized renderer should be much simpler to achieve thanks to the clean split of "rest and rendering" due to the GFX layer of T3D.

And yes, the fix for the bg thread sleeping definitely has helped a lot