Page 1 of 13


Posted: Mon Mar 19, 2012 12:54 am
by 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,



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! :)

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: ... d=goplanes


Posted: Mon Mar 19, 2012 3:09 am
by 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.


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


Posted: Thu Mar 22, 2012 2:08 am
by djcouchycouch
Thanks Shiru, those suggestions helped a lot!

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

Posted: Thu Mar 22, 2012 8:49 am
by Stef
Great work :)
Your parallax scrolling looks really nice and smooth, very nice start indeed :)

Posted: Thu Mar 22, 2012 6:17 pm
by TmEE co.(TM)
Hey this is really lovely :D

Posted: Tue Apr 03, 2012 1:43 am
by ammianus
Very cool. Now my effort looks much more modest. I haven't even got to scrolling yet.

Posted: Tue Apr 03, 2012 2:20 am
by djcouchycouch
ammianus wrote: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.

Posted: Tue Apr 03, 2012 7:52 am
by Moon-Watcher
Looks very nice, do you have a roadmap or something?

Posted: Tue Apr 03, 2012 11:17 am
by djcouchycouch
Moon-Watcher wrote: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.

Posted: Sun Apr 08, 2012 2:14 am
by djcouchycouch
Got some plane-to-tile collisions working! It certainly took me a while and a few tries to get exactly what I wanted.

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.

Posted: Sun Apr 08, 2012 2:30 am
by 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.

Posted: Sun Apr 08, 2012 2:38 am
by 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.

Posted: Sun Apr 08, 2012 7:37 pm
by djcouchycouch
Got wall bouncing to work. Yay.

Posted: Sun Apr 08, 2012 8:12 pm
by sega16
Wow very nice! I can't wait to see the finished game!

Posted: Sun Apr 08, 2012 8:30 pm
by 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;

        // 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