 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 10 of 38   |
|||||
| Author | Message | ||||
| Bleep Guru  Joined: 09/01/2022 Location: United KingdomPosts: 509 |
I have had a more careful look at the code and re-done the framebuffer copy to a much more sensible place. I have also added a piece of code to clear out the keyboard buffer, if you hold the key down and it starts autorepeating, this was making the player run on after releasing the button. I do not see any problems with the player having black under him. As for the player disappearing when you hold a move button down I think this is simply the LCD display not really keeping up, if you change the Pause 10, in the main loop of Volhouts code to say Pause 100, the player is easily visible, so I think this will resolve itself when there is more game logic in there slowing the overall game down a bit. A LCD friendly version of pet10.bas put it in the same place as pet10.bas and try it. pet10LCD.bas.zip Regards, Kevin. |
||||
Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1114 |
how fast is PEEK(VARADDR var)? just for comparison 'no comment |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3150 |
Excellent. Fixes my problem of black on the tile under the guy, and the keyboard buffer flush limits the overrun when the arrow key is held down. With the right arrow held down as the guy walked along the top of the building, sometimes only his head appeared. I changed PAUSE 10 to PAUSE 20 and that fixed that. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4043 |
A couple of recommendations and observations: 1. Until/unless it proves a performance bottleneck always render map and sprites and copy the buffer to the display on every iteration of the main loop, rather than mixing bits of rendering with the game logic. 2. Rather than sprinkling PAUSE statements lock the frame rate of the game loop, e.g. ' Main loop (I'm not guaranteeing this is the best order) Do t = Timer + 100 ... game logic ... render to buffer ... start background copy of buffer to display Do While Timer < t : Loop Loop 3. Why are you using the L buffer rather than the F buffer? IIRC the F buffer is cheaper in some way and at the moment it doesn't look like we need two buffers to do the compositing. 4. Don't use potentially racy timer interrupts (I don't think you are yet but you talked about interrupts in the context of the doors), except possibly for reading user input or playing sounds. Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3150 |
Absolutely for 1 and 2. I don't know enough about 3 & 4 to comment other than that they sound reasonable. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4246 |
On the surface no big changes, under the hood mainly. - uses integers for the UNIT attributes for speed - doors (all AI in the future, doors where first) use state machines, no delays in the future these can become "background" tasks, SETTICK driven. - debug: <SPACE> toggles weapons for the player sprite for now - marked doors return to their marked state (spade/heart/star) but still open all. known bugs: when walking fast you can leave a door half open. pet12.zip Volhout @Tom: there is still one PAUSE left....to simulate AI CPU cycles. PicomiteVGA PETSCII ROBOTS |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4043 |
I strongly recommend not using SETTICK as those interrupts are highly unlikely to occur in a predictable place with respect to the main loop and are also relatively expensive. Presumably these are things that are going to happen every X frames (anything that fires multiple times within a frame is I believe WOMBAT, though you may have a counter-example) so just count the frames and then make the code run for these events run in the main "thread of control". And you'll have to adjust that PAUSE as you implement more AI, or you can just use TIMER and a busy loop to lock the frame rate as I illustrated in my earlier post  .That just shows a lack of imagination on his behalf. Since Elite is playable on the NES with a single controller, you can be damn sure (assuming we can get the performance) I can make PETSCII Robots playable on the Game*Mite too  .Good work Volhout, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3150 |
This isn't firing, but it appears to me that door openings have within-frame movements, and I would expect that certain explosions would (though I'm not familiar enough with the game to say). ("Within-frame" is not the right term, but within the supposedly fixed time that it takes for the guy to move from one tile to the next at top speed. So the main DO loop would not be a per-frame loop, but would as Tom says, use TIMER to tell when an animation step occurs. So if the move step occurs every 500 milliseconds (which seems close to what the online MSX implementation does when you hold down an arrow key), then the three step door animation would occur after 166ms and 333ms, and then the move step after 500ms. Six updates per second seems doable on the LCD--assuming there's enough time in between to do the necessary processing.) And yes, excellent progress. ~ Edited 2023-09-29 07:02 by lizby PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1114 |
@Volhout just tested the 12 ....  @LCD Users (Bleep || lizby || thwill) ... here is a possible solution to just redraw the changed Tiles : add at the start of the Program: 'startup defines Dim TL1%(77),TL2%(77) than change the writeworld_m Sub to: Sub writeworld_m(xm,ym) FRAMEBUFFER write n Local tn=1 For xn=-xm To xm For yn=-ym To ym x=xs+xn*24 y=ys+yn*24 'load tile from world map spn=Asc(Mid$(lv$(yp+yn),xp+xn+1,1)) tl1%(tn)=spn:If TL1%(tn)<>TL2%(tn) Then Sprite compressed tile_index(spn),x,y EndIf Inc tn Next Next 'remember the Tiles For tn=1 To 77:TL2%(tn)=TL1%(tn):Next End Sub so write just the changed tiles to "N" .. don't Framebuffer copy Can you test, if this is faster and/or the image appears less delayed. on VGA: In some places, parts of the half open doors remain visible. But this is a problem that can be taken care of later. I would like to test first whether it performs better in principle Edited 2023-09-29 16:37 by Martin H. 'no comment |
||||
| Bleep Guru Joined: 09/01/2022 Location: United KingdomPosts: 509 |
Hi Martin, Thank you for your code snippet, I will give it a go, however I believe it is unnecessary. One problem is that it will be non deterministic ie. sometimes it will do almost nothing, other times it will have to update everything, so the chances are that to keep things running smoothly, a delay, which compensates for this variability will be needed, all of which will be using up valuable cpu1 time. Where as by simply making the LCD version of the VGA code write to a buffer 'f', instead of straight to the screen 'n' it makes no difference to the game logic, or its speed, then, once all screen updates are finished, do a background framebuffer copy, which uses cpu2, so no/minimal load on the cpu1. The only slight caveat is we would need to make sure that once the copy is initiated the framebuffer wasn't changed, for the time it takes to copy it, which may well just happen by default, we'll need to experiment, because of the time taken running the game logic. Otherwise, if necessary, we can use 2 buffers and alternate between them. Also it appears that the LCD can only ever cope with max of 10 frame updates a second, probably variable, depending on the speed of the LCD in use, but I'm assuming that eventually the game logic will have some fixed cycle/update rate, which hopefully will be less than 10Hz, but all of this is up for experimentation. :-) Otherwise we try to persuade Peter to do a background framebuffer blit, so only the amount of screen which is moving is transferred to the LCD, which I assume might be faster, if even possible? Regards Kevin. Edited 2023-09-29 19:56 by Bleep |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9126 |
The VGA version doesn't support and doesn't need to support background copy as it arbitrarily fast already and, in any case, the second cpu is fully occupied with generating the VGA output Edited 2023-09-29 20:09 by matherp |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3150 |
So far, and depending on how some non-guy-moving events occur in the future, I agree that updating only changed tiles appears unnecessary for the LCD version. It appears that the LCD can handle about 15 move-frames per second. Assuming a top speed for the guy of 5 tiles per second, and sub-movement events at 3 per move (as with the door opening animation), the following might do the trick (all screen writes are to a FRAMEBUFFER, only BLIT COPY f,n,b writes to the LCD (or BLIT COPY f,n to VGA): timer=0 Do ' do necessary stuff, including updating flagAnimation1 & flagAnimation2 as needed if flagLCD then if timer>66 then ' update all changed timer=0 FRAMEBUFFER copy l,n,b ' update LCD--happens on CPU2 elseif flagAnimation2 and timer>44 then ' update an animation flagAnimation2=0 FRAMEBUFFER COPY l,n,b ' update LCD--happens on CPU2 elseif flagAnimation1 and timer>22 then ' update an animation flagAnimation1=0 FRAMEBUFFER COPY l,n,b ' update LCD--happens on CPU2 endif else FRAMEBUFFER COPY l,n ' update VGA--happens on CPU2 endif Loop (EDIT: I changed the numbers above, since it appeared that with Bleep's code in pet10LCD.bas, the guy was moving at about 15 tiles per second (60 tiles across the top of the building in about 4 seconds). With the above numbers for timer (22ms, 44ms, 66ms) the guy moves at about the same speed in pet12 (as adapted for LCD). So I guess the question is, how much processing can be done with CPUSPEED=378000 in 22 milliseconds.) ~ Edited 2023-09-30 00:52 by lizby PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
stanleyella Guru Joined: 25/06/2022 Location: United KingdomPosts: 2129 |
Lots of stuff about frames and blit. Looks interesting for lcd. Just getting frame and layer worked out .. so no need to erase each sprite. |
||||
| Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1114 |
IN GAME MUSIC Music Files by Noelle Amelie Aman from the Amiga Version. thanks to a Windows ProTracker Clone (pt2-clone-win64), I was able to restore the music. there were many broken Samples and I had to repair or replace them. Sounds much better than the First Upload  Restored Music.zip BTW: in Windows/Linux you can use VLC to Play MODs IN GAME Sound FX SFX.zip Sounds in one MOD File and as seperat WAVs SFX Order in Mod File... Sample 1 sounds_dsbarexp Sample 2 sounds_dspistol Sample 3 sound_beep Sample 4 sound_beep2 Sample 5 sound_cycle_item Sample 6 sound_cycle_weapon Sample 7 sound_door_faster Sample 8 sound_emp Sample 9 sound_error Sample 10 sound_found_item Sample 11 sound_magnet2 Sample 12 sound_medkit Sample 13 sound_move Sample 14 sound_plasma_faster Sample 15 sound_shock Sample 16 sounds_dsbarexp Edited 2023-09-30 06:49 by Martin H. 'no comment |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4043 |
Hi folks, I thought I might spend some time this weekend converting the code to load the sprites from the general flash rather than the library thus avoiding the additional library load step at the prompt. Just wanted to check I wasn't duplicating anybody else's efforts first. Best wishes, Tom Edited 2023-09-30 19:05 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1114 |
if you look at the NES Version you can see, that they splitted up the Tilesets into game_field_0 to game_field_3, to me, this looks,that not all Tiles are used in every stage of the Program. maybe this could guide you somehow. Cheers Martin Edited 2023-09-30 20:07 by Martin H. 'no comment |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4043 |
Hi Martin, Unless we start hitting the limits of what can be put in a single flash slot (~100K) then I don't think such an optimisation is going to be necessary. My biggest concern now is how long scanning/processing all the units is going to take. A previous attempt to implement Boulder-Dash on the CMM2 which required a similar scheme floundered on this. I suspect/guess that we may require at least one small CSUB that given the players location and the location of all the "units" generates an array of just the units within say 15 tiles of the player and that it is that list (rather than all 64? units) that is then processed by the MMBasic scan units code. Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4246 |
Hi Martin, Your "items.bmp" contains 6 items (pistol,plasma,medkit,emp,magnet,bomb) But it's size is 48(correct) x 128 pixels. 128 is not divisable by 6. I tried 48x21 and that works reasonable Could you look at it and see if you can improve. I think the official images where each 48x24 pixels ? It would also help when the background would match the layer background, since they should not be transparent when placed on L, or would need this same background when placed on N layer. The background may also be important for the cards. These are 16x16 (48x16 for 3 cards) according the amiga documentation. Thanks for your effort in making this a nice game.... Regards, Volhout Edited 2023-10-03 06:58 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9126 |
Not really following this but three things to note: Sprite widths should be divisible by 2 if possible Sprites should be placed on pixel x-coordinates also divisible by 2 If possible don't use transparent colours If all of the above are true then the firmware can deal with transfers a byte at a time (2 pixels). If not, it has to work nibble at a time which takes > 2x longer |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4246 |
Hi Peter, The items are a bmp, that I plan to load in N, hidden by layer L. With a BLIT framebuffer, I copy sections to the visible layer. Although, now I wrote this…it may not be a good idea since this cannot be ported to lcd easy. Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Page 10 of 38 |
|||||
 Print this page |
