GeezerVison

I believe this has been implemented before, check #565

I like the simple interface and think they solve different problems. Maybe we could have both apps in a world where we are able to choose which apps we want.

One feature that I think is quite nice to have in a dice app, is being able to specify a number of dice, rather than just always rolling one die. I don't think that for this you would need to show the results of all the dice individually, just the final result.

For the rest I think this app looks good! 👍

#565 is doing exactly that already.

You're right, it does do that. But it hasn't been updated in quite a while, and so doesn't merge nicely with some of the changes in InfiniTime. The author of that PR also doesn't seem to be very active, so it's uncertain as to whether it will be updated.

This problem is fundamental for InfiniTime. We need to fix the app problem.
Shameless plug: #1296

Thank you @NeroBurner kindly for your improvements on the code ❤️ Thank you everyone for your comments and feedback as well.

@FintasticMan :

One feature that I think is quite nice to have in a dice app, is being able to specify a number of dice, rather than just always rolling one die.

I definitely appreciate your sentiment, rolling multiples is a frequently needed and useful function of dice! 👍 However I tend to agree with @minacode , there's a value to keeping the interface simple and intuitive, and #565 already implements multi-roll in a lovely way. But I might be thinking about ways to implement that smoothly without crowding the UI too much.

Implemented rolling multiple dice in 52e4af5

(Thanks for the suggestion @FintasticMan ! 👍)

The number of dice can range from 1-9 (default 1), and the sides can range from d2-d99 (default d2). The individual rolls are shown as well. Here's the new look:

As before, any feedback or further suggestions are much appreciated. I'll try to keep it up to date with the official develop branch in the meantime. Thanks everyone :)

Rebased to 1.14! (Very excited about the customizable user app selection implemented in this version of Infinitime.)

I also want to bump this PR in general. It has been ready for a long time, and continuing to work great in 1.14. The shake-to-roll function implemented by @Poohl has been working super well also. This has probably been my most frequently used of the PineTime user apps, and have used it in a few different circles with very good success. Sometimes I have taken the PineTime off the band and passed it around during a tabletop game for players to roll. There have been numerous other PRs for dice apps in the past, so there is definitely interest in such an app from the PineTime community.

I know there are a lot of PRs to review and a lot of more important work to do for Infinitime in general -- all on a volunteer basis, which I recognize and greatly appreciate! However, can the maintainers weigh in on the plans for this at some point? @JF002 Are there plans to add it to the 1.15 milestone? Thanks! :)

@FintasticMan thank you for your kind words & thoughtful feedback/review, I really appreciate it!! ❤️ No apology necessary, you folks have been doing amazing work with InfiniTime and I know you have a ton on your plate!

I really like this app! A couple of concerns: do we really need the C++ random generator, is it that much better than C's rand? Could you try using rand with the bias elimination implemented in #881, and see what the difference in flash usage is?

I noticed that rand() is used for RNG in other apps like Paddle and Twos, and so I did initially use it in earlier versions of the Dice. However, there are a few significant flaws with rand() (detailed below) that make it inferior to the C++11 <random> lib. I think that doesn't matter for the other apps mentioned, where the experience is fine as long as it generally feels random-- but for the Dice, since the whole point of the app is randomness, it feels important for the randomness to be very fair / high quality.

(1) According to official docs, rand() is considered deprecated for most needs as it does not guarantee quality of the randomness of the sequence produced. More details here:

There are no guarantees as to the quality of the random sequence produced. In the past, some implementations of rand() have had serious shortcomings in the randomness, distribution and period of the sequence produced (in one well-known example, the low-order bit simply alternated between 1 and 0 between calls). rand() is not recommended for serious random-number generation needs. It is recommended to use C++11's random number generation facilities to replace rand(). (since C++11)

(2) As you mentioned, there is the possibility of modulo bias with rand() % x (where is RAND_MAX is not divisible by x, then generating smaller numbers is more likely). With rand(), it's possible to correct for it with a few extra lines of code, but feels more elegant to instead use the intended standard library function, which picks integers uniformly distributed on a specified closed interval.

(3) The <random> library has the very neat std::seed_seq function used here, which mixes multiple sources of randomness together (as opposed to srand(), which takes in just 1 seed), and makes seeds that are distributed over the whole 32-bit range even when the inputs are close or poorly distributed. This is nice here particularly because the PineTime has a few possible sources of randomness that can work together in tandem; the dice app mixes the system tick count and the X/Y/Z components of the PineTime's sensitive motion controller (credit to @w4tsn #1199 for the motion controller idea!), making seed collision vanishingly unlikely.

Another concern is how well the shaking works when lower to sleep is also enabled. Could you check if there are any issues there? (I'm also not a big fan of the hack of enabling shake to wake if it's disabled to get it to work, but I don't think that needs to be solved now)

That's a great point; I am not sure as I haven't previously used lower to sleep on my own PineTime -- I will test this shortly and report back here soon!

Thank you for the thorough explanation. I think it shows you've put a lot of thought into this and I agree that using rand() is not well-suited for this application. Let's stick with the C++ random classes you've already implemented then!

Another concern is how well the shaking works when lower to sleep is also enabled. Could you check if there are any issues there? (I'm also not a big fan of the hack of enabling shake to wake if it's disabled to get it to work, but I don't think that needs to be solved now)

Tested current version on PineTime hardware, it's working well! The lower-to-sleep & raise-to-wake continues to work inside & outside the Dice app when these are enabled, and the shake-to-roll works as well.

Awesome, thanks again!!! Let me know if anything else needed prior to merge!

@yusufmte thank you for your hard work and endurance!

We can finally say: Alea iacta est

@yusufmte thank you for your hard work and endurance!

We can finally say: Alea iacta est

Thank you friend, and many thanks to all who contributed and reviewed along the way! 🎉 Alea iacta est, indeed! :)