Appledog

User Tools

Site Tools

Trace:
sd:sd-8516_ppu

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
sd:sd-8516_ppu [2026/04/25 16:16] – appledogsd:sd-8516_ppu [2026/04/25 16:18] (current) – appledog
Line 131: Line 131:
 === Fast tiles and sprites in BASIC with PLINE === Fast tiles and sprites in BASIC with PLINE
 If you have a smart drawing routine that reads contiguous pixels, then clusters of pixels can draw in ~1 cycle. So instead of having to call PPIXEL four times for the top row of a sprite, if the pixels are next to each other they can be detected as such as drawn via PLINE. While this might not be practical on-the-fly, it is interesting to consider a packed image format that would allow this to operate quickly; i.e. store the sprite data itself as a series of line draws. In a 16x16 sprite it is conceivable you could use about half the number of PLINE calls as you would use PPIXEL. The difference is that you would need a special format for storing the image data. This idea fits BASIC's "DATA" statements very well as it would be in a compressed format. The idea is you would store images in a kind of bytecode, and then the BASIC ''BLIT'' routine would read that format to quickly draw a sprite to screen. Of course, there is (will be) a PPU BLIT soon, so no one would use PLINE for this -- but it's possible to do so. If you have a smart drawing routine that reads contiguous pixels, then clusters of pixels can draw in ~1 cycle. So instead of having to call PPIXEL four times for the top row of a sprite, if the pixels are next to each other they can be detected as such as drawn via PLINE. While this might not be practical on-the-fly, it is interesting to consider a packed image format that would allow this to operate quickly; i.e. store the sprite data itself as a series of line draws. In a 16x16 sprite it is conceivable you could use about half the number of PLINE calls as you would use PPIXEL. The difference is that you would need a special format for storing the image data. This idea fits BASIC's "DATA" statements very well as it would be in a compressed format. The idea is you would store images in a kind of bytecode, and then the BASIC ''BLIT'' routine would read that format to quickly draw a sprite to screen. Of course, there is (will be) a PPU BLIT soon, so no one would use PLINE for this -- but it's possible to do so.
- 
  
 == PRECT and PFRECT == PRECT and PFRECT
-Tested and working. 160,000 rps and up in a normal loop. +''AH=$03 draw_rect''\\ ''AH=$04 fill_rect''\\ Tested and working. 160,000 rps and up in a normal loop.
- +
-== PCLEAR +
-Clears screen to color in cl. Tested and working.+
  
 == PCIRCLE and PFCIRCLE == PCIRCLE and PFCIRCLE
-Draws circles. Tested and working. Circles draw depending on their size:+''AH=$05 draw_circle''\\ ''AH=$06 fill_circle''\\ Draws circles. Tested and working. Circles draw depending on their size:
  
 ^ Radius ^ Draw speed ^ Example usage ^ ^ Radius ^ Draw speed ^ Example usage ^
Line 148: Line 144:
  
 For any meaningful use case, this is probably good enough. At 100,000+ circles a second at radius 30 and under, you could write any kind of game with this circle. For any meaningful use case, this is probably good enough. At 100,000+ circles a second at radius 30 and under, you could write any kind of game with this circle.
 +
 +== PCLEAR
 +''AH=$07 clear-to-color''\\ Clears screen to color in cl. Tested and working.
 +
sd/sd-8516_ppu.txt · Last modified: by appledog
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki