 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 : CMM2: V5.05.04b4a, interesting new functionality for test
| Author | Message | ||||
| matherp Guru  Joined: 11/12/2012 Location: United KingdomPosts: 10578 |
New command FRAMEBUFFER Check the Video Command available in V5.05.04b4a This command allows you to create, use and remove a variable size framebuffer which should make many applications which need a working graphics area bigger than the screen easier to program. Moving a 640x400x16 image from the framebuffer to the display takes just over 4mSec. Moving a 320x200x8 image from the framebuffer to the display takes just less than 1mSec. FRAMEBUFFER CREATE HorizontalSize%, VerticalSize% This command creates a framebuffer with the width and height specified in pixels. HorizontalSize>=MM.HRES and <=1600: VerticalSize>=MM.VRES and <=1200 FFRAMEBUFFER WRITE PAGE WRITE FRAMEBUFFER These commands are interchangeable and set all drawing commands to write to the framebuffer and inherit the width and height defined. FRAMEBUFFER BACKUP This command creates a backup copy of the framebuffer. If a backup already exists it is overwritten. This allows the programmer to save the background before he/she starts writing non-static data to it. NB: It won't be possible to use this command if a very large framebuffer is specified in 12 or 16-bit colour depth. A sensible error will be given in this case. FRAMEBUFFER RESTORE [x, y, w, h This command restores all or part of the framebuffer from the backup. This allows the programmer to “clean” all or part of the framebuffer before adding new non-static items FRAMEBUFFER WINDOW x, y, pageno [,I or B‘ This command copies an area MM.HRES by MM.VRES from the framebuffer with top left at x,y to the page specified, The optional parameter specifies if the copy is Immediate or during frame Blanking FRAMEBUFFER CLOSE This command releases the memory resources used by the framebuffer and backup allowing a new framebuffer to be created with a different size MM.INFO(FrameH) This function returns the horizontal size of the framebuffer in pixels MM.INFO(FrameV) This function returns the vertical size of the framebuffer in pixels Notes Setting a different graphics mode which changes the colour depth will close and delete the framebuffer JPG files cannot be loaded to the framebuffer and will error if tried. The framebuffer is deleted by Ctrl-C and by running a new program Changing graphics mode such that MM.HRES or MM.VRES are bigger than the size of the framebuffer will cause it to be deleted. This is a big change to the graphics engine bugs are likely Example use similar to the video: option console serial framebuffer create 1024,1024 page write framebuffer load bmp "1024" 'load a 1024x1024 image to the framebuffer memory framebuffer backup 'back up the image memory cls rgb(red) 'clear the framebuffer to red framebuffer restore 100,100,800,800 'restore the central area of the backup ' line 0,0,1023,1023 'check simple graphics command text 850,850,"hello",,,4,rgb(blue),-1 'check text output to the framebuffer j=0 do mode 4,16 for i=0 to 1023-mm.hres framebuffer window i,j,0 next i for j=0 to 1023-mm.vres framebuffer window i,j,0 next j for i=1023-mm.hres to 0 step -1 framebuffer window i,j,0 next i i=0 for j=1023-mm.vres to 0 step -1 framebuffer window i,j,0 next j j=0 framebuffer restore 'go back to the clean image mode 2,16 for i=0 to 1023-mm.hres timer=0 framebuffer window i,j,0 print timer next i for j=0 to 1023-mm.vres framebuffer window i,j,0 next j for i=1023-mm.hres to 0 step -1 framebuffer window i,j,0 next i i=0 for j=1023-mm.vres to 0 step -1 framebuffer window i,j,0 next j j=0 loop Edited 2020-07-10 00:02 by matherp |
||||
| MauroXavier Guru Joined: 06/03/2016 Location: BrazilPosts: 303 |
Using this on the Gauntlet implementation I can store a map only with floor and walls, and work in the framebuffer with enemies and items, then when something is removed, I will not need to scan the array and restore manually the blocks of that part, I will only need to change the array and restore that part of the framebuffer. The smooth scroll will be much easier to implement too. Another great advantage with this framebuffer it's now I will not worry about offscreen textures and perspective correction on Wolfenstein 3D, which are made each loop. Without the need for these corrections, for sure it will speeds up the things. Abraxas will benefit from this too, making it easier to speed up the Boulder Dash game. Anxious to back to my home to test it! |
||||
| abraxas Regular Member  Joined: 16/06/2020 Location: CanadaPosts: 99 |
Absolutely! This will be of great help with map scrolling. This is important enough to go back to the drawing board on the entire rendering algorithm. The caveat about there still being bugs is a bit worrisome... as it stands I have enough of those of my own ;) Pete, would it make sense for this to also have optional w,h parameters in case someone wants to make a viewport smaller than MM.HRES/MM.VRES? Many games have score/lives panels displayed alongside the map which likely wouldn't be coming from the framebuffer. Of course one can draw blank rectangles to achieve the same visual but it might be cleaner to have that built into the command. Your thoughts? Edited 2020-07-10 01:10 by abraxas |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10578 |
Just BLIT them onto the display page after using the window command. NB current limitations: BLIT should work TO the framebuffer in modes 1,2 and 4. It won't work correctly in modes 3 and 5. BLIT should work within the framebuffer. There isn't currently any syntax for blitting from the framebuffer to another page. If the framebuffer concept tests out OK I'll fill these gaps but it needs lots of special case code. The reason is that modes 3 and 5 store each line twice whereas for memory reasons the framebuffer only stores each line once regardless of current mode. Line duplication for modes 3 and 5 happens in the WINDOW command |
||||
| MauroXavier Guru Joined: 06/03/2016 Location: BrazilPosts: 303 |
Unfortunately in this case I cannot test it yet because Gauntlet and Wolfenstein 3D are totally restricted to mode 3. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10578 |
I was hoping for the community to do some general testing before I commit yet more time to help find any holes or bugs before I commit yet more time and effort |
||||
| abraxas Regular Member Joined: 16/06/2020 Location: CanadaPosts: 99 |
My Boulder Dash engine is not restricted to Mode 3 although that's how I run it by default so I could try to use the framebuffer features provided that support for Mode 3 BLIT is coming eventually. FWIW I think it's a very worthwhile command to have for game devs. I promise to at least experiment with the framebuffer in the next few days but will keep it in a separate code branch until the feature matures. |
||||
| mkopack73 Senior Member  Joined: 03/07/2020 Location: United StatesPosts: 261 |
This is great! I was planning to try to write a simple 3D flight simulator (think Sublogic Flight Simulator 2 on C64 but with filled polygons). Being able to use a framebuffer for the “out the window” view portion and keeping the bottom portion static for the instrument panel (a series of sprites for each of the instruments) should help make things nice and fast and smooth! My CMM2 can’t get here soon enough!!! |
||||
| GregZone Senior Member Joined: 22/05/2020 Location: New ZealandPosts: 114 |
Hi Peter. It's probably just me doing something dumb, but my CMM2 is feezing when running your example code above. I've cut back the code to isolate when this happens: option console serial framebuffer create 1024,1024 page write framebuffer load bmp "Test1024" 'load a 1024x1024 image to the framebuffer framebuffer backup 'back up the image memory mode 4,16 print mm.hres print mm.vres i=0 for j=0 to 1023-mm.vres print j,; framebuffer window i,j,0 next j Here's my console output at the freeze point: Flash: 1K ( 1%) Program (16 lines) 515K (99%) Free RAM: 0K ( 0%) 0 Variables 2048K (39%) General 3136K (61%) Free 480 432 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 ie. The CMM2 freezes / the framebuffer command never returns, when j hit's 81. Observation: 1024 - mm.vres - 80 == 512. (Not that that may have any relevance? LOL) Only other observation is that when I retain the diagonal line, the bottom of the last image displayed (at j=80) appears to be the very bottom of the 1024px high image (ie. where the diagonal line meets the bottom right corner). This is kinda unexpected as the j loop at this point should be displaying a 432px high window at an offset only 81px from the top of the image? I'm sure someone will point out if I'm just doing something dumb?  Edit: For reference, here is my 1024px image properties:  Edited 2020-07-10 09:05 by GregZone |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10578 |
No: its me being dumb. When I cut and pasted the listing I missed the top line MODE 2,16 As a result the framebuffer was created in 8-bit mode and only half as big as it needed to be. I'll try and trap this and generate an error in the firmware rather than locking up. Sorry for your time wasted  |
||||
| GregZone Senior Member Joined: 22/05/2020 Location: New ZealandPosts: 114 |
Thanks Peter. Yes, it does make some sense that the allocation would be based on the current / intended colour depth. That didn't occur to me. When you say you missed the top line "MODE 2,16", I assume this could also have been "MODE 4,16"? ie. You just need to ensure that the intended colour depth is in place before the framebuffer create? Would it not have been possible to store a framebuffer attribute, which specified it's created colour depth? This would then allow the the "framebuffer window" command to determine if colour depth matched the current mode, or even (if possible) to allow an on the fly conversion? ps. No time wasted. Just good to know it wasn't a bug, as such.  |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
