 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 : PAGE DISPLAY vs PAGE copy
| Author | Message | ||||
| joker Newbie  Joined: 06/02/2024 Location: GermanyPosts: 19 |
Hallo, When I first studied CMM2 programs I always found the structure PAGE copy 0 to 1 at the end of the display loop. And this is also the recommended methods in the user manual and the advanced graphics tutorial. Depending on the choosen video mode, this function is very expensive (approx. 5ms on video mode 1 and 4ms on video mode 3). Consider, that you must complete all calculations in less than 12ms if you want 75 frames/second. In the user manual I found PAGE DISPLAY, which just switches the pointer to the video memory to display, which should come without any cost at all (That's what I thought). But it seams that it has the same cost as PAGE copy (I haven't done precise mesurements yet, only some FPS/Frame time calculations in my games). So, why is PAGE DISPLAY not the favorite method to change the display buffer? What is wrong with PAGE DISPLAY that PAGE copy is the priviledged method. I haven't found the PAGE DISPLAY command in the source code yet. So I couldn't verify that really only a pointer is changed. Any help here would be appreciated. In fact, PAGE DISPLAY works as it should, but is needs 5ms time as well. Best Regards Matthias |
||||
| matherp Guru  Joined: 11/12/2012 Location: United KingdomPosts: 8594 |
PAGE DISPLAY has to wait for the next frame blanking to action the change. |
||||
| joker Newbie Joined: 06/02/2024 Location: GermanyPosts: 19 |
Sorry, I missed something in my post. I meant PAGE copy 1 to 0,B So both commands wait for the frame blanking. This is perfectly acceptable. Matthias Edited 2024-03-17 19:37 by joker |
||||
vegipete Guru Joined: 29/01/2013 Location: CanadaPosts: 1083 |
I have found it convenient to use 3 pages. One page is displayed, as usual. The other 2 are used alternately for page flipping. When I finished drawing on one, I'd issue a PAGE COPY i,0,D (I think it's 'D' for copy on next VBL without waiting.) Then I could immediately start drawing on the other page and the firmware would copy the first when it was time. This way, no time would be lost waiting for the page copy to finish. Visit Vegipete's *Mite Library for cool programs. |
||||
| joker Newbie Joined: 06/02/2024 Location: GermanyPosts: 19 |
Hello, This is a quite clever method. Thanks for sharing. I will try it in my next project. Best Regards Matthias |
||||
| joker Newbie Joined: 06/02/2024 Location: GermanyPosts: 19 |
Hello, In the meantime I found a possible answer myself. PAGE DISPLAY <no> will always wait for the next frame blanking. It does this with a busy loop like this: pagesetdone=0 while(!pagesetdone){ CheckAbort(); } If you now use amother command that waits for a frame blanking like map set then these waitings are not combined. Both commands wait for the frame blanking with the same busy loop, which means that the first command is executed in the first frame, the second in the second frame. If you have now code like this PAGE DISPLAY 1 map set Then you need two frame times for this not only one. This will waste 12-15ms at 75 FPS. Alternative: PAGE COPY 1 TO 0, I map set Both commands will be executed in the same blanking period. This saves you 12-15ms right away This, I think, is the reason why nodody is using PAGE DISPLAY, at least not with a custom colormap and colorcycling. PAGE COPY is much more flexible to use Using busy loops in a kernel is not the brightest idea since the invention of interrupts. For me the PAGE DISPLAY chapter is now closed. Best Regards Matthias |
||||
 Print this page |
