Jump to content
jum

gravitar physics techdemo

Recommended Posts

here's a preview of a gravitar or spout type game I'm messing with.

 

press X to thrust.

 

any gameplay ideas welcome.

 

- jum

 

Updated 2005-10-07: uploaded a new version (james1.zip). See what u think.

Updated 2005-11-24: another new version which uses scrolling bg sprite to make a much larger "cave"

Updated 2005-12-05: updated wip version with tilemapped bg sprite and animated ufo.

booster_03.zip

Edited by jum

Share this post


Link to post
Share on other sites

I get a circle array of dots that fall and then a red line at the bottom of the screen. I don't think Handy like's your game demo too much. I'll mess around with it some more...

Share this post


Link to post
Share on other sites

it's just a quick experiment with vertical scrolling, vector rotation, particles and gravity physics.

 

the triangular player ship is represented by dots at it's 3 corner points.

 

thrust as soon as it starts.

Share this post


Link to post
Share on other sites

OK, I get it now.....

 

So is this a start of a Gravitar clone? I played that game almost every day on my way to school at a local mom and pop store. I also have it for the 2600.... great little game...

 

anyways looks like your of to a great start....

 

-Rick

Share this post


Link to post
Share on other sites

The source code is in (low-level) C. If you want it email me: <removed>

 

I was thinking of combining a gravitar-type game with "spout" (ie: no fire button, you use your thrust jet to destroy enemies).

 

Also I'm undecided on whether to implement using vector gfx (raw lines and dots) as it is now, or whether to use sprites.

 

Yeah the 2600 gravitar is impressive.

 

- jum

Edited by jum

Share this post


Link to post
Share on other sites

Very nice, a tad laggy but nice. Might I suggest though, that you move the display window to scroll instead of using a massive 160x306 rendered buffer and relocating the read position? It would be much more RAM, and speed, efficient.

Share this post


Link to post
Share on other sites

I need the 160x306 buffer because (like spout), I want to be able to blast the walls/landscape with the thrust blast.

 

I've locked the framerate to 20fps now. It's maybe a bit sluggish, but at least it doesn't slow down and speed up all the time. I'll post a new version soon.

Share this post


Link to post
Share on other sites
I need the 160x306 buffer because (like spout), I want to be able to blast the walls/landscape with the thrust blast.

954570[/snapback]

 

One more reason to use a sprite instead of the render buffer.

Share this post


Link to post
Share on other sites

Please explain how to implement "deformable terrain" using sprites.

 

Thanks

 

- Jum

Share this post


Link to post
Share on other sites
Please explain how to implement "deformable terrain" using sprites.

 

Thanks

 

- Jum

955175[/snapback]

You could set up a simple tile engine (8x8 blocks perhaps) With each tile having say, 4 modes (blank, semi deformed, deformed, nonexistant) and draw the screen like that, you would get a massive speed boost.

Share this post


Link to post
Share on other sites
:P Cool little demo. I think it would be a cool little Lynx game when finished. It is at least the kind of game you want to play on a hand held. I'll keep checking to see what the progress is. :D

Share this post


Link to post
Share on other sites

Uploaded a new version of the demo. See the first post.

 

- jum

Share this post


Link to post
Share on other sites

Very nice, keep on going, this could become a really cool game.

 

You are using a lot of memory with the large buffer, but with this you are saving on screen redraw, which leaves you extra system power to do neat effects with.

 

You could speed up getpixel and setpixel by using a multiplication table (y*80) instead of the <<6 and <<4 you're using now.

 

calc_ship_verts could be sped up by not using generic sin and cos tables but premultiplying them to give the right distance from the center of the ship.

 

I see you are already using mean(?) (point1+point2)/2 values to create extra interpolation points with little calculation cost. You could also interpolate from the bottom two points to the center of the ship, for a nice spaceship shape.

 

Programming the Lynx in C looks nice BTW, I've been using ASM, which is fast but cumbersome.

 

Your game is inspiring to look at.

Share this post


Link to post
Share on other sites
Very nice, keep on going, this could become a really cool game.

 

You are using a lot of memory with the large buffer, but with this you are saving on screen redraw, which leaves you extra system power to do neat effects with.

 

You could speed up getpixel and setpixel by using a multiplication table (y*80) instead of the <<6 and <<4 you're using now.

 

calc_ship_verts could be sped up by not using generic sin and cos tables but premultiplying them to give the right distance from the center of the ship.

 

I see you are already using mean(?) (point1+point2)/2 values to create extra interpolation points with little calculation cost.  You could also interpolate from the bottom two points to the center of the ship, for a nice spaceship shape.

 

Programming the Lynx in C looks nice BTW, I've been using ASM, which is fast but cumbersome.

 

Your game is inspiring to look at.

960560[/snapback]

 

Thanks for your input man.

 

I'm not concentrating on optimising right now (rather get some good gameplay first), but if you would like to write a fast ship-drawing routine in asm, please do, and I will integrate it into the source code.

 

I can only work out the correct "scaling" of the sin/cos tables once I've figured out whether I need to use 8:8 fixed point or 10:6 or whatever. Also I'm going to cut the sin/cos tables from 256 values to 64 values.

 

- jum

Share this post


Link to post
Share on other sites
Thanks for your input man.

 

I'm not concentrating on optimising right now (rather get some good gameplay first), but if you would like to write a fast ship-drawing routine in asm, please do, and I will integrate it into the source code.

 

I can only work out the correct "scaling" of the sin/cos tables once I've figured out whether I need to use 8:8 fixed point or 10:6 or whatever. Also I'm going to cut the sin/cos tables from 256 values to 64 values.

 

- jum

 

8:8 would probably be faster, but positioning within the large display buffer would be more complicated.

 

I'm not used to doing asm combined with C in CC65, but I'll see if I can mess around with it a little bit :)

Share this post


Link to post
Share on other sites
Please explain how to implement "deformable terrain" using sprites.

955175[/snapback]

 

Use unpacked sprites, use "getpixel" and "setpixel" on them instead of the screen memory.

1 bitplane should be enough for b/w terrain.

 

This is how I do it for my tron clone (which is still somewhere floating around in the net).

Share this post


Link to post
Share on other sites

I used the "setpixel/getpixel on unpacked sprite" in my ChopperX game, for the scrolling terrain (320x50 sprite).

 

I was trying to avoid losing cycles to large sprites, but on the other hand a 300x300 "virtual background" would suit this game better.

 

Do you still have the source code to your Tron game?

Share this post


Link to post
Share on other sites

update: I have now switched to using a 320x512 1 bitplane unpacked sprite for the background, and have made setpixel and getpixel routines that read and write to the sprite.

 

now busy with creating 32 animation frames for the ship rotation. also need to speed up the setpixel/getpixel routines.

 

- jum

Share this post


Link to post
Share on other sites
I used the "setpixel/getpixel on unpacked sprite" in my ChopperX game, for the scrolling terrain (320x50 sprite).

 

I was trying to avoid losing cycles to large sprites, but on the other hand a 300x300 "virtual background" would suit this game better.

 

Do you still have the source code to your Tron game?

962626[/snapback]

 

Yes I have, but it is completly in assembler.

Share this post


Link to post
Share on other sites

see new version at beginning of thread.

 

sage: I can do assembler if I have to. Please email or post your asm source for putpixel.

 

thanks.

 

- jum

 

ps: I have since done the 32 sprites for the ship rotation (actually, 8 sprites that are flipped horizontally or vertically as needed (thank you Lynx designers :) ).

Edited by jum

Share this post


Link to post
Share on other sites
see new version at beginning of thread.

 

sage: I can do assembler if I have to. Please email or post your asm source for putpixel.

 

 

I am not sure if it will help you, because i was using 4 plane background (8 lightcycles -> 8 colors+background color) and a fixed sprite width.

But anyway i will send you part of the code. maybe you want to do a color version, too.

Share this post


Link to post
Share on other sites

Wow, great improvements! The ship controls very nicely. The deformable landscape works really well and is a very cool effect. The anti-aliasing on the ship is a nice touch.

 

I'm looking forward to seeing this turn into a real game. It's very interesting to be able to follow it's progress.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...