Pandora PND packagers: 1) Please provide previewpics. 2) Define primary pic if you give multiple!

[pmprog]

@skeezix (And anyone else interested):


Just had an idea, but why not keep the preview pic outside the disk image, why not just append it/them instead? then when parsing the pxml file, grab them in order of appending (or go by some tag, like PIC1).


Shouldn't this speed up the whole loading process in mini-menu, since you wouldn't need to mount/dismount the pnd?

If you just appended the images as binary blobs on the end of the PND you'll run into two problems:

• You have no filenames
  
• You don't know where each file starts and ends
  

Unless you changed the way PNDs were built (ie, had a binary header at the top of the PND specifying Offset and Length of chunks and their types (Disk image, PXML, Icon, PreviewPicture etc.), but that would require a lot of changes, and don't think it will happen

 

[porg]

Concerning speedup for mounting:


The documentation mentions, that future revesions of PND may use other image formats, possibly having some influence on the speed which previewpics can be loaded.


But the main topic of this discussion is whether to give a standard for specifying a primary / ordered previewpic(s), and this discussion is now continued on the dev mailing list by skeezix.

 

[mcobit]

BTW, I just read my emails form the weekend and I will NOT change 10 pnds only to make a better previewpic the first one.


Actually it is kind of a personal preference, which picture will be shown first.


For example, in my MAME cabinet I have only titlescreens as the previews...


So I appreciate the effort it must have been to go through half the repo and post the suggestions, but I won't repack all those pnds for this purpose.


Maybe I will take that into account, when updates appear, but not right now.


I just don't think it is in a good work/use ratio.

 

[porg]

The use case from which this whole discussion arose:


When I browse in Minimenu and don't remember which game is about what anymore, I toggle the detail pane (with the previewpic (and the optional user notes)) to get a memory refreshment.


If the previewpic is a main-menu screenshot, it mostly does not help my memory, except if it is:

• just an overlay menu, and still shows enough of the game in the background,
  
• styled in the typical game look & feel.
  

Concerning personal preference: Even if the environment (in this case Minimenu) would allow browsing through multiple previewpics, I still advocate for an illustrative primary picture, simply to reduce the necessary interaction steps for the user!!!

• Because if I quickly browse in Minimenu among 10 games, these are 10 steps.
  
• Whereas if I browse through 10 games, and within each game have to browse through 2-5 pics until to get a well enough impression, these are 20-50 steps in total, plus entering/exiting that previewpic slideshow mode possibly introduces some more interaction steps (except if you designate a direct key assignment, but in MiniMenu and also PNDManager almost all keys are assigned), adding another 20 steps, making it 40-70.
  

10 compared to ~50 interaction steps: I think that's worth the maintainers work for improved usability.

 

[mcobit]

Really, if you don't remember what a game was about, just start it and see. I totally agree, that it is nice to see everything on the first look, but well, I don't think people won't have the time to start a game if they want to know what it was.


My 2 cents and as said, I get your point and will update the pnds, when I have to touch them again later, but not now or anytime soon.


Edit: Also, would you give me permission to remove your annoying comments on the repo as soon, as I have made a list of the pnds, that you marked?

 

[porg]

Yes, please feel free to remove my comments.


As you are now informed, and will change the pic order with the next updates of your PNDs, their purpose has been fulfilled.

 

[porg]

Really, if you don't remember what a game was about, just start it and see.

For a user which has about 10 PNDs, the memory problem certainly does not arrive!


But for those who use the advantage of an open source gaming console (yes, that's one of the reasons to choose OP !), they may test many apps (mostly for free!), and somewhen later in the process, reduce to their favorites. For the discover/test/compare workflow a quick reliable previewpic comparison is an efficient memory help!


My reasoning concerning "work/use ratio" for primary previewpics.


Effort for the maintainer:

1. Reordering/renaming in the PXML and the pic files may cost 5-10 mins.
   
2. Generating a new PND from this and testing it maybe another 15mins.
   

On the user's side: Over time it saves 1-10 minutes per user (example: start and quit app, or lookup the game info online, easily takes some time), multiply that with the amount of users...! Easily worth the effort for the maintainer.


And yes, I am realistic, few maintainers will update their PNDs just for their previewpics or icons, but if they some day create a new version, meaning that they anyhow need to do step 2 (generate PND from source files again), then only step 1 (previewpic order) is an additional effort, which hopefully be worth it for the maintainers (example: mcobit).

 

[Dimacus]

If you just appended the images as binary blobs on the end of the PND you'll run into two problems:

• You have no filenames
  
• You don't know where each file starts and ends
  

Unless you changed the way PNDs were built (ie, had a binary header at the top of the PND specifying Offset and Length of chunks and their types (Disk image, PXML, Icon, PreviewPicture etc.), but that would require a lot of changes, and don't think it will happen

Couldn't the offset and length be included in the PXML file?


This would make the creation process a bit more complex, but if tools like pnd_make.sh is modified for this, it shouldn't complicate too much.


How does libPnd handle it now, since both the pxml and icon file are appended, simply looping trough the file searching for the file headers?

 

[pmprog]

If you just appended the images as binary blobs on the end of the PND you'll run into two problems:

• You have no filenames
  
• You don't know where each file starts and ends
  

Unless you changed the way PNDs were built (ie, had a binary header at the top of the PND specifying Offset and Length of chunks and their types (Disk image, PXML, Icon, PreviewPicture etc.), but that would require a lot of changes, and don't think it will happen

Couldn't the offset and length be included in the PXML file?


This would make the creation process a bit more complex, but if tools like pnd_make.sh is modified for this, it shouldn't complicate too much.


How does libPnd handle it now, since both the pxml and icon file are appended, simply looping trough the file searching for the file headers?

You PXML file will need to be updated post PND creation, which, unless you've padded the space first, will require a change in length on the PXML. That's awfully messy