With the release of Torque 2D and with ongoing debate over the organisation of Allegro, I'd like to propose an add-on for use in making games with Allegro.

This would be a set of independent source code files which could be easily dropped into a project as required and offer basic functionality which could be built on for each game. This would be useful both to people new to Allegro and for more experienced people who want a quicker way to make a game.

Many of us here have made code that does this, and there are already libraries out there for some of these suggestions. However I'd like to see a clean and well documented set of source files which are explicitly designed to be dropped into a project and then extended, rather than linked to a project in one fixed DLL. More like a template system I suppose.

By having a cleanly coded system it makes it easier for everyone to make games quicker as well as introducing a common framework for projects.

Here are my source code file suggestions:

1. Screen Update API
No problem for this one, just drop in Chris Barry's excellent screen update code and games can allow the player to select from different screen update methods to find the one best for their machine.

2. Menu Options
Nearly all games use a main menu or options. A handy set of functions to easily create menus and tie them into your own code would be very useful. Would contain code for key/mouse/joypad support.

3. Particles
Particles are more and more common, and a handy set of functions which can be used to create and manage particles would be useful. Perhaps containing function pointers for draw functions?

4. Collision Detection
Already present in several libs, a clean API to handle bounding box and pixel perfect collisions (via bitmasks) between objects.

5. Main Loop
Maybe it seems simple, but a good template for logic/gfx decoupling would help new people to Allegro avoid common mistakes and ask the same questions again and again.

The following suggestions I'm not sure about:

Tilemaps
Routines to handle tilemaps (Is this too different with each game?)

Sprites
Would tie in well with the collision detection code if sprite functions could be use to manage, animate and move sprites.

What do you think about this proposal?

You aren't suggesting that this would be done in... pure C... are you?

Why not C? A correct OO design can be implemented in C too, you know?

Yes, but if you are going for OOP, then C++ has so much more to offer than pure C...

If so, it'll still be awfully ugly.

Not to mention there's absolutelly no point.
And you still can't have most of the functionality (templates, overloading operators, constructors/destructors, etc).

Yes C. Allegro is C.

No it wouldn't be ugly. Look, let's not have a C vs C++ discussion please. If you having something to say about the idea itself then please post..

Allegro also stands for "Allegro Low Level Game Routines"... so if you're going High Level, it's no longer Allegro; it's just something built over Allegro. And then you may as well do it right and use OOP.

The thing is, using templates in C++, draw functions can be inlined for a massive speed benefit compared to using function pointers.

But, I'd have to say that something like this would only be used by the C people. C++ people wouldn't have use for it unless it used a C++ interface.

Have you understood anything in my original post? I'm not proposing an add on to Allegro, I'm suggesting some common source code files which use allegro and would help speed up game development.

Please don't troll my thread with your own personal language preferences. Thank you.

Isn't that roughly what the next version example games coming with Allegro should do?

Ok, a bad choice of words. I proposed an add-on as in an external set of files, not a extra layer over allegro, or a section of the allegro library in a seperate DLL.

You must have understood what I meant if you read the original post though..

You can put stuff like this on the awiki code snippets section, can't you? And then people can port the code to their language of choice, too -- it being publically editable and all.

Yes, but I still think that this thing you're purposing would work so much better in C++, that it'd be rather silly to do it in C.

You asked us what we think, and this is what I think.

Sorry if you thought it was trolling.

I see no reason why there couldn't be C, C++ versions etc..

But to insist that only C++ is the right language to use is the wrong way to go I feel.

Two seperate versions are fine, but don't restrict people using C to have to use C++.

It's always possible to create a C++ wrapper over a C API.

I think the idea is good, not exactly an addon, but just useful code snippets you can throw in your game. They must have good documentation, though, and be highly encapsulated (i.e. they must not depend on each other and must not have weird side effects).

I'm curious: why decide the implementation specifics for unwritten code for pixel perfect collisions and not for anything else? I'm still sure that a Minkowski solution with intelligent caching would be faster than bitmasks and probably no slower without if an RLE solution were properly wrought out.

Yes. And indeed a C wrapper over a C++ API (see, e.g. that little known library DirectX). Surely we can agree: C and C++ APIs for the user, who cares about the internals?

Thomas: You are correct, the implementation specifics should remain flexible.

As long as the user doesn't need to care about the internals of course.

Currently this looks more like a wishlist than a proposal ... how would you have this be organized? Would you start writing these? And where would they be hosted?

Well, the screen update one is there already. I was hoping that discussion and design would encourage other people to want to contribute. The advantage is that new source files could be added and the user can use them in his projects or not as he desires.

I do not think I have the ability to write clean production level code. However I would be happy to host them on my website if this ever became a reality.

Production code is always code that works, but not always code that is beautiful. Think of the Allegro API: it gets the work done, but we all know it could be way better.

like OpenGL has GLUT, Allegro can have an extra addon that gives us an additional high-level library. I think that's what RP is trying to say;)

I was thinking more of a set of interdependent source code files than a library.

Actually there are two ways we could go:

a) Have a documented API for the user to use, the internals are hidden and complex.

Pros: Easy to use, could be quite powerful.
Cons: Not very flexible, limiting for some games.

b) Have a clean set of internal functions which can be expanded by the programmer. (This is more what I was thinking of originally).

Pros: If coded well this could allow the user to expand the routines in a
more flexible and ultimately more powerful way.
Cons: Might be more complex to use than a) (although a clean API could help), Initial bare functions would probably have to be less complex than a)

So is your idea any different from "a collection of useful & well-commented code snippets"?

Well, what do you define as code snippets? One or two functions, or seperate modules?

While not a library these source code files would be useful in developing a game.

Just looking at your posts again Zaphos and you seem pretty negative, any reason why?

Okay, how about this. The project consists of a group of such items. It will have a C and a C++ version of everything. Now, in some cases the code will be a C++ wrapper over C. But other parts of the library may be C++ and then wrapped over with C. That way if something would benefit immensly by being C++, i.e. the particle enginge, it could be written in C++ and then wrapped in C.

If you wrap C++ in C and add it to your project you will have to compile everything as a C++ project though.

No, you just need to compile that part in C++ and then link it into the .a file.

Do you mean something like this:

I started this for one of the speedhack competitions after studying gb/gba developement.

Sounds like a good idea, but since Allegro is open-source anyway, why not just edit it directly? It needs a bit of an overhaul anyway, in terms of function names and such. I'm sure that'd be faster than another wrapper, too.

Edit: Sorry should've read the post fully

It's not a wrapper Kris. It's a set of source code modules to help with higher level game development. Editing Allegro directly would miss the point.

Nonnus: Yep, a bit like that.

Chris' update code is integrated under the hood in the 4.3 branch (which reminds me that I should credit him for it). It'll be a while yet before 4.3 is stable enough for use though...

That said, I would personally not use any of that - but I'm not the target audience anyway. For newbies, I think this could be useful.

I would do it as set of publically maintained and expanded games. They would share a lot of menu code and have a common code structure and style. They would have plain workmanlike graphics and sound, and very generic gameplay (while still being solid and good, hopefully). One from each major genre would do. These would all be available in the same place, even bundled, and the docs can refer to each other. This would evolve into an 'extended examples pack' which would become a de rigeur add-on and could even be made official (i.e. linked from the alleg.sf.net site).

on the other hand

The major effort needed is compiling an up-to-date catalog for all the existing snippets and add-ons. SF and this site both depend on either the project owner or the admin to be Editor-In-Chief of the details. This leads to major bitrot. If you want to volunteer as Editor for the snippets and examples on one of the Wikis (awiki & pixwiki) then you are free to (if you can ever remember your password :p). Wikis are cool because nobody can maintain something like a guide to all Allegro addons single-handed spare-time.

I tried coding a site a coupla years back that automated a lot of the process, but I stuck to GUI add-ons and even then failed to get it finished.

Nice idea - I've used some snippets I've found here; for example a set of functions that made logging pretty easy, as well as a set of functions that help receiving the player name for a higscorelist

Hm. I find this idea rather nice and useful. I already have my own set of modules that I use for my own games (they do mainly what you proposed, Richard), but nonetheless, I'd have fancied something like that when I started.

So, I'm not going to use them (I already have my own, as already pointed out), but I'm in favour of the idea.

I like your idea Richard, as a fairly novice coder myself i'd definately find a use for something like that even if it was just for ideas on HOW to go about things like collisoin detection, tile engines etc in actual code
I realise there's lots of tutorials around on these things like those at gamedev but it'd be very good to have Allegro based examples.

Matts idea is a good one too, getting off the ground can be a very bewildering thing and being able to look at code for very simple working games would be great, I've often tried looking at existing code for games and it's far too much to take in usually. I would like to see things like source for tools like a simple map/level editors too.

I think Shawn just picked the name Allegro because he's into music. It really isn't that low level. Some say it has everything and the kitchen sink. So let's not be stopped by a useless acronym.

I'm pleased that a few people seem to like the idea. So who is open to contributing and doing some code for this proposal?

There, I think, you've hit the nail on the head.
We need more programming and less talking. Quite frankly, I don't see more than one or two people contributing code snippets for this... maybe I'm too pessimistic though.

I think more people would submit their code if they weren't afraid of it being torn apart by their fellow programmers. The problem is person A will submit his/her code, while person B (who might be more experienced but doesn't want to participate) will point out everything bad about it. I don't think these forums would be the best place to get this project done. I think you setup a website, get a forum going there, and invite people who are interested from here. Create an environment where people share ideas and comments respectfully. I don't think everyone here shares that kind of mentality. It must be understood that whatever is created isn't going to be the best design or most efficient that is possible, but atleast it's something.

That being said I'd like to offer my help. I'd love to share with some of you my ideas and I'd love to hear your ideas about the actual implementation of these source files.

I think you are both right.. :/

Another advantage of Wiki is that you don't have to discuss anything, just make the improvements you see fit. Criticism and discussion can be made at the bottom of the page and removed when the issues have been addressed.

In the interests of practising what I preach, I added that gradient fill routine I did last week to awiki. It is here

Allegro is low level library at the moment and I'd like it to stay this way. I think there is no need to bloat code and binaries with even more functions I'm not going to use, like tilemap handling, particles and screen update routines (I'm using AllegroGL and the only functions I usually use is keyboard/mouse input and bitmap loading). If you think Allegro needs more high-level stuff IMHO making it additional easy to use (read: windows binaries available) library and give it allegro-ish name.

PLEASE, read the first post I made. I am in no way suggesting modifying Allegro or making a new library.

I wish people would read the posts properly.

Hey, you mean nobody like my .h file

Richard Phipps, I nominate you as project leader for this new layer of API. Are there any objections? Speak within the next 24 hours or forever hold your peace.

Do you accept?

Also, I'd like to contribute #5, please.

_logic returns: 1=try to draw when logic is caught up, 0=don't draw, -1=quit

Just a little thing I threw together because I'm bored.

Here's a small improvement to Kitty Cat's code. It has an extra parameter, max_frame_skip, that tells the maximum number of frames that can be skipped (not drawn).

Pass -1 for unlimited (what original Kitty Cat's code does), 0 to force drawing all frames (no frame skipping at all, the game will slow down on old computers instead of skipping frames), 1 to allow at much 1 frame to be skipped, and so on.

I hope I didn't do anything stupid, it's late

I've read it, but during reading remaining posts in this thread some of them probably suggested something else. Sorry.

EDIT: When it comes to main game loop I usually prefer delta-based solutions. Frame-based logic often aliases with refresh rate giving somewhat worse results.

With the improvement I did, it's actually possible to do a delta-based logic. Just pass a high value for speed and 0 for max_frame_skip. Your logic callback has a tic parameter, so base your logic on that

I'm not sure, though, how well it'll work with the not very accurate allegro timers.

[edit]
Actually, you'll have to change the line

ticker = currtic;

to

currtic = ticker;

but then in a fixed-delta logic, you should not use the tic parameter. Mmmm... it just seems overkill to me to add a parameter to control this behaviour.

Oh.. change:
while(currtic < ticker)to:
while(currtic < ticker && logic_ret >= 0)

Maybe something more parametrized would work better? For example, delta-based logic is assumed (which can be easily changed) and following parameters are available:
- min_delta - minimum time delta to be used in single logic call
- max_delta - maximum time delta to be used in single logic call
- max_logic_frames - maximum number of logic calls between rendering frames
- timer_frequency - timer ticks per second

And how it could work:
- timer is set to given frequency, timer_frequency could have additional flag telling that high resolution timers (QPC/QPF or gettimeofday) should be used if available
- basing on timer time passed since previous loop is determined (delta)
(remaining part presented as code)

(probably it can be made better, but it's mainly just to show general idea)

This way:
- you can force standard frame-based logic (min_delta=max_delta)
- it keeps call delta in reasonable range
- when rendering+logic can't be run in real-time it starts controlled lag (makes sure that rendering is still done from time to time)
- remaining_time makes sure that time is handled correctly even when min_delta limit is hit (usually it can be set to 0, but sometimes very small deltas may introduce bigger rounding errors)

Richard, that's an EXCELLENT IDEA. i have no idea why anybody would be negative towards it. i'm fairly new to programming and using allegro, and for months i've been researching every scrap of knowledge i could find in order to collect a comprehensive template of "useful snippets of code." if they were put into a .c/.h pair to include with the project, optimized by experienced coders, that would be AMAZING.

i have to tell you, as annoying as it is to have to tell newbies like me to RTFM because i'm the ten thousandth person to ask about tilemaps, its pretty frustrating that there isn't a place for newbies to go for COMPREHENSIVE instruction. If you pull this off, you'll help a lot of people.

PLEASE START A WEBSITE FOR THIS. and think of a catchy name8-)

Hmm.. perhaps it should be
while(ticker-currtic > 0 && logic_ret >= 0)that way it's gauranteed to work even if ticker overflows.

Much as I'd like to be a 'project leader' on this I simply don't have the time. Besides my day job I'm spending my evenings and weekends working on Sunnyball so I can try to release it next month.

Also, it's clear from the code KC posted that his coding foo is better than mine..

But I'm really pleased that people are contributing! It doensn't have to be a massive undertaking, but can start of small and grow hopefully with time. Keep up the great work please!

In the case of using a dynamic library, I would have to agree. This is because the entire library gets loaded into memory. Static libraries on the other hand (as far as I know anyway) only link the used routines into the build. So in the static case, it doesn't really matter how much goodness gets crammed into Allegro, because the amount of bloat will depend only on what the game programmer uses. And even in the case of small libraries, game programmers have to add all that extra code anyway because the library doesn't provide it. I think the bloat argument is completely flawed. That is, (and I say it again) if you're using the staticly linked Allegro.

So why would anyone use the dynamically linked Allegro? Here are some reasons:
1. It's currently the default option (i.e. run make without parameters and the dll is what you get).
2. It makes for smaller game downloads. But again, in the case of static libraries, only the used code is linked. Data is usually much fatter than code anyway.
3. If two or more Allegro games are running at the same time, the Allegro code isn't duplicated in memory. However, this scenario is highly unlikely.

So there's my argument against those anti-bloatware naysayers. I think if there's something very useful and fundamental that could enhance Allegro, it should be added if people like it.

Ok, I'll try again and provide yet another explanation..

I am not talking about a library of any kind.
I am not talking about altering allegro in any way.

What I am talking about is making a collection of source files and relevant headers. Some or all of these files could be added to people's projects.

So.. people can download the collection of files and if there are some they want to use in their project they can copy the relevant source files into their project (i.e. particle section, menu code), modify the functions to suit and have a quicker game development time. This would also help provide clean, bug free and tested code easily.

Is that clear enough?

Yeah Richard...you are talking about skeleton programs. And even skeleton files if you will....hehehe.::) Yeah...I think it would be a nice think for noobies, people that want to learn how to write something, or people that don't want to waste their time rewriting the same damn code! I think a lot of people thought the wrong think here.....8-)

Richard, since you submitted your idea to the public, you must allow the public to do what they will with the idea. If they want to make a skeleton slash library engine thing, then let them. They're contributing anyway, right?

I don't have any code to contribute, only a few desires. I'd like to have some source files for logging, collision detection & object management, scripting wrappers, et cetera.

This would look great as an extra download on the sourceforge website. The 'examples' folder has some examples, but examples that are applied into games would be even better. For example, with the collected scripts we can compile them into mini games and show the differences of each when the different parts are exchanged for different methods.

Kanzure, if people want to do that then that is their right. But people are repeatedly misunderstanding what I suggested, and are instead arguing both for and against something I never meant.

I was wrong in understanding what you meant?!? I'm really confused as to what you mean then Richard...::)

No Don you were right! But others seemed to think I was talking about adding high level functions to Allegro or making a complete library to link into a project.

Ok...I'm NOT as dumb as I look....:o Well that's always nice!

Mage started out as set of individual source modules, but it became easier to do them as a lib, with a shared header.

I think a few larger medium-level modules or libs are best. Really low-level ones like fblend are candidates for inclusion in Allegro, but the medium-level glue needs its own support.

First it needs an acronym!

Allegro Computer Community Medium-level Expansion

libaccme.a

-laccme

Accme: n. The 1337est lib in teh j00niv3rrz . teh h19h3st l3v3l Allergo

Note to Warner Bros. Do Not Confuse despite the similar pronunciation.

Well, I think X-G's partypack definitely has some good shit (the resource manager I'd say should be a requirement for any serious allegro game), and that requires C++. The sprite/animation code is not too shabby either, and definitely a good starting point for something more versatile. The whole xml sprite definition file is not a bad idea, although it has some repetitive information that could be cut out.

I've done a bit of glue code myself, all in C++ because it just makes everything much easier and cleaner to work with (since, imo, I see the allegro api as rather ugly now).

It would be nice to standardize the stuff for use across projects more easily, though.

Marcello

Uhh. Out of concern for the potential project's well-being, I hereby retract my offer made above. Krzysztof and Kitty have shown a quality of work to which I can't lay claim.

Hey, I only made a simple game loop (it's basically the same "skeleton" code I use when making my own programs). The details of which are described in TFM. The only change I made was to have the logic function return what to do: nothing, draw, or quit.

This is something I have been hoping to find. I would probably use it, I'm not a fan of writing low level stuff. It would speed up beginners writing games. Much less questions how to do frame independent movement etc...

And one suggestion:
Just don't over engineer it from the beginning

Another, maybe more Important possible effect of implementing this idea is that we could get a library of "best practices" regarding different aspects of coding a game in allegro - a Wiki sounds like a grand idea for this

I don't know what I'd contribute myself - maybe a framework for doing A* pathfinding on different kinds of maps - something you can use if your map implements the correct methods

Guys, unless someone with more time than myself takes this up then this idea will just die.

Does anyone want to set up a wiki or webpage?

Dude, you can't present ideas like this if you're not going to follow through with them. As they say, if you want something done right, you've got to do it yourself.

You can't expect people to just lead themselves.

Marcello

That's why I called it a proposal, and not my project. I think it's a good idea and others seem to agree and want to see it happen.

Other people have more time, and more coding skills than me and I was hoping some of them would run with the idea..

Everyone else in this thread is probably saying the same thing.

Probably.

Technically, there already are enough wikis. Just for fun made a site with Matty's lib name as title in the awiki But yeah, the problem is more the contents.. I guess it doesn't need to be a complete lib aiming to be able to compete with something like T2D - just a collection of useful stuff, glued together so it can be easily used, should do in the beginning. I don't really have an idea how it can be done though as well, it probably needs a single person starting to do work on it. Who knows where Allegro 4.2.x would be without Evert, or Allegro 4.3.x without Peter. Or without all the addon writers. So this also just needs someone to start it.

Sadly it doesn't seem like many people are commited enough to support something like this.

I wish I could help, but I'm completely overloaded with my shareware work.

So aside from timer code has anyone even discussed what the supposed api would consist of? We just skipped that part and went straight to lamenting the lack of interest which is really a big time saver I suppose. Next time you could just post about no body having time/interest/motivation and save even more time .

There is one big problem with the this 'mid level lib', well, two anyway. Number 1 of course is c vs c++ which hasn't been addressed.

Number two is; suppose you have some midlevel functionality defined; tilemaps and sprites. How big are they? How are animation sequences defined? Sure you can make a default tilemap 32x32 pixel tiles and sprites 64x64, but someone will surely want something different. So you add the functionality to make these things customizable, or maybe it's there from the start. Suddenly this 'midlevel' stuff is quiet detailed and not quiet as rad (rapid application dev) as you might have first supposed.

Surprisingly, no one even mentioned clanlib.

There are 5 possibilities:

• C only

• C++ only

• make both a C and C++ version (Can still use the same ideas between both - just where one uses STL, the other uses hand-crafted structures, and so on. Else whichever gets more interest will be done and the other eventually be given up.)

• make it C with a C++ wrapper

• make it C++ but export a C API

1 and 2 would decrease the number of people working on it, if there would be C as well as C++ people working on it. But all 5 sould work well enough, and can switch from some to others at a later time.

You specify it when you create a tilemap-layer or a sprite, I'd say. A fixed size certainly is bad. In the worst case, could use a #define or something - but I'd say arbitrary layers and tile sizes are a must.

I'm wondering about that as well. The simplest would be to just let the user specify the sequences in user code.

I think you should concentrate on having RAD for the end user. The engine itself can't be done with RAD, i'm quite sure it needs design and solving of complicated problems.

Isn't there a pixelate wiki or something?

If so, why not just start adding individual contributions to it?

That's an interesting point. There have been several prior attempts to start a library or collection of code samples and routines. Maybe interests would be best served by making a list of these and noting what is missing?

Making a heterogenous (everything is done for either C/C++, and compatible with eachother) collection of stuff seems like a too daunting task to me - it would require way too much coordination, bullying and secterism

Just let people add their stuff/tips, and let the users worry about making them work together

Yeah. I linked to it above. MattyMatt actually started something on awiki: http://awiki.strangesoft.net/bin/view/Main/AllegroComputerCommunityMediumlevelExpansion

As a first step, yes. But the real idea of this would be to simply save users from the task to hunt for addons and make them work together.

Personally I think the concern about c/c++ irrelevent. Since in a project like this you really will only have one programmer and concerns of people helping are minimal, that person can choose whichever they prefer. (For example, were I to take on the project, I'd use c++, not caring what anyone else thinks.)

I consider c++ higher level than c, and almost a necessity for clean game design, so a c++ framework for allegro makes perfect sense. It is supposed to have clean interfaces and api. That's a personal opinion.

Marcello

Note how I said

So yes, C vs. C++ is a complete non-issue.