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 7 of 38 | |||||
Author | Message | ||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9122 |
Not the case. Framebuffer copy f,n on the VGA takes 0.6 mSec at 126MHz so max 1500FPS Framebuffer copy to SPI still takes 90mSec so max 11FPS, it's just that you can do other processing while the copy is happening |
||||
Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1114 |
That's what I meant with " in terms of program speed". The Program continues while the 2nd CPU does the "Copy Job". So the Screen refresh is slower, but the Program not. Edited 2023-09-25 22:39 by Martin H. 'no comment |
||||
Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1114 |
For the Programmers .. Here are the last Missing graphics Converted to Pico 121 BMP ... Keycards and Items so my Pixelwork is done Now to the next construction site... The Sound and the Music No. That is the whole point. The sound effect is coded on a specific channel (32 available) but is not included in the music schedule. PLAY MODSAMPLE triggers that channel alongside anything else playing They are all on Github, but in an (for me) unknown Format. Seem to be somehow like MOD but they are not MODFiles. so I have to find a way to convert them(simply renaming them doesn' work ) Edited 2023-09-26 02:00 by Martin H. 'no comment |
||||
Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4243 |
Martin, Would you be so kind to put all your artwork in one ZIP, so I use the correct base to build my library around. Preferably the cards and weapons in sprite form. Thank you, Volhout PicomiteVGA PETSCII ROBOTS |
||||
lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3150 |
This is just a little test with the PicoMite and ILI9341 of Martin's idea of using 8x8 tiles and updating only the changed tiles. I took this image from the MSDOS manual and down-converted it to 320x240 and 16 colors. This provides a play area of 264x200, or 825 8x8 tiles, 25 rows of 33 tiles each. In keeping with another of Martin's suggestions of using the "Information" area in the F framebuffer for tiles, I could save 120 tiles there--3 rows of 40 tiles. I generated the "tiles" by randomly painting pixels of the 16 defined colors of the PicoMite (red, green, blue, etc). Then I simulated 320 rounds in which 5% of the tiles were changed. This resulted in a frame rate (with about 40 tiles per round changed) of 80fps. ' petscii_test.bas ' 120 8x8 tiles saved in F info area, 825 tiles in play area ' scratch variables dim string a,b,c,ch,d,e,s dim float f,g,h dim integer i,j,k,l,m,n,x,y dim integer clr(15)=(rgb(white),rgb(black),rgb(blue),rgb(green),rgb(cyan),rgb(red),rgb(magenta),0,0,0,0,0,0,0,0,0) clr(7)=rgb(yellow):clr(8)=rgb(brown):clr(9)=rgb(white):clr(10)=rgb(orange):clr(11)=rgb(pink):clr(12)=rgb(gold) clr(13)=rgb(salmon):clr(14)=rgb(beige):clr(15)=rgb(grey) dim integer xRow,yCol,xFrom,yFrom,xFromRow,yFromCol dim integer infostart=213, nPlayTiles=825, nPlayTilesPerRow=33, nPlayTilesPerCol=25 dim integer nHiddenTiles=120, nHiddenTilesPerRow=40, nHiddenTilesPerCol=3 y=infostart FRAMEBUFFER create FRAMEBUFFER write F load image "b:/screen1.bmp" FRAMEBUFFER COPY F,N for i=1 to 24 ' rows of 8x8 tiles (random colors) for x=0 to mm.hres-1 pixel x,y,clr(rnd()*15) next x inc y next i 'pause 10000 FRAMEBUFFER COPY F,N pause 3000 FRAMEBUFFER write N load image "b:/screen1.bmp" box 0,infostart,mm.hres-1,mm.vres-infostart,0,rgb(black),rgb(black) ' simulate play -- select tiles to change n=nPlayTiles*.05 ' change 5% of tiles timer=0 for i=1 to mm.hres ' 320 moves for j=1 to n ' changes to n tiles k=rnd()*(nPlayTiles-1) ' which 8x8 target tile to change xRow=k MOD nPlayTilesPerRow ' which of 25 rows: 0-24 yCol=k MOD nPlayTilesPerCol ' which of 33 columns x=xRow*8 ' start of 8x8 to-tile y=yCol*8 ' start of 8x8 to-tile l=rnd()*(nHiddenTiles-1) ' which 8x8 from-tile to use xFromRow=l MOD nHiddenTilesPerRow ' which of 3 rows yFromCol=l MOD nHiddenTilesPerCol ' which of 40 columns xFrom=xFromRow*8 ' start of 8x8 from-tile yFrom=yFromCol*8+infostart ' start of 8x8 from-tile ' a="From tile "+str$(l)+" ("+str$(xFrom)+","+str$(yFrom)+") to tile "+str$(k)+"("+str$(x)+","+str$(y)+")" ' text mm.hres/2,infostart,a,C,7 ' ?a+" Row/Col: "+str$(xFromRow)+" "+str$(yFromCol) ' do : loop until inkey$ <> "" FRAMEBUFFER BLIT F,N,xFrom,yFrom,x,y,8,8 next j next i j=int(timer/1000) i=int(mm.hres/j) a=str$(mm.hres)+" iterations of "+str$(n)+" tile changes; "+str$(j)+" seconds, "+str$(i)+"fps" print a text mm.hres/2,infostart,a,C,7 Here's a 15-second youtube video If 10% of the tiles change with each round (83 tiles), it's 35fps. So a question for Martin: are you planning to generate the 8x8 tiles, and if so, do you have a rational play area made with them? (The same would work in theory with larger tiles.) PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1114 |
Would you be so kind to put all your artwork in one ZIP, so I use the correct base to build my library around. Preferably the cards and weapons in sprite form. Thank you, Volhout Harm here is all Artwork together Artwork.zip additional here is a little guide for setting up the tiles: every square is 24x24 Pixel, help forplacing the Tiles etc. As you see, the Player is allways at position 5 x 5 Good Luck Edited 2023-09-26 04:09 by Martin H. 'no comment |
||||
Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1114 |
So a question for Martin: are you planning to generate the 8x8 tiles, and if so, do you have a rational play area made with them? look at the "Proof of the SubTile-concept" post on the page before. There I used the Petscii GFX Font (sub)Tiles. It's a lot of work to convert the existing 24x24 pixel tiles into nine subtle 8x8 to match the 256 Chars in the GFX-font. So lets wait for the next RC of MMBASIC where the 2nd CPU does the Layer management for LCD. Then we can see how this affects speed and playability (The same would work in theory with larger tiles.) yes and no ... as we scroll 8 pixel at the Time, the 24x24 Tiles would not match Edited 2023-09-26 04:24 by Martin H. 'no comment |
||||
lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3150 |
I'm not sure why a fractional tile could not be blitted. Once they are placed in the F or L framebuffers, they are just pixels. (I admit, my understanding of all this is quite limited.) Are my dimension for the playfield approximately what you are looking at: 264x200 pixels, with 33 8x8 tiles per row and 25 rows? PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4243 |
Based on earlier provided artwork, and tilesets from Martin, I have the player walking the map under cursor control. The "level-a" file in the data folder also contains tile attributes, and unit attributes. These are correctly decoded now, and I use them to determine where the player can walk. But I noticed that my tiles are not 100% matching the maps (level-a, level-b etc..). The first 2 rows, have different tile information. Maybe there is more unit-attributes than I thought, although what I see in the atributes fits the units nicely. So debugging goes on... Volhout PicomiteVGA PETSCII ROBOTS |
||||
vegipete Guru Joined: 29/01/2013 Location: CanadaPosts: 1109 |
Is there any value in the Ultima 1 mini demo I posted a while ago? The world maps exist as a PNG file. The CMM2 made this easy to store on one of the many graphics pages. Individual pixels were read and converted to larger images to paint the view immediately around the player. Visit Vegipete's *Mite Library for cool programs. |
||||
Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1114 |
But I noticed that my tiles are not 100% matching the maps (level-a, level-b etc..). The first 2 rows, have different tile information. Maybe there is more unit-attributes than I thought, although what I see in the atributes fits the units nicely. So debugging goes on... Volhout if I look at the maps in Hex editor with 128 Bytes per Line, i see that the first 6 Rows (768 Bytes) are no Tile Data. first part of LEVEL-C So they will have another use. Like the petscii tilesets, where the first 514 bytes are used for attributes etc. Happy decoding Edited 2023-09-26 15:57 by Martin H. 'no comment |
||||
Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4243 |
From the PETROBOT.h (header file) // MAP FILES CONSIST OF EVERYTHING FROM THIS POINT ON extern uint8_t MAP_DATA[8960]; #define UNIT_TYPE MAP_DATA // Unit type 0=none (64 bytes) #define UNIT_LOC_X (MAP_DATA + 1 * 64) // Unit X location (64 bytes) #define UNIT_LOC_Y (MAP_DATA + 2 * 64) // Unit X location (64 bytes) #define UNIT_A (MAP_DATA + 3 * 64) #define UNIT_B (MAP_DATA + 4 * 64) #define UNIT_C (MAP_DATA + 5 * 64) #define UNIT_D (MAP_DATA + 6 * 64) #define UNIT_HEALTH ((int8_t*)(MAP_DATA + 7 * 64)) // Unit health (0 to 11) (64 bytes) #define MAP (MAP_DATA + 8 * 64 + 256) // Location of MAP (8K) // END OF MAP FILE I concluded that the UNIT attributes (up to 64 units) is encoded in the world map. The lower line is the actual map (Plus 256 bytes offset unknown). The 256bytes offset are BEFORE the map data. And this section is EMPTY. In "level-a" world map they contain &hAA, in all other maps they contain &h00. The UNIT_xxx attributes information however is correct, if contains a number of hoverbots, with X and Y coordiantes and health level, same as player infor (starting coordinate (near lander)) and health. And a number of sliding doors, some automatic, some keycard operated. It happens there are exactly 256 bytes needed for 256 tiles attributes. So I thought the empty 256 bytes where the tile atrributes, but these must be located somewhere else. From above UNIT attribute information and the way the world map is constructed, I think the core works by scanning through the complete UNIT list, on timed interrupt. I am currently thinking about the fastest way to do this. At the moment I store unit attrubutes in 8 strings (length 64). But each reading must be done like this: value = ASC(MIDS$(UNIT_x$(y),x+1,1)) And writing like this (youi update each UNIT location each scan (robots walk, player walk). MID$(UNIT_x$(y),x+1,1))=chr$(value) Maybe it is faster to store the data in an integer array (DIM UNIT%(63) where TYPE = value X coordinate = value >>8 Y coordinate = value >>16 .... Health = value >>56 (this can be done since heath never larger than decimal 70 (the evelibot), so the MSB is not set, making it a negative integer. reading value = UNIT%(x)>>n AND &hFF writing (happens less often) UNIT%(x) = (UNIT%(x) AND mask%) + value <<n The mask% values would be pre-calculated. Anyway...work in progress.... Let's first find the tile attributes, and then look at speed. Volhout Edited 2023-09-26 17:14 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1114 |
Looks like a lot of work, but it's in the hands of professionals I'll see later if I can get the sound files decrypted and reformat them to MOD if possible. the decryption of the File Format should be hidden here. Have Fun and good Luck Mart!n 'no comment |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9122 |
This is more like it This provides a proper platform for games (Tom!) |
||||
Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4243 |
Martin, I found it, there is 1 additional file I needed: "tileset.amiga". Also (to be done yet) there is additional information in the platform_sdl.cpp file, but we may not need that. It looks like an alternative to store sprites in the "black" fields in the tile map. Find attached ZIP. Unzip it go to the "petrobot" folder. refresh your library (manual as is). I will work on uniform file names later. This is it for now. The run "pet8.bas" You can walk the whole map, obstructed only by tiles that cannot be walked according the tile attributes. There is no pixel scroll, only tile based movements. Volhout petrobot.zip P.S. in line 127 you can change the map, I included level-a...level-g Edited 2023-09-26 18:49 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
Bleep Guru Joined: 09/01/2022 Location: United KingdomPosts: 509 |
Very nice Peter, is it in the download yet? ;-) Regards Kevin. |
||||
Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4243 |
Very nice Peter, is it in the download yet? ;-) Regards Kevin. Looks like Peter is also using the ILI9341 in parallel mode, not SPI mode. Tom's game platform needs an update....game*mite2 Volhout PicomiteVGA PETSCII ROBOTS |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4042 |
Impressive as always Peter, I guess I'm not doing it myself or buying you a panel . Given I can't see any configuration in the OPTION LIST I'm assuming it is on fixed pins - not complaining - just observing. Not this year, there are software things to be done to take advantage of the current Game*Mite, not to mention I may have to bribe @bigmik if I'm expecting him to do another 100+ hours of PCB work on a future v2. Even if it were possible to do so, I'm claiming no priority over this. If some other shedder wants to create a handheld based on the parallel interfaced ILI9341 then knock yourselves out. Best wishes, Tom Edited 2023-09-26 19:18 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
Bleep Guru Joined: 09/01/2022 Location: United KingdomPosts: 509 |
My impression, from Peters comments, was that this will (eventually) work on the serial SPI, maybe not quite so fast, but still freeing up loads of processor time on the MMBasic CPU. Regards, Kevin. |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4042 |
Regards, Kevin. I believe with all the work that Peter has done we should be able to get 8-10 fps from the Game*Mite for PicoSCII Robots which I think should be adequate. Biased as I am, I believe the current Game*Mite is a good platform and there is plenty of scope for entertainment from it. In addition it has a useful amount of I/O on its expansion port and enough buttons to make it a potential alternative to @Mixtel90's PicoMite backpack for some applications. Best wishes, Tom Edited 2023-09-26 19:33 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
Page 7 of 38 |
Print this page |