 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : PicoMite V5.07.08 betas
  Page 10 of 11   |
|||||
| Author | Message | ||||
| Volhout Guru  Joined: 05/03/2018 Location: NetherlandsPosts: 4246 |
I have not tried yes, but from reading te description, you coul have memory copy copy 64 bytes (8*8) where it copies 8 bytes, then skips 32 bytes, then copy the next, then skip 32 bytes, until it reached 64 bytes. If that is correct, it may be useable as a single command to BLIT a whole sprite. Testing will show if both read pointer an write pointer skip, or only the read pointer. Then it is not usable. Volhout Edited 2023-09-12 01:54 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9125 |
Wouldn't easily register unsigned char *p=&DisplayBuf[line * 160]; register unsigned char *q=&LayerBuf[line * 160]; register uint16_t *r=fbuff[nextbuf]; for(int i=0;i<160;i++){ register int low= *p & 0xF; register int high=*p++ >>4; register int low2= *q & 0xF; register int high2=*q++ >>4; if(low2)low=low2; if(high2)high=high2; *r++=(low | (low<<4) | (high<<8) | (high<<12)); } |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9125 |
Your wish..... PicoMiteVGA.zip Note the new optional parameter to not copy black MODE 2 CLS RGB(yellow) FRAMEBUFFER create FRAMEBUFFER write f Box 100,100,100,100,5,RGB(red),RGB(blue) FRAMEBUFFER blit f,n,100,100,30,30,100,100 CLS Box 100,100,100,100,5,RGB(red) FRAMEBUFFER blit f,n,100,100,60,60,100,100,1 |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4043 |
You've alluded to this before, what "description" are you reading ? As far as I can tell MEMORY COPY has no skip functionality ... and even if it did what you propose would only work if the buffers were the same width. Have I rolled a 1 on my "understand what is being talked about" check ? Best wishes, Tom Edited 2023-09-12 03:02 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4246 |
I was confused in reading memory copy integer. I tried it, and it does not what I want. You have to copy each of the 24 lines And you cannot copy 24 pixels since an integer = 8 bytes = 16 pixels (4bpp) So I can copy 16x24 and 32x24 but not 24x24. And I need a loop of 24 to do it. So it is going to be slow. Alternatively you could copy columns of 16 pixels wide and 24 high in a single memory copy integer. But again 16 or 32 pixels. 24 is not possible. Then maybe custom font is even faster. Or simply using sprites, and dynamically loading what is actually in this screen to save memory Thanks for brainstorming... Volhout Edited 2023-09-12 04:03 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
stanleyella Guru Joined: 25/06/2022 Location: United KingdomPosts: 2129 |
does any of this work for lcd non vga? looks interesting but too fast to follow the thread. |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4246 |
This works great !!! Thanks Volhout P.S. I was first confused about the extra parameter, but that was because in my test I used the blit to blit to layer L, where black is transparent. so blit black = transparent, do not blit black -> also transparent... P.P.S. there was a program in memory, and most commands had changed (index different). After reloading from filesystem all was fine. Edited 2023-09-12 05:53 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9125 |
V5.07.08b16 https://geoffg.net/Downloads/picomite/PicoMite_Beta.zip Consolidates the changes as above New command BLIT/SPRITE MEMORY address%, x, y, w, h BLIT and SPRITE are interchangeable This takes data from an area of memory specified by the "address%" and treats it as a RGB121 image with height h and width w. It then copies this to the current output with the top left at x,y This includes in firmware the idea presented here but makes it more powerful by allowing the blit to happen to any x,y coordinate and the area to be blitted to be any size including having a width which is an odd number. The command will output on F and L framebuffers for all Pico variants (as sepcified by FRAMEBUFFER WRITE) and also to the screen on the PicoMiteVGA when in mode 2. The command handles x,y,w,h combinations that may overlap the screen but cannot protect against an "address%" that is invalid or which is too small for the data requested. The code is optimised if w and x are even numbers so things like 24x24 sprites placed on a 24x24 grid will be extremely fast (c 0.2mSec) Simple example code MODE 2 a%=Peek(cfunaddr test) Sprite memory a%,3,37,5,5 Inc a%,16 Sprite memory a%,19,19,5,5 Do :Loop CSub test 00000000 'sprite 0 00FFFFFF FF000FF0 FFFFF000 0000000F 'sprite 1 00888888 88000880 88888000 00000008 End CSub Note that each character in the CSUB is effectively the colour code for one pixel and because the ARM processor is little-endian the order of writing to the screen for each word in the CSUB is p7,p6,p5,p4,p3,p2,p1 Also note in the example that although each "sprite" is 25 pixels (5x5) in the CSUB the sprite boundary must be on a byte boundary. In my case I have packed each sprite to 32 pixels but it could have been 26 pixels although that would have reduced readability of the code. Of course the sprites can be different sizes if required. The Basic code just has to know where each sprite starts in the CSUB. Also multiple CSUBs could be used if this helps readability. The real power of this is that if you store the CSUB in the library there is almost an unlimited number of mini images that can be available to the program to blit onto the display. The colour codes (0 to F) are: BLACK,BLUE,MYRTLE,COBALT, MIDGREEN,CERULEAN,GREEN,CYAN, RED,MAGENTA,RUST,FUCHSIA, BROWN,LILAC,YELLOW,WHITE Now what we need is a simple editor to create the CSUB from an image (Jim?  )I believe this new command can transform game writing on the Pico. Because it is so fast, screens can be assembled in the framebuffer very quickly and then copied to the display Edited 2023-09-15 18:48 by matherp |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4043 |
Neat. Now whilst you are on a roll how about: - Blit from buffer/screen to memory address; sometimes you want to make a temporary backup of an area of the display to restore later without having to reserve a whole frame buffer. Also you might want to add memory -> memory blits for convenience even though that is just a MEMORY COPY. - Blit from A to B for buffers and memory (and between memory addresses) where you can specify a colour (not just black) in A that should be treated as transparent when copied to B. I think with those present some of the old BLIT/SPRITE commands (and limits on number of sprites) become obsolete provided the programmer is happy to work with addresses. Best wishes, Tom. Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4246 |
Using the new V50708b16 on picomite VGA petscii Different methods to paint the world map into the window PicomiteVGA V50708b15 @ 252MHz 11 tiles wide, 7 tiles high Method time sprite write 56ms sprite write (tuned) 49ms sprite write (tuned, no world map read) 39ms framebuffer blit f,n 70ms framebuffer blit f,n (tuned) 62ms framebuffer blit f,n (tuned, no world map read) 52ms sprite memory 25ms sprite memory (no read world map) 19ms conclusion: the read of the world map takes 10ms (asc(mid$(a$(x),y,1))) may need to look at a more efficient way to store the world map The SPRITE MEMORY is not from library (yet) but it seems by far the fastest way to draw the 11x7 tiles window of the world map. It is so fast that brute force drawing all tiles is probably faster than implementing an algorithm to draw only the changed tiles. I will continue developing using the framebuffer blit (the slowest) until I have a consistent tile set (debugging is so simple: frambuffer copy f,n to see where things go wrong) and will start working on a way to get the same tiles in the library as a csub. This may require multiple CSUB's since there is only 128k program memory that should hold the CSUB in ASCII text before you can type "LIBRARY SAVE" and it gets compressed. Volhout EDIT: SPRITE MEMORY taking data from library is just as fast as from program memory Edited 2023-09-15 20:31 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4246 |
@Peter, Sometimes things surprise you. After things happen it is completely clear why, but the consequence may be severe. Therefore my request. I would like to have a warning message when adapting the OPTION MODBUFF. For much of the development I use the A: drive. And hourly I make a backup to B: (SD card). My unit had (as result from tests previously) still a large modbuffer. When I tried to remove the modbuffer (OPTION MODBUFF CLEAR) my complete A: drive was formatted. "loosing your sh*t means .... loosing your sh*t" (quote from "READY PLAYER ONE movie). This is one of those (rare) things where a warning would help...... Volhout PicomiteVGA PETSCII ROBOTS |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9125 |
OK No Will add a parameter to BLIT MEMORY that specifies a colour (0 to 15) to not copy BLIT/SPRITE MEMORY address%, x, y, w, h, [,col] NB: this will slow the transaction even when on byte boundaries Will consider Blitting from one framebuffer to another a sub area with a non-copy colour e.g. BLIT FRAMEBUFFER f1, f2, x1, y1, x2, x2 [,col] where f1 and f2 must be different and can be F, L, or (for VGA only) N That's it!!!!!!!!!! Will do Edited 2023-09-15 21:15 by matherp |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4043 |
Hi Peter, I'm honestly sorry to "go on" but I recognise a once in a while opportunity. Why not include w & h in what is stored in "memory sprites". Sure it will take up 4/8 bytes but it will save a bunch of MMBasic variable lookups when rendering these "memory sprites". Note that because of the way it works I don't think there is any use-case for using a different w & h when blitting out of memory. Can I counter with a use-case ? In PETSCII robots you don't need a full frame buffer to composite the map because some of the screen is taken up by the overlay that doesn't need to be updated to quite the same fidelity. So you save memory by just allocating a "memory sprite" for the map and use blits between "memory sprites" to fill it and then a memory -> screen blit to render it. Note this suggests it isn't just a MEMORY COPY because it would be nice to support the "colour not to copy" parameter. Best wishes, Tom Edited 2023-09-15 21:30 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9125 |
This becomes a programming nightmare for a limited use case so no. Hidden framebuffer space can already be used for storage as per Martin's ideas |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9125 |
I've replaced the b16 download. Changes as follows: BLIT MEMORY address%, x, y[,col] BLIT FRAMEBUFFER F/L/N, F/L/N, xfrom, yfrom, xto, yto, width, height [,col] You must now include the width and height of a memory sprite in the sprite definition as two 16 bit integers. This then avoids specifying them in the Basic command. The option colour(col) can be between 0 and 15 and if specified that colour will not be copied. If omitted all colours are copied. e.g. MODE 2 CLS RGB(green) a%=Peek(cfunaddr test) Sprite memory a%,3,3,0 Inc a%,20 Sprite memory a%,19,19,1 Do :Loop CSub test 00000000 00050005 00FFFFFF FF000FF0 FFFFF000 0000000F 00050005 11888888 88111881 88888111 00000008 End CSub The new command is basically the same as FRAMEBUFFER BLIT with the following differences: 1. Can only operate on framebuffers and, only in the case of the PicoMiteVGA, the screen. Cannot be used with a TFT screen. 2. Very much faster than FRAMEBUFFER BLIT 3. The option colour(col) can be between 0 and 15 and if specified that colour will not be copied. If omitted all colours are copied FRAMEBUFFER create FRAMEBUFFER write f Box 100,100,100,100,5,RGB(red),RGB(white) FRAMEBUFFER write n Sprite framebuffer f,n,100,100,1,1,100,100 Sprite framebuffer f,n,100,100,120,117,100,100,15 |
||||
vegipete Guru Joined: 29/01/2013 Location: CanadaPosts: 1109 |
Is there a specific value that indicates 'copy all colours"? Maybe -1? Otherwise, two of these BLIT commands, plus an if statement, are needed if transparency is determined by the user at run time. Visit Vegipete's *Mite Library for cool programs. |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4246 |
Peter, There is something wrong with the b16 release. 1/ Try Martin's SPRED (sprite editor) Create a sprite (just a new one, background color red, no need for fancy stuff) Save the sprite... all pixels are white. 2/ One of the last posts in the PETSCII thread, there is a zip "Layer.bmp" (RGB24 format) Just load image it in mode 2, and save image it (save will be in 4bpp format). The result is a 38k file (size is correct) that has all pixels green. No image. I have no idea what causes it. Martin's SPRED program does not use graphics commands, it creates the sprite file character for character. Volhout Edit: maybe it is caused by running a program that uses framebuffers prior a program that does not. Edited 2023-09-16 12:58 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9125 |
Is the above a long winded way of saying SAVE IMAGE is broken on the VGA version? Now fixed if you re-download Edited 2023-09-16 17:05 by matherp |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4246 |
Peter, Maybe... But sprite editor does not save an image,have not seen that command in the listing. I will try this evening. Away from home now. Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4246 |
Hi Peter, Afaik it is fixed. A quick check shows both editor and game work. Have not re-tried the csub sprites yet, more later. PicomiteVGA PETSCII ROBOTS |
||||
| Page 10 of 11 |
|||||
 Print this page |
