Darkhog Posted April 20, 2013 Share Posted April 20, 2013 I've read that when ANTIC (pretty accurate name now, huh?) is disabled (memory adress 559 dec or $22f hex = 0 ), atari operates about 30% percent faster. But I didn't notice any differences with PLOT operations, i.e. after setting this memory area to 0 and then restoring value after image has been drawn (to remove that nasty "rendering" behavior), time spent plotting was roughly same, the only change was that screen was blank until "rendering" been finished. What I'm doing wrong? More importantly, is there any faster version of PLOT for ACTION! ? Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted April 20, 2013 Share Posted April 20, 2013 Actually there is ... it's called POKEing directly to screen memory. As mentioned before, you figure out your screen memory from PEEK(88)+PEEK(89)*255, we usually assign this to a variable called SCR (at least I do) The method of plot differs according to which graphics mode you are in, but for our purposes, we will deal with the three most common situations: 1. Graphics 8. The screen has 40 bytes across, and there are only two colors, so each byte can be reduced to a series of 8 bits ... the 1 bits indicating an active pixel. This means each byte is 8 pixels wide. So for instance, let's say you want to plot a pixel at screen coords 0,0. You would make a chart like this: 10000000 (8 bits, the first pixel is activated) ... convert it to decimal (128 in this case) then POKE SCR+0,128. 2. Graphics 15 (or Antic mode E). Again we are dealing with 40 bytes, but as this mode uses 4 colors, the 8 bytes are arranged into bit pairs, as follows: 00 - BAK 01 - PF0 (color 1) 10 - PF1 (Color 2) 11 - PF2 (Color 3) So if you used this pattern: 11 01 10 00 ... you would have (using the Atari default colors) a 4 pixel pattern consisting of blue - orange - green - black (bg). To plot this, again convert it to decimal and POKE it to the correct SCR location. 3. GTIA MODES (Graphics 9, 10, or 11): 40 bytes again, but this time the 8 bits are divided into 2 nybbles, or groups of 4 bits. Each nybble can refer to any of the 16 color values in the GTIA modes. So for example, using this: 1100 0110 ... makes 2 gtia pixels of color 12 and color 6. To plot this pixel group, again you convert the 8 bits from binary into decimal and POKE it as before. Doing plots like this are WAY faster than using the plot command and saves time, but requires a bit more calculation. Now, if you are using character mode (like Graphics 0), you will be poking a single code to the screen which refers to your ATASCII character, however the screen codes are different from ATASCII. screen code 0 is a space char, for instance. You calculate your screen location as before, but you would need to refer to this table to figure out your character codes: http://www.atariarchives.org/mapping/appendix10.php You use screen codes 0-127 for characters, and 128-255 are inverses of 0-127. These are for Graphics 0 (Antic 2) and Graphics 12/13 (Antic 4/5) ... for Graphics 1 and 2 (Antic 6/7), it's different yet again (sigh) ... 64 characters only, and screen codes 0-64 plot the character using PF0 color ... then each range of 64 is used with the next PF color. The advantage here is, you can poke control characters like arrows or the clr character to the screen and it will display the char itself! You can even poke the return character (Inverse-escape, screen code 219) and have it show on the screen instead of it printing a carriage return. Quote Link to comment Share on other sites More sharing options...
Darkhog Posted April 21, 2013 Author Share Posted April 21, 2013 Text mode isn't problem, as speed of Print and Printe is good enough. My game runs on Graphics 7 (ANTIC's 13 if I didn't mess up). Will this work like mode 15? Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted April 21, 2013 Share Posted April 21, 2013 it's identical, as each screen line is 40 bytes. Your screen ram is cut in half, is the only difference. Quote Link to comment Share on other sites More sharing options...
Darkhog Posted April 21, 2013 Author Share Posted April 21, 2013 Is cut in half in 7 or 8? Also, is there any faster method that one used by Plot function to change color of specific pixel on the screen? This is very important for precise positioning objects such as software sprites (you can't rely on 3 player sprites and 4 missiles when you are trying to make bullet hell) and drawing procedural stuff (like blood splats). Another thing, are pixels in bytes organized in rows or columns? E.g. if I'd put byte 00011011bin onto screen, will it be arranged that: [00] [01] [10] [11] or that? [00][01][10][11] Quote Link to comment Share on other sites More sharing options...
+JAC! Posted April 21, 2013 Share Posted April 21, 2013 Come on, grap on the spirit of the 80ies again and POKE ANY ADDRESS WITHOUT FEAR.. and see what happens! It'll give you much more fun and understanding then this internet thing :-) 1 Quote Link to comment Share on other sites More sharing options...
+Larry Posted April 21, 2013 Share Posted April 21, 2013 ... just avoid that 800 "paperweight -- self destruct" vector from Analog magazine! -Larry Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted April 21, 2013 Share Posted April 21, 2013 (edited) The pixels are in rows from left to right in groups of 4. And to change just one pixel, you'd just need to do an add or subtract from the current byte on the screen. Example: You have this pattern on screen (using the Atari default colors: black for background, orange for PF0, green for PF1, blue for PF2)) orange-green-black-blue 01 10 00 11 This pattern converts to 64+32+2+1, or 99 Now let's say you wanted to plot an orange pixel in the third column. You would just take the value of the pixel for that column only, like so: black-black-orange-black 00 00 01 00 This is 4 in decimal. Then you add the 4 back to 99, and get the value of 103. This value will turn on the third pixel to orange but leave the others as is. So in short, you are adding or subtracting values on the binary level. Just do some experimenting, try poking the screen around in immediate mode, and see what happens. It's a good way of learning by doing, how the Atari creates it's bitmap graphics on the most basic level. Edited April 21, 2013 by Synthpopalooza Quote Link to comment Share on other sites More sharing options...
Darkhog Posted April 22, 2013 Author Share Posted April 22, 2013 (edited) I always thought that POKEing someone is impolite . But I'll try it, thanks. Also if I'd have byte 01 10 00 11 and I'd like to put 01 in fourth column? ORing it in wouldn't do a thing, what I should do? Edited April 22, 2013 by Darkhog Quote Link to comment Share on other sites More sharing options...
TMR Posted April 22, 2013 Share Posted April 22, 2013 Also if I'd have byte 01 10 00 11 and I'd like to put 01 in fourth column? ORing it in wouldn't do a thing, what I should do? No, if you OR the %11 in that fourth column with %01 you'll get %11 back (if a bit in one byte OR the other is set, set a bit in the result). AND can be used to clear bits first, so ANDing %01100011 with %11111100 it'll leave the other six bits you don't want to change intact whilst clearing the two you do. Once that's done you can OR it with %00000001 to set the bits you want. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted April 22, 2013 Share Posted April 22, 2013 PEEK the byte, AND it with %11111100, then OR it with %00000001. The general procedure for writing pixels to the display is: 1) Load byte 2) AND with background mask (to clear the bits you're going to change) 3) OR in new pixel bits 4) Store byte Quote Link to comment Share on other sites More sharing options...
Darkhog Posted April 22, 2013 Author Share Posted April 22, 2013 Thanks. Once I'll know bit of assembly, I'd try to make my own Plot routine. Maybe it'll be faster. Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted April 22, 2013 Share Posted April 22, 2013 And this is for when you do learn assembly, remember this: Try to use locations on page zero for temp storage when you do your routine, that will sharply cut down on your time spent executing code. Reason why: Zero page (locations $00 through $FF, or 0 through 255 decimal) only require one byte to process. This can double your routine's execution speed. One caution, is that real estate at zero page is at a premium, much of it is taken up by system routines and such. Good news is, since you aren't using BASIC, you have more zero page locations at your disposal. Quote Link to comment Share on other sites More sharing options...
Darkhog Posted April 25, 2013 Author Share Posted April 25, 2013 Bad news is that Action! occupies same locations as BASIC does and I hope to use Action! for game logic and other non-critical elements and assembly only when my game's performance is suffering by NOT using it. Quote Link to comment Share on other sites More sharing options...
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.