Time Plot WIP

[artrag]

WIP

 

ps

the name is broken on purpose

demo.cfg demo.bin

Edited June 15, 2022 by artrag

[DZ-Jay]

15 hours ago, artrag said:

WIP

 

ps

the name is broken on purpose

demo.cfg 57 B · 9 downloads demo.bin 9.96 kB · 9 downloads

Hey!  I see that you're putting to use the "windowed scroll" routines to great effect. :)

 

It looks very nice.  I can't wait to see how this develops. ?

 

Just one comment:  It looks like the sprites are 8x8.  Not knowing the constraints and trade-offs you are considering, would it be possible to make them 8x16 in double vertical-resolution to add more detail?  If not, I'm sure it will still look great.

 

    -dZ.

[artrag]

This time the scrolling will work also in pal machines

Intybasic have different timings for the DEFINE command in PAL and the NTSC machines

The previous code was working only on NTSC machines

 

About sprites, all is provisional, the scrolling is taking just 12 tiles, so there are 52 tiles to be used for the rest of the game.

Anyway the main problem is the constrain on the number of sprites rather then their resolution 

demo.cfg demo.bin

[TIX]

can we have a sample video ?

[artrag]

At your command

[DZ-Jay]

2 hours ago, artrag said:

This time the scrolling will work also in pal machines

Intybasic have different timings for the DEFINE command in PAL and the NTSC machines

The previous code was working only on NTSC machines

Ah, right.

 

2 hours ago, artrag said:

About sprites, all is provisional, the scrolling is taking just 12 tiles, so there are 52 tiles to be used for the rest of the game.

Anyway the main problem is the constrain on the number of sprites rather then their resolution 

demo.cfg 57 B · 4 downloads demo.bin 9.95 kB · 5 downloads

 

What changed in this version?

 

    -dZ.

[artrag]

Different order of define/ wait /screen instructions depending on the pal/ntsc flag

It should adapt to the machine and work on both standards 

Edited June 14, 2022 by artrag

[DZ-Jay]

2 hours ago, artrag said:

Different order of define/ wait /screen instructions depending on the pal/ntsc flag

It should adapt to the machine and work on both standards 

Sorry, I meant on the second binary you posted in this thread.

 

   dZ.

[+cmadruga]

@artrag

Nice!!! And thanks for posting it, as I had this port on my bucket list.
Now I know it will be in very good hands.

 

So it seems you are not using hardware scrolling. Are you redefining background cards as the player changes directions? If yes, good job mapping all the variations in cloud positions. I suppose having all clouds be identical simplifies things.

 

I will be interested in seeing how you will deal with multiplexing. To me that’s the most challenging aspect of this port. There’s certainly no shortage of moving elements in this game.

 

 

 

 

[artrag]

Clouds take 12 tiles and are defined on fly. The first rom was for Ntsc machine but was presenting a glitch on Pal machines.

The second rom works on both systems.

The oddness is that according to the video mode the position of the wait command have to change.

About enemies and bullets I am  doing experiments with software sprites, but when passing over the clouds the result isn't very good 

 

[DZ-Jay]

4 hours ago, artrag said:

Clouds take 12 tiles and are defined on fly. The first rom was for Ntsc machine but was presenting a glitch on Pal machines.

The second rom works on both systems.

Ah, ok.  I misunderstood you.  I just noticed the PAL issue on the first ROM.
 

I tested the new one on jzIntv in both modes and works great. ??

 

Quote

The oddness is that according to the video mode the position of the wait command have to change.

What do you mean?  In PAL mode, the CPU runs slightly faster and the vertical blanking interrupts arrive slightly later, so there is definitely a difference in timing that must be accounted for.

 

Also, the DEFINE command in IntyBASIC only buffers the GRAM copy by setting the parameters.  The actual copy happens at the top of the next interrupt.  This further pushes down the rest of frame processing.

 

Perhaps the BUSRQ fetches that the STIC performs to populate the BACKTAB are affected by this timing?  Honestly, I haven't played around much with screen re-draws in PAL, but I'll investigate.

 

By the way, is this using the same plotting routines from the Cloudy Mountain project we were working on?  I tested my last build of that one in PAL and NTSC (in emulation), and it seemed to work well in both.

 

 

Quote

About enemies and bullets I am  doing experiments with software sprites, but when passing over the clouds the result isn't very good 

For bullets, you may get away with it since they are usually fast and fleeting (Kai Magazine games seem to abuse this with their bullets to good effect).  But for enemies it may not work that well.

 

Perhaps a wacky idea but ... rather than having enemies overlap with clouds at arbitrary positions, how about ensuring that they can only cross at specific aligned boundaries.  This can contain the error surface of overlap to a specific card or region.  Then you could reserve a MOB to correct it, or manipulate the background cards at that specific location.  Just a thought.

Great job so far.  The scrolling alone is impressive.  I have to ask ... are you completing and releasing any of these projects soon?

 

    dZ.

Edited June 15, 2022 by DZ-Jay

[artrag]

Cloudy Montain has all tiles precomputed in Gram, here the tiles are loaded on fly and must go in sync with the update of the backtab area when there is the need to scroll that table (i.e. each 8 pixel steps).

The odd is that in order to keep in sync tile definitions and backtab update the code has to change between pal and ntsc

 

[artrag]

About completing and releasing we will see, I cannot promise anything.

I hope to  be more consistent than with galaxian 

[DZ-Jay]

2 minutes ago, artrag said:

Cloudy Montain has all tiles precomputed in Gram, here the tiles are loaded on fly and must go in sync with the update of the backtab area when there is the need to scroll that table (i.e. each 8 pixel steps).

I understand.  The loading of GRAM will necessarily affect the timing available for the BACKTAB drawing.  So if that becomes a problem, you could try to pre-load GRAM before the 8th scroll step so that it doesn't interfere with the BACKTAB copy.

 

But you seem to have addressed it already.

 

2 minutes ago, artrag said:

The odd is that in order to keep in sync tile definitions and backtab update the code has to change between pal and ntsc

Ah, I see.  It may depend on the way you had staggered those two.  I would imagine that if the two are done right after VBLANK (i.e., after the WAIT), then it wouldn't matter, since in PAL you would have more time to copy GRAM before the STIC reads the BACKTAB data.

 

    dZ.

[DZ-Jay]

5 minutes ago, artrag said:

About completing and releasing we will see, I cannot promise anything.

I hope to  be more consistent than with galaxian 

No worries, I understand.  I was just wondering if these were just technology experiments or if you actually had plans to complete them

 

I'm sure it's a but of both, and like always happens with these things, the balance and priority changes all the time.

[artrag]

Galaxian now is using a double buffer to update the tiles for moving the fleet.

This makes the code independent by the ntsc/pal differences but costs double tiles.

Here the instruction flow changes according to ntsc/pal flag to keep the sync between tile definitions and tile positions.

It is odd, but the same code doesn't work on both systems, what works in ntsc will glitch in pal and vice versa 

[DZ-Jay]

9 minutes ago, artrag said:

Galaxian now is using a double buffer to update the tiles for moving the fleet.

This makes the code independent by the ntsc/pal differences but costs double tiles.

That's quite clever.  It is very expensive, but I is effective.  I can see why this wouldn't work well for Time Pilot, since the background scenery is more fluid.

 

9 minutes ago, artrag said:

Here the instruction flow changes according to ntsc/pal flag to keep the sync between tile definitions and tile positions.

It is odd, but the same code doesn't work on both systems, what works in ntsc will glitch in pal and vice versa 

Would you mind sending me a PM with the code differences between both so that I can see where the oddness lies?

 

    -dZ.

[wolfy62]

Time Pilot is an awesome game,and I am very happy to see you working on this particular port, Artrag. 

Thank you!?

[artrag]

Here an initial attempt of software bullets. They work in NTSC, but in PAL, for some sort of timing problem, are not visible in the first half of the screen...

Still investigating 

demo.cfg demo.bin

[artrag]

In order to avoid the issues related to the critical timing I've restored the double buffering scheme.

Studing on how to add up to 8 sftware bullets (for now only one is active)

 

demo.cfg demo.bin

[artrag]

Now with 4 software bulletes

They flicker a bit too much for my tastes

demo.cfg demo.bin

Edited June 27, 2022 by artrag

[artrag]

Rename and try to see 8 bullets 

demo-1.cfg demo.bin

[artrag]

Starting to get shape. I'm moving to ASM a part of the code.

With more clouds now

 

demo.cfg demo.bin

Edited July 5, 2022 by artrag

[artrag]

Now the sky follows the ship direction

Bulletes can be casted by the main ship (but their timing is wrong)

 

demo.cfg demo.bin

[DZ-Jay]

13 hours ago, artrag said:

Now the sky follows the ship direction

Bulletes can be casted by the main ship (but their timing is wrong)

 

demo.cfg 80 B · 3 downloads demo.bin 15.61 kB · 4 downloads

It looks very good! ?

 

To be honest, the multiplexing and overlapping cards of the bullets and enemies does not look too bad, and I have to say I barely noticed it -- probably because it all seems so smooth.  The main sprite blanking out the clouds, though, is a bit distracting, maybe because that's where my eye (as the player) is mostly focused on.  But it's not too bad, considering all the other elements you are able to fill in.

 

There are a couple issues I noticed that I thought to point out, in case they are actual bugs and not limitations of your design.  None of them are too big.

• Sometimes, especially when aiming towards the North-East quadrant, the bullets "stick" to the nose of the plane for a few frames before launching.
• When the play is rotated at some angles, particularly when aiming towards the North-West, the screen scrolling does not change orientation until past the 45⁰ angle.

 

Also, and perhaps this is a bit of a stretch based on your current design and framework, is it at all possible to scroll at smaller increments than 45⁰?  (Probably not, but I thought to ask.)

 

Great job!  It's very impressive.

 

     -dZ.

Edited July 7, 2022 by DZ-Jay