> On 2020-07-30, at 20:17, smf <smf_at_null.net> wrote: > > On 30/07/2020 16:19, silverdr_at_wfmh.org.pl wrote: >> - bitmap data is not bound to screen position so the place the desired graphics will get displayed can be chosen arbitrarily, which can be noticed on the video above > > Ok, so it looks like the effect when you put data in a different bank or > interleaved in a font and switch between them, but without the complexity. I am not fully convinced I understand the relation so let me reiterate how this works. When you do "regular" split-screen effect, the hires (or character) data on different portions of the screen can in fact come from different memory regions. The typical thing of the day was displaying some stuff in the upper/middle portion of the screen in one mode (hires/multi/multi-font/etc) coming from one memory area and/or VIC membank, and below that a section in another mode (often regular text screen) coming from another memory area/membank. The limitation of that is that unless rastertime costly tricks like FLD/VSP are employed, the data to be displayed needs to be at specific locations in specific memory areas. And even if one could sacrifice that much rastertime, still the above mentioned tricks were limited in other ways. If I am not mistaken now one can shift displaying the upper memory regions down the screen and the left-hand regions to the right but not the other way around. IOW at least part of the data was hard-bound to a specific screen location and couldn't be displayed elsewhere. Think lower-right corner data displayed in the upper-left one without moving bits around. Please correct me if I am wrong on that - I surely could refresh mem cells on those. On top of that doing even simple vertical split-screen incurs high rastertime toll. Last but not least all that graphics bits we talk about need to occupy the same memory, which could otherwise be used for program code. Now enter BeamRacer - an arbitrarily sized (memory limited of course) piece of linear[*] bitmap data or freely selectable portion of it can be displayed at any screen location, similar in this aspect to how hardware sprites work (except dimensions). This means one can create a "sprite" picture of any dimensions (including the standard, VIC-II sprite dimensions of 24x21 pixels and display it anywhere on the screen. Obviously this can also be animated, etc. Oh, and did I mention that the graphics can be flipped/mirrored/inverted/EORed at [close to] no cost? ;-) https://www.dropbox.com/s/fmffxzh8dkbvowf/flipped.jpeg https://www.dropbox.com/s/ub7ntmuzzk368t1/mirrored.jpeg The main limitation is compositing, which VIC does automatically for its hardware sprites. In this aspect the described BeamRacer way is more similar to a fine granularity split-screen rather than sprites. > Could you create a 32x32 tile based bitmap screen? Again - not sure I understand what you mean but if I understand correctly then yes, you can create something like a 32x32 pixel font and place the glyphs on screen in a similar manner to how the regular text screen works - by putting a "screen code" where appropriate. Of course the glyphs don't have to be alphanumeric. They can be any kind of graphic tiles. * - as can be read from e. g. any PBM file -- SD!Received on 2020-07-31 17:00:03
Archive generated by hypermail 2.3.0.
