BlitzMax versus TGB (Torque Game Builder)
BlitzMax Forums/BlitzMax Beginners Area/BlitzMax versus TGB (Torque Game Builder)
| ||
| I've been comparing 2D engines some (mostly BlitzMax & TGB [Torque Game Builder]). I wanted to get some opinions on which one people thought was better for 2D games. I'm an experienced programmer, so the language (Basic vs. C++) thing is not a concern for me. I been using Blitz3D and like it a lot. I didn't get very far with TGE (Torque Game Engine - the 3D one) because of the huge learning curve. Cross-platform support (Windows and Mac) is important to me (and they both support that). The built in editors in TGB seem like it might be a big plus, wherein BlitzMax you have to build your own or look for a third party one. However, my previous experience with the other Torque engine, would lean me back to BlitzMax Thoughts? What are the pros and cons of each. |
| ||
| on an old machine, TGB's shooter demo crawled to a halt, literally to a standstill. Blitzmax crawled to 15fps but remained playable with far more going on screen. 400mhz pc with tnt card. Your choice... |
| ||
| They do different things. One of the major differences is that TGB uses collision hulls, where as Max2D uses pixel perfect collisions. So depending on what you want to do, that might effect your choice. The tools with TGB really do make it seem like more of a whole product. However those tools are absolutely nessecary, where as with Max2D you can 'wing it' and still get decent results. Since you know C++, one major advantage is that you'll be able to use TGB in your favorite IDE (where as BlitzMAX doesn't have much in the way of supporting 3rd party developer environments). Lastly, for comparative licenses, TGB is 4 times as expensive. Personally, I'd recommend BlitzMAX, but I am biased. |
| ||
| I am not biased at all, and I dropped TGB in favour of Bmax. Actually it was like this: TGB -> C++ with popcap -> Bmax Reasons: speed, compatiblity and flexibility. TGB is slower than both popcap and blitzmax by a considerable margin. Then you have popcap - very quick but its hardware acceleration isn't any faster than blitzmaxs' opengl, however it is faster at DX. What swung it was Bmax provided much faster development times with a language thats fun to use as well. |
| ||
| As I own both, I will try to give a more objective picture of TGB than "BM is better" ... TGB definitely has its Pro: - Full level, GUI and effect editor. - Easy to use, event basing script engine (no need to go into the source to do something). - Use polygon collision instead of pixel which is a must have for physical collision reaction. - Internal system that splits too large textures to allowed subimages. - Its support and documentation is worlds better than BRLs - It has a dev network which has a lot of ressources and tutorials. It has its drawbacks as well: - It uses a C Style script and its sources are in C++ which means that you need a C++ compiler if you want to alter the engine. - It takes significantly more time and effort to understand how it works as it bases on torque. But its worth the time as TGB is definitely an extremely powerfull and capable dev environment - The license might be a problem for the big boys: You need to buy a commercial license if your publisher earns more than 250'000$ per year. (if you do that yourself, you will most likely be out of probs). you need as well to show the TGB logo at the start. *thats no prob to me, as I normally anyway credit things this way that helped me to do the job* - At the moment, TGB is in a change from old Torque 2D 1.0.2 to TGB 1.1. This means that the level editor is comming in and some internal workings change completely. This is causing some headache at the moment (with the intermediate build that was not meant to go "user public" at first). - Due to the point above, most tutorials on TDN are outdated for the moment, but will be ok again when 1.1 is out. (at the moment, they are mostly for beta1 not beta2 which introduced the leveleditor) |
| ||
| - Use polygon collision instead of pixel which is a must have for physical collision reaction. Objective? You can have polygonal collision in BlitzMAX aswell. This form of collsion however is significantly easier to write than a pixel based one. If you had to replicate the Max2D collision system in TGB you'd be in trouble real quick. Replicating TGBs collision system in BlitzMAX is a trivial matter. |
| ||
| I've not said a is better than b nor vice versa. PP is very usefull for concave images or very complex images that would need a lot of polygons to be accurate. PP is just useless for physical reactions as it does not give you collision point and especially collision normal. Without writing your own collision system for BM you are restricted to simple geometric objects where you easily can calculate the collision point and normal (circles for example) Mmplementing an efficient polygon collision system isn't an easy task, otherwise we would have a module by now that works with an acceptable speed not one thats as slow as pixel perfect. I'm used to both systems and both have Pro and Cons ... But from the point of "innovative" game ideas, the impossibility to do collision physics is a serious lack. While I don't see much of a problem if I don't have pixel perfect as it is not needed in most cases at all. (users are not able to tell the difference of 2-3 pixels in a game, but they definitely are if an object bounces of in the totally wrong direction) |
| ||
| To be fair I have no intention of using blitzmax's pixel based collisions. I'm gonna go with vector for speed. I don't think "editors" are a draw to TGE. I found them lacking and I made my own in Bmax anyway. |
| ||
| Mmplementing an efficient polygon collision system isn't an easy task, otherwise we would have a module by now that works with an acceptable speed not one thats as slow as pixel perfect. First of all, Max2Ds pixel perfect collisions aren't slow by any definition of the word, secondly, I believe Indiepath has a collision hull library. Whether he wants to share it or not is another matter. But from the point of "innovative" game ideas, the impossibility to do collision physics is a serious lack. Those who claim something is impossible should not interrupt those who are doing it. :o> While I don't see much of a problem if I don't have pixel perfect as it is not needed in most cases at all. Well you're entitled to your opinion. |
| ||
| Flameduck: That with Indiepath is like a proof that it isn't an easy task ... There have been other approaches here on the board for polygon collision but they all were not much more performant than BMs PP collision. *the last approach was the one even skid posted. Was the "BM PP is so slow" "comparision test"* I know that BMs PP is quite fast, but PP lacks two elemental part: early drop & optimation for statically combined sprites (tile layers for example). When you test pixelperfect, you can't say after 2 steps that they don't collide (unless their bounding boxes do not even intersect), you need to test all pixels. Polygoncollision through SAT for example does not need to test everything. This is very important in 2 scenarios (at least from my point of view): 1. Large sprites (not that much of a problem to me so far as Kamaya is able to split images up and handle them like 1) 2. Tilemaps! Here it is a serious problem because it must test the whole "underground" in a sidescroller for example which are a lot pixels, while it is possible to optimize the polygons to reduce it to much less tests. (thats wherefor Kamaya will use it beside physics) But thats ok to me. Its just another feature that might make Kamaya more interesting to potential costumers, isn't it? :-) But I'm getting off topic. To come back to topic: TGB (especially since Beta 2) and BM have both their strengths and weaknesses. Thats why I use both and will be using both in future as well, both for their specific tasks and where they have their strengths. I would all, that are interested TGB, suggest that they wait until 1.1 is done with the new editors and the new stuff on the page. At the moment half of them are broken as everything *beside GUI editor* is moved into the level editor. Thus the informations aren't always up to date and the new examples aren't online as well outside the beta. |
   |