Jump to content
IGNORED

Deep Zone


artrag

Recommended Posts

Here you can find the last update of a test game born to test intybasic and overgrow out of control

 

Be Aware:

Someone on Internet has ripped off this code producing a blatant fake Gyruss game on cartridge trying to sell it to an obscene price

 

This code is © Copyright 2015 of Arturo Ragozini. All rights are reserved.

It is only for educational purposes, no commercial use is allowed unless permission is requested.

 

This will not ban scammers and pirates out the intellivision word, but at least now none will be able to say he didn't know that the code wasn't for free use.

 

[edit]

New releases continue in the Intybasic competition 2018 thread

http://atariage.com/forums/topic/277250-entry-2018-deep-zone/page-4

 

Video from an outdated version

 

https://youtu.be/Jd2tplpCxGw

 

update:

 

Features in the current release (dzgorf2018_04_07b):

 

- two enemy sets

8 kinds of movements:

 

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)

7 stars from back clockwise

8 stars from back anti clockwise

 

- fixed issues with collisions

- angular resolution increased

- variable speeds for warp, enemies and ship

- enemy speed increases at each enemy wave (shown in the top right corner, in yellow)

- you pass to a new swarm after killing 8 enemies of a given type (now just 4 for testing)

- bosses appear after 8 waves (provisional code)

- bosses now can cast bullets and kill the player

- new energy bar for bosses

- support for score and lives

- Gyruss controls on 16 directions

- game over sequence and music (courtesy of First Spear)

- improved music and voice when ECS is present

- background animation for the space warp/meteor warp after bosses

- in game music (6 channel log player for PSG+ECS)

- title screen with rolling credits

- menu screen for sfx testing (press 0 from titles)

- 6 sfx and 4 voice samples in the test screen

- voice without intellivoice: in game speech using the PSG (and the ECS if present)

- PSG log player for intro music (data imported by a pt3 player on msx)

- new rom layout (up to 84K)

dzgorf2018_02_25.rar

dzgorf2018_03_09c.rar

dzgorf2018_03_25.rar

dzgorf2018_04_04.rar

dzgorf2018_04_05a.rar

dzgorf2018_04_7b.rar

dzgorf.rom

Edited by artrag
  • Like 6
Link to comment
Share on other sites

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,
post-24767-0-93977900-1443298043.gif

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

Link to comment
Share on other sites

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
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 ?

 

dzgorf.rom

Edited by artrag
Link to comment
Share on other sites

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

 

post-24767-0-92550500-1443384239_thumb.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.

  • Like 1
Link to comment
Share on other sites

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
  • Like 1
Link to comment
Share on other sites

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]

dzgorf.rom

Edited by artrag
  • Like 1
Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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