So I recently finished a game and I use Windows but most of the people on this forum use Linux so I would like to know how easy is it to port it to linux? I could create a virtual linux machine easy enough but I don't know how to use anything in linux. Is it as easy as learning the gcc commands to compile the exact same project or would I need to rewrite some parts of the code/edit resources?

I don't think most of the people here use linux, but there is a fairly significant fraction that at least sometimes ^[1] use linux.

As for the porting, what api? Did you use any platform specific code? If its pure Allegro, then the port should be easy.

It's all allegro, I don't think I used any platform specific code, but I'm pretty newb. If it's possible for anyone to download the source code (http://www.filedropper.com/194zsource) and just check if it compiles alright I'd really appreciate it.

I compiled the sources, I only had to make 2 small change to get the to compile under Linux. First was the use of #include <windows.h> that I just removed, second was a `for ( auto &c :` that I turned into a `for ( auto c :`.

I did have some problems with the display of transparency of the sprites, but I found they were fixed if I added an al_clear_to_color(al_map_rgba(0,0,0,0)) on every sprite bitmap before drawing the sprite into them. I'm surprised this even worked before on Windows. Allegro doesn't zero out a new bitmap for you, you have to do that yourself.

I attached the dynamically built binary for 64 bits Linux, which will only work if someone has all the same shared libraries I do, and a build script. Hope this helps somewhat, but feel free to ask more.

Hmmm, interesting, thank you so much! I wish I knew more about Linux or programming in general that I'd be able to figure out why the transparency doensn't work. Thank you for taking the time to do that!

What were the problems you had beoran? No transparency, or something else? Could you clarify? I've seen some PNGs that display correctly with the Windows/OSX native loaders but transparency is sometimes not transparent or only parts of it is with libpng.

I edited my post, the problem was due to the sprite bitmaps not being zeroed out with a fill. It's not due to Allegro, I think.

So you call al_clear_to_color( al_map_rgba(0,0,0,0)) on each sprite after setting the target to the new sprite but before calling al_convert_mask_to_alpha? That's to clear out the new bitmap and prevent any left over data from being drawn to it correct?

I didn't look at the source, but from beoran's description I'm betting you have something like:

ALLEGRO_BITMAP *b = al_create_bitmap(w, h);
al_set_target_bitmap(b);
al_draw_bitmap_region(b2, sx, sy, sw, sh, dx, dy, 0);
al_convert_mask_to_alpha(b, color);

After you call al_create_bitmap() the bitmap you created has undefined contents. Which means it might be all zeroes, or it might be random garbage (or it might even be a picture of your gf ). So you have to call al_clear_to_color after al_set_target_bitmap. An alternative way to do it (though in this case it just makes it more complicated I think) is to use a blender like this:

...
al_set_target_bitmap(b);
ALLEGRO_STATE state;
al_store_state(&state, ALLEGRO_STATE_BLENDER);
al_set_blender(ALLEGRO_ADD, ALLEGRO_ONE, ALLEGRO_ZERO);
al_draw_bitmap(b2, ...);
al_restore_state(&state);
...

The "ONE, ZERO" blender doesn't skip alpha pixels: it'll copy them directly into the target instead of "drawing" them... in effect it'll be the same as clearing.

That's exactly what I was wondering, thank you! Gonna fix that right now

I've seen what Beoran described, though I didn't know it was platform specific. Makes sense that an initialized part of the video buffer would have stuff on it - but the effect, a glitchy, inverted copy of my desktop, was pretty cool to look at.

In general though it's always good practice to assign any block of data before you use it. You don't do int i; printf ("%i", i); for a reason, after all, and when you copy a transparent image to a bitmap with an alpha-aware blending mode (the default), you are implicitly copying what was there before during the blend operation, even if the existing data is junk.

Exactly, Trent, that's what I ment. Sorry for the pun.

Winfield, exactly. C does almost nothing behind our backs, so if we don't initialize a local variable or a newly allocated memory block, then it's contents may be garbage. They may even zeroed out, by mere accident. We can't rely on it. It's up to us to make sure every variable and memory area gets correctly initialized.

(Emphasis mine:)

This. This was what had me pulling out my hair for days, when I was but a youngling, which was three weeks ago. Because int i; i++; works just fine in the global scope.

I really like C, and I'm sure there are architectural reasons for that "gotcha", but jeez. That's the kind of stuff we make fun of PHP over!

No, that is not the kind of stuff we make fun of php over

also, imo, always initialize your variables, unless you're doing tricksy things.

The reason local variables aren't automatically initialized to 0 in C is performance. Normally the first thing you do with local variables is store some calculated result in it, so letting the compiler put a 0 or such in there is a waste of time. And this matters a lot for functions that get called in tight loops.

Global variables do get initialized automatically to 0 because the compiler has to allocate space for those at compile time anyway, and initializing those global variables only happens once at start up of the program, so the performance overhead is far smaller.

In most cases, if you wonder why something is so in C, it's normally either due to legacy code compatibility or performance reasons.