EDs latest is concern for screenshots being included in dbps, because he was worried about a repo going down and not having screenshots of the stuff he installed in his own Pyra.
For heavens sake, so many people on Discord already called you out for being annoying, now you're continuing it here?
I already said on Discord I won't continue the discussion with you, but I'll (once more) repeat said things here (which you apparently didn't understand).
Couple issues with that:
1. We didnt fund your personal project for just you ED.
Correct. You bought a hardware that I planned to produce. Not even software. Just the hardware. 90% of the development costs have been paid by my shop, btw.
So you didn't even fund 0.1% of the project. Don't speak for others.
And you didn't buy any part of me. If I'd love it to have screenshots included in the DBPs, that's my own personal request. I can make as many requests to any devs as I like.
It doesn't mean they will jump on it and do it. In the end, I can't code and only tell what I'd love to have. I don't pay any devs, so whether they want to include it or not, it's up to them.
I can still show concern for that. When 200 DBPs are released without screenshots and the feature is later added, most of them won't be updated.
We did an upgrade of the PND specs once with the Pandora. As a result, not all of the PNDs that were available before the repo has been created are in the repo. Some are only available on the old file archive. Why? Because the repo refuses them because of the change, and no one updated them.
That's something I like to prevent, and screenshots ARE useful for games (I chose 90% of the games I played on the Pandora based on the screenshot in the repo).
2. Why isnt the concern production?
Because that's something completely different?
GC / Uniqueplast / me here in the office handle the production. There's a lot going on in the back you don't know in details regarding tweaks, fixes, quality control, etc.
None of them will probably code screenshots into the existing DBP code.
So... what's the connection here...?
You also don't seem to be concerned too much about the production. Yesterday I finished 7 units when I had 3 hours of time, today you kept me busy for around 1.5 hours, which would've been 3 - 4 more Pyras.
3. Why arent you concerned about the huge graphics issues?
Well, if I follow your own advise above and shouldn't say anything about the software... then... why should I even be concerned?
I only claimed to deliver the hardware, never the software side. The graphical things are pure software, so according to your own logic, I should stay out of that.
However, as I personally want to see that things are working, so I'll try to help as good as I can.
Most of the OpenGL issues come from the OpenGL Wrapper we're using, and ptitSeb (who is the original author) is regularly working on that and fixing bugs.
The other thing is that SDL does not work with TILER when it's fullscreen and some hardware acceleration for scaling would be nice here.
Though it's also possible to port SDL games to SDL2 (which can use OpenGL), so in that case, hardware acceleration won't be needed anymore.
There are other important lowlevel things (audio driver, etc.) where some devs have already worked on but it's not finished, and (if you follow the kernel mailing list), I will set up bounties for these things to get more devs to work on that.
However, devs needed here would need a Pyra (or at least the OMAP5 devboard), as low-level work and debugging is hard otherwise.
And you need to have a lot of hardware knowledge, a normal game or application developer usually can't do that.
Whereas a Pyra software manager or adding screenshot capabilities into the DBP stuff can be done by any developer, even without having a Pyra at hand.
As explained on Discord: Totally different kind of developers, so one doesn't effect the other. Same as on point 2.
So lesson learned be quicker in preprepreordering.
