Closed dirkwhoffmann closed 4 years ago
Despite my first post, I decided to go with iCarousel ๐. Stay tuned.
To overcome the boredom of governmental imposed imprisonment, I was working on a new experimental feature: Auto screenshots (TM) ๐.
Here is how it works. If a disk is dragged into the emulator, the newly designed ADF dialog comes up:
Looks a little boring, I know. To let the fun begin, first enable auto screenshots:
To generate screenshots, hit df0: and do what you would usually do with an Amiga. In case of Shadow of the Beast, just sit in front of your computer and wait until it has finished loading (which literally takes forever).
From now on, when you insert the disk again, the dialog looks like this ๐:
I have to admit that this is kind of a marketing picture ๐. Because the emulator takes screenshots based on a hard-coded schedule, it sometimes grabs an empty screen ๐คญ.
All images are stored locally in the Application Support folder:
The directory name is the fnv64 fingerprint of the inserted disk.
Right now, up to 6 screenshots are taken. The intervals are hard-coded inside the following function. Maybe we can come up with better timing scheme. One could also allow an infinite number screenshots with a logarithmic time scale (e.g., by doubling the interval between screenshots every time a new one is taken).
void
Amiga::serviceScrEvent()
{
static int delay[] = { 20, 30, 30, 30, 30, 30, 0 };
int num = numAutoScreenshots();
takeAutoScreenshot();
putMessage(MSG_AUTOSCREENSHOT, agnus.slot[SCR_SLOT].data);
if (delay[num]) {
agnus.rescheduleRel<SCR_SLOT>(SEC(delay[num]));
} else {
agnus.cancel<SCR_SLOT>();
}
OK, let's bring this to the next level. There are already two storages for snapshots: Auto-taken snapshots and user-taken snapshots. And there is already a dialog for managing them:
I think the straight-forward thing to do now is to add two similar storages for screenshots: Auto-taken screenshots and user-taken screenshots. User-taken screenshots could be generated by pushing a button in the toolbar just like user-snapshots are generated. In addition, there could be a screenshot dialog similar to the shown above. Now, when a disk is dragged in, the emulator first searches for user-saved screenshots. If it founds some, it displays them in the iCarousel view. If it doesn't find any, it'll display the auto-taken screenshots instead.
Looks good. ๐คค Maybe we could display snapshots here instead of pictures only ? Snapshots also have picture plus a gamestate. On selection you could beam yourself into the game state. The storage place of the gamestates could be the same as you did for the pictures. Hm I donโt know ๐ค game state is much bigger who does the housekeeping, how to delete a snapshot ? ๐Good question how to delete individual pictures in your current concept?
Maybe for the game states we better need something different, more organised. A game state browser?
Menu-> open game state browser
Which opens an extra window. With a list. Each row a different game for which the user explicitly saved a gamestate . Each column a picture of a user saved gamestate for the game of that row. Can scroll vertical for the different games or horizontal for the game states of particular game. Like netflix. As an user option we could also implement Netflix famous endless lists ... you never reach the end of the list because the content randomly repeats. We want keep the user ๐คจ infinitely scrolling maybe after hours of scrolling he gets bored and finally decides to play the Amiga top 10 of most worse games ever ๐บ๐พ
you never reach the end of the list because the content randomly repeats
My Netflix list has become infinite, but never repeats. Don't know how I did it ๐. Now I am struggling with the Hilbert hotel paradox. You can kick as many customers out of the hotel as you want without creating vacancy (OK, usually it's more positively formulated: There's always room for a new client).
A game state browser?
Unfortunately, I think we have to backpedal a bit, because things are tricky.
My experience with VirtualC64 has shown that the snapshot format is likely to change from release to release. This means that we shouldn't pursue any approach that is based on storing snapshots persistently in a data base. Originally, I wanted to have snapshots to ease game play. Like saving a snapshot before making a hard decision in a game: Should I go through the left door or the right door? Should I rescue the brunette princess or the blonde?
Another issue is this: Screenshots are bound to the fingerprint of the most recently inserted disk. Now, many games have multiple disks. This means that most screenshots are bound to the second or third disk of the game. This is OK for screenshots, but it wouldn't work for snapshots.
I think I have to dump my previous screenshot idea, too. The problem really is size. For VirtualC64, a lot of users asked my for screenshot support in the past. Hence, I think this is really something people want to have. However, they want to have high-quality screenshots and not just thumbnail images. Now, the problem is size: If we saved high-quality screenshots instead of thumbnails, we cannot just dump them into Application Support and never delete them.
My new idea is to add kind of "Like" button that makes auto-taken screenshots persistent. All other screenshots will be overwritten each time you reuse a disk. I think it's important to keep it simple, because it's still just an eye-candy feature.
Iโve reworked the entire thing on the lessons learned. Here is my new approach:
When the user inserts a yet unknown disk, the dialog looks as follows:
Now imagine that the user hits df0: and plays a couple of minutes:
imagine ... imagine ... imagine ๐ฅฑ
The next time, he inserts the disk, it will look like this:
The dialog automatically displays all screenshots that were taken in the background while the user was playing.
Now, by clicking the star below the center image, the user can โlikeโ the image which moves it to the 'favorites'. So, letโs do this for a couple of nice images:
click .. click ... click ๐คค
Now, when the disk is inserted again, the emulator finds the favorites on disk and displays them instead of the auto-captured images. In my example, this looks like this: ๐
There are some more options. By using the arrow buttons, the user is able to shuffle the images around (in case he doesnโt like the ordering). And by clicking on the path folder, the finder comes up. Going one level up in the finder reveals the directory structure. Auto-screenshots are kept in folder 'auto' and the selected favorites are kept in folder 'user':
All auto-taken screenshots are deleted automatically when a new disk is inserted. All favorites are kept until the user deletes them. Deleting is easy. When the favorites are displayed, the star icon changes to a trashcan icon.
Ok lets execute the concept ...
The next time, he inserts the disk, it will look like this ... Now, by clicking the star below the center image, the user can โlikeโ the image which moves it to the 'favorites'.
Ok good ... reinserting the disk lets me select my favourites from the auto-taken screenshots ๐ ... very nice I like this one
All auto-taken screenshots are deleted automatically when a new disk is inserted.
Oh no. They are deleted before I can select one.๐ญ
Maybe still a bug in the concept or did I something wrong ?
did I something wrong ?
You are not eligible to post today, because you said you are two days off from your computer. Hmm, OK, maybe you're using your smartphone ๐ค.
They are deleted before I can select one.
No, inserting the disk happens when you close the ADF dialog (e.g., by pressing Df0:). Hence, they will be there when you use the disk a second time. But this also means that you only have one chance to add the cool pics to the favorites ๐...
My favorites ๐
My favorites ๐
I love it !
You are not eligible to post today, because you said you are two days off from your computer.
Gotcha.๐ฌ Ok how to argue now?๐ค ... I meant duration of calendar days, which implies that everything between 24h and 48h is two days. I was off 24h and 1 minute which is 2 calendar days, no ?
I was off 24h and 1 minute which is 2 calendar days
๐ค Hmm, I need to recalculate that in a quiet moment.
I was surprised you left the house anyway. Didn't you look out of the window? ๐ฌ
I think the new approach is quite handy. It's really simple to click some nice artwork together ๐:
With the new approach, I might even be able to reactivate my idea about a screenshot browser. Since auto-screenshots get deleted automatically (at least when using a disk twice) and favorites can be deleted manually, disk capacity doesn't seem to be a major issue any more ๐ค.
With the new approach, I might even be able to reactivate my idea about a screenshot browser.
Yes yes yes ๐คค... With an option for netflix infinity list style ๐
Here is the new (experimental) snapshot / screenshot browser:
What I don't like about the current concept is that snapshots and screenshots are treated so differently. Firstly, snapshots are volatile, but screenshots are persistent (at least the favorites). I think that's acceptable due to the reasons explained in one of my other posts. Secondly, snapshots are organized in a flat hierarchy (in two lists, one for auto-taken snapshots and one for user-taken snapshots) whereas screenshots are organized hierarchically (they are bound to a specific ADF to make the artwork stuff work). This is what I don't like. I think many users wouldn't understand the conceptual difference. Maybe it makes sense to organize snapshots hierarchically, too. But to make things transparent the hierarchy would have to be made visible (in some way) inside the browser (kind of a directory list, and the thumbnail pictures would be the directory items).
... to make things transparent the hierarchy would have to be made visible (in some way) inside the browser (kind of a directory list, and the thumbnail pictures would be the directory items)
Maybe for the game states we better need ... oh I already said this above ๐ค
Maybe for the game states screenshots we better need something different, more organised. A game states screenshot browser?
Menu-> open game states screenshot browser
Which opens an extra window. With a list. Each row a different game for which the user explicitly or auto saved a game state screenshot. Each column a picture of a user user or auto saved game states screenshot for the game of that row. Can scroll vertical for the different games or horizontal for the game states screenshots of particular game.... like netflix, no ? ... On this photobook like wall you can just click then on a games screenshot to make it favourite and click again to remove favourite status. On mouse over a white x on the right upper edge lets you delete the screen shot. Drag selection for multiple screenshot pictures ... yes we like that too ๐คค, non?
favourite status is marked with a small red soviet army star !
Which opens an extra window. With a list. Each row a different game ...
I get your point. Spinning the idea further leads to a powerful emulator frontend that not only supports ADF files, but C64 files as well. It would be a Netflix like UI with options such as โLaunch in VirtualC64โ and โLaunch in vAmigaโ. I think FSUAE went that way to some extend with the Arcade frontend. However, I donโt want to start such a big project now (at least not before Iโve written an Atari 2600 emulator ๐คค).
Right now, I am trying to clean up the coding mess on the dev branch by bringing the already implemented stuff into some useful state. My current plan is to move the already existing screenshot management tools from the ADF dialog into the combined snapshot / screenshot dialog. The splitted table view will go away. It will be replaced by something like this:
The ADF dialog will be simplified a bit. When a disk is inserted, it first searches for screenshots in the favorites folder. If images can be found, those images are displayed as eye candy. If there are no favorite images, the auto-saved screenshots are displayed. If there are no images at all, a default image (the one with the white camera) is displayed.
For some reason, it seems to take me forever to code this ๐. Thus I am getting a little bit frustrated about myself, because I am wasting so much time on this features. On the other hand, isnโt this what we are supposed to do? Sitting at home, wasting time, and dreaming about the day when toilet paper will be back in store shelves ๐?
Thus I am getting a little bit frustrated about myself, because I am wasting so much time on this feature
don't ask me for the time spent with the fullscreen thing in vc64web ๐. But hey, we are only supposed to do what we like to do or what we like to think ... vive l'inspiration libรฉrรฉ. But I get your point, it is like being a great pirate captain with a big destroyer that hunts a small shallop loaded with a small trunk full of gold coins toilet paper rolls ... and the shallop is quick and agil ... ๐ค ... it won't let you enter so easily ... ๐ซ... it is so agil and you want that gold coins toilet paper so desperatly ... and oops the shallop makes another of that quick turn maneuvers ... ๐
don't ask me for the time spent with the fullscreen thing in vc64web
Yeaahhhh. giving up is not an option! There are more rounds to come. Stay tuned...
Need to get back to Netflix... Rambo II is playing ....
The sky is clearing up. I think I have a pretty neat solution now. It works as follows:
When a disk is inserted the first time, the ADF dialog appears like this:
Simple and clean. When a known disk is inserted, the dialog provides some additional eye candy:
The auto-saved / user-saved selector is history. If there are user-saved images (aka favorites), those images are display. If not, the auto-taken images are displayed.
Screenshot management happens inside the new snapshot / screenshot browser. While watching Rambo on Netflix yesterday ๐ฆพ, I discovered that iCarousel has a freaking cool Time Machine layout mode ๐คค. Now, the user can browse through all snapshots and screenshots in "Time Machine mode" and do the same things that were possible in the ADF dialog before (moving auto-taken screenshots to the favorites, deleting screenshots, changing the arrangement order).
There are still some issues left (i.e., when browsing through snapshots. I didn't really test the snapshot view yet which means that it is definitely broken by now ๐).
Just encountered another issue:
Let's assume, two emulator instances are running in parallel with the same disk in df0 ๐ณ (the disk in df0 decides where the screenshots are stored). Both emulator instances would record screenshots and push them back into the Application Support folder from time to time. This creates chaos, because they would constantly overwrite the images of the other instance.
I think I have to jeopardize the idea of saving auto-taken screenshots on disk. Only user-taken screenshots should be saved. This means that the ADF dialog won't show auto-taken screenshots if there are no user-taken screenshots. That's OK, I think, because I already changed the dialog to only show user-taken screenshots. This is because auto-taken are usually not that visually appealing (multiple copies of the same image, empty screens etc.)
Oops, I did it again ๐. I've reworked the whole thing ๐ฅต. Over night, I've come to the conclusion that snapshots and screenshots do need a different handling, because they are simply not the same. E.g., snapshots have a natural temporal ordering which means that a time-machine like view is adequate. Screenshots don't have this temporal character. For them, any kind of gallery view is the natural choice. To make a long story short: The shared snapshot / screenshot browser is history (it had a short life-span anyway).
In the next release, there will be two toolbar sections. One for snapshots and one for screenshots:
Clicking the time-machine icon in the snapshot section opens the snapshot browser. The browser works very similar to Appleโs Time Machine. You can move back and forth along the z-axis with a nice animation. Snapshots can be saved, restored, or deleted:
The split view is gone, because I wanted to simplify things.
The folder icon in the screenshot section opens up the screenshot browser. It pretty much resembles what was there in the ADF dialog before. In the manually-taken-screenshot view, the user can delete screenshots or reorder them. In the automatically-taken-screenshot view, there is a star button to move an auto-taken screenshot to the user-taken screenshot (which makes it persistent).
The ADF dialog has been simplified, too. Because screenshots are now managed inside the new screenshot browser, all buttons are gone. The dialog simply displays the manually saved screenshots (if any).
There is another change. Screenshots are now bound to the first disk inserted into df0. I think this resembles the typical use case. Inserting some game boot disk, hitting reset, playing the game.
I hope that I still like that solution tomorrow. If yes, I can switch back to low-level stuff. There is some more CPU work to do ๐.
Inspiration is the key ! The driver of true artists greatest work. ๐๐๐ป
Raffael, Leonardo da Vinci and others did something similar calling it renaissance. Modern word for that is retro.
I still love it ๐. Hence, the issue can be closed, I think.
I am trying to add an image view to the ADF mount dialog that mimics the cover flow / carousel style Apple once used in the Finder.
So far, I've found the following frameworks:
iCarousel https://github.com/nicklockwood/iCarousel
YRCoverFlowLayout https://github.com/solomidSF/YRCoverFlowLayout
LNICoverFlowLayout (Swift port of YRCoverFlowLayout) https://github.com/sumitlni/LNICoverFlowLayout
If somebody knows another suitable framework, please let me know. Otherwise, Iโll try to port YRCoverFlowLayout from iOS to macOS.