Purple Martians update

no-reply@allegro.cc (Michael Weiss) — Sun, 12 Aug 2018 00:28:22 +0000

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 allegro.cc, but I don't have a members.allegro.cc 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 allegro.cc 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 https://github.com/mweiss001/purple_martians

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:
mweiss001@gmail.com

Download Purple Martians from itch.io:
https://mweiss001.itch.io/purple-martians

Purple Martians project page on allegro.cc:
https://www.allegro.cc/depot/PurpleMartians

Github repository for my project:
https://github.com/mweiss001/purple_martians

My youtube channel with game videos and original music:
https://www.youtube.com/user/mweiss0001

no-reply@allegro.cc (Frank Drebin) — Sun, 12 Aug 2018 17:58:36 +0000

WOW

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

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

no-reply@allegro.cc (Michael Weiss) — Sun, 12 Aug 2018 22:13:14 +0000

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:

#SelectExpand
  1
  2void get_new_screen_buffer(void)
  3{
 al_set_target_backbuffer(display);
 al_clear_to_color(al_map_rgb(0,0,0));
  6
 int alp = active_local_player;
 int c = players[alp].color;
  9
 // draw frame in local player's color
 for (int x = 0; x < BORDER_WIDTH; x++)
    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
 // default place and size to draw on screen_buffer
 int bw = BORDER_WIDTH;
 int sbx = bw;
 int sby = bw;
 int sbw = SCREEN_W-bw*2;
 int sbh = SCREEN_H-bw*2;
 20
 // how big is the entire level after scale factor is applied?
 int sls = (int) ((float)2000 * scale_factor_current); // sls = scaled level size
 23
 // is the entire level smaller than the screen buffer width?
 if (sls < sbw)
 {
    int a = sbw - sls; // how much smaller?
    sbw = sls;         // new screen_buffer blit width = sls
    sbx += a/2;        // new screen_buffer blit xpos
 }
 31
 // is the entire level smaller than the screen buffer height?
 if (sls < sbh)
 {
    int a = sbh - sls; // how much smaller?
    sbh = sls;         // new screen_buffer blit height = sls
    sby += a/2;        // new screen_buffer blit ypos
 }
 39
 // find the size of the source screen from actual screen size and scaler
 int SW = (int)( (float)(SCREEN_W - bw *2) / scale_factor_current);
 int SH = (int)( (float)(SCREEN_H - bw *2) / scale_factor_current);
 if (SW > 2000) SW = 2000;
 if (SH > 2000) SH = 2000;
 45
 // find where to grab the source screen from based on the players position
 int PX = al_fixtoi(players[alp].PX) + 10;
 int PY = al_fixtoi(players[alp].PY) + 10;
 49
 // this method always has the player in the middle of the screen
 //int WX = PX - SW/2 -10; // set window from PX, PY
 //int WY = PY - SH/2 -10;
 53
 // set the scroll hysteresis (a rectangle in the middle of the screen where there is no scroll)
 int x_size = SW / 8; // larger number is smaller window
 int y_size = SH / 12;
 57
 if (WX < PX - SW/2 - x_size) WX = PX - SW/2 - x_size; // hit right edge
 if (WX > PX - SW/2 + x_size) WX = PX - SW/2 + x_size; // hit left edge
 if (WY < PY - SH/2 - y_size) WY = PY - SH/2 - y_size; // hit bottom edge
 if (WY > PY - SH/2 + y_size) WY = PY - SH/2 + y_size; // hit top edge
 62
 // correct for edges
 if (WX < 0) WX = 0;
 if (WY < 0) WY = 0;
 if (WX > (2000 - SW)) WX = 2000 - SW;
 if (WY > (2000 - SH)) WY = 2000 - SH;
 68
 // used by get_new_background to only get what is needed
 level_display_region_x = WX;
 level_display_region_y = WY;
 level_display_region_w = SW;
 level_display_region_h = SH;
 74
 // this is what all the previous calculation have been building up to:
 al_draw_scaled_bitmap(level_buffer, WX, WY, SW, SH, sbx, sby, sbw, sbh, 0);
 77
 #ifdef SHOW_HYSTERESIS_WINDOW
 float hx1 = SCREEN_W/2 - x_size * scale_factor_current;
 float hx2 = SCREEN_W/2 + x_size * scale_factor_current;
 float hy1 = SCREEN_H/2 - y_size * scale_factor_current;
 float hy2 = SCREEN_H/2 + y_size * scale_factor_current;
 al_draw_rectangle(hx1, hy1, hx2, hy2, palette_color[10], 2);
 #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...

no-reply@allegro.cc (Frank Drebin) — Tue, 14 Aug 2018 02:41:04 +0000

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.

no-reply@allegro.cc (Edgar Reynaldo) — Tue, 14 Aug 2018 03:00:40 +0000

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.

Michael Weiss said:

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

matthew@allegro.cc