Goplanes
Moderator: Mask of Destiny
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
Goplanes
*********** 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
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
Last edited by djcouchycouch on Fri Jan 04, 2013 8:30 pm, edited 1 time in total.
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
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
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
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
Scrolling is much, much smoother now, as you can see from my latest update:
http://www.youtube.com/watch?v=RWLPk1tap8M
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
Hey this is really lovely
Mida sa loed ? Nagunii aru ei saa
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
-
- Very interested
- Posts: 117
- Joined: Sun Jan 02, 2011 9:14 pm
- Contact:
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
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.Moon-Watcher wrote:Looks very nice, do you have a roadmap or something?
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
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.
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.
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.
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.
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
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.
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
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) :
This is the internal drawLine function but you have the complete method in bmp.c
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;
}
}
}
Last edited by Stef on Tue Apr 10, 2012 8:22 pm, edited 1 time in total.