- Online Community Forums » The Depot » Purple Martians update

This thread is locked; no one can reply to it. rss feed Print
Purple Martians update
Michael Weiss
Member #223
April 2000

Hi all,

I have been working on cleaning up and documenting my Purple Martians project.

I wrote some HTML pages of detailed code descriptions.

I was planning on hosting then on, but I don't have a account. I have been a member for almost 20 years, but never have signed up for the free web site. I requested one from Matt a few months ago, but I guess he rarely makes an appearance here anymore. So sad. I hope this doesn't mean that is going the way of the dodo.

Anyway, if anyone would like to look at my detailed code descriptions and give any feedback, I would be most grateful.

I have attached them to this post in a zip file, but they are also available with the rest of my project on

Of particular note, I am most proud of the netgame code, followed by the dynamic screen resizing while the game is running. The use of splines in the logo is neat too.

The code is almost all straight C, at one point I was going to convert it all to C++, but gave up due to to sheer enormity of the task.

I break some good programming styles, mostly with my use of global variables, but I honestly can't see a way around it that isn't more complicated and non-intuitive. I always try to minimize my use of globals, but some variables just need to be visible in lots of different scopes.

I'm setting programming aside for now to switch back to my other creative outlet, writing and recording music. I took almost a year of all my spare time fixing up and polishing this project. I have to call an end to it at some time. There is no end to what I could add, change, redo, etc. But as it stands now, I am proud of what I have been able to accomplish.

The one thing I like most about allegro is that it is a game programming library, not a game engine. You are free to implement your game however you want. I looked into Unity once, and even though it is very impressive and you could do some amazing things with it, you have to do things their way. For me, most of the enjoyment comes from figuring out from scratch, how to do things my way.

This is mostly a vanity project. I did it because I wanted to. I wanted to prove to myself that I could do it. I would be just icing on the cake if other people liked it too.

I also write and record original music, and there are many parallels between that creative endeavor and programming.

I create something that did not exist before. I give it away for free. I do it mostly for me, but would love it if others appreciated it also.

So please have a look at the detailed code descriptions and tell me your thoughts. Good, bad, ugly, whatever.

Thanks everyone!

Michael Weiss

my email:

Download Purple Martians from

Purple Martians project page on

Github repository for my project:

My youtube channel with game videos and original music:

Frank Drebin
Member #2,987
December 2002

WOW :o

Now this is what I call a documentation! I took a look and there's nothing I can tell to do better. In fact it is so well documented that I feel it's rather like a tutorial for someone (or for yourself) to understand the structure of your source code ;D

I like how the screen resizing works in the game though sometimes I think that screen can go off-center (see attached screenshot).

Michael Weiss
Member #223
April 2000

Thanks Frank,

I tried to make the documentation very thorough, especially for the complicated parts.
What you might not have noticed though is there are large parts that I haven't even started to document. If I had more time maybe...

As far as the centering thing goes, I know what you mean, I am not 100% satisfied with that myself.

The player is not supposed to be in the exact center anyways.

I originally had it that way, but later changed it to a method with a hysteresis rectangle in the center of the screen that the player was free to move in without causing the level to scroll.

Its size is customizable in the code:

1 2void get_new_screen_buffer(void) 3{ 4 al_set_target_backbuffer(display); 5 al_clear_to_color(al_map_rgb(0,0,0)); 6 7 int alp = active_local_player; 8 int c = players[alp].color; 9 10 // draw frame in local player's color 11 for (int x = 0; x < BORDER_WIDTH; x++) 12 al_draw_rectangle(x+0.5f, x+0.5f, (SCREEN_W-1-x)+0.5f, (SCREEN_H-1-x)+0.5f, palette_color[c + (x * 16)], 1); 13 14 // default place and size to draw on screen_buffer 15 int bw = BORDER_WIDTH; 16 int sbx = bw; 17 int sby = bw; 18 int sbw = SCREEN_W-bw*2; 19 int sbh = SCREEN_H-bw*2; 20 21 // how big is the entire level after scale factor is applied? 22 int sls = (int) ((float)2000 * scale_factor_current); // sls = scaled level size 23 24 // is the entire level smaller than the screen buffer width? 25 if (sls < sbw) 26 { 27 int a = sbw - sls; // how much smaller? 28 sbw = sls; // new screen_buffer blit width = sls 29 sbx += a/2; // new screen_buffer blit xpos 30 } 31 32 // is the entire level smaller than the screen buffer height? 33 if (sls < sbh) 34 { 35 int a = sbh - sls; // how much smaller? 36 sbh = sls; // new screen_buffer blit height = sls 37 sby += a/2; // new screen_buffer blit ypos 38 } 39 40 // find the size of the source screen from actual screen size and scaler 41 int SW = (int)( (float)(SCREEN_W - bw *2) / scale_factor_current); 42 int SH = (int)( (float)(SCREEN_H - bw *2) / scale_factor_current); 43 if (SW > 2000) SW = 2000; 44 if (SH > 2000) SH = 2000; 45 46 // find where to grab the source screen from based on the players position 47 int PX = al_fixtoi(players[alp].PX) + 10; 48 int PY = al_fixtoi(players[alp].PY) + 10; 49 50 // this method always has the player in the middle of the screen 51 //int WX = PX - SW/2 -10; // set window from PX, PY 52 //int WY = PY - SH/2 -10; 53 54 // set the scroll hysteresis (a rectangle in the middle of the screen where there is no scroll) 55 int x_size = SW / 8; // larger number is smaller window 56 int y_size = SH / 12; 57 58 if (WX < PX - SW/2 - x_size) WX = PX - SW/2 - x_size; // hit right edge 59 if (WX > PX - SW/2 + x_size) WX = PX - SW/2 + x_size; // hit left edge 60 if (WY < PY - SH/2 - y_size) WY = PY - SH/2 - y_size; // hit bottom edge 61 if (WY > PY - SH/2 + y_size) WY = PY - SH/2 + y_size; // hit top edge 62 63 // correct for edges 64 if (WX < 0) WX = 0; 65 if (WY < 0) WY = 0; 66 if (WX > (2000 - SW)) WX = 2000 - SW; 67 if (WY > (2000 - SH)) WY = 2000 - SH; 68 69 // used by get_new_background to only get what is needed 70 level_display_region_x = WX; 71 level_display_region_y = WY; 72 level_display_region_w = SW; 73 level_display_region_h = SH; 74 75 // this is what all the previous calculation have been building up to: 76 al_draw_scaled_bitmap(level_buffer, WX, WY, SW, SH, sbx, sby, sbw, sbh, 0); 77 78 #ifdef SHOW_HYSTERESIS_WINDOW 79 float hx1 = SCREEN_W/2 - x_size * scale_factor_current; 80 float hx2 = SCREEN_W/2 + x_size * scale_factor_current; 81 float hy1 = SCREEN_H/2 - y_size * scale_factor_current; 82 float hy2 = SCREEN_H/2 + y_size * scale_factor_current; 83 al_draw_rectangle(hx1, hy1, hx2, hy2, palette_color[10], 2); 84 #endif 85 86}

It seems to works pretty good, except when changing screen size, the player gets pushed up against the edge of the hysteresis window. I've noticed it myself, but couldn't think of a way to do anything about it.
I mean, its doing what it was designed to do. The player is staying in the hysteresis window.
Sometimes things you are interested in seeing are off the screen, but I can't think of an automated way to tell what you want to see and scroll it back on the screen.
So I just decided to live with it. Its pretty minor. And if you want to see more, just zoom out a bit.

What did you think about the netgame code?

PS I checked out Brutalo Deluxe back when you released v3.30 and liked it.
Especially the particle and blood effects.
I just ported my game from A4 to A5 like you did.
I wasn't as bad as I had thought, although it was very time consuming.
I would be happy to share my experiences, or try to give advice if you want.
I am curious how you handle events and timing, and what your main game loop looks like.

Thanks for the feedback...

Frank Drebin
Member #2,987
December 2002

The netcode looks reasonable, however, I didn't set up a net game to test the functionality by myself. Are you using TCP or UDP?

Well I think I am using pretty much the same game loop like all the Allegro 5 tutorials suggest and the same one you are using in the 'Events'-section of your documentation - so nothing secret here...

BTW: When porting a game from Allegro 4 to Allegro 5 I found this article quite useful - most of what I had to do is mentioned here.

Edgar Reynaldo
Major Reynaldo
May 2007

It would do you some good to add some organization to your data. Use structs to group data that belongs together.

Globals ARE bad. If every file needs to access every piece of data throughout the program, it means your code is not modular. Wrap your data in a struct, and then pass a pointer to that struct. Voila, you now have access to everything you did before, but you don't need to share it with every module you have.

To be honest, your code suffers from what I call "Urban Sprawl". My old Spiraloid program looked like that. There were dirty hacks all over the place, and functions were way too long.

Your documentation is awesome, but hard to find in your repo.

I applaud your work. You've made quite the awesome little game.

If you were to rewrite the game from scratch, I'm sure the code would look completely different, but there's no really no point doing that when you have something that already works.

I was planning on hosting then on, but I don't have a account. I have been a member for almost 20 years, but never have signed up for the free web site. I requested one from Matt a few months ago, but I guess he rarely makes an appearance here anymore. So sad. I hope this doesn't mean that is going the way of the dodo.

The best way to reach Matthew is by email, or PM.

Go to: