Mclaneinc Posted January 17, 2018 Share Posted January 17, 2018 I'll push this a little sideways which won't hurt as its already bordering on daft as it is. I always presumed the use of AA was only really usable in a fluid way on newer more powerful machines because of the calculation time needed. So I presumed that AA would not feature especially on a moving image on an Atari because it wasn't realistically viable because of the CPU. IE, it could do it but the frame rate would be nil I just guessed that BB uses a drawing routine that 'mimics' AA to a degree? Just trying to a. find out if I'm right and b. pulling this away from a normal Emkay thread Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 17, 2018 Share Posted January 17, 2018 AA is an effect. For something like sprites if enough colours are available for static defined frames you can get it for free. No extra expenditure of CPU, just the need to have a palette entry that's a blend of 2 other ones. For something like a shaded poly game like Carrier Command you could get it by using more processing power. By my observation but without having looked into the code I would say that Ballblazer falls in the middle of those 2 scenerios but probably more towards the "for free" end of the spectrum. Proper AA on something like a scaled and rotating vector object or arbitrarily drawn lines comes at a fairly big cost (by old computer standards at least). Fudged AA or "free" AA like in this game would be fairly cheap. Likely there are code optimizations going on where adjacent coloured horizontal regions are rendered brute-force a byte at a time and probably some table-based lookup that moves along dependent on the angle. Having the extra colour in for AA might mean a bit of extra memory used, or might come at no extra cost there. Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted January 17, 2018 Share Posted January 17, 2018 Thank you kind sir... Quote Link to comment Share on other sites More sharing options...
VladR Posted January 17, 2018 Author Share Posted January 17, 2018 Thanks for the checkerboard examples. I actually haven't seen Dimension X before (and none of those C64 demos). So, it's definitely going to be a good source of inspiration. Let's start breaking them down: TrailBlazer: - no horizontal scrolling - fixed perspective - 38 rows - Nearest segment is 16 pixels tall, so that's the max number of frames we need to prestore - (160*38) / 2 = 3,040 pixels -> 760 Bytes - since there is no scrolling, we only need to update the bytes around the 4 inner edges (during forward movement) - The top 8 scanlines don't even have that many bytes, so the total is going to be smaller than 38*4 - In my excel, the breakdown of the edges was approximated to 268 Bytes, and I'd hazard a guess it's 256, as plenty edges don't need to store 2 bytes, just 1 (the cost of doing that is during offline pre-processing, so it doesn't matter at runtime) - 268*38 = 10,184 Bytes -> so all frames fit under 10 KB - Unrolled Copying those 268 Bytes in a loop costs 10 cycles per byte (LDA ptrData,X STA $3001...$3300 INX) and a bit of memory, thus 268*10 = 2,680 cycles per field PMG - 2 players+2 missiles per ball - Height : 20 Bytes - 2 players : 20*2 = 40 Bytes per ball A crude first version of PMG scrolling : LDX #40 LoopStart: 5 LDA (ptrFrom),Y 6 STA (ptrTo),Y 2 INY 2 DEX 3 BNE LoopStart 18 Cycles per Byte Moved 80 Bytes per 2 balls 1440 Total Cycles for 2 balls (we could save loop overhead by merging both balls into same loop, or even unroll (that'd cost just 40*5 = 200 Bytes per ball and save (5*40)*2 = 400 cycles out of 1,440) Remaining cycles for audio+input+game logic after most expensive components are taken care of: NTSC PAL 29,833 Start 35,800 Start -5,673 Antic -5,673 Antic -7,980 DLI (38*2*105) -7,980 DLI -5,360 2 Fields -5,360 2 Fields -1,440 PMG -1,440 PMG ----------------- ----------------- 9,380 Available 15,347 Available The next most expensive thing that game needs to update is the 38*2=76 Byte color array that will be indexed during DLI. That should be doable in 1,500 cycles (as the main array will be prepared at level load-time), still leaving more than enough room for audio and input and the couple flickering stars. The PAL version certainly could have more things on screen. Can somebody give me an average ballpark estimate for 2-channel audio cycle cost ? Quote Link to comment Share on other sites More sharing options...
VladR Posted January 17, 2018 Author Share Posted January 17, 2018 Dimension X: - resolution: 160x192 - 1 field, 70 scanlines - there's only 8 color changes over the field (one per each segment) If we don't use Antic's HScroll, this is the breakdown: NTSC PAL 29,833 Start 35,800 Start -9,609 Antic -9,609 Antic -840 DLI (8*105) -840 DLI -200 PMG -200 PMG ----------------- ----------------- 19,184 Available 25,151 Available 25,000 is enough for brute-force redraw of the rectangle edges... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 17, 2018 Share Posted January 17, 2018 Just toying with pc proto. This has 32 steps at the moment so its just matter of tweaking the parameters. Horizontal lines would be the dli flips. Resolution etc is not tweaked to say 320x200 1 Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 17, 2018 Share Posted January 17, 2018 Dimension X: - resolution: 160x192 - 1 field, 70 scanlines - there's only 8 color changes over the field (one per each segment) If we don't use Antic's HScroll, this is the breakdown: NTSC PAL 29,833 Start 35,800 Start -9,609 Antic -9,609 Antic -840 DLI (8*105) -840 DLI -200 PMG -200 PMG ----------------- ----------------- 19,184 Available 25,151 Available 25,000 is enough for brute-force redraw of the rectangle edges... Small correction. DX is in 320x res. Its antic mode f. Quote Link to comment Share on other sites More sharing options...
emkay Posted January 17, 2018 Share Posted January 17, 2018 Small correction. DX is in 320x res. Its antic mode f. Seems, you're getting old. The scoreboard is F the chessboard is E . Quote Link to comment Share on other sites More sharing options...
VladR Posted January 17, 2018 Author Share Posted January 17, 2018 Small correction. DX is in 320x res. Its antic mode f. That would explain 2 colors per segment. I swear I didn't notice it's highres... However, The Antic cost remains the same, as it stores double the amount of pixels in byte, right ? Quote Link to comment Share on other sites More sharing options...
emkay Posted January 17, 2018 Share Posted January 17, 2018 cough... Quote Link to comment Share on other sites More sharing options...
VladR Posted January 17, 2018 Author Share Posted January 17, 2018 On the topic of Antialiasing, while I don't have much more to add than Heaven and Rybags said, just a quick reminder: 1. Antic scrolling : the antialiasing is indeed free, as it's just a pixel value stored in the scanline (not updated at run-time), so scrolling it doesn't impact framerate (Antic takes care of that for us) 2. CPU Scrolling: antialiasing is not free, as instead of 1 byte, we have to update 2 bytes per edge (there's 3 pixels that scroll), so it's going to cost double Example with CPU Scrolling: A: Color of Left Quad B: Color of Right Quad X: Antialiased pixel AAAA.XBBB.BBBB : Starting point AAAA.AXBB.BBBB : Scroll once AAAA.AAXB.BBBB : Scroll once AAAA.AAAX.BBBB : Scroll once AAAA.AAAA.XBBB : Ending point Running condition per scroll (CMP + BNE -> 6-7 cycles) is not going to be faster than simply storing the second value blindly. But perhaps there's an unrolled scenario that could take care of that, though I don't think it'd be possible without jumptable, which would grossly inflate the costs for every single edge... Quote Link to comment Share on other sites More sharing options...
VladR Posted January 17, 2018 Author Share Posted January 17, 2018 I worked out an example of scrolling and found out that I don't need to update 2 bytes without antialiasing, just 1 byte. That literally halves the scrolling cost I posted few my posts back (with the example of different perspective). Example of scrolling right BBBB.BBBB.AAAA.AAAA : Start BBBB.BBBB.BAAA 1 BBBB.BBBB.BBAA 1 BBBB.BBBB.BBBA 1 BBBB.BBBB.BBBB 1 BBBB.BBBB.BBBB.AAAA : End I have 130 edges in the 160x48 field. So, that's 130 Bytes to update. I came up with this code (must be unrolled for all 48 edges) that I believe is the fastest possible: Scanline 48 : Edge 1 3 LDX sl48_ByteOffset ; X = ByteOffsetFromLeftScreenEdge 3 LDY sl48_ByteIndex+1 ; Y = EdgeScrollValue 4 LDA EdgeSTAValue,Y 5 STA sl48_vidPtr,X Scanline 48 : Edge 2 3 LDX sl48_ByteOffset+2 ; X = ByteOffsetFromLeftScreenEdge 3 LDY sl48_ByteIndex+3 ; Y = EdgeScrollValue 4 LDA EdgeSTAValue,Y 5 STA sl48_vidPtr,X 15 cycles per edge 130*15 = 1,950 cycles for all edges of whole field. Of course, updating the table will cost few thousands cycles each frame (haven't worked out yet exactly how much). I think this is a good candidate to implement and see if there's something I missed. Here's the adjusted cycle breakdown for 1 field: NTSC PAL 29,833 Start 35,800 Start -5,673 Antic -5,673 Antic -1,950 Scrolling -1,950 Scrolling -7,600 Draw Field -7,600 Draw Field ------------------ ------------------ 14,610 Available 20,577 Available Quote Link to comment Share on other sites More sharing options...
jmccorm Posted January 17, 2018 Share Posted January 17, 2018 (edited) I didn't see one time-saving (edit: or space-saving) technique explicitly mentioned. if I missed someone else's coverage of this technique, consider this a remedial version to help us dumb people to grasp it. In not, enjoy the new observation: It was mentioned that a DLI was done for each segment. You had a DLI to draw the horizontal anti-aliased line across the screen at almost almost no cost. Then you had a DLI to restore the light/dark squares back to normal. Except, it can either set the colors as light/dark, or it can invert them and set them as dark/light. This is important because if your update technique is to paint only the difference between the existing screen and the next screen, if there is a very large horizontal difference, you can invert the colors and draw a smaller change. If blocks are 32 pixels wide, and there was a move of 26 pixels, instead of drawing a 26 pixel offset update, you could invert the colors and then draw a much smaller 6 pixel offset update. The worst case would be an update that moves a block exactly half of its horizontal width (16 pixels). Anything more, and you can flip. (And it looks like it limits max horizontal speed so where a front-row block effectively alternatives between white/black, because anything much more would give a weird rotoscope effect.) Of course, you can be clever about your maximum speed and the size between steps to avoid this and some other issues. So when I actually went to pull it up in Altirra and did the Control-F8 to pull up the color Display List analysis, I saw that Ballblazer actually does invert the light/dark color palette, but it appears to be doing it for a different reason. I didn't check too far into it, but I'm guessing that they used horizontal scrolling in combination with this technique? I could very well be wrong on that. The point here, though, is that if you're updating the difference between the current image and the next image, the problem is only half as expensive as the ordinary worse case because you can invert the color palette and move everything the complete width of a square for free. If you're using a different rendering method, like holding the pre-rendered lines in extended memory, you may only need to hold half of those, because the rest of the cases can be generated by inverting the color of the squares. I hope this helps introduce a new technique into the discussion. If not, then I hope that I ended up rephrasing someone else in a way that us dummies could more easily pick up on it. Edited January 17, 2018 by jmccorm 1 Quote Link to comment Share on other sites More sharing options...
VladR Posted January 17, 2018 Author Share Posted January 17, 2018 3 pages ago, I was under impression that you have to redraw the screen even for a forward movement, but this morning I actually didn't just think it through, but layed out the DLIs for one segment in editor and realized: - when you do HScroll for each scanline you are using the DLI to change the colors (nothing new here) - But why change the colors only per segment (e.g. ~8 times per field), if you are paying the CPU cost per each scanline ? - You might as well alternate the 2 colors in the DLI at each and every scanline (changing 2 colors in DLI is easy) - this means no precalced frames and would fit in 16 KB machine too Each scanline would have to have a full quad width on each side of screen (e.g. few pixels for top scanline but over a hundred for bottom scanline) Thus you would subtract 5,673 cycles for Antic and 10,080 for DLI, leaving you with 14,080 for NTSC and 20,047 for PAL. That's certainly more than enough to update the 48-byte color array you would index during DLI (which, BTW, even precomputed, takes only 48*48 = 2,304 Bytes). See ? It's no fun and challenge to do it the Atari way. But to try to achieve the same just via CPU, is much more challenging Also, I'd personally like to use this effect in my flatshader, (doublebuffered which obviously implies no DLI), so I have an agenda here to get it to run on 6502 without Antic as this effect could be used for texturing axis-aligned polygons... Quote Link to comment Share on other sites More sharing options...
jmccorm Posted January 17, 2018 Share Posted January 17, 2018 (edited) Related, here is Altirra's representation of the display colors and the pixels for an active game of Ballblazer. The playfield is painted with pixels of three colors (area color 0, border line color, area color 1). The playfield is only striped in one direction. Moving forward/backwards is complete display list color work, and the screen pixels are not repainted/redrawn. Moving left/right looks like horizontal scrolling plus display list dark/light color swapping (to save on stored image space). Super easy for those sneaky Lucasfilm guys. Edited January 18, 2018 by jmccorm 2 Quote Link to comment Share on other sites More sharing options...
VladR Posted January 18, 2018 Author Share Posted January 18, 2018 Altirra can do that ? I had no idea. Thank you for visual confirmation of my previous post's theory! Quote Link to comment Share on other sites More sharing options...
jmccorm Posted January 18, 2018 Share Posted January 18, 2018 Altirra can do that ? I had no idea. Thank you for visual confirmation of my previous post's theory! Thank phaeron for including some good debugging & reverse engineering tools. I wish I knew of a good tutorial which walked through many of them. 1 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted January 18, 2018 Share Posted January 18, 2018 Little factoid about Ballblazer and Rescue on Fractalus: Lucasfilm developed the games under a custom designed C cross compiler that ran on their Sun-1 hardware. -Thom 1 Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 18, 2018 Share Posted January 18, 2018 cough... jpg.jpg Yup. Me getting old. My memory saved the image when you get hit and I thought I remember that semi transparent shine through of play field Quote Link to comment Share on other sites More sharing options...
emkay Posted January 18, 2018 Share Posted January 18, 2018 Moving forward/backwards is complete display list color work, and the screen pixels are not repainted/redrawn. That's the point. Quote Link to comment Share on other sites More sharing options...
emkay Posted January 18, 2018 Share Posted January 18, 2018 See ? It's no fun and challenge to do it the Atari way. But to try to achieve the same just via CPU, is much more challenging Actually, the most challenging on the Atari is to get things done There are "gazillion" prods on the road of development that never reached the mount Fuji, because people didn't use the Atari's best features 1st and add CPU as good as possible. Ballblazer is working fine, it was there back in the 80s and it was fun to play. Quote Link to comment Share on other sites More sharing options...
roland p Posted January 18, 2018 Share Posted January 18, 2018 (edited) It would be fun to create real anti-alias pixels for the diagonals instead of the current fake ones. You have to account for the errors, generated by skewing an already diagonal line, too though... Edited January 18, 2018 by roland p Quote Link to comment Share on other sites More sharing options...
emkay Posted January 18, 2018 Share Posted January 18, 2018 Moving left/right looks like horizontal scrolling plus display list dark/light color swapping (to save on stored image space). Super easy for those sneaky Lucasfilm guys. A question about "super easy"... ? In post #106 the video shows the vertical lines zoomed isometric and moving. You think, this effect is simple horizontal scrolling in the Atari game? Quote Link to comment Share on other sites More sharing options...
jmccorm Posted January 18, 2018 Share Posted January 18, 2018 (edited) A question about "super easy"... ? In post #106 the video shows the vertical lines zoomed isometric and moving. You think, this effect is simple horizontal scrolling in the Atari game? Ouch! I like you emkay, but you're busting my balls twice in a row now for the same post? First, because my simple description somehow restated someone's point about something (which I said that I likely would be doing), and now for claiming that they made the problem too easy? So, let's see how I'll defend myself on this one. As I mentioned, I studied the effect in Altirra's Color Analysis GTIA Visualization mode running on a live game. I fiddled with the controls to get a good understanding of the interactions between how I moved they joystick, what pixels were scrolled on-screen, and what was going on with the colors on each scanline. Unless I'm missing something obvious in the live interaction of these elements, I think I've got it. But I'm willing to learn more! A general list of the effects used: 1] An extremely simple pixel layout, as shown in post #115. That's the whole playfield (as far as a snapshot of visible pixels) in video memory. No pixels appear to be redrawn or modified, just horizontal scrolling to control what pixels are shown on-screen. 2] A DLI to slice up the strips vertically and to create light/dark squares (and the anti-aliased vertical borders) and to provide the illusion of forward/reverse movement. 3] hscrol to slide the entire playfield left/right but only as far as one full stripe to partially address horizontal movement. 4] An inversion of the light/dark squares in the DLI (effect #2 above) to replay the same hscrol area and address the rest of the horizontal movement problem by making the square that we're scrolling across appear to be the opposite color. So that's basically a rewording of what was in that message. I hope I'm not misunderstanding your question. Ballblazer's playfield (and playfield movement) appears to be a combination of horizontal scrolling and DLI. It seems simple and smart to me. If I'm just being boneheaded here, let me know where I'm going wrong with this? EDIT: Or maybe you're not asking about horizontal scrolling at all. Was it my selection of the word "easy"? I view it as easy in comparison for far more difficult techniques to achieve the same effect. Or maybe you're saying that Lucasfilm used far more than those 4 things, and there are pixels being redrawn or some other interesting factor used to coerce the Atari to present the playfield? Or the non-obvious contributions, like the carefully defined widths or speeds? I might be missing some context along with a very clear question in order to understand the full flavor of what you're chasing. Edited January 18, 2018 by jmccorm Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 19, 2018 Share Posted January 19, 2018 Ouch! I like you emkay, but you're busting my balls twice in a row now for the same post? First, because my simple description somehow restated someone's point about something (which I said that I likely would be doing), and now for claiming that they made the problem too easy? So, let's see how I'll defend myself on this one. As I mentioned, I studied the effect in Altirra's Color Analysis GTIA Visualization mode running on a live game. I fiddled with the controls to get a good understanding of the interactions between how I moved they joystick, what pixels were scrolled on-screen, and what was going on with the colors on each scanline. Unless I'm missing something obvious in the live interaction of these elements, I think I've got it. But I'm willing to learn more! A general list of the effects used: 1] An extremely simple pixel layout, as shown in post #115. That's the whole playfield (as far as a snapshot of visible pixels) in video memory. No pixels appear to be redrawn or modified, just horizontal scrolling to control what pixels are shown on-screen. 2] A DLI to slice up the strips vertically and to create light/dark squares (and the anti-aliased vertical borders) and to provide the illusion of forward/reverse movement. 3] hscrol to slide the entire playfield left/right but only as far as one full stripe to partially address horizontal movement. 4] An inversion of the light/dark squares in the DLI (effect #2 above) to replay the same hscrol area and address the rest of the horizontal movement problem by making the square that we're scrolling across appear to be the opposite color. So that's basically a rewording of what was in that message. I hope I'm not misunderstanding your question. Ballblazer's playfield (and playfield movement) appears to be a combination of horizontal scrolling and DLI. It seems simple and smart to me. If I'm just being boneheaded here, let me know where I'm going wrong with this? EDIT: Or maybe you're not asking about horizontal scrolling at all. Was it my selection of the word "easy"? I view it as easy in comparison for far more difficult techniques to achieve the same effect. Or maybe you're saying that Lucasfilm used far more than those 4 things, and there are pixels being redrawn or some other interesting factor used to coerce the Atari to present the playfield? Or the non-obvious contributions, like the carefully defined widths or speeds? I might be missing some context along with a very clear question in order to understand the full flavor of what you're chasing. You nailed it down. I guess thats what I tried to say some posts earlier. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.