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 2 of 38 | |||||
Author | Message | ||||
Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4239 |
//copied here for consistency 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:32 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4040 |
Unless I have a fundamental misunderstanding of the PicoMite LIBRARY I'm personally unconvinced about its general purpose use. It looks like it is designed for use in a device that only runs a known fixed set of programs (i.e. a dedicated PETSCII Robots device) but on a general purpose "computer" you surely have issues regarding other programs contending for contents in the LIBRARY. Personally I'd prefer the ability to reallocate this piece of flash as general purpose "ROM", e.g. within a program: OPTION NO_LIBRARY ' Do not process the "LIBRARY" flash ' as MMBasic. LIBRARY LOAD "data.bin" ' Replace contents of "LIBRARY" flash ' with raw bytes read from file ' - the programmer accepts the risk the ' user might quite have liked the ' contents of their LIBRARY - tough. lib_ad% = MM.INFO(LIBRARY ADDRESS) x% = PEEK(BYTE lib_ad% + offset%) YMMV, Tom Edited 2023-09-15 20:45 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1113 |
I'm currently in the process of adapting/convert/repaint every Tile into.spr Files. Here is How it could look like on the Pico with this Layout we are able to hide 53 Tiles under the Border Edited 2023-09-15 21:06 by Martin H. 'no comment |
||||
Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4239 |
@Tom, You can already do a library clear. One thing that comes to mind is: if we know the start address of the FLASH slots (there are 3 left unused by me currently) we could used those as binary storage. Until the moment we select the slot it in MMBasic, we coudl store anything there. MEMORY COPY could fill them from framebuffer (or...) SPRITE/BLIT MEMORY could use them, same as we do the LIBRARY now. Volhout PicomiteVGA PETSCII ROBOTS |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9121 |
The library functionality is standard across most of the MMBasic range and will not be changed Writing to flash memory requires disabling all interrupts and is not something I intend to allow to be accessed in MMBasic except through the existing limited no. of commands. |
||||
Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4239 |
@Martin: nice.... As developmentis going right now, I will not store any tiles in layer N (*). There is plenty of space available (or will become available). The window whould be 11x7 tiles (264x168) to be compliant to the PET version. AFAIK there are 255 tiles in the amiga version. That is 255 x 288bytes = 73.4kbyte. Essentially that will fit in library and in a flash slot. (**) Volhout (*) In my testing it shows that the graphics (the blitting) is sooo fast that every single line of code to determine what tile to pick from where, and go there is slowing things down. So I would prefer to store all tiles in ONE place. One index, one calculation, BLIT... (**) to efficiently use the amiga library we need to analyze the amiga code. Because Amiga is most likely using one graphics plane only (the player is mapped onto the floor, not in a different layer). Edited 2023-09-15 21:24 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6797 |
IMHO the Library is nice as a developmental tool, allowing you to have various useful routines to hand. However it's of little use if you are going to distribute a program as you are going to have to either integrate any library routines into your program (and you could have worked round that without the Library facility) or provide the user with some way of pre-loading your library routines - and they may not have space. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9121 |
Have a look at a number of Geoff's applications where he uses the library for things like fonts Load the library code - library save Load the program code - run not too taxing surely Edited 2023-09-15 21:29 by matherp |
||||
Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4239 |
Oops... my fault. MEMORY COPY can only access RAM, not FLASH... Thanks for the correction. Volhout PicomiteVGA PETSCII ROBOTS |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4040 |
Note I only ever suggested using the library's flash-slot as **ROM** populated from a file by calling an MMBasic command, not a free-for-all. But unless I'm mistaken it can't be done programmatically. Consider the use case of two games, "PETSCII Robots" and "Super PicoMite Elite Firefox Skyrim Extravaganza" that both want to *separately* make use of this "storing sprites in library CSUBs" facility. As far as I can see you can't write a menu program that will allow the user to select once of those games and perform the necessary manipulations on the contents of the library. Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1113 |
The Display shoes 11x7 Tiles so it is compliant to the PET version. if we have max 256 differed Tiles, The map can then be a collection of the tile numbers. I will see, if I am able to "decode" the Maps from Github. Displaying 77 sprites isn't really time consuming. To speed things up, if necessary, replace the X loop with 11 “Sprite Write” commands For example, the player's animation, depending on the direction of movement, could be temporarily stored under the Border. 'no comment |
||||
Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4239 |
@Martin, There is one complication in using the library. The endianess is different in library versus sprite file. So the order Sprite file 24,1,24 123456789ABCDEFGHIJKLMNO '1st row, 3x8pixels 123456789ABCDEFGHIJKLMNO '2nd row 123456789ABCDEFGHIJKLMNO essentially 12345678 9ABCDEFG HIJKLMNO CSUB definition 00000000 87654321 GFEDCBA9 ONMLKJIH '1st row 3x8 pixels 87654321 GFEDCBA9 ONMLKJIH '2nd row 87654321 GFEDCBA9 ONMLKJIH Otherwise it would have been a simple thing to change the sprite files into a CSUB definition. I have just tried with multiple CSUB's in the library, and that works. You just end up with multiple starting points. There is one benefit in using the library and CSUB's. They are in linear order. You do not have to convert sprite number into X and Y corrdinates (in Framebuffer). Multiply the sprite number by 288, and you have the pointer. Volhout Edited 2023-09-15 22:16 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1113 |
also you have to notice This means that the numbers of the colors differs from the numbers within a sprite file colors: '--Colorscheme used in SPR Files BLACK,BLUE,GREEN,CYAN,RED,MAGENTA,YELLOW,WHITE MYRTLE,COBALT,MIDGREEN,CERULEAN,RUST,FUCHSIA,BROWN,LILAC I have to check that, then it wouldn't be a problem to translate it and/or write a additional Export routine to the Sprite Editor Edited 2023-09-15 22:37 by Martin H. 'no comment |
||||
Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4239 |
Martin, I downloaded the user manual for the game. It shows (some of the) the maps. Maps are 128 x 64 tiles (8kb when 1 byte per cell). To make life easier, I suggest The tiles (you are converting) should be grouped in 2 groups 1/ static tiles (floor/walls/grass/water/etc), there should be 127 of these maximum 2/ dynamic tiles (explosions, movements (opening doors), player, robots, etc..) On the world map any number < 128 will directly translate into a tile Any number > 128 will be an AI unit. The AI unit has a attribute list. In this list is the related tile number(s) depending on it's state. The AI tile can be any tile 0...255). This allows to keep a compact world map. I also have been looking at the video (part 1 is most interesting). From that I derive: world_map (x,y) each cell (byte) contains a base tile number if number < 128 then tile if number > 127 then AI unit under/on tile tile_attrib (128) each cell (byte) contains tile capabilities (taken from youtube film David) bit 0 = can walk on it bit 1 = can hover over it bit 2 = can be moved bit 3 = can be destroyed bit 4 = can be see through bit 5 = can push onto bit 6 = bit 7 = AI unit_attrib (128,8) each object can have capabilities (taken from youtube file David) byte UT = (unit type .. robot/door/etc...) byte X = X coordinate byte Y = Y coordinate byte A = byte B = byte C = byte D = byte H = health (or hit points) Volhout Edited 2023-09-15 23:30 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6797 |
Oh, it's not taxing at all. You do have to remind them to permanently delete the contents of their beloved library before they can test run your program, of course. :) If you are putting together a project then there's no development being done and you can do anything with the library space, it doesn't matter as it's not going to be used for anything else. If you want to test run someone else's programs that may use the library then you'd better have a spare platform to run it on, or at least make sure you have a good backup of your library routines so that you can put them back. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1113 |
so here is my work so far ... All Levels, Tiles and most of the Sprites.. There is a little test program, I haven't optimized anything here yet because it's just for illustrative purposes. PETSCII.ZIP The assignment of the tiles to the maps is not yet correct but I've moved enough pixels for today. Has anyone contacted David Murray about permissions? Edited 2023-09-16 02:35 by Martin H. 'no comment |
||||
Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1113 |
I downloaded the user manual for the game. It shows (some of the) the maps. Maps are 128 x 64 tiles (8kb when 1 byte per cell). To make life easier, I suggest The tiles (you are converting) should be grouped in 2 groups 1/ static tiles (floor/walls/grass/water/etc), there should be 127 of these maximum 2/ dynamic tiles (explosions, movements (opening doors), player, robots, etc..) On the world map any number < 128 will directly translate into a tile Any number > 128 will be an AI unit. The AI unit has a attribute list. In this list is the related tile number(s) depending on it's state. The AI tile can be any tile 0...255). Volhout Looks promising, now I just have to find pictures of the levels to know which tile belongs to which number. From what it looks like so far it is not the order in which they were arranged in the Tile.png 'no comment |
||||
Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1113 |
Has anyone contacted David Murray about permissions? After watchig all his Petscii Robots Videos finaly it looks like David gave a general OK at Timecode 24:06 Petscii Robots - The FINAL Update so it would be fine Edited 2023-09-16 06:57 by Martin H. 'no comment |
||||
Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1113 |
The assignment of the tiles to the maps is not yet correct but I've moved enough pixels for today. I recreated the Tiles from the PSP Version and now they assign to the tilenumbers in the maps. PETSCII.ZIP looks good, so far. Edited 2023-09-16 18:06 by Martin H. 'no comment |
||||
Amnesie Guru Joined: 30/06/2020 Location: GermanyPosts: 396 |
Martin, this. looks. amazing! With the new implementations from Peter, I am really curious about this development. Greetings Daniel |
||||
Page 2 of 38 |
Print this page |