Pi2 running graphics half as fast as a B+??
Neil Fazakerley (464) 124 posts |
I’ve been playing with some BASIC graphics animation on a B+, using double banking as there’s quite a lot of plotting to get through for each frame. Monitoring the frame rate shows a solid 58/59fps, which looks fine and gives no detectable flickering or judder. I’ve now bought a couple of Pi2 boards so I can have some variations running side by side for comparison purposes. I was surprised to find the Pi2s can only manage 30fps running the same code as the B+. Given that the Pi2 is supposed to be quite a bit quicker than the B+, could this slower frame rate indicate a much shorter lag between the wait for VSync call and the screen bank change? It’s all I can think of that could be causing the problem – with a shorter period for writing to a bank, screen draws may be over-running Vsync and skipping every other frame. I’ve been able to get the frame rate back to an indicated 58/59, but only by REMming out a good half of the frame draw procedures. What’s the conventional bank switch code for the Pi in a 1920 × 1080 64k colour mode, just so I can check I’ve got all my switching ducks in a row? |
Jon Abbott (1421) 2592 posts |
If you’re double buffering then you need to swap before waiting for VSync:
If you’re triple buffering, you can use the more logical:
|
Neil Fazakerley (464) 124 posts |
This is the double-buffering construct I’m using currently on the B+: REPEAT UNTIL 0 It seems to work smoothly at 60fps on the B+ but the same code (on the same MicroSD card) looks like it’s missing every other frame and runs at 30fps on the Pi 2. |
David Feugey (2125) 2687 posts |
So I suspect you should do: |
Jon Abbott (1421) 2592 posts |
Assuming bank% is your backbuffer, try:
|
Rick Murray (539) 13351 posts |
Hmmm… Just sent an email to The Pi Hut. Tried RISC OS with an update to the latest firmware on my new Pi2. Then tried the Pi Zero version of OSMC. Then tried every uSD I could lay my hands on. With or without SD cards, the behaviour is identical. Green light on, red light on a fraction of a second later. No blinks, no nothing. Nothing on HDMI. Nothing on analogue video. I would have expected to see blinks for RISC OS and OSMC as the machine at least loads the firmware, even if nothing else. Likewise for all the other SDs, there’s no firmware but I’d expect at least one blink as it looked. Nothing. Power supply is good. It’s a 2A that runs the Pi1 and the Vonets. Tried also with a 2A capable battery pack. And two different cables. RISC OS SD is 8GB SanDisk Ultra. It’s on the “working” list, and works in the Pi1. It’s an 8GB card in the Pi Zero. And I’d have thought it would accept and blink a time or two for at least one of my other SD cards? But no. I’m just not getting any response from this thing other than it turning its lights on. :-( |
André Timmermans (100) 617 posts |
For the DigitalCD plugins I work as follows: work on a frame SYS “XOS_ScreenMode”,6 : REM flush screen buffering (RISC OS 4/6) work on new frame This works on RISC OS 4/6 on the RISC PC with either 2 or 3 banks. |
Peter Duncan (1657) 23 posts |
Re: Rick – “But no. I’m just not getting any response from this thing other than it turning its lights on. :-(” Same problem with my Pi2 from the PiHut. Sent it back for a replacement which seems to be taking an age to arrive. Good luck with getting a response to your email from them. Can’t say that my experience of communicating with them has been good. |
Michael Emerton (483) 136 posts |
Not that it would make that much of a difference I am sure, but you could switch to the SWI Number as opposed to the name to stop the look up delay… At least that is what I have been told (I ought to take my own advice!) Are we able to screen bank at 1080p now? last time I looked at it, there wasn’t enough memory due to coding restrictions in RISC OS? I would like to use it in my app to stop the tearing of my scrolling text! |
Steve Drain (222) 1620 posts |
But you use Basalt, don’t you? That does the SWI-to-Number conversion for you at run-time. ;-) |
Anthony Vaughan Bartram (2454) 455 posts |
Hi, In my experience there is a variable behaviour on the Raspberry Pi where sometimes it waits for the vertical blank when you switch draw buffers and sometimes it does not: After discussion with Jeffrey Lee I opted for triple buffer and implemented a one time calibration routine which selected whether to wait for the vertical blank or not. Code fragment and discussion is here: |
Neil Fazakerley (464) 124 posts |
Thanks for the suggestion Jon. Tried it, but I get bad flicker/tearing on the B+ with that order. Bear in mind I’m double buffering, not triple buffering, as I need to use 64K colours, 1080p. I’ve tried every possible combo/order of the four revelant lines but the only one that works without flicker is as I posted above, illogical though it looks. |
Neil Fazakerley (464) 124 posts |
Unfortunately, as I need 64K colours in 1080p, I have to make do with double buffering, Andre. I’m using a light-source shading routine on animated 3D shapes, so 256 colours are way too crude for smooth lighting effects. |
Neil Fazakerley (464) 124 posts |
Michael, try using the code I posted back at the start of the thread and you should be able to double bank in a 1080p 64k colour mode (e.g. SYS “OS_ScreenMode”,15,“X1920 Y1080 C64K LTRGB”). If you’re drawing a lot of graphics for each frame, you’ll still need to plot the highest on-screen items first, lowest last, to beat the scan line as it moves down the screen. All this assumes you have fake_vsync_isr=1 in your CONFIG/TXT file. |
Rick Murray (539) 13351 posts |
Well, what a <beep>ing waste of time. Sent the Pi2 back on Halloween. Tracking showed it got there on the 4th. Heard nothing, so got in touch today. They wanted to know the tracking number “to look into it”. I gave them the link to the tracking page (so don’t pull the lost in post on me, thank you). Just got an email to say sorry, the Pi2 is no longer available so I’ll be getting a refund instead. Sheesh. [aside: wonder how refunds work on virtual credit cards?!] So, does anybody know where I can get an original ARMv7 Pi2 that isn’t at some stupid inflated price because of “collectors item” mentality? I’d like a bit more oomph running RISC OS without the headaches of ARMv8 compatibility… |
David Pitt (102) 743 posts | |
Rick Murray (539) 13351 posts |
Useful. It is on the French version – http://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/8326274/ – but RS won’t touch you unless you have a SIRET (company reg number). They have a site that is aimed at the general public. No Pi in sight. In fact, it looks like it is modelled on what Maplin used to be. http://www.rs-particuliers.com I remember back in 2008, Farnell sent me a big catalogue via UPS (!) so I checked with them, but their ones are the new type. http://fr.farnell.com/raspberrypi-boards Looks like, next month (after pay day) I might be able to get one from Amazon. A tad more expensive, but not so much so (remember the RS price is “HT” which means without VAT). https://www.amazon.fr/Raspberry-Pi-Processeur-900MHz-lecteur/dp/B00T2U7R7I Thanks for the pointer, anyway. :-) |
Michael Grunditz (467) 531 posts |
I think I can source a Pi2 if you are interested. 50eur maybe. |
Rick Murray (539) 13351 posts |
Hey – while I was looking at Pis in Amazon, I came across this: serial to WiFi: https://www.amazon.fr/dp/B01BMK65UK Could this be patched into the networking somehow to provide RISC OS with cheap’n’cheerful WiFi? It looks as if the stack is on the board, all one needs to do is talk to it via serial. Looks like it uses AT commands? https://cdn.sparkfun.com/datasheets/Wireless/WiFi/Command%20Doc.pdf Hmm, is it capable of more than one connection at a time, though? That could complicate things…but it looks like it might be kinda fun to play with. ;-) |
Chris Evans (457) 1614 posts |
You need to be sure it is a BCM2836 Pi 2 V1.1 not a Pi 2 V1.2 BCM2837 |
Tristan M. (2946) 1035 posts |
Rick: re the esp8266. Short answer is no. I have heaps of esp8266 variants around the place. Really nice little chip. However you’d have to be outright nuts enough to do something like implement SLIP or PPP on it and some ??? in the middle. I believe they are capable of opening multiple ports but I’ve never really needed to. On the other hand, if you want to do something like have a debug console accessible via WiFi, an esp8266 with stock firmware, post configuration of course, can do that. Or maybe a dozen lines of code via the Arduino IDE, or maybe via NodeMCU Lua. I suppose I had better add, there’s an article via Hackaday on how to use an esp8266 as a wifi device, but I’m not sure if the hack could be adapted to RISC OS. I believe it involves physically disconnecting the ROM, and then uploading the firmware for a different model via SPI. The other model has the same uC but different additions I believe. But then you still need a driver. But it will be via SPI at least. |