27 replies to this topic

[jum]

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.

Attached Files

•  booster_03.zip   6.79K   136 downloads

Edited by jum, Mon Dec 5, 2005 6:57 AM.

[Zeptari1]

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

[jum]

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.

[Zeptari1]

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

[Heaven/TQA]

i would like to see the source code... (if it's written in asssembler...) any chance?

[jum]

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, Mon Nov 28, 2005 3:49 AM.

[TailChao]

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.

[jum]

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.

[sage]

jum, on Wed Oct 26, 2005 10:33 AM, said:

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

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

[jum]

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

Thanks

- Jum

[TailChao]

jum, on Thu Oct 27, 2005 7:30 AM, said:

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

Thanks

- Jum

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.

[T2KFREEKER]

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.

[jum]

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

- jum

[Lamer Deluxe tm]

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.

[jum]

Lamer Deluxe tm, on Sat Nov 5, 2005 6:12 AM, said:

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.

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

[Lamer Deluxe tm]

jum, on Sun Nov 6, 2005 9:04 AM, said:

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

[sage]

jum, on Thu Oct 27, 2005 11:30 AM, said:

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

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

[jum]

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?

[_cooper_]

Interesting Techdemo Jum, i'm looking forward to see the further versions!

[jum]

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

[sage]

jum, on Wed Nov 9, 2005 7:51 AM, said:

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?

Yes I have, but it is completly in assembler.

[jum]

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, Fri Nov 25, 2005 1:06 AM.

[sage]

jum, on Fri Nov 25, 2005 5:58 AM, said:

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.

[jum]

Uploaded another new version. See first post.

- jum

[Lamer Deluxe tm]

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.