next »

[Javilop]

I actually do think that (fairly) advanced collision detection is so important that it should be a part of the library. To me, "rapid development" means that the library include solutions to many problems that are both common and tedious to solve, right out of the box. If I were to make a game, and had to choose between different libraries to use, I'd choose the one that had done the most work for me. That way, I could focus more on the design of the game.

But what do you think is better? Just to wrapp internally all the methods of an existing physical lib (like box2d). Or just to provide tutorials an examples of how to use Box2d + IndieLib together?

I think wrapping is not the correct way. For the same thing I'm not wrapping any sound engine. But people are using the one they prefer and there are examples.

What's your opinion?

[Zaphos]

Hey -- just downloaded this and started going through the tutorials today (I'm so slow ...) and just wanted to say I like it a lot so far!  I'll probably have more detailed comments once I've made a game with it

But what do you think is better? Just to wrapp internally all the methods of an existing physical lib (like box2d). Or just to provide tutorials an examples of how to use Box2d + IndieLib together?

I think wrapping is not the correct way. For the same thing I'm not wrapping any sound engine. But people are using the one they prefer and there are examples.

What's your opinion?

I think a tutorial on Box2d + IndieLib together would be pretty good.

It seems like wrapping another library is just asking for headaches, as one gets updated on a different schedule than the other ... and a lot of games have very 'custom' collision detection and response anyway so a lot of the box2d stuff is not universally needed anyway.

There might be some simpler, paired down functions which would be useful to add -- for example, a function that takes a point and a bounding primitive, and returns the smallest vector which would push the point out of the object.  Or a function which takes two bounding primitives and does the same.

[Javilop]

Hey -- just downloaded this and started going through the tutorials today (I'm so slow ...) and just wanted to say I like it a lot so far!  I'll probably have more detailed comments once I've made a game with it.

Don't hesitate to ask if you have doubts. Here or in "help" section, under IndieLib forums. I think better the second option.

I think a tutorial on Box2d + IndieLib together would be pretty good.

Yep! I requested one on the forums. If nobody tries, I'll try myself. Currently you can check out this test (using primitives, not sprites): http://www.indielib.com/forum/viewtopic.php?t=10

It seems like wrapping another library is just asking for headaches, as one gets updated on a different schedule than the other

I'm agree.

There might be some simpler, paired down functions which would be useful to add -- for example, a function that takes a point and a bounding primitive, and returns the smallest vector which would push the point out of the object.  Or a function which takes two bounding primitives and does the same.

I think I'll let only overlaping checking (the one is already implemented) without giving collision response. Box2d would be a better approach for those who needs collision response or extended physical needs.

[nihilocrat]

Unsuprisingly, you can. If you don't declare any shapes Box2D won't do anything, and you can declare everything as sensors there will be no physics done at all, just collision detection. Also, Box2D's broadphase is a standalone component, which can be useful on it's own for simple collision applications.

I'm coming from a Chipmunk background, where by all accounts it seems like you must have a body (physics object) to have a shape (collision object). This adds a lot of unnecessary overhead, or does stuff like push around / spin objects when I don't want them pushed around / spun. I would much rather have a physics engine from which I can remove the collision responses and just keep the collision detection. I will have to check out Box2D.

[BorisTheBrave]

Yes, shapes define collisions, which are what you want, and bodies dynamics that you don't. And bodies are mandatory, as a container for shapes. But sensors disable the collision response part, stopping stuff from bouncing off each other.

Chipmunk apparently does not have sensors, so that would explain the confusion. Box2D is not quite as easy to use as some of its competitors, but it is generally more "feature complete".

There is still some overhead from the unused physics, but it should just be negligible loop or two to check that all the bodies are of this form, and storing some stub data structures.

I should add you will likely want static bodies as well (as in Chipmunk), which disables slightly more stuff too, but I'm not sure that static-static collisions are reported (as in normal usage you don't really want that).

[mirosurabu]

I've checked out IndieLib in more detail the other day. And I have to say I was wrong when I compared Allegro with IndieLib. You can't compare these two, for IL has obviously much more functionality.

But I still think that PyGame is more productive and better rapid prototyping alternative. While it does not have all the features IndieLib has, the simplicity and the beauty of Python makes it quicker to use.

What would be nice, I think, is to have someone write IndieLib module for Python. This could be perfect combination. I could do this, but I don't have enough free time.

[BorisTheBrave]

Pygame looked great, until I read the docs closely and it admitted as it's software mode only, it cannot actually handle modern resolutions with scrolling backgrounds. Who would want that?

[mirosurabu]

As far as I could understand PyGame is not software-mode only, but authors do encourage software surfaces. Since it's basically SDL module for Python, authors tend to blame all limitations on SDL. And, as far as I could notice, IndieLib is built on top of SDL as well. Or maybe I am wrong.

[Javilop]

What would be nice, I think, is to have someone write IndieLib module for Python. This could be perfect combination. I could do this, but I don't have enough free time.

Oh god! This would be something incredible. I have been thinking in that for a long time, but there are still so many things to add to IndieLib. Hopefully some people would start to use IndieLib a bit more and some of them will join the development team.

BorisTheBrave was right, I need to offer a "IndieLib team" guidelines or something like that, explaining a bit more how the engines works. The good part is the engine is REALLY STRONGLY COMMENTED, so if someone enough brave try to read it, it would be more or less easy.

And, as far as I could notice, IndieLib is built on top of SDL as well.

It uses SDL only for the window management and Input. But all the rendering is made directly upon polygons using Direct3d. One of the greates features is that you can load images of any size (not only power of two images) and the engine will cut them into optimum blocks taking in count details as the maximum texture size that allows your graphic card, etc. All this is completly transparent for the user, but you can also set the width of the blocks if you wish (this can be useful for having really big backgrounds, like 10000x10000 pixels). The blocks that are outside the ViewPort are directly discarded. And furthere more, if the camera is zoomed or rotated, and the image is scaled and rotated the blocks are correctly discarded too.

If some of you are interested on this feature I can make a tutorial.

[Ravine]

Hi Loover.

i'm starting to work my cpp skills (i'm more a C# dev at the moment) and i've started to download IndieLib, through the wiki. But the wiki link to the DirectX SDK points to the November 2007 (and not the latest one, the Nov 2008). I realized it after downloading and installing it (yeah, bad move).

maybe that link http://msdn.microsoft.com/en-us/directx/aa937788.aspx is the generic one to the DirectX "Latest Downloads page", and you should update the wiki according to that (or maybe the http://msdn.microsoft.com/en-us/directx/ "generic" link).

On IndieLib, it looks quite straightforward, and i'm eager to work with it.

[Javilop]

Hi Ravine!

I'm glad you are using IndieLib.

Thank you for the tip, I've already updated the wiki.

If you have any other doubts, you can use "help" section under IndieLib forums.

Don't forget to show us your progress

[Javilop]

So, you like to use C#, Vb.net, Haskell, Nemerle, F#, whatever else .Net language? Then you can use it together with IndieLib.

Vigin, on IndieLib forums:

I made a C++/cli wrapper for IndieLib to harness it's abilities from all managed languages.
I did it mainly for myself, but after a several weeks of work I thought that it may be useful for someone else, so here I am to share it with you.
If you don't want to read all this b/s, links are at the bottom.

http://www.indielib.com/forum/viewtopic.php?t=115

[Javilop]

Two smart guys are making Indielib cross platform: http://t.co/K7lL38l

[Javilop]

I always knew that Open Source was the correct way of releasing IndieLib.

Now I'm happy to announce that it has been ported by two smart guys to MAC and Linux and they are currently working in a iOS port.

I hope this will give a new life to IndieLib and I hope you will give it a try!

Here you have: http://www.indielib.com/

[Javilop]

Release update: We are happy to announce that Indielib Cross-platform v.0.5.1 SDK is just released. This is a bugfix version that fixes some annoying bugs in the 0.5 version.

Go grab a copy while it's still fresh from the download page http://www.indielib.com/tools/ A list of the fixed bugs can be found in the forum in this thread http://indielib.com/forum/viewtopic.php?f=1&t=569