Would anyone be interested in working on another mega demo?

[sometimes99er]

 

[TheMole]

20 hours ago, Asmusr said:

It could be F18A. That YouTube channel has a few other F18A videos. But it's hard to see because the video is so grainy.

Ah... I love the F18A, but that would be a shame... the F18A can do that specific thing a whole lot better than what this video shows (as far as we can tell, given the low bitrate, of course  ).

[+FarmerPotato]

This test puts a black outline around a sprite pattern, without using another sprite.  It displays the outline in one frame, then the interior on the next frame.  Repeat with a new location.  

 

Can someone run this on a real 9918, and tell me if you perceive the sprites moving together, or if you perceive them out of sync?

 

I haven't run this on real iron, only questionable emulation (Wine+Classic99).   I think I see it dropping frames--it has to do DirectX to OpenGL.

 

The .obj file is DF80 Load and Run.  It's inside the DSK container as well. 
 

EDIT - the program name  DEF is START. Or the first word ...

EDIT - it is synced to VDP interrupt:

 

1. Prepare data in CPU RAM buffer
2. Wait for interrupt
3. Write sprite attribute table for interiors
4. Wait for interrupt
5. Write sprite attribute table for outlines
6. Increment location counter
7. Loop

 

 

sprite.dsk sprite.lst sprite.obj sprite.asm

[retrodroid]

On 6/4/2024 at 9:45 AM, FarmerPotato said:

Can someone run this on a real 9918, and tell me if you perceive the sprites moving together, or if you perceive them out of sync?

 

I haven't run this on real iron, only questionable emulation (Wine+Classic99).   I think I see it dropping frames--it has to do DirectX to OpenGL.

FYI my perception is that running JS99'er on Firefox provides a solid 60FPS (on my mac at least) and that these types of tricks render well, and consistently with what I see on my MiSTer w/ CRT. I've also seen flickering, etc. on Classic99 (w/ wine) that don't appear in these other environments.

[Tursi]

One important note with flicker tricks is that the CRT is important. Most flicker tricks look poor on most LCD displays, and outright terrible on some. (I had one that tried to de-interlace the image, even though it wasn't interlaced.) Even LCDs that change the image 60 times a second won't look as good as a CRT due to lack of persistence.

 

 

Edited June 5 by Tursi

[+FarmerPotato]

2 hours ago, Tursi said:

I had one that tried to de-interlace the image, even though it wasn't interlaced.)

I did wonder how it would appear on TV.  The even/odd fields with different sprites would have been parts of one frame on a TV, interlaced. (I think. NTSC math is easy to get wrong.) So on TV it would be skewed half a pixel. 
 

When I get to a color monitor I want to see what quality changes if I double each field before moving location. From EO, try EEOO or EOOE. 

A related idea I want to test: when there is a 5th sprite on a line, sort that sprite data up to #1 to give it some display time. Repeat.

[Asmusr]

1 hour ago, FarmerPotato said:

I did wonder how it would appear on TV.  The even/odd fields with different sprites would have been parts of one frame on a TV, interlaced. (I think. NTSC math is easy to get wrong.) So on TV it would be skewed half a pixel. 
 

When I get to a color monitor I want to see what quality changes if I double each field before moving location. From EO, try EEOO or EOOE. 

A related idea I want to test: when there is a 5th sprite on a line, sort that sprite data up to #1 to give it some display time. Repeat.

I haven't tried your code on real iron (I would need it as a cartridge image in order to do so), but if what you're doing is: 

1. display outline
2. display inside
3. move

I think you should try instead with:

1. display outline
2. move
3. display inside
4. move

I believe the eye anticipates the movement, and if it doesn't move every time the outline and the inside seem to come apart. At least that's how it appears on emulation.

 

You should also be able to obtain something that looks like a third color, if, for instance, the outline is red and the inside is yellow, and you have some pixels that are drawn both with the outline and the inside, they should appear as orange.

 

Edited June 6 by Asmusr

[Asmusr]

I'm thinking of an effect that mixes hardware and software sprites. For instance, we shoot lots of balls into the screen, and as they slow down, e.g. by hitting other balls, they turn into software sprites, giving the impression that we have found a way to use more than 32 sprites and more than 4 in a row. The idea is that because the software sprites are slow, the bitmap image would only have to be updated every 4th frame or so, which should be manageable.

[sometimes99er]

3 hours ago, FarmerPotato said:

A related idea I want to test: when there is a 5th sprite on a line, sort that sprite data up to #1 to give it some display time. Repeat.

Unfortunately the information about 5 or more sprites on a screen line is a flag (set or not), so we don't know which is the so called 5th sprite. Ref. E/A-manual page 269.
Since there can be 5 or more sprites on a line and also elsewhere on the screen, we would have to compute which sprites are not displayed or only partly displayed, and then decide which to move up in the sprite attribute list.

Now if we distribute our sprites carefully, and watch when the flag is suddenly set, then we might more easily deduce which sprite has trouble, and try to move it out of the way - probably by changing its direction or detonating it.

[sometimes99er]

On 6/3/2024 at 3:37 PM, TheMole said:

Wait, what? Does anyone have any idea how this is done?

On 6/3/2024 at 5:05 PM, Asmusr said:

It could be F18A. That YouTube channel has a few other F18A videos. But it's hard to see because the video is so grainy.

Must be F18A.

[sometimes99er]

 

[whoami999ster]

9 minutes ago, sometimes99er said:

 

very nice the effect of the walking man in ZX demo

 

[+FarmerPotato]

8 hours ago, sometimes99er said:

Unfortunately the information about 5 or more sprites on a screen line is a flag (set or not), so we don't know which is the so called 5th sprite. Ref. E/A-manual page 269.
Since there can be 5 or more sprites on a line and also elsewhere on the screen, we would have to compute which sprites are not displayed or only partly displayed, and then decide which to move up in the sprite attribute list.

Now if we distribute our sprites carefully, and watch when the flag is suddenly set, then we might more easily deduce which sprite has trouble, and try to move it out of the way - probably by changing its direction or detonating it.

 

I was reading the 9918A manual:

 

VDP Status Register >8802

+---------------------------+
| F | 5S| C | n  n  n  n  n |
+---------------------------+

 

F interrupt flag. The F status flag is set to 1 at the end of the raster scan of the last line of the active display. 

5S flag:

1. "The 5S status flag is set to a 1 whenever there are 5 or more sprites on a horizonal line (0-192) and the frame flag is equal to a 0. "
2. "The 5S flag is cleared to 0 when the status register is read or VDP is externally reset."
3. "The number of the fifth sprite is placed in the lower 5 bits when the 5S flag is set and is valid whenever the 5S flag is 1."
4. "The setting of 5S will not cause an interrupt."

Frame flag is mentioned in 1.  I guess Frame flag means 'F' too?  That would imply that 5S can be set one or more times during raster scan, but is left unchanged after F is set to 1.  Seems useful.     Or Frame flag is some other internal bit (like raster scan is in progress)

 

It implies that when you read the VDPSTA, you get the latest one reported.  So a loop that waits for F=1 could record each valid n. (While F==0 check 5S, n. repeat)

 

 

Is that not how the chip actually works?

 

 

 

 

Edited June 6 by FarmerPotato

[Asmusr]

28 minutes ago, FarmerPotato said:

 

I was reading the 9918A manual:

 

VDP Status Register >8802

+---------------------------+
| F | 5S| C | n  n  n  n  n |
+---------------------------+

 

F interrupt flag. The F status flag is set to 1 at the end of the raster scan of the last line of the active display. 

5S flag:

1. "The 5S status flag is set to a 1 whenever there are 5 or more sprites on a horizonal line (0-192) and the frame flag is equal to a 0. "
2. "The 5S flag is cleared to 0 when the status register is read or VDP is externally reset."
3. "The number of the fifth sprite is placed in the lower 5 bits when the 5S flag is set and is valid whenever the 5S flag is 1."
4. "The setting of 5S will not cause an interrupt."

Frame flag is mentioned in 1.  I guess Frame flag means 'F' too?  That would imply that 5S can be set one or more times during raster scan, but is left unchanged after F is set to 1.  Seems useful.     Or Frame flag is some other internal bit (like raster scan is in progress)

 

It implies that when you read the VDPSTA, you get the latest one reported.  So a loop that waits for F=1 could record each valid n.

 

 

Is that not how the chip actually works?

Yes it is. I have attached an old demo of mine were the 5th sprite is bouncing when the flag is set. To see it, load 5TH as an E/A#3 file.

5THSCRAWL.dsk

[Asmusr]

But for a flicker routine, my experience is that alternating between sending the sprites to the VDP in ascending and descending order is better, at least if you have less than 9 sprites on a line.   

[Tursi]

15 hours ago, FarmerPotato said:

I did wonder how it would appear on TV.  The even/odd fields with different sprites would have been parts of one frame on a TV, interlaced. (I think. NTSC math is easy to get wrong.) So on TV it would be skewed half a pixel. 

The signal actually contains enough information for a CRT to know it's not interlaced, that's why we get a stable image. But since LCDs need to digitize the image, it's entirely up to the chipset. The one TV that I had worked like you are describing - assuming it was interlaced and displaying alternate frames on different scanlines (most of the time. Because the half-line is missing, it would get confused from time to time and switch frame order). I've had two devices that refuse the signal outright. But most of the LCDs I have used attempt the signal more or less correctly, and it's just the fact that modern LCDs are very fast to switch that makes it less desirable. You really want 20-30ms of blend between frames, and modern LCDs average single digits.

 

Edited June 6 by Tursi

[Tursi]

3 hours ago, Asmusr said:

But for a flicker routine, my experience is that alternating between sending the sprites to the VDP in ascending and descending order is better, at least if you have less than 9 sprites on a line.   

This seems to work best. I tend to also rotate my table by four sprites as well as flipping the drawing order on alternate frames. It's otherwise conceivably possible, I think, to have a state where sprites near the middle of the list are always hidden. At any rate it only costs a little code, no mentionable time, since my routine to copy the sprite table into VRAM takes a starting offset.

 

But people have invented as many flicker routines as there are coders, and everyone seems to think theirs is the best. You can find some heated debates in other forums here. 

 

[jrhodes]

We could always try to install Windows on the 4a

 

 

[Tursi]

18 hours ago, sometimes99er said:

 

That '64 demo is such a work of art - been years since I've watched it.

 

[sometimes99er]

@FarmerPotato @Asmusr
Information about the number of a 5th sprite is indeed available. E/A-manual page 269 even says so. My bad. It also says, that the number of a 5th sprite is only available if the Coincidence flag is set. That's a strange dependence !? Is that really true ?

[Asmusr]

2 hours ago, sometimes99er said:

Is that really true ?

No it's not. 

[sometimes99er]

4 hours ago, Asmusr said:

No it's not. 

O.k. Thanks. 🙂

[Elia Spallanzani fdt]

On 6/7/2024 at 4:11 AM, Tursi said:

That '64 demo is such a work of art 

Wow. 

[whoami999ster]

On 6/1/2024 at 10:39 PM, Asmusr said:

I would like to encourage anyone to post suggestions for demo effects that you like, no matter how impossible they might seem. 

 

https://youtu.be/F9vJy7lDHzk?si=eqT_kc9wCLxsCnI4

 

here my cent ... a little hint for the animation can be found here ... 

In general I like "concept" ... also for this demo IMHO we should start from the "message" we want trasmit (graphics/coloes and sound) and not a simple summary of wonderfull effect  (at this point I realize that nothing is impossible for our TI99 wizard ) ...

Sorry for bothering you all ...    

[sometimes99er]

Maybe one could redo a movie trailer/scene. Perhaps mostly static scenes (camera remains stationary) with sprite animation. 🙂