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 : PICO PETSCII
Page 3 of 38 | |||||
Author | Message | ||||
Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1113 |
Hey Daniel, even with Peters Routine, if I move all Tiles to CSUB, there is not enough memory to keep all 256 24x24 Tiles at the same Time. So I think I have to tokenise each Tile to 3x3 Bytes, were each adresses a 8x8 Pixel Picture-Element. Like in the original PET Version, but with 8x8 Picture-Element instead of PETSCII characters. This has to fit in 256 8x8 Tiles, which costs, in comparison,just a fragment of the memory. If it is hidden under the Border it would need no additional Memory at all. But, I have no idea how long it will take me to do the conversion. Cheers Martin 'no comment |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9122 |
256 24x24 tiles will easily fit in the library if loaded say 64 at a time 24*24=576 pixels = 288 bytes + an overhead of 4 bytes / sprite = 292 bytes * 256 = 73Kbytes Library size on PicoMiteVGA is 100K If it was really necessary you could also envisage using a simple compression where each byte was a count and then a colour 24,1,24 006A000A0000A00060000A60 06A0000000000006A00000A0 0A00BB00006A000A00000000 000B77F00AA0000000000000 00BF777B00000000000A6A00 00BF777B0000000000A00000 000BFFB000A6000000000000 0000BB09900A600A000000A6 00000000B900A0006000000A 000000000F900000A0000000 999999999079000000000000 000000000007900000000A6A 999999999900F9000000A000 0000000000000F9000000000 060000A0000000F90906A000 A00000A60000000B0B006000 0000000A000009000B000000 000A600000060999BF000000 0000A600006A000000000000 6A000A0000A0000000000000 000000A00000000000A00006 000000000000000006A0000A 00000000600A00000A000000 00000006000060000000A600 would become 24,1,24 0261A103A104A1036104A161 0261A10C61A105A102A102B2 0461A103A10BB172F102A20F B1F173B10BA161A104B1F173 B10AA108B1F2B103A1610F01 B2019202A16102A106A16108 B19102A1036106A109F19105 A107990171910F08719108A1 61A19A02F19106A10F01F191 0A6104A107F19101910161A1 03A105A16107B101B102610A A1059103B109A16106610193 B1F10AA1610461A10C61A103 A104A10F04A10BA104610F02 61A104A1086102A105A10D61 046107A16102 Edited 2023-09-17 00:35 by matherp |
||||
Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1113 |
Compression certainly saves a lot of bytes. If MM Basic can process this directly, I save having to decode it using software. I will add that, and the option for CSUB, to the sprite editor when I release a newer version. Sorry if I'm asking a stupid question, but I somehow missed how it works with the library... do you have a link to it. 'no comment |
||||
Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1113 |
Here the next evolution this is to ilustrate how a scrolling through the Map can be done Many Sprites and the "Layer" has been redrawn, so use them included here scrolltest.zip The speed is mainly dependent on the loading time of the Tiles It makes little difference whether you have set the Pico to 252000 or 378000. So if one manages to convert the whole Tiles to CSUB and keep it in memory, that would mean a drastic acceleration again. The Background Layer(N) is used for the Scrolling so no space for Hiding things PS: if you want to make this demo running endles change the in the 4th last line. from y=0:inc ox to y=0:inc ox:if ox>116 then ox=1 Edited 2023-09-20 19:37 by Martin H. 'no comment |
||||
Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4243 |
Martin, A very early stage of the game. Using your layer.bmp, but still using my own tiles. The tiles are in framebuffer since it gives me easy opportunity to debug (I can see what is wrong by typing "framebuffer copy f,n" The player can move over carpet, grass, tarmac, not through walls. You have 2 weapons, and can shoot plants...hihi....through windows.... It is a very small map. I will work on a larger map soon, but this one is good for debug. The mini map consists only characters that can be typed from the keyboard, so I can easy modify it. The ASCII values are translated to tile numbers. This is temporary... Next on my list - search mode, and find items (so you will have to look for weapons) - move mode, move a chair.... - implement a linear moving robot - implement ammo count, and damage count - make a larger map. - make doors open/close This is a gigantic project. It may take a year to finish... If you want: When you replace tiles with the compatible tiles in your Amiga set (change names in "frame_tiles.bas") you can see how it looks with your tiles. The "walls" around the world are a quick fix. The actual maps Davis provides show inpenetratable bush at the outsides of the map (5 wide horizontally, 3 wide vertically) meaning your 11x7 window on the world map will never show outside borders. It would however take up half of my small map. So I took walls. Put all in ZIP one folder, run "test_pet7". Don't look at coding, it is work in progress, and not made for estatics. Regards, Volhout test_pet7.zip Edited 2023-09-20 21:28 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1113 |
As I mentioned earlier I try to reverse-engineer the original tileset.pet File to make them match to the Maps If this is done, I am able to Paint 8x8 Pixel Tiles, matching the Amiga/PSP Tileset. And with this, they just 8192Bytes + the Tileset file. Which will fit in the Picos Memory 'no comment |
||||
Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4243 |
Tried your test program Impressive graphics. I really have to port your tiles....this is awsome. Scrolling is a bit irregular at 252MHz. Maybe that is because you are doing quite a lot, taking sprites from the SD card (in my case), and use only 1 sprite at a time. You are scrolling left (player walking right). If you insist in implementing pixel scroll this way, you have to change the layout. You need a 24 pix atthe left side of the screen to paste your new tiles when walking left....(*) Nice to see you have implemented the complete a-map. Volhout (*) or does the scroll wrap around ? then you can plaste the left side tiles at the utmost right edge, one pixel up.... P.P.S: I strongly believe 8x8 is not fast enough. Memory efficient, YES, but not fast enoug. Edited 2023-09-20 22:38 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1113 |
1. no i dont :-) The Sprite Scroll wraps the screen, so I can Paint the new Tiles under the the "Mask" on the Right Side. if I scroll to right, they appear on the Left the scroling is just so slow, because it loads 9 Tile from the SD Card (for the next Column) while scrolling 24 Pixels. The time for the actual drawing of the sprites is the smallest part.. You can test it, if you just load some 24x24 Sprites at Sprite 20-28, dont reload new Tiles and just paint them.. 'scroll test MODE 2 Dim LV$(64) Length 128 Open "Data\LEV-a.bin" For input As #1 For f=0 To 63:LV$(f)=Input$(128,#1):Next Close #1 'prepare screen path$="tiles\" FRAMEBUFFER layer FRAMEBUFFER write l Load image "layer.bmp" FRAMEBUFFER write n ox=0:oy=0 For y=0 To 8 For x=0 To 11 vl=Asc(Mid$(lv$(y+oy),ox+x+1,1)) Sprite load path$+"TL"+Hex$(vl,3)+".SPR",1 Sprite write 1,x*24,y*24 Next Next FRAMEBUFFER write l ox=13 x=0:oy=32 'scroll left For y=20 To 28 Sprite load path$+"TL"+Hex$(y+(Rnd*128),3)+".SPR",y Next f=4:y=0 Do 'fn$="sprites\SP"+Hex$(f,3)+".SPR" 'Sprite load fn$,1 'FRAMEBUFFER write l 'Sprite write 1,120,96,0 vl=Asc(Mid$(lv$(y+oy),ox,1)) 'Sprite load path$+"TL"+Hex$(vl,3)+".SPR",20+y FRAMEBUFFER write n nn=-2-(y Mod 2) Sprite scroll nn,0 Inc y If y =9 Then 'draw next column For y=0 To 8:Sprite write 20+y,264,y*24,0:Next y=0:Inc ox: If ox >116 Then ox=1 EndIf Inc f:If f=8 Then f=4 Loop if you then just scroll 8 Pixel (size of on Char) you will se how fast it get Edited 2023-09-20 23:22 by Martin H. 'no comment |
||||
Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4243 |
Martin, Do you want me to research putting all the tiles and sprites into CSUB into library ? So I come up with a receipt for you to implement ? Volhout PicomiteVGA PETSCII ROBOTS |
||||
LeoNicolas Guru Joined: 07/10/2020 Location: CanadaPosts: 479 |
Hey guys Can we have a public git repo for the project? It allows people to contribute to the project and also easily get the source code for testing. If possible, I would like to make contributions. |
||||
Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4243 |
I like the idea, maybe somone experienced can help. But honestly, at the moment I am in the stage of experimenting what pico can do, and how is the best way to implement this huge undertaking (memory wise, speed wise). I learn from Martin along the way. He has already some game design experience (i.e. frogger) and is a master in graphics. Volhout PicomiteVGA PETSCII ROBOTS |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6798 |
Do you think it's ready for that, when it's still early days on finding ways to store and manipulate the sprites and background? Edited 2023-09-21 00:22 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1113 |
Harm, Peter published a tool for convertig spr files to compressed CSUB. But I have no Idea how to store and recall them in a Lib. It would be great, If you can manage that. But some robot-sprites still need, in my opinion, a little preparation, so I have to repaint them, which is time-consuming, so I can only do it little by little. What I want to say, some sprites are not yet in the final version, or I still see room for improvement, so I hope that they can be replaced later, even in the CSUB form. Best Martin 'no comment |
||||
Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4243 |
Hi Martin, I have the basis working, but it is inconvenient. You need to do a lot manually. Maybe Peter reacts with some tips to make it easier. Volhout PicomiteVGA PETSCII ROBOTS |
||||
Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1113 |
Good to hear, that it works at all .. First make it work, than make it convenient WIP I now managed to decode the structur of the original Tileset Files, Every Tile is 3 by 3 Chars, as they where original PETSCII encoded. they are serially encoded 256 Bytes TL starts at Byte 514 of the Tileset File After this next 256 Bytes belongs to TM ....and so on so you end with an Array of 9x256 Bytes I am still working on creating 8x8 Pixel Tiles that match to the Tileset. All in all this will use much less memory than 256 24x24 Tiles Edited 2023-09-21 17:51 by Martin H. 'no comment |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4042 |
I agree with that. Personally I think the whole LIBRARY approach (not just for PETSCII Robots or CSUBs as data) is a dead end when using the PicoMite as a "general purpose computer" unless a program can specify what to load into the library (starting from a blank slate) as the first commands it issues. I've had a look and if possible at all that would be pretty damn tricky and I doubt Peter will do it ... but have I said that to make it more likely that he will do it ? . If rather than a program for general purpose computer you are building a dedicated PETSCII Robots device then the LIBRARY approach is fine and it doesn't matter that commands have to be issued at the prompt because (1) you only have to do it once, and (2) once you've done you can clone that Pico's flash and simply distribute the whole thing as a .uf2 file as if it were a custom firmware. If you do want it to be a program for a general purpose computer then you need to shrink the sprites (as per what Martin is looking at) and/or page sprites off disk, i.e. keep the 64 most recently used sprites in RAM (an INTEGER array) and load sprites into that array from A:/ as required discarding the oldest sprite each time. It means adding a layer of indirection to the sprite address lookup and the occasional pause but I suspect it would work in the context of PETSCII Robots. Finally (?) I think it would be possible to implement something along the lines of: FLASH BACKUP <slot>, <filename> FLASH RESTORE <slot>, <filename> Which would dynamically (and from within a program) save and restore the contents of flash slots (including the library) as binary data. Then with some way to get the address of a flash slot (MM.INFO) or an extension to PEEK, e.g. PEEK FLASH <slot> BYTE <offset> I think you would have a very fast, flexible, general purpose mechanism for extending a program with binary data. Notes: 1. Using this to play with the contents of the LIBRARY could not be used to dynamically load code into a running program, and would cause a crash if you used it to replace code that was present when a program started. 2. You would need some sort of "magic word" which if present as the first 4 bytes of a FLASH/LIBRARY slot would mean this is not code, don't try to treat it as such. 3. When RESTORE-ing it may be worth paying the performance penalty to check whether the current contents matches the file and thus reduce flash wear by avoiding unnecessary writes. Assuming I don't get shot down by a missile from Peter I volunteer to do this firmware work once there is sufficient evidence that PETSCII Robots on the PicoMite is feasible (i.e. the game logic can run fast enough) and that there is the "will" to carry it through to completion. Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6099 |
Loading up the library is not difficult If I can do it... Jim VK7JH MMedit MMBasic Help |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4042 |
Yes Jim, but you've got a PC in the driving seat and are sending a command to the serial console / prompt. The use-case that I believe @Volhout wishes to address is: - Start standalone PicoMiteVGA - Type one command on the PS2 keyboard that will run "PETSCII Robots" including replacing the current contents of the LIBRARY with contents read from one or more files. Now other than potentially setting up a macro on one of the Fn keys (and that won't help you if you wanted to start PETSCII Robots from a separate menu program) there is as far as I can see currently no way to achieve this. Best wishes, Tom Edited 2023-09-21 19:54 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
Amnesie Guru Joined: 30/06/2020 Location: GermanyPosts: 396 |
Same here. The goal is to have a standalone device. Greetings Daniel |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4042 |
What does "standalone device" mean ? Does it mean: 1. A device dedicated to playing PETSCII Robots? That shouldn't require any changes to the firmware, having got one Pico installed correctly and setup to AUTORUN you just clone its flash and provide it for others to download as a .uf2. 2. A (possibly multi-file) program that can be started with a RUN command on a standard PicoMiteVGA, either at the prompt of from within another "menu" program. Best wishes, Tom Edited 2023-09-21 20:12 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
Page 3 of 38 |
Print this page |