 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 : PicoMiteVGA: SPRITE MEMORY
| Author | Message | ||||
Hawk Senior Member  Joined: 15/07/2021 Location: AustraliaPosts: 141 |
I'm just getting up to speed with the SPRITE MEMORY command. Is this the command that allows sprites to change appearance by pointing to a different region of memory for its data? Is a sprite actually created, or it is a portion of memory just copied to the screen/framebuffer? One thing I don't understand is that the sprite is not allocated an ID as other sprites are. So all the other commands that manipulate sprites won't have any effect on these sprites. |
||||
Martin H. Guru  Joined: 04/06/2022 Location: GermanyPosts: 1113 |
It is a portion of memory just copied to the screen/framebuffer. CSUB(s) can be used as the source memory you copy from. so you can determinate the Sourceadress by using spad%=Peek(cfunaddr csubname) Like this: Mode 2:CLS RGB(white) spad%=Peek(cfunaddr SPRITES) Sprite memory spad%,148,106,9 ' Source, x-pos, y-pos, transparent color CSub SPRITES 00000000 'Offset 0 'PL0100 is compressed 801C0018 929F0698 9F042103 22012103 24039D03 25019B06 24029908 99072101 91042403 22049A02 9B029105 91042302 21059A03 A2019908 97092103 01C1A101 01320413 019502A2 1201C2A1 11311351 A1C20131 A1019402 511102C2 311252F1 01A1C201 01930191 1102C2A1 1153F151 02A30131 01930191 531202A2 A1033211 95019101 06311306 01910191 04320197 01910532 04180198 01910191 02530197 91053112 53019801 91045302 97019101 11025301 91013151 91019101 12019801 03310331 01910191 06530199 01910191 5111019A 01910131 01910191 029B0191 01910331 01910191 0191059C 919F0191 00009E03 End CSub Peter (matherp) posted a little Program, which translates every *.spr File in a Folder to one CSUB, compresses them only if the result is smaller than uncompressed and also generates the Offsettable. There is no Sprite-ID using this command. If you have more than one Sprite, you have to adress them with an offset-tabel. The advantage of this is that the number of sprites is limited only by the memory and the you can choose the transparent color. But, you lose the advantages such as collision detection, background buffering, etc., so your program has to take care of that. hope that helps, Cheers Martin Edited 2024-01-22 18:08 by Martin H. 'no comment |
||||
| Hawk Senior Member Joined: 15/07/2021 Location: AustraliaPosts: 141 |
Thanks for the explanation. So it sounds like it’s less of a sprite, and more of just an image. Is there a method of reading the image data at the intended location on the display so that it can be stored manually, and then replaced at a later time? I remember doing this sort of image manipulation in Turbo C.  |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4233 |
Hi Hawk, When the image data is on screen, and you want to store it (on SD card) you can use SAVE IMAGE "name.bmp" or SAVE COMPRESSED IMAGE "name.bmp" Martin wrote a program BMP2SPR.bas that converts a BMP image to sprite data (just in case you need it). The Picomite works with BMP (compressed or raw). Saving in JPG or PNG is not in PicoMite Basic. Volhout P.S. you can also "LOAD IMAGE "xxx.bmp". Load image is compatible with compressed and ram images. Edited 2024-01-23 07:00 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
vegipete Guru Joined: 29/01/2013 Location: CanadaPosts: 1109 |
Look at SPRITE READ. Visit Vegipete's *Mite Library for cool programs. |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6787 |
@ Hawk The PicoMite doesn't have "true" sprites, they are all handled in firmware. Consequently there are restrictions that you don't get with sprites handled by hardware video controllers. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Hawk Senior Member Joined: 15/07/2021 Location: AustraliaPosts: 141 |
Thanks @mixtel, I understand that the PicoMiteVGA has “software sprites”, but all the other SPRITE commands reference a sprite Id, whereas SPRITE MEMORY doesn’t. The copied data is not associated with one of the software sprites at all. It’s more like the “putimage” function back in Turbo C days. This new command may allow implementation of custom software sprites which manage their own data, although that would be a lot of work in BASIC and not as fast as the kernel sprites. I’ve still been trying to work out how I can modify the appearance of an existing sprite to animate it. |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4233 |
Vegipete has written Simple Sprite Edit, that helps designing animation. Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1113 |
So far correct, but you can also write the "image" to the "layer" level, so you don't have to worry about caching the background. The "video chip" in the Pico is the 2nd CPU, which takes care of the VGA image structure independently of your program and also which layer of the image memory is displayed. "Real software sprites" would be a significant programming effort of their own. Caching the background, ANDing with the mask-data, and ORing with the sprite data and write the whole thing back into the screenmemory. And that for every Byte BG ="10101010" Mask ="11000011" Sprite="00111100" BG AND Mask: "10101010" AND "11000011" = "10000010" This OR Sprite:"10000010" OR "00111100" = "10111110" With every change you have to access both the cashe and the screen data. None of this is something you want to do in BASIC.  Save the individual animated spritestates one after the other in the "CSUB" and call them one after the other by changing the source address. Cheers Martin Edited 2024-01-30 14:52 by Martin H. 'no comment |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4233 |
There are sprite commands in PicoMiteVGA that restore the background when moving the sprite while using a single layer. sprite support is actually quite good. Since there can only be 127 commands, the BLIT MEMORY was grouped with the sprite commands, and is called SPRITE NEMORY, but it is a blit. The other sprite commands actually work on sprites. There can be some 30 sprites in PicoMiteVGA Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Hawk Senior Member Joined: 15/07/2021 Location: AustraliaPosts: 141 |
I agree. I was enjoying using the sprite commands to move objects around the screen. I only ran into problems when I wanted to change the bitmap associated with a sprite. I need to get back to solving this problem. Thank you. That explains why the command seems a bit out of place. When you think of it as BLIT MEMORY it makes far more sense, and I understand that for the PicoMiteVGA, BLIT and SPRITE are interchangeable. |
||||
| Hawk Senior Member Joined: 15/07/2021 Location: AustraliaPosts: 141 |
That sounds doable. It sounds like I might need that tool to convert my bitmaps into CSUBs afterall. Does MMBASIC handle it if the CSUBs are different sizes? Although for the animation that I have in mind, I can set the unused pixels as transparent and keep the sprites the same size. A little bit of wasted data. It's time I updated my firmware to the latest release so that I can take advantage of these new changes. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3801 |
CSUBs were added as a way to call (non-Basic) code (in C, but could be anything) so can be just about any size. John Edited 2024-01-31 18:40 by JohnS |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4233 |
Yes, graphical elements disguised as sprites in a Csub can be virtually any size. FlappyBird uses 8*8 as smallest, and 195*50 as largest in one Csub.. Volhout Edited 2024-02-01 02:12 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
 Print this page |
