next »

[nihilocrat]

We have a few different ideas now... Jeff Lindsay has a pretty crazy one that might just work...

Awesomesauce!

[Kornel Kisielewicz]

...and homegrown data structures.

Um, for heavens sake, why would anyone want THAT? O.o

Anyway, I'm all thumbs up for that, and can provide some code, once you guys agree on a common structure and coding conventions. BTW, be wary of the forever-in-design-perfect-engine tendency .

[nihilocrat]

I think it might be the other thread, but the rationale was that for the time being avoiding STL would also avoid porting issues that would come from it. I haven't really met any such problems with it, but I assume Alec knows what he's talking about.

I assume it's prudent to just use some existing open-source 2D rendering code and implement it within the object/component model. As I stated before, I see graphics as a generally "solved" problem in the open source world and would much rather see an engine that can handle the nongraphical "Model" side of things.

[Rob Lach]

Just read through this thread. Great ideas all around.

I am very much for a component system especially considering how quickly one is able to prototype new systems with games previously created, but in the case of an open source project, having small pieces people could work on without bothering anyone until they are done is a godsend. Things like that ensure that a project will continue to be developed over time mainly because it is so extensible.

An example is the Foobar2000 music player, which is pretty much the audiophiles music player of choice mainly because people can develop and drop in their own components, and although the core is closed and I believe developed by only one person, a majority of the features come from third-party developers.

I like where this project is going.

[arckie]

...and homegrown data structures.

Um, for heavens sake, why would anyone want THAT? O.o

Check out the discussion somewhere like http://www.gamedev.net/community/forums/topic.asp?topic_id=424168

For someone working on their own little project, or on tools development, the STL would be fine though!

[Will Vale]

One argument I have against STL which doesn't seem to come up much is that there's too much of it. It's OK to say "only use the good bits" or "only use the fast bits" but it's very easy to end up using things you probably shouldn't. I guess you could also pull out what you want stuff from the STL or Boost, but I've found that to be a chore when I've tried it because there are always lots of dependencies. Plus some STL classes offer a kitchen sink interface, as opposed to a more focused, less committee-designed one - std::string is a key offender here - making it harder to get the good bits without the bad.

STL (and to a lesser extent Boost) have a smell of the kind of code you write when you do a big design up front as opposed to focusing on what you need now and growing/refactoring over time when another need is demonstrated. There are some great core ideas in there, but they tend to get diluted by the desire to be everything to everyone.

If you have your own toolkit, you can just provide the bits that work efficiently and well, and let people use those without worrying about opening Pandora's box. If a coder needs something more than you offer, they can write it. And if it gets used in several places you can bring it back into the toolkit.

Caveat: All this applies mainly to high performance console games - don't take it as dogma for smaller indie games, where STL can be a big productivity win. Just be in mind what it costs you, especially if you plan to be multiplatform.

Cheers,

Will

[Alec]

STL's fine. For portability, I'd like to wrap structures though.

[Rob Lach]

STL's fine. For portability, I'd like to wrap structures though.

STL is more than good enough for something like this. Any optimization past something like STL is more than usually game specific.

I also agree with wrapping the structures.

[Kornel Kisielewicz]

Sooo... any movement on this project? ;-)

* a public trac-like site?
* a read-only svn repo?
* a collaboration wiki?

[Melly]

In other news, it's been ages since I last saw you here Kornel.

I'm also curious on the standing of this project. But I bet Alec is a very, very busy man already, with two whole games in development.

[jackf]

Are you considering GameObjects to be individual entities, or can there be multiple GameObjects that create a yet larger unit, each with their own components?

This project intrigues me because I did the same sort of thing in C under the idea that every part (floor, enemies, player) of the game world would be of a datatype, and complication beyond rectangles would be obtained by adding "children". Without classes as I was inter-object communication was very difficult (Head object was hit, child Gun object should fire back).

If you can get this off the ground it seems like it would be fun, albiet similar to a lot of other game-making utilities.

[Kornel Kisielewicz]

In other news, it's been ages since I last saw you here Kornel.

I usually just lurk, and it's only recently that I got back to indie-coding

I'm also curious on the standing of this project. But I bet Alec is a very, very busy man already, with two whole games in development.

That's why I suggested to set up some collaboration environment.

[Eclipse]

STL is evil D:

....and slow.

But it's okay for small things!

[Klaim]

It's not at all, I made full NDS games with heavy use of STL. Sure you have to understand how it works and sometimes how it is implemented for your target platform/compiler, but the performances are more about how you use it than the STL itself.

In the end, STL only provide very basic structures. That's the usage that is important.

[Kornel Kisielewicz]

It is funny when people say "STL is slow" and then implement their own structures that turn out slower... I've done measures and stress tests of vector vs. new[] and map vs. a quite good non-STL implementation targeted at speed, and iterators vs. direct access on both GCC (4.3 FWIW) and MSVC (2008) on three different architectures on two OS'es, using cycle-based measuring and the differences were constantly marginal or non-existant.

True, if you carefully tune the structures to the target architecture (hell of a job), and throw away run-time checks, you'll get a performance boost. But the game is not worth the reward, unless it's optimizing specific parts of code on the latest stage of development. Also, availability of a good STL implementation on a newborn platform with it's own compiler not always meets our expectations, but usually it's just a matter of time.

People who say STL is slow, are either begginers who don't know how to use it properly, or who brainlessly keep repeating what they hear, or absolute experts. The scary majority however is the former...

[Snakey]

STL is evil D:

....and slow.

But it's okay for small things!

I would be interested to see what container types you would implement or use in your own structures.

[Will Vale]

The one I would recommend (and use myself) is an iterable random access container (i.e. like a vector) with some differences:

* No automatic growing of the container when it runs out of space.

* Specify capacity as construction parameter.

* Add a set_capacity() method to change this.

* erase() is non-order-preserving and copies the end element into the vacated slot.

* clear_memory() provided to remove the allocation of the vector without having to use the non-obvious swap trick.

Obviously you could implement this in terms of std::vector and it wouldn't be a whole lot of work. You could also look at EASTL for some good commentary on this topic.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html

Cheers,

Will

[Kornel Kisielewicz]

The one I would recommend (and use myself) is an iterable random access container (i.e. like a vector) with some differences:

How about boost::array (or std::tr1::array for that matter...)?

[Will Vale]

boost::array and tr1::array are an adaptation of compile-time-constant size native arrays to STL standards. Fine and all, but nothing like what I was describing. 

[Kornel Kisielewicz]

Yeah, I noted that after I posted. Still, you can use a vector because:

* "No automatic growing of the container when it runs out of space." <- you can check that yourself. Range checking would be done anyway to allow safe usage, so it isn't such a big performance hit.
* "Specify capacity as construction parameter." <- AFAIR you can do that with a vector.
* "Add a set_capacity() method to change this." <- reserve/resize depending on need for pre-clearing
* "erase() is non-order-preserving and copies the end element into the vacated slot." <- I don't exactly understand what you want here.
* "clear_memory() provided to remove the allocation of the vector without having to use the non-obvious swap trick." <- also exists, and once you know the trick it's not a problem.

Also, you might look at using new-allocated arrays with the boost constructs -- you can iterate over an array like over a container. Also, it's still always better to build up on stl/boost than reinvent the wheel .