Practice Repositories

[3hM2Nwbp]

Such a library would take quite a bit of research for those not already up to speed on the various compression theories and specifications. It's pretty much an entire field in itself - a good start (if it's green flagged) would be to gather as much documentation about the target formats as possible.

[z05DSL3A]

I like the idea of an Image library (vector and raster). In the past I have wanted to use JPEG 2000 and SVG (different projects) but could not find a good library that was not out of my price range. There is plenty of scope for other libraries and projects; compression, xml, image processing, machine vision...

[anonymous23323124]

Image processing might be cool, I think. If we made a general framework, we could all contribute "effects" in the form of DLLs with a specific public interface. Then the main application could allow stringing together of various effects and so forth.

As for JPG, etc, isn't there a free library called libjpeg?

[Athar]

Such a library would take quite a bit of research for those not already up to speed on the various compression theories and specifications. It's pretty much an entire field in itself - a good start (if it's green flagged) would be to gather as much documentation about the target formats as possible.

I'm not suggesting reimplementing any of the compression algorithms - that would be crazy.
Rather, the library should provide a clean C++ interface to existing implementations.

[hamsterman]

When choosing a project we need not only to think how useful that project would be, but also, how much cooperation would we need, who could write it, etc.

My opinions on the ideas so far:
*game. I think this is a fairly good one, even tough very abstract. Writing a game would require a lot of discussion on the general structure. I'm not sure if that is good or bad. It might be a pain if we all have many ideas and little experience.. Also, I think there would be parts for people of different skill levels and interests.

*networking or utility library.

computerequip wrote:

But there's already too many networking libraries >.>!

Though this could be split into fairly (but not totally) independent modules, which is a good thing.

*archive manager. I could see that work. But then, why could anyone ever prefer it over existing archive managers. It would be awesome if this community project resulted in something really useful..

*library for loading images. I think this might be the best so far. There is no good one library for that (have you ever tried loading a gif animation?). There are many algorithms of different complexity. They are all fairly independent, but need a unified interface.

(did I miss anything?)

[z05DSL3A]

As for JPG, etc, isn't there a free library called libjpeg?

I'm not suggesting reimplementing any of the compression algorithms

Maybe I misunderstood the nature of 'Practice Repositories', I was thinking that we would be building something from the ground up. I'll wait and see what gets decided.

[Athar]

I'm not sure how much practical use an image library would have, as there are already powerful libraries for loading/saving and/or manipulating images, such as ImageMagick, DevIL, FreeImage and cairo.
And I found loading animated GIFs to be quite easy with FreeImage.

Maybe I misunderstood the nature of 'Practice Repositories', I was thinking that we would be building something from the ground up.

Sure, in that case it would be the compression library and the archiver. Building something from the ground up isn't impaired by depending on other libraries - there's no way around that anyway (short of creating a new OS).

[anonymous23323124]

I'm not sure if we're building from scratch or not: I think it depends on which project we pick.

It's just that you said a JPEG2000 library was out of your price range.

JPEG 2000 ... could not find a good library that was not out of my price range

I was merely highlighting such a free library. Perhaps it doesn't class as "good" - I haven't tried it...

[z05DSL3A]

I think I'm going to back out of this one; as my point seems to have been totally missed.

[anonymous23323124]

@Grey Wolf Sure :) I didn't mean to come across as argumentative.

[S6k9GNh0]

@Grey Wolf: I was under that impression too... being productive is a secondary item given out by starting a repository meant to provide people with experience.

Although, I was thinking twice about it, if we were to create a image library, I was thinking about branching the project into several little projects in which those projects filled the specification of each image format to encode and decode each image (and other stuff...). Perhaps this is too difficult?

[chrisname]

We should be writing programs that are
1. Fun. I think this is the most important point, or people will simply become apathetic and stop contributing.
2. Challenging, but not overly difficult. Again, this prevents apathy and feelings of indirection.
3. Useful, if not for the general public, than at least for ourselves. Again again, prevents apathy and makes the project seem like it has a "point".

[S6k9GNh0]

Then, a small game or two at first? People usually enjoy making games. We could start everything from scratch, the entire engine which would include something like a basic window, sound, and graphical engine? Games are also always productive in some way. Games also include anything from basic to complex logic and can easily take advantage of the latest C++ features where as we may not be able to as such with an image library.

[ultifinitus]

I would recommend a game per person. Make an easily expandable engine and have someone work up a simple gui to swap between functions and have each team member make their own "function" (actually a full game) and make sure that the engine has the capability to grab input, display sprites, play sounds, and move pixels about, and you've got yourself a GIGANTIC but awesome group project =]

[anonymous23323124]

That idea is a pretty good one.

Each person would simply have to write a DLL that exported functions of the form:

int playgame();
std::string GetName();

Then the GUI could simply scan each DLL in a directory, try to find the functions and then display the game names at runtime. Then the user could select it and the GUI would just have to call the correct playgame function.

Any engine we made would have to be dynamically linked, so all the games could use the same engine binaries at runtime.

EDIT: Alternately, the different games could simply be different executables, to avoid the additional complexity of a playgame function.

[S6k9GNh0]

Implementing playgame() sounds extremely similar to implementing an application entry point (main()) that uses the engine in the same manner. It sounds like we add a pointless amount of complexity.

On a side note, I was wondering where the repo should be hosted? I was thinking on my server but I'd think that's a bad idea as some may look at that as promoting myself. So, a host such as github or bitbucket sounds more proper. Feedback?