Deep Zone

[+nanochess]

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

 

Here you go (click to animate)

 

[mthompson]

Here are a couple of more screen shots for you. Cool game.

 

[Rev]

Cool. Thanks

[+DZ-Jay]

artrag, I wonder if the warp effect would be more effective with a star field rather than full line segments. When blown up to the true blocky size of an Intellivsion screen, the rays sort of distract from the action.

[pimpmaul69]

i like the new controls. now i wish they had made tempest cause the disc is a perfect controller for it.

[artrag]

artrag, I wonder if the warp effect would be more effective with a star field rather than full line segments. When blown up to the true blocky size of an Intellivsion screen, the rays sort of distract from the action.

I will try but to do a decent work I need gram tiles

[+Tarzilla]

artrag, I wonder if the warp effect would be more effective with a star field rather than full line segments. When blown up to the true blocky size of an Intellivsion screen, the rays sort of distract from the action.

I'm of two thoughts on the warp...

1) I think it is too uniform. As a long time owner of a Gorf arcade machine, I'm conditioned to seeing a more randomized warp pattern. The uniform expanding square of nothing is too distracting. Watch a video of the arcade Gorf to see what I mean. The Colecovision version has a similar problem because of tiles but does a good job of hiding by varying the lines. Maybe randomizing the expanding black box of nothing so it isn't affecting each line of the warp the same way at the same time.

 

2) I played lots of Gyruss so when moving the ship I'm expecting random stars...

But that's all from long time conditioning, others might disagree due to their previous experience...

 

The player ship motion is nicely done.

[+DZ-Jay]

I will try but to do a decent work I need gram tiles

Can you share your GRAM allocation strategy? Perhaps we can offer suggestions on how to utilize it differently.

[+DZ-Jay]

I'm of two thoughts on the warp...

1) I think it is too uniform. As a long time owner of a Gorf arcade machine, I'm conditioned to seeing a more randomized warp pattern. The uniform expanding square of nothing is too distracting. Watch a video of the arcade Gorf to see what I mean. The Colecovision version has a similar problem because of tiles but does a good job of hiding by varying the lines. Maybe randomizing the expanding black box of nothing so it isn't affecting each line of the warp the same way at the same time.

 

2) I played lots of Gyruss so when moving the ship I'm expecting random stars...

But that's all from long time conditioning, others might disagree due to their previous experience...

 

The player ship motion is nicely done.

In my opinion, the problem is not the "expanding box of nothingness," but that the rays are actually quite chunky as compared to other aspects of the display.

 

Other than a randomized star field like in Gyruss, I was thinking that the lines could be broken into individual pixel patterns. That way, although it may still be regular enough to cycle effectively, the effect may blend better with its surroundings and look more "transparent."

[artrag]

Can you share your GRAM allocation strategy? Perhaps we can offer suggestions on how to utilize it differently.

 

No strategy, all the gram is for scaled sprites (8 frames for enemy type, 6 enemy types + 1 enemy bullet)

The last spare 8 cards are used: 2 for the main ship, one for main ship bullets, 4 for completing the warp lines, 1 spare

 

About warp animation, this is another option

 

Edited September 29, 2015 by artrag

[+DZ-Jay]

No strategy, all the gram is for scaled sprites (8 frames for enemy type, 6 enemy types + 1 enemy bullet)

The last spare 8 cards are used: 2 for the main ship, one for main ship bullets, 4 for completing the warp lines, 1 spare

 

That's what I meant, your GRAM allocation map. Are you allocating 8 GRAM tiles per enemy type? So that's...

• 8 frames per enemy type
• 6 enemy types
• 1 bullet
• TOTAL: (8 x 6) + 1 = 49

 

How about if you allocate one card (actually, two cards for double vres sprites) per visible sprite (for as many enemies can be visible at a time) and just cycle GRAM on each frame as necessary? You only need to cycle the card of an enemy when it crosses Z-plane boundaries that require it.

 

On generation of a new enemy, you just assign it to one of the allocated slots.

 

About warp animation, this is another option

I'm not a fan of the solid lines. Can you try breaking them up into "dotted lines" with empty spaces in them? You could animate an expanding star field, sort of like "marching ants," by just cycling between as little as two cards.

Edited September 29, 2015 by DZ-Jay

[artrag]

Enemy bullet has 8 scales like other enemies.

So you have 8x7 = 56 frames. Actually I reuse for explosions two of the shapes used for bullets and enemies but it does not matter here.

The 8 spare tiles are those used for main ship, its bullet and the warp.

 

I could for sure update on fly the cards in GRAM of the enemies on the screen. This means copying 8 bytes at each change of scale for the 4 attacking enemies and their two bullets. I think that now there is enough CPU time for changing this inner working system, but I was thinking to spend the spare CPU time to speed up the whole game removing a couple of WAIT.

Anyway we will see.

I would move on instead to rework aspects of the game for now more or less work.

Edited September 30, 2015 by artrag

[intvnut]

I'm not a fan of the solid lines. Can you try breaking them up into "dotted lines" with empty spaces in them? You could animate an expanding star field, sort of like "marching ants," by just cycling between as little as two cards.

 

Even if you didn't do "marching ants", I think having a less bright color and/or using dashed lines (even if the 'dashed' aspect didn't shift frame-to-frame) might help the effect. Not sure, really, w/out seeing a mockup, though.

[artrag]

I can try in blue.About dashed lines I do not have appropriate tiles in grom (if I do not move to dynamic definitions for enemies). I could only remove more tiles.

It would look like moving lines in empty space (as opposite to now where it looks like black tiles moving on static lines)

Edited September 30, 2015 by artrag

[+DZ-Jay]

I can try in blue.About dashed lines I do not have appropriate tiles in grom (if I do not move to dynamic definitions for enemies). I could only remove more tiles.

It would look like moving lines in empty space (as opposite to now where it looks like black tiles moving on static lines)

 

I think dynamically cycling the enemies animation will free up the GRAM for many other things. It may be the way to go, though I know it'll be a big change.

 

There should be enough time to process all the cards, since they will be staggered at only the moments they need to change scale.

[artrag]

There is cpu time for updating all the 4 sprites (8 or 16 bytes) and update about 16 tiles for the background and keep the speed as it is or (not and) make everything twice or three times faster...

Edited September 30, 2015 by artrag

[+DZ-Jay]

There is cpu time for updating all the 4 sprites (8 or 16 bytes) and update about 16 tiles for the background and keep the speed as it is or (not and) make everything twice or three times faster...

Wait, the 16 cards for the background, are you talking BACKTAB cells, or more GRAM cards? I thought you were using GROM.

 

I haven't seen your code, but in my own game, I managed to animate three composite sprites, using all 8 MOBs at double vertical resolution (2 GRAM cards) plus some GRAM cycling for background items, and still keep the refresh rate at 60 Hz, including enemy movements and (simple) AI.

 

You should be able to do the same with IntyBASIC.

 

I've found that buffering all changes and only updating what is required on a frame, removes the bottle neck. The rest (e.g., BACKTAB changes) is not time critical (as it pertains to the VBLANK ISR), so it can be updated off the critical path.

 

I believe IntyBASIC Already buffers the GRAM updates for you, and you should be able to selectively update the buffers as needed, rather than doing it on every frame.

[artrag]

Wait, the 16 cards for the background, are you talking BACKTAB cells, or more GRAM cards? I thought you were using GROM.

 

I haven't seen your code, but in my own game, I managed to animate three composite sprites, using all 8 MOBs at double vertical resolution (2 GRAM cards) plus some GRAM cycling for background items, and still keep the refresh rate at 60 Hz, including enemy movements and (simple) AI.

 

You should be able to do the same with IntyBASIC.

 

I've found that buffering all changes and only updating what is required on a frame, removes the bottle neck. The rest (e.g., BACKTAB changes) is not time critical (as it pertains to the VBLANK ISR), so it can be updated off the critical path.

 

I believe IntyBASIC Already buffers the GRAM updates for you, and you should be able to selectively update the buffers as needed, rather than doing it on every frame.

16 cards in gram

Note that now the game updates one single thing per frame.

Backtab at frame 0, main sprite and bullets at frame 1, one enemy at time in frame 2,3,4,5.

The final result is 60/6= 10 fps.

In this way I have full room to replace backtab update by animated stars in gram and add gram update for enemies.

I could also keep everything as it is and rise the frame rate to 20 fps or more

Edited September 30, 2015 by artrag

[+DZ-Jay]

16 cards in gram

Note that now the game updates one single thing per frame.

Backtab at frame 0, main sprite and bullets at frame 1, one enemy at time in frame 2,3,4,5.

The final result is 60/6= 10 fps.

In this way I have full room to replace backtab update by animated stars in gram and add gram update for enemies.

I could also keep everything as it is and rise the frame rate to 20 fps or more

OK got it, so a pipelined approach. I took a different approach, setting up a "dirty flag" vector when animation cycling or enemy movements crossed a boundary requiring GRAM update, and then buffered the card change by adding it to a queue.

 

Only in the worst case scenario would all objects required updating during a single frame. However, in practice, that rarely happened, and if a sprite's animation skipped a frame due to dropped GRAM writes, it wasn't critical enough.

 

Your game is definitely different, but I wonder if a similar "write on dirty" approach can help you reduce the pipeline stages and speed up the game.

[artrag]

OK got it, so a pipelined approach. I took a different approach, setting up a "dirty flag" vector when animation cycling or enemy movements crossed a boundary requiring GRAM update, and then buffered the card change by adding it to a queue.

 

Only in the worst case scenario would all objects required updating during a single frame. However, in practice, that rarely happened, and if a sprite's animation skipped a frame due to dropped GRAM writes, it wasn't critical enough.

 

Your game is definitely different, but I wonder if a similar "write on dirty" approach can help you reduce the pipeline stages and speed up the game.

 

I have no problem in speeding up the game as it is now, and I was thinking to progressively rise the speed in order to rise the difficulty.

Try this rom (where I've just removed a WAIT) and tell me how it goes.

This is the max speed I can get atm.

dzgorf_ultra fast.rom

[artrag]

I've tried to put in blue the later warp scheme I proposed. The results are in attach (at normal and full speed).

dzgorf_blue_normal.rom

dzgorf_blue_max_speed.rom

[+DZ-Jay]

 

I have no problem in speeding up the game as it is now, and I was thinking to progressively rise the speed in order to rise the difficulty.

Try this rom (where I've just removed a WAIT) and tell me how it goes.

This is the max speed I can get atm.

 

 

What I was saying is that there shouldn't be a need for more than one wait. Your time-sensitive tasks could be handled (or at least signaled) during the retrace interrupt using ON FRAME, and everything else runs in the normal game loop outside the critical path, with a judiciously placed WAIT in order to synchronize back with the frame.

 

I haven't seen the code, so I do not know how compatible this is with your current approach.

 

I've tried to put in blue the later warp scheme I proposed. The results are in attach (at normal and full speed).

 

Although the darker blue seems to be an improvement over the bright white, the solid rays are still a bit distracting. In either colour, it looks to me more of a flickering set of lines than a warp effect, sorry. I think it's time to seriously consider using GRAM for this if you want to keep the effect and want it to be cool and effective -- unless you figure out how to get away with using GROM "ASCII" characters like the period, colon, etc. for this.

 

As for the speed changes, the problem is that you just sped up the engine without adjusting the relative velocities of any object. The player's spaceship is fast and responsive (as it should), and reminds me of Gyruss; but the enemies are comically fast and look like they are being sped in "fast forward" mode; and the warp effect is just a blinking mess.

 

I think that the max/ultra speed is the right way to go, for it will allow you to update objects and game state closer to real time, but then you'll need to adjust the relative speed of animation and motion of everything individually.

 

To be sure, I really like the responsiveness and speed of the player ship in the max/ultra versions. I strongly feel you should keep it that way. Everything else, however, needs to be adjusted.

 

One more thing: I think the collision detection is being affected by splitting the process over a few frames. I had noticed that most of the time my bullets appear to not affect the enemies nor their bullets. This is more noticeable when compared to the max/ultra version, where bullets seem to collide more accurately.

 

If you are keeping the pipeline approach, then I suggest you treat collisions in one of two ways:

• Apply all position changes and check for collisions afterwards on the same frame
• Apply position changes over more than one frame and check for collisions on the next frame after all are done

Again, I haven't seen the code, so I do not know exactly what is affecting collisions. I'm just basing my opinion purely on observation while playing.

 

-dZ.

Edited October 1, 2015 by DZ-Jay

[+nanochess]

There is a good trick for subpixel movement I tend to use it in my games.

 

 

    CONST speed_enemy = $30    ' Less than 1 pixel speed
 
    speed1 = speed1 + speed_enemy
    IF speed1 >= $40 THEN speed1 = speed1 - $40:GOSUB move_enemy

 

The fastest element in your game (the spaceship moves very well) is the base speed, everything else can move slower with this snippet.

 

You can tune enemies and enemy bullets this way. (for example, easy enemies at speed $28, fast enemies at speed $38)

[artrag]

 

 

What I was saying is that there shouldn't be a need for more than one wait. Your time-sensitive tasks could be handled (or at least signaled) during the retrace interrupt using ON FRAME, and everything else runs in the normal game loop outside the critical path, with a judiciously placed WAIT in order to synchronize back with the frame.

 

I haven't seen the code, so I do not know how compatible this is with your current approach.

 

 

Look yourself, there is just a single WAIT

[artrag]

 

Although the darker blue seems to be an improvement over the bright white, the solid rays are still a bit distracting. In either colour, it looks to me more of a flickering set of lines than a warp effect, sorry. I think it's time to seriously consider using GRAM for this if you want to keep the effect and want it to be cool and effective -- unless you figure out how to get away with using GROM "ASCII" characters like the period, colon, etc. for this.

 

As for the speed changes, the problem is that you just sped up the engine without adjusting the relative velocities of any object. The player's spaceship is fast and responsive (as it should), and reminds me of Gyruss; but the enemies are comically fast and look like they are being sped in "fast forward" mode; and the warp effect is just a blinking mess.

 

I think that the max/ultra speed is the right way to go, for it will allow you to update objects and game state closer to real time, but then you'll need to adjust the relative speed of animation and motion of everything individually.

 

 

It was just an hack to show the current max speed. The relative speed of each section has to be tuned and parametric with the level of difficulty (I use in general something very close to what Oscar proposed).

In order to move the warp to GRAM and animate the enemies on fly I need to rise significantly the CPU load. The final max speed will be much lower, I guess about 10-15 fps.

Edited October 1, 2015 by artrag