Jump to content
IGNORED

gravitar physics techdemo


jum

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
Link to comment
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

Link to comment
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
Link to comment
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.

Link to comment
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.

Link to comment
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.

Link to comment
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

Link to comment
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 :)

Link to comment
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).

Link to comment
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?

Link to comment
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

Link to comment
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.

Link to comment
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
Link to comment
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.

Link to comment
Share on other sites

  • 2 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

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