52 replies to this topic

[sometimes99er]

I'm pretty sure that's how it works. My last hardware experience is way back in the eighties, but from what I've read and discussed with Tursi and Guttag, I think the sprites are totally recalculated every scanline - as in the sprite display system is scanline oriented and does not know what went on in the previous scanline.

EDIT: NOT SO !

Edited by sometimes99er, Mon Feb 20, 2012 12:13 PM.

[rocky007]

mmh...i'm not so sure...

try this :

1 CALL CLEAR
10 CALL CHAR(128,"FF00000000000000")
20 CALL CHAR(129,"00FF000000000000")
30 CALL CHAR(130,"0000FF0000000000")
40 CALL CHAR(131,"000000FF00000000")
50 CALL CHAR(132,"00000000FF000000")
100 CALL SPRITE(#1,128,2,50,50)
110 CALL SPRITE(#2,129,3,50,50)
120 CALL SPRITE(#3,130,2,50,50)
130 CALL SPRITE(#4,131,3,50,50)
131 For I=1 to 15
132 print "POSITION #5 ";i
140 CALL SPRITE(#5,128,2,45+I,60)
141 CALL KEY(0,K,S) :: IF S<>0 THEN 142 ELSE 141
142 next i
200 goto 200

The sprite #5 is totally hided by the 4 others

Edited by rocky007, Mon Feb 20, 2012 9:29 AM.

[sometimes99er]

Yep. Classic99 and MESS shows the same. 4 sprites shown according to priority. Doesn't matter if the individual scanline in a sprite is transparent. Doh. How does the real hardware show this ?

100 CALL CLEAR::CALL SCREEN(2)
110 CALL CHAR(33,"FF00FF00FF00FF")
120 FOR A=0 TO 3
130 CALL SPRITE(#(A*2+1),33,16,100,100+A*16)
140 CALL SPRITE(#(A*2+2),33,14,101,100+A*16)
150 NEXT A
160 GOTO 160

Edited by sometimes99er, Mon Feb 20, 2012 9:50 AM.

[rocky007]

no, even on real hardware :

Attached Files

•  pic002.gif   87.31K   20 downloads

Edited by rocky007, Mon Feb 20, 2012 10:17 AM.

[sharapos]

Hello Rocky,

I want to learn MLC and your game would be a good occasion to learn. Would you add your source code to the game you will post ?
I want to port games as you do. I hope your game will attract someone to read the MLC posts from moulinaie (only 260 views!)
I thank you in advance.

[moulinaie]

sharapos, on Mon Feb 20, 2012 11:16 AM, said:

Hello Rocky,

I want to learn MLC and your game would be a good occasion to learn. Would you add your source code to the game you will post ?

I'll be happy to help if someone starts a new project !
Guillaume.

[sometimes99er]

rocky007, on Mon Feb 20, 2012 10:17 AM, said:

no, even on real hardware :

Bummer. Thought I'd seen it and used it, but apparently not. Okay, I'm getting old.

[rocky007]

sharapos, on Mon Feb 20, 2012 11:16 AM, said:

Hello Rocky,

I want to learn MLC and your game would be a good occasion to learn. Would you add your source code to the game you will post ?
I want to port games as you do. I hope your game will attract someone to read the MLC posts from moulinaie (only 260 views!)
I thank you in advance.

of course, the source will be released with the game.  You can already download my previous game in the MLC archive ( Kaboom ! ). MLC is really easy to program.  Don't hesitate to ask if you need help

Edited by rocky007, Mon Feb 20, 2012 11:58 AM.

[sharapos]

rocky007, on Mon Feb 20, 2012 11:58 AM, said:

sharapos, on Mon Feb 20, 2012 11:16 AM, said:

Hello Rocky,

I want to learn MLC and your game would be a good occasion to learn. Would you add your source code to the game you will post ?
I want to port games as you do. I hope your game will attract someone to read the MLC posts from moulinaie (only 260 views!)
I thank you in advance.

of course, the source will be released with the game.  You can already download my previous game in the MLC archive ( Kaboom ! ). MLC is really easy to program.  Don't hesitate to ask if you need help

Ok I will loo k Kaboom . Thank you.

[sharapos]

moulinaie, on Mon Feb 20, 2012 11:27 AM, said:

sharapos, on Mon Feb 20, 2012 11:16 AM, said:

Hello Rocky,

I want to learn MLC and your game would be a good occasion to learn. Would you add your source code to the game you will post ?

I'll be happy to help if someone starts a new project !
Guillaume.

I also thank you Guillaume

[Tursi]

sometimes99er, on Mon Feb 20, 2012 7:59 AM, said:

I'm pretty sure that's how it works. My last hardware experience is way back in the eighties, but from what I've read and discussed with Tursi and Guttag, I think the sprites are totally recalculated every scanline - as in the sprite display system is scanline oriented and does not know what went on in the previous scanline.

Well, this statement is true, but the VDP does not look at the pattern when it calculates sprites, only the sprite's position. If you actually turn sprites on and off per scanline, you could get what you were after, but the timing of the system seems not to be accurate enough to do scanline effects on anything better than 3-4 scanlines.

The way that sprite generation works is that the VDP first scans the sprite table, looking for sprites that need to be drawn on the current line. It has four registers in which is saves the numbers of the sprites it finds (and the fifth sprite gets dropped into the status register). It does this search before the line starts. When the line begins drawing, then it only needs to deal with those four saved sprites - that's where the limit comes from, and this process does happen every scanline from scratch.

The per-line-color trick you talk about is used a lot on the Atari 2600, Sometimes99er, they can move their objects around quickly and accurately enough (in truth they have to, or they don't get a game ).

Of course, you can do SOME effects like you show there. By stacking three sprites, for instance, your red satellite sprite would work with just one sprite per scanline. Anything you can color on just the top and bottom would work that way. You could also double-buffer the sprite table and do some flicker coloring by swapping it out every vertical blank. Unfortunately otherwise you need to accept two sprites on a line for two colors.

[matthew180]

To build on what Tursi said:

Sprites are actually shown on the line *below* where their y-coordinate indicates.  The 9918A only has four sprite pattern shift registers, which is why it can only display pattern data for up to four sprites on any given horizontal line.  There are two main steps to drawing the sprites:

1. Get a list of the four sprites to draw
2. Get the pattern information for the four sprites to draw and load the pattern data into the shift registers

To determine which sprites to draw, the sprite table is scanned starting during the blanking period at the end of the current scan line, and continues *through* the next scan line.  The accesses to the sprite y coordinates is interleaved with tile pattern memory access for the current line, as well as CPU window accesses.

While the list is being scanned, the sprites that were previously loaded into the shift registers are being shifted out.

Also at the end of the current scan line, during the blanking period, but *before* the scanning of the the sprite y coordinates, the pattern data for the list of four sprites that was just determined during the current scan, is accessed and loaded into the shift registers to be displayed during the next scan line.

Quote

The per-line-color trick you talk about is used a lot on the Atari 2600, Sometimes99er, they can move their objects around quickly and accurately enough (in truth they have to, or they don't get a game ).

I believe the 2600 has to draw the screen via software (kind of like the Timex Sinclare did), so most of the game logic only executes during the vertical refresh.  Also, since the software is doing the drawing, they know where the horizontal scan is at all times.

In the 99/4A, the 9918A is updating 262 lines at a rate of 60Hz (NTSC), which means a single scan line only takes about 63.61us, which is not a lot of time compared to the execution time of a 9900 instruction, which is somewhere between 4us and 94us depending on the instruction.  Even with horizontal interrupts (which the 9918A does not provide), you can't respond fast enough to really do anything *during* the current scan line, and you would have to be very efficient to affect the next scan line.

I attached (a rather large 1.6MB) image of the 9918A timing diagram, if anyone wants to see the low-level details.  I think it is cool.

Attached Files

•  1978 9918 Master Timing by Serigio Maggi.jpg   1.36MB   21 downloads

Edited by matthew180, Tue Feb 21, 2012 10:23 AM.

[matthew180]

Rocky007, cool game by the way!  Did you pre-order an F18A?  It would be nice to know if people are going to consider making games that take advantage of the new enhanced features, otherwise it is hard to justify adding any enhancements.  It would be possible to write a game that detects the F18A and enabled features like smooth scrolling around the maze, extra tile / sprite colors, etc.  Just a thought.  I can't wait to check out the game!

[rocky007]

Hi Matthew180,

Of course i already preordered your F18A and i already planned a game for it !... for H.E.R.O.,i can't promise enhanced version for now bec i'm counting the bytes to finish the game and it 260 levels...
it will be difficult to add extra things.  need to see when the game will be completed if some free space available.

[moulinaie]

matthew180, on Tue Feb 21, 2012 10:29 AM, said:

Rocky007, cool game by the way!  Did you pre-order an F18A?  It would be nice to know if people are going to consider making games that take advantage of the new enhanced features, otherwise it is hard to justify adding any enhancements.  It would be possible to write a game that detects the F18A and enabled features like smooth scrolling around the maze, extra tile / sprite colors, etc.  Just a thought.  I can't wait to check out the game!

But generallly, a special version of MLC could be released to take advantages of the enhanced possibilities of the F18A.
I also ordered one, and I think I will work on it.

That would require Tursi to make a F18A version of his great Classic99. I am now used to take advantage of his debugger to help me in the MLC development.

Guillaume.

[matthew180]

moulinaie, on Tue Feb 21, 2012 12:43 PM, said:

That would require Tursi to make a F18A version of his great Classic99. I am now used to take advantage of his debugger to help me in the MLC development.

I believe he is considering adding support.  Tursi?  He only likes to emulate real hardware, and since the F18A is going to happen, it believe it qualifies. :-)

There have been plenty of times I would liked to have had F18A support in Classic99 to help me debug my own mess!  That's kind of like a chicken and egg situation though.  It sure makes life easier having an emulator though, and access to the person writing it.

[Tursi]

I'm willing to add F18A support, partially because it's real hardware, partially because the extensions are minimal (I don't want to do a whole 9938, for instance), and partially because there is already software that supports some of these extensions (TurboForth 80-columns) and most importantly because I personally want to play with some of the modes myself. . Once the feature set is definately locked down and some free time coincides, I'd like to get them in there. Time is the main issue, since this will be the catalyst for the VDP rewrite.

[OLD CS1]

matthew180, on Tue Feb 21, 2012 1:27 PM, said:

I believe he is considering adding support.  Tursi?  He only likes to emulate real hardware, and since the F18A is going to happen, it believe it qualifies. :-)

Seems like a legit loop-hole to me.

[Willsy]

matthew180, on Tue Feb 21, 2012 10:13 AM, said:

I believe the 2600 has to draw the screen via software (kind of like the Timex Sinclare did), so most of the game logic only executes during the vertical refresh.  Also, since the software is doing the drawing, they know where the horizontal scan is at all times.

Correct. The Atari 2600 has no 'graphics chip' to speak of. You draw your screen by literally writing software to change the colour that is sent to the TV at a particular location on the scan line. The longer your routine takes to execute, the lower the horizontal resolution. Normally, game logic executes at the end of a frame.

The Atari folks call this technique 'racing the beam'.

[Tursi]

Willsy, on Wed Feb 22, 2012 4:22 AM, said:

Correct. The Atari 2600 has no 'graphics chip' to speak of. You draw your screen by literally writing software to change the colour that is sent to the TV at a particular location on the scan line. The longer your routine takes to execute, the lower the horizontal resolution.

Sort of true, but a bit over-simplified, The 2600 TIA can draw a scanline without CPU intervention. The playfield can handle 20 pixels in the first half of the screen, then automatically repeat or mirror those pixels for the second half of the screen. It can also automatically draw the pixels for two players and two missiles (8 pixels wide, though they can be stretched and other effects) and a ball (solid, but variable width).

The CPU is needed to manage the horizontal sync at the end of line, as well as to update the patterns for the playfield, players, and missiles. (Usually it also decides whether to turn the players and missiles on or off, otherwise the players vertically fill the screen).

Using careful timing, you can change the registers DURING a scanline to get effects like more sprites on a single line, or non-symmetrical playfields. To get higher horizontal resolution than the playfield's 40 pixels is actually achieved by manipulating the player/missile graphics in real time.

The 2600 forum here is worth a browse for anyone curious to see how far a really low-end system can be pushed, it's just amazing.

Apologies for the off topic.

[rocky007]

yes, just have a look on Boulderdash for Atari 2600 to see how far the limits can be pushed !  it's simply incredible !

[OX.]

Hi Rocky007, This rendition of H.E.R.O looks awesome!  Are you finished developing it yet?

[rocky007]

thank OX.  ..i started a pause in march and promised myself to finish it in may. But i have to agree that i'm not so trustable
i hope to have enough free time to finish it very soon

[OX.]

Anyone know what happened to Rocky and the TI99 version of H.E.R.O?

[moulinaie]

Rocky started again working on the HERO program.
But unfortunately, he needs some improvments in MLC and I can't get the time to do it to help him finishing his work.

Guillaume.