Entry 2018: Deep Zone

[artrag]

This is the rom for the above video

I'm looking for a good way to avoid to multiplex the main ship when double fire is active

dzgorf (1).rom

[artrag]

Things to fix:

 

Boss mode

-The energy bar of enemies is corrupted by stars on the warp

-The star field and the boss and the energy bar can interfere in tile definition (intybasic cannot update 3 sets of tiles in the same frame)

 

General gameplay

- I want to avoid multiplex of double bullets with main ship, but this hits with the limit of 3 set of tiles per frame (now stars and main ship are updated on fly)

- music player is glitchy with other songs, the issue has to be investigated

 

 

Improvements on hold

-enemies with barriers

-new movements and sprites

- bonus mode after each boss

[Kiwi]

I really love the new starfield and the power up. It certainly helps you out.

 

I do like the double bullet and don't mind the multiplexing the player's ship.

 

I do notice that the starfield get really fast during the boss scene. It is fine during the stage. Boss 3 and 4 the boss and the star becomes the boss pattern for 1 frame then return back. I would update the starfield in one frame, then update the boss's sprite in another frame.

 

I wondered if the score have a limit of 65535 or the game will end at some point before hitting the number. Maybe having a byte to keep track of the 10,000th place of the score. So it would increase by 1 every time it get to 10000.

 

Upon game over, the game should either stay on the game over screen or have the high score and last game score be at the title screen or high score screen.

 

This game is really have improved from the first version. It is really cool to see the transformation of this game from the beginning to now. That starfield is awesome!

[artrag]

The glitch is a consequence of the fact in boss mode there are 4 sets of tiles that could be updated in the same frame.

 

1) energy bar

2) stars

3) main ship

4) boss

 

IntyBASIC supports only two sets updated at the same time.

The original code was structured to reduce the chances of overlap with 3 sets.

Now with stars, the system to avoid collisions has to be rewritten.

Edited June 11, 2018 by artrag

[+DZ-Jay]

The glitch is a consequence of the fact in boss mode there are 4 sets of tiles that could be updated in the same frame.

 

1) energy bar

2) stars

3) main ship

4) boss

 

IntyBASIC supports only two sets updated at the same time.

The original code was structured to reduce the chances of overlap with 3 sets.

Now with stars, the system to avoid collisions has to be rewritten.

What about staggering the updates? Updating star-field and energy bar on odd frames; main ship and boss on even frames?

 

I don't know how you are computing your animation frame-rates, but even if you use a differential-analyser algorithm to animate, you could still compute fractional frame-rates that never update on the same display frame.

 

dZ.

[artrag]

I've only had the time to fix stars overlapping with core and energy bar and to extend the score up to 65.536.000

 

I still need to fix random "collisions" among tile sets being updated in the same frame

dzgorf.rom

Edited June 11, 2018 by artrag

[+DZ-Jay]

I've only had the time to fix stars overlapping with core and energy bar and to extend the score up to 65.536.000

 

I still need to fix random "collisions" among tile sets being updated in the same frame

 

One technique I use for the score is to color-code roll-overs. That way you could reduce the cost of Bin-to-Dec conversion and the real-estate on display. Or you could also do something like how Galaxian counts its levels: use a 4 or 5 digit score display, and just tack-on a "badge" icon on overflow. It may even serve as motivation for the player to see he earned a badge.

 

Well, that's if you could spare the GRAM.

 

-dZ.

[+DZ-Jay]

I just played the latest version and here's some feedback:

• Although I like the idea of the new star-field, in my opinion it goes much too slow to be effective.
• The slow player's movement, slow star-field, and slow missile conspire to make the game feel a bit lethargic.
• Also, all animations give the impression of being "synchronized," as if they all "tick" at the same time, which feels a bit odd.
• The extended score display looks a bit odd with so many zeros (it'll be a while before I fill those in!).
• At the very start of the game, the first two or three shots I make cause the screen to flash white for a frame. I do not know if this is part of the game, but it does not seem to happen later.
• After a few seconds, my ship starts moving faster, but it is not clear to me what I did to cause that. Perhaps there is a game mechanic which needs to be conveyed differently.

 

By the way, if it seems like my feedback only points out the negative, it's because I am trying to offer suggestions on what I think could be improved. There is plenty to like. The sampled voice is particularly impressive and goes well with a space shooter (although sometimes I cannot understand what it says).

 

I am also curious as to how you implemented the sound effects. Are they just PSG register logs or scripted?

 

-dZ.

[artrag]

I just played the latest version and here's some feedback:

• Although I like the idea of the new star-field, in my opinion it goes much too slow to be effective.

The stars should start going faster as the levels go up. Enemies and starfield should speed up each time you kill 4 enemies.

 

The slow player's movement, slow star-field, and slow missile conspire to make the game feel a bit lethargic.

 

You need to pick up white flashing globes to get speed ups and later other bonuses.

Be aware, sequence for bonuses is not random.

 

Also, all animations give the impression of being "synchronized," as if they all "tick" at the same time, which feels a bit odd.

 

Do you speak about enemies or starfield?

 

The extended score display looks a bit odd with so many zeros (it'll be a while before I fill those in!).

 

Yes, I have to cut them and one single color

 

At the very start of the game, the first two or three shots I make cause the screen to flash white for a frame. I do not know if this is part of the game, but it does not seem to happen later.

 

You are spending your 3 bombs. Use the other key to shoot and save the bombs for bosses.

 

After a few seconds, my ship starts moving faster, but it is not clear to me what I did to cause that. Perhaps there is a game mechanic which needs to be conveyed differently.

 

Have you collected any bonus pod or something?

By the way, if it seems like my feedback only points out the negative, it's because I am trying to offer suggestions on what I think could be improved. There is plenty to like. The sampled voice is particularly impressive and goes well with a space shooter (although sometimes I cannot understand what it says).

 

I am also curious as to how you implemented the sound effects. Are they just PSG register logs or scripted?

Sfx are log of registers produced by an editor working in windows

 

-dZ.

Edited June 12, 2018 by artrag

[+DZ-Jay]

You need to pick up white flashing globes to get speed ups and later other bonuses.

Be aware, sequence for bonuses is not random.

 

OK, I saw those, I didn't know what they did. It seems that sometimes I speed up temporarily and sometimes it stays sped up. It seems a bit confusing. Could the globes be colour-coded or shaped differently for different types of power-ups?

 

Do you speak about enemies or starfield?

 

Both, and the player's ship. It is just a visual impression, an illusion, not reality. The game, as it starts, seems to be updating in lock-step, as if every few frames all graphics are updated. It gives the game a bit of an odd lethargic look.

 

Yes, I have to cut them and one single color

 

OK.

 

You are spending your 3 bombs. Use the other key to shoot and save the bombs for bosses.

 

Ah. Well, for what it's worth, it is not at all clear, since the same button continues shooting normal missiles afterwards. Perhaps the bombs should be the "secondary" button and just do bombs, or maybe a keypad option?

 

 

Have you collected any bonus pod or something?

 

Probably. Since I couldn't tell what those orbs did, I may have collided with some of them. However, like I said above, sometimes it speeds up temporarily (flashing), and sometimes it stays permanent. Honestly, it seems a bit confusing.

 

Sfx are log of registers produced by an editor working in windows

 

Ah, gotcha. May I ask, is it an editor freely available or your own custom tool? And if the latter, would you mind sharing it?

 

I've always been fascinated by sound synthesis and sound effects, but I suck at it.

 

-dZ.

[artrag]

Look here for AYFXEDIT

 

https://shiru.untergrund.net/software.shtml

 

On Github there are improved versions able to export in CSV and other improvements

 

One of the most important things is that it can read PT3 files (one channel at time) and that it comes with a huge library of sfx from msx and zx spectrum games

[artrag]

About bonus pods, they are color coded.

 

White is speed up (up to 3 maximum, after you get only score)

Red is double fire (only once, after you get only score)

 

There are also extra bombs, barriers, extra lives but I cannot remember their color now

 

I'm planning a page with instructions looping with the title screen showing bonuses, keys, and other game details

[+DZ-Jay]

About bonus pods, they are color coded.

 

White is speed up (up to 3 maximum, after you get only score)

Red is double fire (only once, after you get only score)

 

There are also extra bombs, barriers, extra lives but I cannot remember their color now

 

I'm planning a page with instructions looping with the title screen showing bonuses, keys, and other game details

OK, I didn't notice the colour differences, I thought they were all grey/white.

 

The attract screen will certainly help. :thumbsup.

[artrag]

Press "2" while in the title screen to have a short summary of possible bonuses

 

DEFINE collisions are still there, I know.

dzgorf.rom

[+DZ-Jay]

Press "2" while in the title screen to have a short summary of possible bonuses

 

DEFINE collisions are still there, I know.

 

I see it, that helps. If I may make another suggestion: the colour flashing of the orbs should be slower so that the eye can process the actual "main" colour better. If you really wish to have it that fast, then ensure that the palette for each orb is different. As it stands, they all go through Tan and a few other "flat" colours, which sort of cause the orbs to blend together.

 

-dZ.

[artrag]

WIP

 

https://drive.google.com/open?id=1zCJgOz9K8bawz63KXgEUr5QTXSynd26P

 

 

Note that to see correctly the multiplexed sprites you need to download locally the AVI files and play it with a local player (e.g. VLC)

The Google video player will cut at 30Hz the frame rate, suppressing half of the main ship and bullets

Edited June 14, 2018 by artrag

[+DZ-Jay]

WIP

 

https://drive.google.com/open?id=1zCJgOz9K8bawz63KXgEUr5QTXSynd26P

 

 

Note that to see correctly the multiplexed sprites you need to download locally the AVI files and play it with a local player (e.g. VLC)

The Google video player will cut at 30Hz the frame rate, suppressing half of the main ship and bullets

 

What's being multiplexed? The only flicker I see is from the shield...

 

dZ.

[artrag]

Bullets, main ship and double shoot, shields

[+DZ-Jay]

Bullets, main ship and double shoot, shields

 

Well, I didn't notice those flickering at a glance, so I'd say it's all good! I'll take a look again just to make sure.

 

-dZ.

[artrag]

DEFINE collisions are still there. For the rest, for the intybasic competition I would only tune the difficulty by adding enemies and lowering the rate of power pod

 

I find a bit off how DEFINE and DEFINE ALTERNATE works.

 

You can only change TWO sets of tiles per frame even if you are within the limit of 16 tiles/frame.

 

I understand that extending the number of sets would have used precious ram.

 

Nevertheless maybe something could be improved even if you stay with just two "transfer slots".

 

Now in my code I cannot say if I have to use DEFINE, DEFINE ALTERNATE to initialize a given set of tiles, of if I have to postpone that update to the next frame, because I do not know in advance if previous sections of code have already booked or not a transfer slot.

 

This because in deep zone the speed of different game elements increases level by level, so, it is hard to say if and who will try to take a transfer slot in a given frame.

 

 

What about using a function in place of define as statement, able to say if the "booking" has been taken or not ?

 

Something able allow to code like this

 

if (counter1<0) and (DEFINE(card_num1,total1,label1)) then

BOOKING OK: counter1 = rate1

else

counter1 = counter1 + 1; ' DELAY THIS UPDATE TO NEXT FRAME

end

 

if (counter2<0) and (DEFINE(card_num2,total2,label2)) then

BOOKING OK: counter2 = rate2

else

counter2 = counter1 + counter2 + 1; ' DELAY THIS UPDATE TO NEXT FRAME

end

if (counter3<0) and (DEFINE(card_num3,total3,label3)) then

BOOKING OK: counter3 = rate3

else

counter3 = counter2 + counter3 + 1; ' DELAY THIS UPDATE TO NEXT FRAME

end

etc etc

dzgorf.rom

Edited June 15, 2018 by artrag

[Kiwi]

The define issue does shows up when the starfield is at maximum speed during the boss fight at time stamp 12:39. I wouldn't mind that the starfield be at the speed before that timestamp. The define issue doesn't occur before that during the boss fight. Maybe put a speed limit on the starfield animation.

[+DZ-Jay]

Spares copies to GRAM is a hard problem (tell me about it! I just went through the pain of implementing a "GRAM copy queue" for my own framework; see the IntvPROG mailing list for details, if interested).

 

The reason it is hard is because there is considerable over-head in setting up source and destination prior to each copy block, which can eat your cycles really fast. The "DEFINE" directives attempt to reduce this overhead by static declaration and by removing spareness by limiting the copy loop to a single contiguous block.

 

Perhaps adding more "DEFINE" alternatives is not the best solution.

 

In Christmas Carol, I have something similar to "DEFINE," but it's an array in ROM storing descriptors for the Source, Destination, and Length of each block you wish to copy. (The mechanism is a bit more sophisticated, checking a "dirty" flag for each entry to only copy those that require it.) I mostly use it to update MOB animation cards, so the length is usually 1 or 2 cards, depending on vertical-resolution.

 

For example:

    ; Register animation objects:
    REG_ANIM_OBJ(ELF,     Elf,     vDouble)
    REG_ANIM_OBJ(GHOST,   Ghost,   vDouble)
    REG_ANIM_OBJ(SNOWMAN, Snowman, vDouble)

Which translates to something like:

    ;       Pointer to source    Pointer to destination   Length
    ;       -------------------- ------------------------ ------    
    DECLE   ELF_OBJ.AnimSeq,     GRAM_BLOCK.Elf,            2
    DECLE   GHOST_OBJ.AnimSeq,   GRAM_BLOCK.Ghost,          2
    DECLE   SNOWMAN_OBJ.AnimSeq, GRAM_BLOCK.Snowman,        2

In P-Machinery 2.0 I went with a different solution. I implemented a "GRAM copy queue," which is an array in RAM. Rather than marking each animation object "dirty" and iterating over all of them to copy those; a similar record to the above is added to the queue in RAM. During VBLANK, the game engine iterates over the queue and copies all blocks.

 

If IntyBASIC could spare the RAM, it could use something like either of these techniques. The first one requires resolving the record descriptors during the copy block, so it has more overhead. The second one puts the overhead outside the critical section, making the loop faster.

 

Under optimal conditions (i.e., full VBLANK2 period), the Christmas Carol solution can copy at least 8 double-card GRAM blocks, or 16 cards in total. I admit I didn't really stress-test it, since the "dirty flag" mechanism reduced the incidence of concurrent updates significantly.

 

Under the same conditions, the P-Machinery 2.0 solution can copy up to 22 to 24 cards, in a mixture of single or double-card GRAM blocks. It does require a large enough chunk of RAM for the queue, 2 x 16-bit words per entry. (Also, it employs fully unrolled loops for high-performance, so it takes a considerable chunk of ROM too!)

 

I'm sure there are other solutions, perhaps even better suited. Indeed, Joe Z. had proposed one in the IntvPROG list which utilized a greater amount of ROM rather than RAM, but which can yield similar, if not better results. I haven't fully studied it, and never got around to implement it, so I can't really explain it right now.

 

One other alternative is for the IntyBASIC kernel to defer copy to the programmer: Offer an event handler similar to "ON Frame..." that will call back a custom routine at the top of the VBLANK period, and let the programmer do what he needs to do based on his own conditions. IntyBASIC could also offer some "GRAM copy primitives" that are optimized for performance, so that the programmer doesn't have to write his own copy loop.

 

-dZ.

Edited June 16, 2018 by DZ-Jay

[artrag]

Being able to change just two tile sets per frame can be limiting in complex games.

The define issue could be a valid reason to learn CP1610 assembly...

 

Anyway, atm I'm trying to implement a flag reporting if the define set or the alternate define set have been already "booked" in this frame, so that I can postpone the update at the next frame.

 

Oscar, would it work something like this:

mainloop:

wait

flag = 0 : ' bit 0 DEFINE is booked, bit 1 ALTERNATE DEFINE is used

if (flag and 3 = 3) then 
    postpone update for stars
else if (flag and 1) then
   DEFINE stars: flag = flag or 1
else if (flag and 2) then
  ALTERNATE DEFINE stars: flag = flag or 2
end if

if (flag and 3 = 3) then 
    postpone update for main ship
else if (flag and 1) then
   DEFINE main ship: flag = flag or 1
else if (flag and 2) then
  ALTERNATE DEFINE main ship: flag = flag or 2
end if

if (flag and 3 = 3) then 
    postpone update for energybar
else if (flag and 1) then
   DEFINE energybar: flag = flag or 1
else if (flag and 2) then
  ALTERNATE DEFINE energybar: flag = flag or 2
end if

goto mainloop

Edited June 17, 2018 by artrag

[+DZ-Jay]

What about if "DEFINE" wasn't a single statement, but worked like "DATA" and statically defined any number of rows?

 

The programmer would have to assume that the overhead of many "DEFINE" statements will limit the number of cards he can copy, but it would give him a chance to use, say, 4 or 5 "DEFINE" statements of one or two cards each and it could still work.

 

This is then similar to the way it worked in Christmas Carol (the REG_ANIM_OBJ macro works just like a DEFINE in IntyBASIC, except that it can be entered many times).

 

-dZ.

[+DZ-Jay]

artrag,

 

A few points:

• I think by now we've hammer the problem into nanochess' head, so I'm sure he is aware of it.
• Whatever solution he comes up with (if he wishes), will not be accessible for the IntyBASIC Programming Contest.
• Therefore, if you are to work-around the limitations for your game, we'll have to see what solutions are available to you immediately, within IntyBASIC (i.e., without Assembly Language).

Personally, I haven't even taken a look at your source so I do not know the mechanisms of the problem -- and even if I tried, it would probably take me a long while to actually understand it and follow it. I will give it a try, just in case I can help, but I invite others to provide ideas. Perhaps nanochess, intvnut, or GroovyBee (the foremost experts in IntyBASIC) can also offer some suggestions.

 

To me, this is one of those critically important things that IntyBASIC must do well in order to support fast-paced arcade action games. The "ASM" directive goes some ways towards this goal (it offers the best of both worlds), but it would be even greater if IntyBASIC could do it natively. I'm sure there are ways, but it's up to Oscar to decide.

 

-dZ.