Sixty frames = one simulated year.

Changed the mechanics a bit. Added more color information.
Green - too young
Grey - too old
Pink - female
Blue - male
Solid Pink - take a guess

Things that affect the outcome.
Population density - the larger the starting population the more likely the simulation will sustain
Size of the circles - the larger they are the more plentiful will be the collisions
CONST min - The lower the more fruitful the society will be
CONST maxm - The higher "
CONST maxf - The higher "

The goal is to achieve simulation sustainability without too explosive growth and with not too many failures.

DISCLAIMER ABOUT THE CURRENT SETTINGS
It is just a numbers game. The settings are restricted to what is commonly possible. They are not 100% realistic. It is not meant to be politically correct. So just consider these settings being for a primitive society without written laws or moral standards.

The morally correct may want to increase the circle size and increase the minimum age! Etc.

When I want to code something in basic like I would in C I have to stop what I am doing, research if basic has an equivalent, understand the syntax, learn the syntax, remember the syntax and then try to make it work. In C I just know how.

For example, when generating a capture en passant move one could simply use an IF statement like so for white:

IF to_square = ep_square then
target_square = to_square - 10 ' on a 12x10 board
ELSE
target_square = to_square
END IF
target = board(target_square)

In C one can do it like above or like this:

target_square = ts ^ ((en_passant_bit == 1 << ts) << 3);
target = board[target_square];

This uses unsigned 64 bit integers. It takes advantage of the fact that bit 4 is set for all the possible en passant squares. It works by computing the truth value of (en_passant_bit == 1 << ts) which yields a 0 or 1. Then it left shifts the 0 or 1 into bit 4 which results in either 0 or 8 that is then exclusive_ored with the 4th bit of the to_square .

This might be able to be done in basic but without doing a lot of work and experiencing much aggravation and spending a lot of time researching I just do not know if it can be.

 
   

If the cases are a sequence of numbers, 0, 1, 2, ...., n, then for the application in question, how large would n be?
Would each case have it's own sub, or would some cases share the same sub?
I am thinking of some sort of binary search could be implemented, rather than linearly starting at 0 and testing for a match with each possible integer up to n.

Steve clued me in on the right alternative in another thread, ON GOTO/GOSUB.

You could get there with 12 IF statements, if you were a complete beginner at data interpretation.  Simply by breaking those statements into binary values, you easily reduce the maximum number of comparisons down to 4.

IF X < 7 THEN '1 TO 6
   IF X < 4 THEN '1 TO 3
      IF X < 3 THEN 'IT'S 1 OR 2
           IF X < 2 THEN 'IT'S 1   ELSE 'IT'S 2
     ELSE 'IT'S 3
     END IF
   ELSE 'IT'S 4 TO 6
        'AS ABOVE
   END IF
ELSE 'IT'S 7 TO 12
     'AS ABOVE
END IF

A maximum of 4 comparisons for up to 16 items...  It's not quite as fast as 1 to 1 jump tables, but it's not bad overall.

---

Remember, you can always fall back on the old ON... GOTO... statements also.

ON X GOTO 100, 200, 300, 400, 500, 600, 700, 800, 900, 1000, 1100, 1200

I think those tend to be 1 to 1 jump style lists.

Yes, of course hand crafted If blocks can be optimised. In my code though I'm using SELECT CASE because I just assumed that QB64 would write an equivalent C switch statement. I'm new to QB variant basic. The ON...GOTO statement might be the answer. I'll check it out. Thanks!

No problem mixing your languages, of course. But this:

Did you try using the select case block you proposed in the first post of the thread you started about SELECT CASE? Did you actually compile it and run it just to make sure it would work as slow as you expect or are you assuming it will be so slow without trying first?

Move generation, captures only generation, make move and unmake move all benefit greatly from jump tables. There are 12 cases just for the pawn. We can get to the correct pawn code by one jump that is not conditional or we can get there by IF IF IF IF IF IF IF IF IF IF IF IF until we find the correct one. The problem in chess is it is constantly in flux and predicting the outcome of any if statement tends toward 50/50 and false branch predictions drags down performance tremendously. If ones goal was to write a correct but intolerably slow chess engine then it does not matter. But in this tutorial my code does not make sense because it is counter productive to the goal of writing a fast chess engine. If statements are just not good for performance in a chess engine.

It's BASIC. If constructs from other languages get thrown in then it's not BASIC any longer.

But but but a jump table can be created from a SELECT CASE construct without the basic coder even being aware. There would be absolutely no change to the basic language itself. Sorry if I was unclear about that.

You can check the c++ result by opening internal/temp/main.txt after the IDE gives you an OK in the status bar.

And no, the answer is no.

A select case block is a glorified (and very convenient) long IF block.

Thanks for the answer. That is very sad for performance. My chess program is going to run really slow. With a few performance enhancements QB64 could become a serious production language. That is a shame that it is not because I really like the Basic syntax.

Let me try to explain the move generator a little better then. Using lots of IF statements in a chess engine is a performance killer. I avoid IF statements whenever possible. In C there are two choices. A switch (SELECT CASE) statement and an array of function pointers. These days I'd use the function pointers which is called a jump table. C/C++ compilers can make jump tables out of switch statements but it is hit and miss. C/C++ compilers can also substitute IF statement for switch cases if there are not enough cases. That is why I'd use function pointer arrays to take all decisions away from the compiler. As far as I know I do not have that choice in QB64? So all I can do in QB64 is use the theoretically best approach and hope that QB64 and Mingw64 do a good job. With that said let's look at the code.

There is an array of 40 type piece. The piece[0].nxt holds the first white piece and piece[20].nxt holds the first black piece. And start_index(wtm) gives either 0 or 20.
Therefore we get the first piece like so: piece_index = next_piece(start_index(wtm)).
Okay, I see that I changed the data and did not change the code, oops. So make that: 
piece_index = piece(start_index(wtm)).nxt. I'm really sorry about that, too many senior moments. Anyway, now that we have the first piece we can find its from square: from_square = piece(piece_index).squ. When we are done with the piece we get the next piece at the end of the main loop like this: piece_index = piece(piece_index).nxt. And I have not added that yet, another oops. So yes, it would be hard to understand in such an incomplete state, my bad :(. Now that we have the from square, we look up the type of piece it is. Did I mention that on the chessboard are indexes, not piece types. That is why we have to use the piece index to look up its type: SELECT CASE piece(piece_index).typ. The pawns will take more study. Essentially they are treated as 12 different types depending on which square they are on. For example X2R is a white pawn on rank 2 or a black pawn on rank 7 on file 1 and therefore they need not check for a left capture thus the X. A white pawn on rank 2 away from an edge file is L2R. And the 2 means it can move one or two squares. This is all done to avoid a plethora of IF statements. Also, why make checks that can be avoided all at the cost of one SELECT CASE statement. In the pawn cases 2 is double move, 1 is single, E is check for en passant and P is promotion.

The knights are much more simple. The knight moves can be done in a loop executed 8 times. However, it is faster to "unroll the loop" and repeat the code 8 times.

            CASE WN
                to_square = from_square + 8 'one up and two to the left
                target = chess_board(to_square) 'EMPTY, piece_index or off-edge square
                action = white_target(target) 'exactly the action to take
                SELECT CASE action
                    CASE EMPTY_SQUARE
                        Record_Move from_square, to_square
                    CASE FRIENDLY_PIECE
                    CASE ENEMY_PIECE
                        Record_Capture from_square, to_square, target
                    CASE OFF_BOARD
                END SELECT 'on to the next offset

The sliders are more fun! Once again we unroll the outer loop.

            CASE WB
                to_square = from_square + 9 'prime first to square, up and to the left
                DO
                    target = chess_board(to_square) same as for knight
                    action = white_targets(target)
                    SELECT CASE action
                        CASE EMPTY_SQUARE
                            Record_Move from_square, to_square
                            to_square = to_square + 9 'This time we are in a do loop, next t_s
                        CASE FRIENDLY_PIECE
                            EXIT DO 'we exit the loop when we can't go further
                        CASE ENEMY_PIECE
                            Record_Capture from_square, to_square, target
                            EXIT DO
                        CASE OFF_BOARD
                            EXIT DO
                    END SELECT
                LOOP

More will become clear. For example the various record move subs will not return right away. They will call the capture only search to resolve captures and add a score to each move. This must be done at the leafs of the tree anyway and doing it for every move in the tree cost very little and has huge benefits. The first is that in the gen all moves routine there is no ENEMY_KING case because only legal moves are generated as the capture search will catch any illegal move and not record it. And having a score for move ordering is huge because the alpha-beta routine performs more spectacularly the better the move ordering is. The end result is that there will be a legal (as opposed to pseudo legal) list of moves that we can do a one pass sort to find the move with the best score to try first. And if it is the best move a huge amount of the search tree will be beta pruned.

I hope this helps. :))