Jump to content

Photo

Deep Zone Gorf

homebrew Gorf Tempest

214 replies to this topic

#1 artrag OFFLINE  

artrag

    Dragonstomper

  • 652 posts

Posted Sat Sep 26, 2015 10:42 AM

Here you can find the last update of a test game born to test intybasic and overgrow out of control 
 
update:
 
 
6 kinds of enemies:
 
1 spinning left
2 spinning right
3 linear at random position
4 linear close main ship position
5 zig zag
6 homing (now slower than the main ship)
 
Features:
- Speed tuning, variable speeds for warp, enemies and ship
- Level increases after you pass the 6th enemy type (shown in the  top right corner, in yellow)
- You pass to a new swarm after that 5 enemies of a given type have been killed
- Support for score and lives
- Gyrus controls on 16 directions
- Game over sequence
- New animation for the space warp
- Slowed bullets from main ship
- New  music (2 channel chords courtesy of First Spear)
- Game over music (courtesy of First Spear)
- Bosses appear after each 6 waves (no interaction ATM, press buttons to cycle them all and enter to skip the boss phase)
- New title screen
- Added 5 sfx and 5 voice samples in the test screen (ECS needed)
 
Now compiled with IntyBasic v1.2.8
 

Attached Files


Edited by artrag, Mon Oct 31, 2016 12:36 AM.


#2 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 9,790 posts
  • Triple-Stripe Mo' Bro
  • Location:NC, USA

Posted Sat Sep 26, 2015 10:45 AM

Cool! Thanks for sharing this, artrag. :)



#3 artrag OFFLINE  

artrag

    Dragonstomper

  • Topic Starter
  • 652 posts

Posted Sat Sep 26, 2015 11:14 AM

The space warp can improve using Gram

I'll think something better



#4 Kiwi ONLINE  

Kiwi

    Stargunner

  • 1,345 posts

Posted Sat Sep 26, 2015 2:08 PM

Suggestions on enemy types.  You could have enemies that homes in your current position.  One that stays in their lane and fires at your position.  A slow homing missile that have to be dodge.  A meteorite that cannot be destroy, blocks your shot.

Boss type, could stay in the middle of the screen surrounded by a shield.  The shield demonish every time your shot hits it in a specific position. 

Something like this,
sample.gif

Shield graphic can be change by uploading graphic to it gram's cell. 



#5 artrag OFFLINE  

artrag

    Dragonstomper

  • Topic Starter
  • 652 posts

Posted Sun Sep 27, 2015 1:16 AM

Now SPR_LIGHTBLUE enemies start on your line and are faster, while SPR_ORANGE are just faster.

Main ship controls have been reverses (the ship starts in the lower part of the screen so it is more intuitive)

 

In order to add other enemies (and change the warp animation with something more consistent) I need to rearrange the frames for zooming enemies in order to remove any redundancy (there are many repeated frames in the small scales).

I think I could gain 6-7 tiles, i.e. the room for an extra alien  (or missile) and if I reuse something (I have 4-5 tiles free ATM), for some stars in the warp animated decently.

 

About endboss, I was thinking something similar (using DZ) ;-)

 

 

 

[edit]

New files in the first post 

I used 4 GRAM tiles to complete the rays in the space warp, the blue dots were distracting and potentially confused with bullets.

Now without removing redundancy I've only one tile free 

 


Edited by artrag, Sun Sep 27, 2015 12:27 PM.


#6 Kiwi ONLINE  

Kiwi

    Stargunner

  • 1,345 posts

Posted Sun Sep 27, 2015 11:31 AM

I've wondered if the your character ship's graphic is all loaded on GRAM.  You could redefine the GRAM card instead of using about 16 cards for a ship.  Should be enough time to redefine after a 'wait' command is called.  If you move your ship and the graphic has to change it can use a flag to activate the redefine function to occur after a wait statement.  You could swap in new alien graphic when they are going to be used in that section of the game.  Or just use specific GRAM card to redefine the alien's graphics.  You could even go 16 pixel high sprites. 

I usually do 32 cards for sprites, and then 32 cards for BGgraphic.



#7 artrag OFFLINE  

artrag

    Dragonstomper

  • Topic Starter
  • 652 posts

Posted Sun Sep 27, 2015 12:00 PM

I've wondered if the your character ship's graphic is all loaded on GRAM.  You could redefine the GRAM card instead of using about 16 cards for a ship.  Should be enough time to redefine after a 'wait' command is called.  If you move your ship and the graphic has to change it can use a flag to activate the redefine function to occur after a wait statement.  You could swap in new alien graphic when they are going to be used in that section of the game.  Or just use specific GRAM card to redefine the alien's graphics.  You could even go 16 pixel high sprites. 

I usually do 32 cards for sprites, and then 32 cards for BGgraphic.

 

The main ship needs 32 frames (it has more frames but on the circle only 32 are shown) so it is already in ROM and update on fly.

Now all enemy animations are in GRAM, each animation has 8 frames (8 scales), so now I use 5*8=40 cards for enemies, 2*8=16 cards for the two frame explosion (reused also for enemy bullets), two tiles for main ship, one for its bullets, 4 for the BG (diagonal rays \ and / non present in GROM).

40+16+2+1+4 = 63

 

The trick to free space is to remove duplicated frames in the animations (seen by far all enemies are almost  a point or a couple of points).

I could gain about 10 frames and fit one or two other enemies.

 

Another option, as you say, is to load on fly definitions for enemies when they are supposed to appear.

 

This is possible as without sprite multiplexing, I cannot have more than 4 enemies on the screen at the same time.

If we admit that the active enemies are all of different kinds, I have room for a 5th enemy in GRAM. 

 

This allows to load the 8*8 = 64 bytes of the next enemy kind over multiple frames, while you are fighting againt the last 4 enemy kinds.

 

Actually what is almost missing now is the logic to control swarms and enemy waves, that should be connected to the way GRAM is updated to allow new enemy graphics.

Probably focusing on this latter strategy leads to better results than packing the current enemy definitions, as in the end I should in any case add logic for enemy waves that keeps track of the game progression

 

 

[edit]

Kiwi I implemented a homing enemy ( try this rom where the blue homing enemy loops) is it close to what you was meaning  ?

 

Attached Files


Edited by artrag, Sun Sep 27, 2015 1:06 PM.


#8 Kiwi ONLINE  

Kiwi

    Stargunner

  • 1,345 posts

Posted Sun Sep 27, 2015 2:16 PM


[edit]

Kiwi I implemented a homing enemy ( try this rom where the blue homing enemy loops) is it close to what you was meaning  ?

 

Yup.  It make it like the enemy is actively trying to destroy your ship.  I think the movement of the ship would be slower around the arc so your ship has the option to evade the enemy and a possibility have your missile hit the enemy as it tries to get into your lane. Later levels, this enemy will be as right now. 

 

 


Another option, as you say, is to load on fly definitions for enemies when they are supposed to appear.

 

This is possible as without sprite multiplexing, I cannot have more than 4 enemies on the screen at the same time.

If we admit that the active enemies are all of different kinds, I have room for a 5th enemy in GRAM. 

I think this would work if the enemy sprite is using a fixed card slot.  Like enemy 0 would use card 2, enemy 7 would be using card 10.  My only concern if the STIC can keep up with redefining the GRAM

Something like
sprite 0,slotx(0)+$300,sloty(0)+$80,(cs(0)*$1000)+$800+16+slotc(0)
sprite 1,slotx(1)+$300,sloty(1)+$80,(cs(1)*$1000)+$800+24+slotc(1)
sprite 2,slotx(2)+$300,sloty(2)+$80,(cs(2)*$1000)+$800+32+slotc(2)
sprite 3,slotx(3)+$300,sloty(3)+$80,(cs(3)*$1000)+$800+40+slotc(3)

 

Then next frame.

 

sprite 0,slotx(4)+$300,sloty(4)+$80,(cs(4)*$1000)+$800+48+slotc(4)
sprite 1,slotx(5)+$300,sloty(5)+$80,(cs(5)*$1000)+$800+56+slotc(5)
sprite 2,slotx(6)+$300,sloty(6)+$80,(cs(6)*$1000)+$800+64+slotc(6)
sprite 3,slotx(7)+$300,sloty(7)+$80,(cs(7)*$1000)+$800+72+slotc(7)

 

Right now, my work in progress game is using...

sprite 0,slotx(0)+$300,sloty(0)+$80,(cs*$1000)+$800+64+slotp(0)

Always single size x. half card height at 16 pixel high.  GRAM card starts at 8, and can reach card 40 if needed.   Turning on the pastel color bit using cs by multiplying. 

KaboomWIP4.gif.gif <-- click to animation. 

Kinda hard to capture multiplexing effectively by using gifcam and the built in jzintv imv.  So you can see that the bomb turned into the water splash object when it is collided with the basket.  Also, turned into explosion object when it reach the bottom. 



#9 artrag OFFLINE  

artrag

    Dragonstomper

  • Topic Starter
  • 652 posts

Posted Sun Sep 27, 2015 3:03 PM

Kiwi, just a question, why do you use sprites for bombs ? You could use cards and avoid flickering. All you need is 7 cards holding the 7 steps of a bomb across two tiles.

Look at Blow Out, the balloons are tiles, you could get the same effect for bombs.



#10 Kiwi ONLINE  

Kiwi

    Stargunner

  • 1,345 posts

Posted Sun Sep 27, 2015 3:19 PM

For hardware collusion with the basket, 16 pixel high bomb sprites instead of 8(there are 9 bomb sprites in the game), easier to spawn bomb from the bomber's position, animation for sprites, and have a background made of a building. 



#11 artrag OFFLINE  

artrag

    Dragonstomper

  • Topic Starter
  • 652 posts

Posted Sun Sep 27, 2015 3:49 PM

Kiwi, I've lowered the angular speed of the blue homing enemies and uploaded all files in the first post (the one with lives).

Let me know if you like it more



#12 Kiwi ONLINE  

Kiwi

    Stargunner

  • 1,345 posts

Posted Sun Sep 27, 2015 4:29 PM

I like it. 



#13 artrag OFFLINE  

artrag

    Dragonstomper

  • Topic Starter
  • 652 posts

Posted Mon Sep 28, 2015 6:51 AM

I will give a try to an alternative control method

#14 artrag OFFLINE  

artrag

    Dragonstomper

  • Topic Starter
  • 652 posts

Posted Mon Sep 28, 2015 3:58 PM

This is with a gyrus like control method

The ship goes where the disk is aiming

 

better this or the previous ?

Attached Files



#15 Kiwi ONLINE  

Kiwi

    Stargunner

  • 1,345 posts

Posted Mon Sep 28, 2015 5:26 PM

Almost,

When you press a direction in Gyruss it goes to that position.  When you let go of the button and the ship didn't reach it designation, the ship stops in it track. 



#16 pimpmaul69 OFFLINE  

pimpmaul69

    River Patroller

  • 4,815 posts
  • INTV Brotherhood Technician
  • Location:Colorado

Posted Mon Sep 28, 2015 8:42 PM

not bad. would be better if it had 16 directions instead of 8.



#17 artrag OFFLINE  

artrag

    Dragonstomper

  • Topic Starter
  • 652 posts

Posted Mon Sep 28, 2015 11:18 PM

Can I read 16 directions in intybasic?

#18 intvnut ONLINE  

intvnut

    River Patroller

  • 2,752 posts
  • Location:@R6 (top of stack)

Posted Mon Sep 28, 2015 11:43 PM

Can I read 16 directions in intybasic?

 

Yes.

 

If you use the lookup table approach I used in the other thread, you just need to include one add'l bit to get all 16 directions.

 

There's an additional bit I call "corner" that gets set in certain diagonal directions.    Here's my crappy diagram I've been using for years as my own personal reference:

intv_pad.png

 

What this diagram says is that

  • Bit 0 gets set for directions SE through WSW
  • Bit 1 gets set for directions NE through SSE
  • Bit 2 gets set for directions NW through ENE
  • Bit 3 gets set for directions SW through NNW
  • Bit 4 gets set for four disjoint spans:
    • SW - SSW
    • SE - ESE
    • NE - NNE
    • NW - WNW

 

Expressed as a table converting controller disc bits to a direction:

.


C L U R D
4 3 2 1 0   Direction

0 0 0 0 0   None
0 0 0 0 1   S
0 0 0 1 0   E
0 0 0 1 1   SSE

0 0 1 0 0   N
0 0 1 0 1   invalid
0 0 1 1 0   ENE
0 0 1 1 1   invalid

0 1 0 0 0   W
0 1 0 0 1   WSW
0 1 0 1 0   invalid
0 1 0 1 1   invalid

0 1 1 0 0   NNW
0 1 1 0 1   invalid
0 1 1 1 0   invalid
0 1 1 1 1   invalid

1 0 0 0 0   invalid
1 0 0 0 1   SSW
1 0 0 1 0   ESE
1 0 0 1 1   SE

1 0 1 0 0   NNE
1 0 1 0 1   invalid
1 0 1 1 0   NE
1 0 1 1 1   invalid

1 1 0 0 0   WNW
1 1 0 0 1   SW
1 1 0 1 0   invalid
1 1 0 1 1   invalid

1 1 1 0 0   NW
1 1 1 0 1   invalid
1 1 1 1 0   invalid
1 1 1 1 1   invalid

.

So, extending the LUT technique I used on the other thread, instead of ANDing with $F, AND with $1F.  And instead of 16 entries you have 32.  I think you can take it from here...

 

Other than that, I don't think IntyBASIC supports 16-direction natively.  nanochess can weigh in to be sure.  I didn't see it in the 'manual.txt', but I only quickly scanned it.


Edited by intvnut, Mon Sep 28, 2015 11:50 PM.


#19 Tarzilla OFFLINE  

Tarzilla

    Stargunner

  • 1,696 posts
  • Location:Alberta, Canada

Posted Mon Sep 28, 2015 11:50 PM

Can I read 16 directions in intybasic?


Look at the bottom of constants.bas the 16 directions are defined

#20 artrag OFFLINE  

artrag

    Dragonstomper

  • Topic Starter
  • 652 posts

Posted Tue Sep 29, 2015 12:34 AM

How odd... the designer of the Inty controllers was severely disturbed...
 
Anyway, this is the 16 direction version with the addition kiwi suggested.
 
How does it work now ?
I cannot fully test it on emulators as I have no idea on how to emulate all the 16 directions from keyboard.
 
[sources updated in the first post]

Attached Files


Edited by artrag, Mon Oct 12, 2015 11:25 AM.


#21 intvnut ONLINE  

intvnut

    River Patroller

  • 2,752 posts
  • Location:@R6 (top of stack)

Posted Tue Sep 29, 2015 12:48 AM

I cannot fully test it on emulators as I have no idea on how to emulate all the 16 directions from keyboard.
 
It is actually possible.  (That's not to say it's easy.)
 
jzIntv maps the following inputs to the disc by default:
.
Fine-grain directional pad inputs:

    U   I   O
      \ | /
       \|/ 
    J --+-- K      Left controller disc
       /|\
      / | \
    N   M   , 
   
    W   E   R
      \ | /
       \|/ 
    S --+-- D      Right controller disc
       /|\
      / | \
    Z   X   C 

.

These mappings give 8 directions to each controller.  To get the 16 directions, press pairs of keys.  For example, [K] gives East, [O] gives Northeast, so [K]+[O] gives East-by-Northeast.

 

You can test this using "handdemo" from SDK-1600, or the hand controller test in MTE-201.

 



#22 Kiwi ONLINE  

Kiwi

    Stargunner

  • 1,345 posts

Posted Tue Sep 29, 2015 12:53 AM

Yes, this is perfect control.  I love it!!!

I just finished putting in control options for Mad Bomber involving the disc controls to attempt to simulates analog controls.  I just used constant.bas as reference to get the hexidecimal numbers from it since I prefer to use numbers instead of typing in the alias.  For example,

CONST DISC_SOUTH_SOUTH_EAST    = $0003

To use this, you can type

if cont=$3 then dothis

 

or

 

if cont=DISC_SOUTH_SOUTH_EAST then dothis

 

Just make sure to correct the alias south west to $0019, and not $0025

If you have an xbox or an analog controller handy, then you can use all 16 directions much easier.  Jzintv default controls for the disc is in the manual.  Press 2 key together fine directions to get the input.



#23 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 9,790 posts
  • Triple-Stripe Mo' Bro
  • Location:NC, USA

Posted Tue Sep 29, 2015 3:21 AM

How odd... the designer of the Inty controllers was severely disturbed...

 
Actually, it's a type of Gray Code encoding, and at that it does its job to prevent ambiguous signal decoding, given the mechanical nature of the controller.
 

I cannot fully test it on emulators as I have no idea on how to emulate all the 16 directions from keyboard.

 
On a keyboard, it handles much better, although I would prefer the ship to go faster.  In Gyrus, the speed of rotation of your ship is quite fast! :)

 

    -dZ.



#24 intvnut ONLINE  

intvnut

    River Patroller

  • 2,752 posts
  • Location:@R6 (top of stack)

Posted Tue Sep 29, 2015 7:50 AM

I cannot fully test it on emulators as I have no idea on how to emulate all the 16 directions from keyboard.

 
Oh, and I almost forgot: jzIntv also supports analog joysticks.  So, if you have one of those, you can test with that also.
 
I realize that's not quite the same as the controller disc, but it's something, and it's less clunky than pressing pairs of keys on the keyboard.
 
 

Actually, it's a type of Gray Code encoding, and at that it does its job to prevent ambiguous signal decoding, given the mechanical nature of the controller.

 
Yeah, I was actually rather impressed when I saw how it all laid out.  Not only does the encoding support 4 way, 8 way and 16 way games easily (with very natural encodings for 4 and 8 way), but also has the nice gray-code property of only one bit changing at a time as you roll through the directions.
 
I'm just generally impressed with how much functionality they engineered into 8 control lines, all w/out any blocking diodes or matrix scanning.
 
 
 

How odd... the designer of the Inty controllers was severely disturbed...

When it's in the lookup table format, it is pretty awful.  If you instead show it as a table of values ordered in counter-clockwise order starting from south, it actually looks pretty sane.


Edited by intvnut, Tue Sep 29, 2015 7:54 AM.


#25 Rev OFFLINE  

Rev

    A.K.A. Revolutionika

  • 15,135 posts
  • Location:NC

Posted Tue Sep 29, 2015 8:05 AM

Would it be possible to get a screen shot or gif? Thanks!





Also tagged with one or more of these keywords: homebrew, Gorf, Tempest

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users