Goplanes

[djcouchycouch]

*********** EDIT: January 4th, 2013 ***************

A bit of unfortunate news.

I'm stopping all development for this project. Art and videos will also be taken down.

I wish and hope to revisit this project again, but won't be happening any time soon.

Thanks for watching,
DJCC.


***********

Hi,

The forum's been so helpful, I figured it might be a good idea to show off what I've been working on these past few weeks. It's pretty modest, but it's better than nothing!

http://www.youtube.com/watch?v=0yYn-VjaG_M

It's another on a long line of remakes/conversions of a game I made a long time ago, called Goplanes. Here's a page on the original version: http://www.xbattlestation.com/2DFS/game ... d=goplanes

Thanks!
DJCC

[Shiru]

Good start.

The tearing is probably because you see scroll offsets too late. You need to organize the code in a way that you only do VRAM/VDP parameters updates at VBlank time, and everything else, including preparation of the data for the updates in remaining time.

Like:

Wait for vblank

Set scroll
Set palette
DMA precalculated sprites list
DMA/update precalculated data for tilemaps

Update sound
Poll controller
Calculate game state
Prepare sprites list, data for tilemaps

Loop

[djcouchycouch]

Thanks Shiru, those suggestions helped a lot!

Scrolling is much, much smoother now, as you can see from my latest update:

http://www.youtube.com/watch?v=RWLPk1tap8M

[Stef]

Great work
Your parallax scrolling looks really nice and smooth, very nice start indeed

[TmEE co.(TM)]

Hey this is really lovely

[ammianus]

Very cool. Now my effort looks much more modest. I haven't even got to scrolling yet.

[djcouchycouch]

Very cool. Now my effort looks much more modest. I haven't even got to scrolling yet.

Don't worry about it! Just do a little bit every day, no matter how much, and soon enough you'll be surprised how much you'll have done.

[Moon-Watcher]

Looks very nice, do you have a roadmap or something?

[djcouchycouch]

Looks very nice, do you have a roadmap or something?

My current plan is to get something similar to the original Goplanes version up and running. Just that will take me a while to do. Then I'll see how it goes. At the very least, I'll have some kind of engine to work with in case I want to do something else.

[djcouchycouch]

Got some plane-to-tile collisions working! It certainly took me a while and a few tries to get exactly what I wanted.

http://www.youtube.com/watch?v=m1x2hYsK62Q

From the description:

Finally got plane-to-tile collisions to work. Spent the past two weeks thinking of and trying various schemes for tile-exact collisions without being too stupid slow.

First scheme was to detect whether there was a tile at the Goplane's current position + speed. If a solid tile is detected, do line-line intersects with the tile edges the Goplane potentially touched. (no more than 2 at a time, so it wasn't that bad). The intersection would be where the plane would bounce of from. But it didn't work because the player speed could potentially be greater than the tile width, making the Goplane "skip" tiles and going through them. Plus another corner case that was super annoying made me drop this scheme.

The second scheme was the first thing I had thought of, but dismissed as being potentially too slow. Instead of detecting a single position ahead of the plane, I cast a ray from the player to the its next position using the Bresenham line algorithm. If a solid tile is detected, then use the position previous to the detection of the collision.

Spent an afternoon benchmarking probably a dozen different C-language implementations of Bresenham's line algorithm and various tweaks to find the fastest one. Moral of the story: ever take a guy's claim of "fastest line algorithm evar" at face value.

Also, before the plane was using a virtual coordinate system of 128 points for every pixel. This made casting a ray very, very expensive (length of pixel ray * 128). The virtual coordinate system is used to smooth out the plane's motion across pixels, especially when flying at the angles it does. I simplified the virtual coordinate system to be 2 points for every pixel and the results are still pretty darn good. So casting a ray is much faster.

The white square ahead of the plane indicates the plane's angle and whether the plane is colliding with a tile.

The collision method is still kinda expensive, but in my current plans, only the Goplane will collide with tiles this way. Other objects will have much simpler collision detection.

Next step is to make the plane bounce off surfaces.

[Shiru]

If you use large steps, larger than an object or wall thickness, you still can use simple collision detection - just move the object in few iterations by smaller steps.

Judging by the video, it is the exact same thing as wall clipping in a tilemap based Wolfenstein 3D like game - it certainly could be done without any line/line or other complex collision calculations.

[djcouchycouch]

I need the exact pixel where the plane collides with the tile for when it bounces off. If I use fewer steps, the plane might find itself too deep into the tile and get stuck when it tries to bounce back. I could do something where I do simpler detections going forward, but then if I collide with a tile, I go backwards from the collision point to find the exact pixel where it should touch. But I'm not going to worry about that for the moment.

[djcouchycouch]

Got wall bouncing to work. Yay.

http://www.youtube.com/watch?v=wtiiEJC0mBM

[sega16]

Wow very nice! I can't wait to see the finished game!

[Stef]

So do i, very nice progress

By the way, about fast Bresenham line C implementation, you can actually check in the bmp.c source of the library.
I needed line drawing method and tried to get a "not too bad" C code (i compared generated assembly code) :

Code: Select all

static void drawLine(u16 offset, s16 dx, s16 dy, s16 step_x, s16 step_y, u8 col)
{
    const u8 c = col;
    u8 *dst = &bmp_buffer_write[offset];
    s16 delta = dx >> 1;
    s16 cnt = dx + 1;

    while(cnt--)
    {
        // write pixel
        *dst = c;

        // adjust offset
        dst += step_x;
        if ((delta -= dy) < 0)
        {
            dst += step_y;
            delta += dx;
        }
    }
}

This is the internal drawLine function but you have the complete method in bmp.c