Production Pyra photos/videos/thoughts thread


matzesu

Forum Addict!
Staff member
Joined
Oct 24, 2008
Messages
10,163
Age
36
Location
Germany,, Saarland, at home
Ditnt though about my Upcoming Pyra Video the last week, so maybe its time to ask for some suggestions:

- What should i show, and how to say it?
- I cant show mame as i dont had this on my Pandora, just PS1, Gameboy Gameboy Collor, SNES NES N64 DS GBA and some of the Sega Stuff including Genesis (Megadrive)

- I will not make an Unboxing Video, just Pictures as its a bit divicult whit my Setup to show things bigger than the Pyra..

Its One Take as i dont know how to cut Movies..

Oh and as i plan to make this Video when i have some time, its may be that the Pyra then got allready some use bevor, so its not just out of its box
 

docbroke

Banned
Joined
Feb 21, 2019
Messages
466
Age
39
Location
India
You can try cutting/joining video on pyra using handbrake. ffmpeg is another option but it will require command line or scripts.
 

matzesu

Forum Addict!
Staff member
Joined
Oct 24, 2008
Messages
10,163
Age
36
Location
Germany,, Saarland, at home
If i would try to cutt or to join, the Video would take another 2 Months (tm)..
I think One Take is a bit more autenthic, i dont want to make this on a uber provessional Base ^^

Some Books as a Kickstand, this time a bit more preparation on my English, and hopefully more fluid speek should work out..
 
  • Like
Reactions: rSl

Neelix

Insecticidal Maniac
Joined
Jan 8, 2011
Messages
3,259
Location
Melbourne, Australia
For copy, paste I find autocutsel particularly useful. It is in Debian repos. On my laptop autocutsel is configured to keep primary selection and clipboard in sync, so there is no need for Ctrl+C, anything selected (primary buffer) is automatically copied to clipboard, and can be pasted with either shift+insert or Ctrl(+shift)+v
Oddly enough, it's that very behaviour that leads me to tend to prefer Ctrl+C & Ctrl+V to using the middle mouse button for copy and paste. I have a tendency to want to paste over a selection, which is somewhat difficult if the act of selecting the text I want to replace pushes it into the clipboard buffer.

-Neelix
 

levi

Still fresh, damnit!
Joined
Oct 6, 2008
Messages
13,018
Location
Somewhere off the coast of the EU
Ditnt though about my Upcoming Pyra Video the last week, so maybe its time to ask for some suggestions:

- What should i show, and how to say it?
- I cant show mame as i dont had this on my Pandora, just PS1, Gameboy Gameboy Collor, SNES NES N64 DS GBA and some of the Sega Stuff including Genesis (Megadrive)

- I will not make an Unboxing Video, just Pictures as its a bit divicult whit my Setup to show things bigger than the Pyra..

Its One Take as i dont know how to cut Movies..

Oh and as i plan to make this Video when i have some time, its may be that the Pyra then got allready some use bevor, so its not just out of its box
One take is fine, your conversational english is easily good enough for that. And as you say, it does seem more authentic sometimes to do that, like Dave on EEVBlog usually just waffles on.

I don't know how soon a lot of these emulators will be released. I mean, davashah's already got retroarch running, as as long as you can get that set up the same on your system a lot of this stuff should just come as part of that. I don't know if N64 and even PS1 will work out of the box, so if you could report on that to set my expectations that'd be nice. I'll have to put my thinking cap on if you want suggestions on actual games to try out, since beyond F-Zero on N64 and maybe Mario Kart: Super Circuit on GBA I don't really have go-to games on a lot of those systems.
 

wawrus

Still Fresh
Joined
Jul 18, 2020
Messages
4
Since the devs are still working on the battery control from a software side and the bits of the SoC that offload computation still being worked on, it is hard to say what battery life -will- be. What it is right now is ~8+ hours sitting on the desk with the screen on and about 2-3 hours doing stuff that pegs the CPU. Frankly we need a way to easily purposely throttle the CPU on a per-app basis because 150+ fps on some games like Hostile Takeover is a waste of cycles. A lot of programs are built to consume all resources available to boost frame rate - which doesn't help battery life. But, what it is now could also be seen as 'worst case' where the CPU is doing 3D, MPEG, etc instead of offloading those to specialized circuits. The software side for the 3D is in the works, I have played around with it a bit - so great progress is ongoing!
Thanks for the detailed and informative response! Makes a lot of sense. Some partners and I did an early Android handset back in 2008, and I watched the battery tuning from the sidelines (I was upper layers of Android, Input Methods, bundled apps, signaling for push). I know it's challenging, especially for some of the use cases this group will throw at it. As a volunteer effort, it's impressive, and I don't presume too much expressing appreciation on everyone's part for the great work by the developers. I'm really looking forward to getting my hands on mine. and hacking as I can.
 

theredbaron

Very Active Member
Joined
Feb 12, 2014
Messages
108
Location
/home/theredbaron/
Since the devs are still working on the battery control from a software side and the bits of the SoC that offload computation still being worked on, it is hard to say what battery life -will- be. What it is right now is ~8+ hours sitting on the desk with the screen on and about 2-3 hours doing stuff that pegs the CPU. Frankly we need a way to easily purposely throttle the CPU on a per-app basis because 150+ fps on some games like Hostile Takeover is a waste of cycles. A lot of programs are built to consume all resources available to boost frame rate - which doesn't help battery life. But, what it is now could also be seen as 'worst case' where the CPU is doing 3D, MPEG, etc instead of offloading those to specialized circuits. The software side for the 3D is in the works, I have played around with it a bit - so great progress is ongoing!
I know next to nothing, so the following could be wrong but...

Frankly we need a way to easily purposely throttle the CPU on a per-app basis because 150+ fps on some games like Hostile Takeover is a waste of cycles.

I believe this is already doable, via the linux kernel with cgexec. And pretty easy to, I think, as I was able to use it to do ram limiting, and I don't know jack.

I would bet, once the Pyra is fully "out", we will get a nice cgexec cpu:cpulimit guide on the best setup, how much cpu popular programs need, etc. Then its just a mstter of changing .desktop files exec setting, aliasing, whatever.

Sent from my H3123 using Tapatalk
 

docbroke

Banned
Joined
Feb 21, 2019
Messages
466
Age
39
Location
India
Last edited:

Confuzzled

Active Member
Joined
Oct 1, 2018
Messages
71
Since the devs are still working on the battery control from a software side and the bits of the SoC that offload computation still being worked on, it is hard to say what battery life -will- be. What it is right now is ~8+ hours sitting on the desk with the screen on and about 2-3 hours doing stuff that pegs the CPU. Frankly we need a way to easily purposely throttle the CPU on a per-app basis because 150+ fps on some games like Hostile Takeover is a waste of cycles. A lot of programs are built to consume all resources available to boost frame rate - which doesn't help battery life. But, what it is now could also be seen as 'worst case' where the CPU is doing 3D, MPEG, etc instead of offloading those to specialized circuits. The software side for the 3D is in the works, I have played around with it a bit - so great progress is ongoing!
Throttling the cpu on a per-app basis is indeed possible now.

Start reading from this post: https://pyra-handheld.com/boards/threads/preparing-for-a-prototype.76956/page-33#post-1667599

tl;dr Use cgroups. Set up is a 'bit finicky', but the capability is built in to Linux.
 
Top