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 4 of 38 | |||||
Author | Message | ||||
Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4243 |
@Tom, I agree that the library may not be the best way forwars, but for speed, there is nothing that can beat it. So let's just try it first. This is research... @Martin, unpzip attached into a folder. then load "spr_csub.bas" library save load "tile0_csub.bas" library save load "tile1_csub.bas" library save load "tile2_csub.bas" library save memory You should have 72k in your library, consisting of 4 csubs named "SPRITES, TILE0, TILE1, TILE2". In this folder is also a set of index file that was created dusring the CSUB creation process. In below program I use these indexes to create an index array. The index array contains the absolute memory addresses where each sprite or tile lives in memory. The sprite number is the index in the array. 'write tiles from library 'get start addresses spr%=Peek(cfunaddr SPRITES) til0%=Peek(cfunaddr TILE0) til1%=Peek(cfunaddr TILE1) til2%=Peek(cfunaddr TILE2) 'build index file Dim sprite_index%(&h60) Dim tile_index%(&hff) Open "spr_index.txt" For input As #1 For i=0 To &h5a Input #1,a$ sprite_index%(i)=spr%+Val(a$) Next Close #1 Open "tile_index0.txt" For input As #1 For i=0 To &h3f Input #1,a$ tile_index%(i)=til0%+Val(a$) Next i Close #1 Open "tile_index1.txt" For input As #1 For i=&h40 To &h7f Input #1,a$ tile_index%(i)=til1%+Val(a$) Next Close #1 Open "tile_index2.txt" For input As #1 For i=&h80 To &hff Input #1,a$ tile_index%(i)=til2%+Val(a$) Next Close #1 MODE 2 Sprite compressed sprite_index%(20),70,100 'a sprite Sprite compressed tile_index%(20),100,100 'a tile from the first csub Sprite compressed tile_index%(70),130,100 'a tile from the second csub Sprite compressed tile_index%(150),160,100 'a tile from the 3rd csub Even when the tiles and sprites are not the latest, use this to see if it works. I can simply share the programs that created the csubs and index files, so you can apply on newer tile sets... Volhout martin_2_test.zip Edited 2023-09-21 21:54 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3150 |
Following these steps with a Picomite with ILI9488 and adding FRAMEBUFFER creation and writing results in this (small portion of otherwise blank screen): Does this make sense? Does it include everything you would expect? PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4243 |
Hi Martin, Lizby, Lizby, that is completely correct! This code below makes the screen scroll live... Quite impressive speed on the pico VGA. It uses Martins earlier test code. Regards, Volhout '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 'make an index file create_index '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 blit compressed tile_index%(vl),x*24,y*24 Next Next FRAMEBUFFER write l ox=13 x=0:oy=32 'scroll left 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 blit compressed sprite_index%(f),120,96 ' 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 vl=Asc(Mid$(lv$(y+oy),ox,1)) 'Sprite write 20+y,264,y*24,0 blit compressed tile_index%(vl),264,y*24 Next y=0:Inc ox:if ox>116 then ox=1 EndIf Inc f:If f=8 Then f=4 Loop 'create index file sub create_index 'get start addresses spr%=Peek(cfunaddr SPRITES) til0%=Peek(cfunaddr TILE0) til1%=Peek(cfunaddr TILE1) til2%=Peek(cfunaddr TILE2) 'build index file Dim sprite_index%(&h60) Dim tile_index%(&hff) Open "spr_index.txt" For input As #1 For i=0 To &h5a Input #1,a$ sprite_index%(i)=spr%+Val(a$) Next Close #1 Open "tile_index0.txt" For input As #1 For i=0 To &h3f Input #1,a$ tile_index%(i)=til0%+Val(a$) Next i Close #1 Open "tile_index1.txt" For input As #1 For i=&h40 To &h7f Input #1,a$ tile_index%(i)=til1%+Val(a$) Next Close #1 Open "tile_index2.txt" For input As #1 For i=&h80 To &hff Input #1,a$ tile_index%(i)=til2%+Val(a$) Next Close #1 end sub Once you have the library filled, it will remain until you do "LIBRARY DELETE". For this code to work you need the world map that martin provided in the Data folder. So copy previous ZIP files in the game root directory. And run above program. Edited 2023-09-22 01:10 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
Bleep Guru Joined: 09/01/2022 Location: United KingdomPosts: 509 |
Very impressive :-) between 2.2 and 12.5mS per iteration at 252MHz so a scroll rate of about 133Hz or between 1.5 and 8.3mS per iteration at 378MHz so a scroll rate of about 200Hz!!! This was on a VGA. Regards Kevin. Edited 2023-09-22 03:21 by Bleep |
||||
Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1113 |
as the N-Screen on Pico (without VGA) uses the Memory of the LC Display, you should be able to use the Framebuffer for the graphic-operations and Framecopy it to N. AT the Moment i have no Pico with LCD Working, but I will test the implementation, when Toms Game*Mite arrives :-) 'no comment |
||||
Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1113 |
Once you have the library filled, it will remain until you do "LIBRARY DELETE". For this code to work you need the world map that martin provided in the Data folder. So copy previous ZIP files in the game root directory. And run above program. I will test it tomorow, No Pico today, just MMB4W At the moment I'm in the process of giving the sprites a frame so that they can stand out better from the background. From ----> To Like Imagine / Ocean often done for Spectrum 'no comment |
||||
lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3150 |
If I correctly understand what you are saying, that is what I have done with Volhout's code, with this at the top: FRAMEBUFFER create FRAMEBUFFER write F and this at the very end: FRAMEBUFFER copy F,N PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3150 |
I'm afraid I haven't understood how that works. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1113 |
I'm afraid I haven't understood how that works. You need the Files in the Filestructure, like in the Zip File. look at the Demo: I read the world map of the Level into the LV$ Array. Each value in the array represents the number of the tile at its position,byte by byte. (Because there are only a maximum of 256 different tiles, saving them as String,one Byte per Tile, seems to me to be the most effective solution). The Map Files are sored in the "Data\" subfolder Filling the Array Start of the Demo: 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 This stores the Map of 128x64 Tiles. each Tile is 24x24 Pixel. So the entire playing field can be a maximum of 3072*1536 pixels. For the Display, 11x9 tilenumbers, depending on the player's position, from the LV$ () array are read and presented. I hope my explanation is somewhat understandable Edited 2023-09-22 14:41 by Martin H. 'no comment |
||||
Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1113 |
This code below makes the screen scroll live... Quite impressive speed on the pico VGA. It uses Martins earlier test code. Regards, Volhout wow, thats fast, I am totaly thrilled I tidied it up a bit, because the pixel-wise scrolling was only there to enable the Tiles to load evenly. For every 8 pixel scroll, one animation step of the player sprite.Since the original ran on 8x8 pixel ASCII/PETSCII in text mode, smaller steps are unnecessary. As you can see, I added a Pause 75 in every Frame to keep it smooth. That time could be used, in the Game to calculate the Gamelogic etc. 'CSUB scroll test MODE 2 Dim LV$(64) Length 128 Open "Data\LEVEL-c" For input As #1 For f=0 To 63:LV$(f)=Input$(128,#1):Next Close #1 'make an index file create_index 'prepare screen 'path$="tiles\" FRAMEBUFFER layer FRAMEBUFFER write l Load image "layer.bmp" FRAMEBUFFER write n ox=0:oy=32 For y=0 To 8 For x=0 To 12 vl=Asc(Mid$(lv$(y+oy),ox+x+1,1)) Sprite compressed tile_index%(vl),x*24,y*24 Next Next FRAMEBUFFER write l ox=13 x=0:oy=32 'scroll left f=4:y=0:sn=0 Do FRAMEBUFFER write l Sprite compressed sprite_index%(4+sn),120,96 Inc sn:If sn=4 Then sn=0 FRAMEBUFFER write n Sprite scroll -8,0 If f=7 Then 'draw next column For y=0 To 8 vl=Asc(Mid$(lv$(y+oy),ox,1)) Sprite compressed tile_index%(vl),264,y*24 Next y=0:Inc ox:If ox>116 Then ox=1 f=4 EndIf Inc f:Pause 75 Loop 'create index file Sub create_index 'get start addresses spr%=Peek(cfunaddr SPRITES) til0%=Peek(cfunaddr TILE0) til1%=Peek(cfunaddr TILE1) til2%=Peek(cfunaddr TILE2) 'build index file Dim sprite_index%(&h60) Dim tile_index%(&hff) Open "csub\spr_index.txt" For input As #1 For i=0 To &h5a Input #1,a$ sprite_index%(i)=spr%+Val(a$) Next Close #1 Open "csub\tile_index0.txt" For input As #1 For i=0 To &h3f Input #1,a$ tile_index%(i)=til0%+Val(a$) Next i Close #1 Open "csub\tile_index1.txt" For input As #1 For i=&h40 To &h7f Input #1,a$ tile_index%(i)=til1%+Val(a$) Next Close #1 Open "csub\tile_index2.txt" For input As #1 For i=&h80 To &hff Input #1,a$ tile_index%(i)=til2%+Val(a$) Next Close #1 End Sub now its time to write the scrolling for the other 3 directions Cheers Martin Edited 2023-09-22 17:14 by Martin H. 'no comment |
||||
Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4243 |
PETSCII ROBOTS ARCHITECTURE PROPOSAL Gameplay Watch the video's from the "8bit guy" on Youtube to get an idea of what is involved. Especially the one about "gameplay". Total this is about 2 hours of TV watching. Human interface Since picomite VGA uses a PC keyboard, it is primary goal to support th PC keyboard. For the keyboard layout, and associated functions see attached manual in link With the Amiga tiles that Martin uses for this game, we could mimick the MSDOS version. Download the MSDOS manual . GITHUB There are several people getting excited about this game, some would like to contribute. I am looking for someone who could set up a GIT, and explain in few lines/words how to use it. Honestly, I have done it before, but just made an account, and dragged some files into it, but that way you use GITHUB as a dropbox with the name GITHUB. The game itself. I am not a game designer, my strength is designing electronics. Sa as a programmer I cannot be trusted to give fair judgement. Having said that, based on my limitted experience in debugging MAXITREK and tuning performance on MMBasic code, I propose the following: The picomite. The picomiteVGA has a variety of video and audio capabilities. Best game experience can be achieved using video mode 2 (320x240 in 16 colors), and using PLAY SOUND commands. This allows playing music on channels 1 and 2 (melody and rythm) and action sounds on channel 3 (and 4). Since the MMBasic program will get large (50 kbyte+) the video will use only the normal video plane N, and the sprite layer L(FRAMEBUFFER LAYER). The sprite layer is on top of the video layer, and transparent for color 0 (black). Storage It is target that the whole game fits on the picomite A: drive. Setup: 'this section does all initialisation for the game 'it initializes the sound heartbeat (SETTICK) 'intro 'the intro screen is shown, and some user preferences are shown 'here you load the world map in a local copy (the world map will become modified during 'the game play. This local copy will be saved with GAME SAVE Main: 'this is a sequence that is processed fast. It should only have blocking slow down for non-game-related 'activities (such as "SAVE" or "PAUSE" or maybe an explosion). DO 'get user controls 'keyboard (or in future game controller) 'Player moves 'in this section the player is controlled over the map 'will involve scrolling map 'Player actions 'this is a large section that lets player shoot, search, move 'this changes local map (blow up a bridge) and updates inventory etc.. 'explosions can trigger a sequence of effects, potentially slowing the game 'AI units 'this involves robots that move on the map, sliding doors 'my current idea is to show the animations on L layer, until the animation 'is finished, then modify the local copy of the world map as new "static" state LOOP sound: 'The sound is the only timed interrupt in the game. 2 voices will run the sound track. 'the other 1/2 will be "enabled" in the main loop (a flag) and processed in this same 'heartbeat. Before we had "NOISE" as a sound, it was needed to use a very fast SETTICK, now we can benefit from the NOISE. I cannot stop myself from mentioning that speed is going to be the major problem. True that our dual core ARM processor in the RP2040 can run at 252MHz. But MMBasic is an interpreter. Each MMBASIC command we execute, at 6502 at 1MHz can execute 10-30 micro instructions. Therefore we should not try to do the same. Try to "preprocess" as much as possible (i.e. pre-calculate music notes for the sound, so the whole soundtrack interrupt is short). Try to do things with bulk, where the original game might process individual items. And it will be hard. The original game is very much "byte" related, and "character font" related. I hope we can team up and make this work. Please look at my proposals, and respond. Volhout Edited 2023-09-22 17:27 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4243 |
@lizby (and others) Put attached ZIP on a SD card (unzipped), and run scroll_test2.bas This is Martin's previous demo, with all required files. As mentioned, when you remove the "pause 75" you will see the blistering performance of Peters BLIT COMPRESSED, decompressing tiles from the library and painting them on screen. And this works for "any size" sprites. So the PETSCII tiles for the door cards (that are smaller), and the tiles for the weapons (that are largr at 32x24) can also find place in the same library. Volhout lizby2test.zip Edited 2023-09-22 18:05 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1113 |
IMHO it should be a Pico Version, not just a clone. So the Gameplay, the look and feel should be as close as it can get on the Pico. Fortunately, david published the Source Code on GitHub, so, to make it a Pico Version, the program sequence should run as close to the original SourceCode as possible. I'm less worried about speed, of course a 6502 can write a byte to a memory location faster than we can display a sprite on the screen. For this I use functions in my demo, so that only a small part of the screen actually has to be redrawn at a time, while in the original the whole screen has to be redrawn over and over again by the 6502. (For test, remove the PAUSE Command in my last listing to see how fast this can get). I'll continue to adjust the graphics for the Pico, once all of them have been satisfactorily ported, I'll move on to the sounds and music. Edited 2023-09-22 18:07 by Martin H. 'no comment |
||||
Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4243 |
Martin, I looked at the CPP code, and it is very educating. I think we can use it as a platform to start out with. There are many limitations in the pico we have to work out as we go. This is especially interesting...notes from the author // NOTES ABOUT UNIT TYPES // ---------------------- // 000=no unit (does not exist) // 001=player unit // 002=hoverbot left-to-right // 003=hoverbot up-down // 004=hoverbot attack mode // 005=hoverbot chase player // 006= // 007=transporter // 008= // 009=evilbot chase player // 010=door // 011=small explosion // 012=pistol fire up // 013=pistol fire down // 014=pistol fire left // 015=pistol fire right // 016=trash compactor // 017= // 018= // 019= // 020= // NOTES ABOUT UNIT NUMBERING SCHEME // --------------------------------- // 0 = player unit // 1-27 = enemy robots (max 28 units) // 28-31 = weapons fire // 32-47 = doors and other units that don't have sprites (max 16 units) // 48-63 = hidden objects to be found (max 16 units) // NOTES ABOUT DOORS. // ------------------- // A-0=horitzonal 1=vertical // B-0=opening-A 1=opening-B 2=OPEN / 3=closing-A 4=closing-B 5-CLOSED // C-0=unlocked / 1=locked spade 2=locked heart 3=locked star // D-0=automatic / 0=manual // HIDDEN OBJECTS // -------------- // UNIT_TYPE:128=key UNIT_A: 0=SPADE 1=HEART 2=STAR // UNIT_TYPE:129=time bomb // UNIT_TYPE:130=EMP // UNIT_TYPE:131=pistol // UNIT_TYPE:132=charged plasma gun // UNIT_TYPE:133=medkit // UNIT_TYPE:134=magnet // NOTES ABOUT TRANSPORTER // ---------------------- // UNIT_A: 0=always active 1=only active when all robots are dead // UNIT_B: 0=completes level 1=send to coordinates // UNIT_C: X-coordinate // UNIT_D: Y-coordinate // Sound Effects // ---------------------- // 0 explosion // 1 small explosion // 2 medkit // 3 emp // 4 haywire // 5 evilbot // 6 move // 7 electric shock // 8 plasma gun // 9 fire pistol // 10 item found // 11 error // 12 change weapons // 13 change items // 14 door // 15 menu beep // 16 walk // 17 sfx (short beep) // 18 sfx Volhout EDIT: the MMBasic program size needs to stay under 73k. The 100kbyte program space also needs to store the tokenized version of the program. I tested with a comment-less program, and could get to 75k MMBasic. Edited 2023-09-22 20:04 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1113 |
To get used to the Game: Online MSX Version While the game controls are customizable, the default control settings are: the cursor keys to move in all four direction, W, S, A, D keys to fire up, down, left and right, SPACEBAR to use an item, Z to inspect an object, and M to move an object. In elevators, use cursors LEFT and RIGHT to select the level, and use DOWN to exit the elevator. In menus, the cursor keys and SPACEBAR should be used. Finally, ESC key allows you to pause or quit a map, TAB for mini map, and SELECT to toggle the music in game on and off. 'no comment |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4042 |
That sounds fishy, let's hope Peter comments. I don't have a PicoMiteVGA at hand, but on my PicoMite I've got a perfectly happy 90+K (source size) MMBasic program that with the MEMORY command reports: Program: 81K (65%) Program (2899 lines) 43K (35%) Free This matches my understanding that the program space (which I believe is in the flash, but I've been confused before) only contains the tokenized program. Best wishes, Tom Edited 2023-09-22 21:49 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1113 |
I don't have a PicoMiteVGA at hand, but on my PicoMite I've got a perfectly happy 90+K (source size) MMBasic program that with the MEMORY command reports: Program: 81K (65%) Program (2899 lines) 43K (35%) Free Hi Tom, that is what I expected, on a non VGA as you use internal Memory for Screen. How does it look, if you enable the Framebuffer? I don't have a PicoMite with LCD at hand, but if there would be an LCD Port, this has to draw all on the Framebuffer and copy to N (the LCD Screen) when a new screen is ready Edited 2023-09-22 22:01 by Martin H. 'no comment |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4042 |
Sorry, I don't understand you. The FRAMEBUFFER doesn't effect this; it reserves its memory from the variable RAM not the program space. Remember that the MMBasic interpreter has a pseudo Harvard architecture rather than the von Neumann architecture of pretty much every other computer we've heard of. So there is no trade-off between program size and variable RAM ... well there is but Peter hardcoded that trade-off into the firmware. Yes probably. Note that because of the bottleneck of the SPI display the Game*Mite (for example) in its current configuration with an 320x240 ILI9341 SPI can only update the entire display at something of the order of 10 Hz which is probably too slow for PETSCII Robots. I haven't tested yet because Peter hasn't uploaded the latest firmware to github so I have been unable to update the Game*Mite firmware with the new sprite functionality ... in theory I could install the standard PicoMite firmware on the G*M, but I figured I'd just be patient. Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3150 |
Thanks for that. I don't currently have a PicoMite with SD card available. I'll try to cobble one up today. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6798 |
An LCD system is where you might get speed problems, unless it's a parallel display. VGA is far faster. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
Page 4 of 38 |
Print this page |