AI driving simulation

README.md

Moved to skeeto/scratch/aidrivers

Thanks for the detailed ffmpeg example, @Nioub!

I am currently trying to reimplement this in rust for practice. Are you aware that the loop.png is not fully black and white? It has 2 (neighbouring) pixels in other colors:

Unexpected colored pixel at 157, 257: Rgba([0, 255, 0, 255])
Unexpected colored pixel at 158, 257: Rgba([0, 0, 255, 255])

@Kaligule, yup, that's the starting position (green) and starting direction (blue). See "input image format" in the source file header.

Ahh, I didn't read that part. Thanks.

@skeeto thanks for this great little project! I've been trying to study it by slowly porting it to Swift and I'm stuck with the innermost loop in draw_vehicles:

static void
draw_vehicles(struct ppm *f, struct map *m, struct vehicle *v, int n)
{
    int s = f->w / m->w;
    for (...) {
        for (...) {
            for (int j = -s/2; j < s/2; j++) {
                ...
            }
        }
    }
}

The loop variable j is initialized to -s/2 and the loop condition is j < s/2. But isn't s is going to be 1 in most cases? Since the map is initialized from the ppm file and it's width and height are set to be the same. In that case -s/2 and s/2 are both zero and the loop doesn't do any iterations.

@hashemi I am not the author, but I think I know what is going on here.

the dimensions are not the same

First thing to notice is that the loop and loopoverlay are do not have the same dimensions at all:

loopoverlay.png: 1920px × 1080px
loop.png: 480px × 270px

So s (probably short for scale) is actually 4 in this example.

magic numbers

In the two inner loops there are hidden two magic numbers:

        for (int d = -s*2; d < s*2; d++) {
            for (int j = -s/2; j < s/2; j++) {
                ...
            }
        }

is equivalent to :

        int vehicle_length = 4 * s;
        int vehicle_width =   1 * s;
        for (int d = -1/2 * vehicle_length; d < +1/2 * vehicle_length; d++) {
            for (int j = -1/2 * vehicle_width; j < -1/2 * vehicle_width; j++) {
                ...
            }
        }

So actually these numbers in the loop determine how the vehicle is drawn. And as the vehicles in the blogpost are really thin, you are right in that this loop will not be that big.

Does that help you?

Thanks @Kaligule! I'd figured that s likely means scale but didn't realize that the map and final PPM had different dimensions, that clarifies why the code works on the given example.

I guess the code only works correctly if s (scale between map and final ppm) was 2 or more, otherwise vehicles won't get drawn.

Have you considered publishing your rust implementation? I'd love to read it to see how you decided to organize your code. I'm trying to stay as close to C at first but have plans for reorganizing it to be more idiomatic Swift.

@hashemi I am a bit hesitant to publish it, because it is a learning project - I am still new to rust and this code is not much prettier then the original (though I gave my best when naming the variables). But I guess there is no shame in learning and not being perfekt. I'd be glad to hear feedback.

Here is the repo.

@hashemi I just added the scaling to my implementation (I had just not used the overlay until now, instead I drew onto the collision map). It was interesting and I definitelly had to iterate over it multiple times.

My bigest realization was that it is not enough to just adjust the position of every car pixel. That would spread out the cars pixels over a bigger area, making it less dense. The scale really has to get into the car length and car width before you iteratate over them.

Your problem persists, of course. I decided to make the cars thicker in my simulation, so this is not as big of an issue anymore.

I realized if you don't specify an overlay image file, the code will just create a blank PPM file that is 12 times larger than the map.

In case someone is interested, I just made my Swift port public.