Jump to content
  • entries
    106
  • comments
    796
  • views
    139,607

GTD: IV

Sign in to follow this  
Guest

1,110 views

GTD STANDS FOR Goofy Tech Demo, by the way. :D

 

So I wasn't real satisfied with the way things looked yesterday; so I decided to give up using the sprites for the player's bullets, and use the missiles instead. This means no crazy weird shapes/colors for bullets, plus it also means no background starfield. :(

 

But, you can actually see your bullets, which I think is a little bit more important. Plus I figure I can use sprites for special weapons that move slower and might be easier to see. So, changes:

 

-Using M0 and M1 for player bullets, each flickered at 30 Hz (when necessary) for 4 bullets on screen at once. To my surprise, happily, four bullets, at the speed they are moving, is plenty to fill the screen.

-Collisions between bullets and enemies are working, though sometimes bullets appear to pass through enemies. I think it is sometimes because I need to jigger the horizontal comparison between bullet and enemy and sometimes it is because the bullets are moving 4-pixels at a time and possibly jump right over enemies without ever hitting them.

-Collisions between the player's ship and enemies are working; currently it just kills the enemies.

-Sometimes the screen jumps a bit; I assume because the collision detection routine takes too long.

 

ss.bin

Screenshot:

blog-6060-1138919359_thumb.png

Sign in to follow this  


12 Comments


Recommended Comments

Or Galaga, at the very least. Or... this would work really well for some of the waves in Juno First, too.

 

Nice demo, Bob!

Share this comment


Link to comment

Last night I realized why sometimes bullets passed through enemy ships - because I was only checking bullet-to-enemy collisions every other frame.

 

Since bullets moved every frame, that caused some problems.

 

So, new problem:

Checking bullet collisions every frame takes too long with 4 bullets and 16 sprites. It fits with 12 sprites, but 12 seems...too few. Especially since 2 are taken up by the player sprite. Maybe it's ok, though.

 

So I can check bullet collisions every other frame and accept that bullets will pass through enemies or I can reduce the number of bullets or sprites (or both).

 

Not sure what to do here. Not really sure I want to take this any further, actually.

Share this comment


Link to comment
Last night I realized why sometimes bullets passed through enemy ships - because I was only checking bullet-to-enemy collisions every other frame.

 

Since bullets moved every frame, that caused some problems.

 

So, new problem:

Checking bullet collisions every frame takes too long with 4 bullets and 16 sprites.  It fits with 12 sprites, but 12 seems...too few.  Especially since 2 are taken up by the player sprite.  Maybe it's ok, though.

 

So I can check bullet collisions every other frame and accept that bullets will pass through enemies or I can reduce the number of bullets or sprites (or both).

 

Not sure what to do here.  Not really sure I want to take this any further, actually.

 

If you decide not to take it any further, it'd be nice to see the source on [stella]!

Share this comment


Link to comment
If you decide not to take it any further, it'd be nice to see the soruce on [stella]!

Ehhhh. It's so freaking ugly. We'll see.

Share this comment


Link to comment
If you decide not to take it any further, it'd be nice to see the soruce on [stella]!

Ehhhh. It's so freaking ugly. We'll see.

 

Heh. I have a few projects like that.

 

Too bad there's no cheap way to do Superchip games, since an extra 128 bytes would probably be very useful here.

 

For a game like Satan's Hollow, I find myself thinking that what's needed might be a way of combining RAM and ROM display lists. Many of the monsters in that game move in fixed patterns, so it might not be necessary to hold all their positions in RAM. The difficulty would be overlapping the ROM-based movements and RAM-based ones. The closest thing I can think of to practical for doing that would be to have 30Hz flicker between the formation-flying birds and the other birds. The formation birds would use NUSIZx as appropriate (some clever adjustment of the formations would be necessary to make this workable) and the diving birds would have their motion rules set up so that at most two were on a scan line (probably by using rules similar to Commie Mutants).

 

Some interesting possibilities, but perhaps too tricky.

Share this comment


Link to comment
Too bad there's no cheap way to do Superchip games, since an extra 128 bytes would probably be very useful here.

Wouldn't cannibalizing common SC games work?

Share this comment


Link to comment
Wouldn't cannibalizing common SC games work?

 

Awfully labor intensive. The parts budget for my 4A50 cart is quite reasonable; it's assembly labor that's the killer (unless you know somebody with nothing better to do who'd like to assemble them for free). Unsoldering the SuperChips from Dig Dug carts without damaging them and then re-soldering them into other boards seems like it would be rather time consuming.

Share this comment


Link to comment
Guest
Add a comment...

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