iTGB 1.2 ETA

#161 Guys: Unities 3D approach to games is a major downside in my viewpoint. I don't want the complexities of level design in a 3d perspective, nor the requirement to important 3d models, even if their simple or flat or whatever.

The TGB interface for game design is extremely good from my perspective. I think the Game and engine are excellent, albeit with iphone specific bugs and missing much needed iphone optimizations. However fundamentally it's *exactly* what I personally, and I imagine others, want for creating 2d games.

If I decide I want a 3d engine I'll buy iTorque or unity, but I don't have the resources or time to step up from 2d to 3d game development.

There are only 3 things I want from iTGB very badly, besides the minor but very annoying known defect fixes (in order of importance to me):
1. PVR support for sprite sheets. And ideally engine change to use u/v coordinates instead of breaking my 96x96 cell into a 128x128 individual texture even in non-pvr mode. Memory issues on iPhone are #1 problem with iTGB IMO.
2. Much faster base startup time.
3. Better memory management around assets.
4. Better documentation/tutorials for those who want to do the majority of their programming in C++. Scripts are not realistic for an entire game unless it's a non-frame rate oriented game. Engine is very easy to work with but it's very script centric both from a code perspective and a documentation perspective.
5. Better documentation for things like: saving games, networking, etc.


#1 is a major deal for me, #2-3 are very important, the others are important but not much of a problem. #1 is something I can't fix myself, #2-3 I can fix myself but the time requirement is large and I will have problems merging changes when upgrading to new iTGB versions.

The only thing stopping the specified scenario is the way iTGB handles sprite sheets and de-optimizes them. Also PVR is very important for sprite sheets because characters tend to have more frames than anything else and thus more art assets.

#162 To shamelessly plug myself, when the TGB Kart Kit is out, you'll be able to use a 2D engine to make a 3D games, which I think is more useful than the other way around. So you'll be able to design your level in the Level Builder, then do some function calls and see it all behave in "3D."

I personally like the idea of 3D being something I can turn on, rather than have it dictate my whole development process.

#163
Bret's wish list above is a good one. I hope version 1.2 has at least 1, 2, and 3. I don't care about #4 (C++). If I wanted to write a game in a lower level language I wouldn't be using iTGB at all. The whole point is to have a lightweight scripting language to work with, but it needs to be fast, robust, and well-documented.

#164 48 hours before the puppy massacre continues :P

@chris, I have been following your kit. Where can i get it?

Eaymon

#165 You guys must be working on something really great if your having this much delay. I'm looking forward to seeing the changes you make.

PS. Please no more 100's of useless messages about slapping puppy's. It'd be nice to see relevant/useful posts instead of 20-30 silly messages.

#166 @Bret - It's actually 6 posts about slapping puppies. There's really nothing we can do here, your suggestions are great, but it's still up to GG if they care to implement it in a timely manner.

Those silly/stupid posts are only done to keep this thread on top and maybe get a response every now and then with GG, they didn't work, just further proof that trolling doesn't work, so I'm stopping it. Also coz Ronald loves them puppies.

As my new project, it's a simpler game than before. It can be done in iTGB 1.1, but I just don't wanna deal with the annoyances of that version.

#167 @Eaymon: Here and soon.

UPDATE: Here and now.

#168 @ee yea it's just nice to not have to wade through lots of useless posts to see if there has been a real update to the issue. I think there were at least 3-4 pages from everyone involved related to your puppy escapades.


I've gotten the workflow down smooth now, and the bugs rarely if ever interfere with me. I've had a lot of fun the past week working on my game. The c++ behavior/component model in TGB really makes extending the engine easy and a pleasure to do. I'm going for 95% native components with only script for glue. But that's because I *hate* scripting, you have to write code, run, manually test, put echo"" all over the place and rinse repeat to get it correct. With C++ behaviors you get compile time checks for bad code, an integrated debugger with stepping and inspection, lower memory usage, direct access to all iphone capabilities, and really fast execution speed.

#169 Bret, this is encouraging, and a different angle than I was using. I tried using iTGB for the GUI and the scripting to get into the "Torque mindset" so to speak.

But with my C++ background, perhaps I'm going at it all wrong.

Got any good resources you could share for working with the TGB/iTGB behavior/component model?

#170 @Eric Take a look at the behaviorshooter_components example. That's how I learned to do the behaviors. Couple things to know.
1. Create your own group and then link to it externally so you can have your extensions in a separate directory than the iTGB source for easy updates.
2. Components require glue script to hook into iTGB so don't forget about that (wasted a bit of my time before someone pointed this out to me).
3. You need to recompile tgbgame and TGB in the torque2d project so you can hook it all up into TGB for testing. I usually keep both projects open when working. I usually just select the ALL target for that and compile all 4 targets after I've successfully compiled it in the iphone project (4 targets in ALL causes 4 copies of same error, so doing it in the iphone project first simplifies fixing compile issues)
4. To debug you need to rename "TGBGame Debug.app" to TGBGame.app and right click and do show package contents and rename the executable inside it to TGBGame. Probably a better way but I'm not sure how to get iTGB to run the debug version. I don't do this too often, only when I have a bad bug I need to debug for.
5. Focus on the part of the AdvComponents in the examples because finding behaviors on other objects is really useful.

I can help you out once you have specific questions. I'm still ramping up on Console functions but so far their not too complicated once you realize how to get the parameters out correctly and look up object id's using the Sim::find methods.

I highly recommend going this route if your a coder.

#171 Thanks Bret. I'll take some time to familiarize myself with what you suggested. Probably ping you later with questions.

#172 So I decided to do a quick investigation into the PVR issue with Cell based sprite sheets. The work horse appears to be in t2d/t2dImageMapDatablock.cc .

Now I'm not sure if I'm understanding everything correctly but it appears that iTGB does not create a seperate texture for every cell in a sprite sheet. In reality what it does is re-pack the source image into the destination texture, which is only 1 texture if all the sprites in the PNG fit onto the largest hardware supported texture size.

The problem with PVR sprite sheets seems to be simply in the loadTextures() method where it does this work. PVR support was only added for the one case where the number of frames == 1. This is likely because GBitmap stores the number of BYTES per pix instead of the BITS per pixel.

It looks from cursory inspection that you might be able to fix PVR sprite sheets by simply fixing the way the source is repacked into the destination texture buffer in this function. I haven't studied the issue in detail enough but it doesn't look terribly difficult unless I missed something (highly likely).

To me this means that iTGB doesn't "deoptimize" sprite sheets, it preserves the 1:1 mapping. The real problem appears to be in creation of the texture for cell or key based images for PVR sprite sheets only. Of course this is all a little bit out of my expertise area but that's what I've gathered so far.

#173 Yeah, one of our programmers noticed that when the sprite sheet gets repacked, each frame gets stacked on top of one another. I believe this causes issues since PVRs need to be powers of 2....it is possible to fix it, but quite a bit of work to retool the system.

#174 7 days have past Micheal.... any news?

#175 Nose the grindstone, wrapping it up. Today or tomorrow.

I will post a message in this thread, then lock it. Then I will post a sticky thread at the top announcing iTGB 1.2. That post will contain details about the release, and how to post bugs and feedback.

#176 That is good news! Thanks Mich!!!

#177 Awesome can't wait.

#178 nice two days later we will start the thread iTGB 1.3 ETA :P

#179 Hope to see a thread with all new features and improvements... ( how much FPS for iTGB 1.2 ?)

#180 Ee we better squeeze in some final puppy slapping before epic thread gets locked lol