DEV Community: Rosen Alexandrov

Monte Carlo for casino bonuses: the expected value of free spins hides a 90% chance of nothing

Rosen Alexandrov — Tue, 03 Nov 2026 09:16:12 +0000

In an earlier post I used a one-line formula for the value of a casino bonus: winnings minus the expected cost of the wagering. It is fast and it is what most calculators use, ours included. But a single expected value hides the thing players actually experience: most of the time the result is nothing, and once in a while it is a lot.

So I wrote a small Monte Carlo simulation in plain JavaScript and ran 100,000 players through the same offers. The averages barely surprised me. The distributions did.

Note: this is a probability exercise, not advice to gamble. Gambling is 18+, and every simulated slot here has a house edge, exactly like real ones.

A toy slot with a 96% RTP

Real slots do not publish their pay tables, so the model is a simplified slot: a spin pays a multiple of the bet with a fixed probability, and the probabilities are scaled so the return to player is exactly 96%.

const BASE = [[0.5, 0.10], [1, 0.08], [2, 0.05], [5, 0.02], [20, 0.004], [100, 0.0006], [500, 0.00004]];
const raw = BASE.reduce((s, [m, p]) => s + m * p, 0);
const PAYS = BASE.map(([m, p]) => [m, p * (0.96 / raw)]);   // RTP = 96%

function spin(bet) {
  let r = rand();
  for (const [mult, p] of PAYS) { if (r < p) return mult * bet; r -= p; }
  return 0;
}

About half of all spins pay something, most wins are small, and a 500x hit comes roughly once in 12,500 spins. rand() is a seeded generator (mulberry32 with seed 42), so every number in this post can be reproduced.

Free spins, then wagering

The offer: 50 free spins at €0.20. The winnings are credited as bonus money, and before you can withdraw them you must bet them a number of times at €0.20 per spin. If the balance drops below one bet, you are out.

function freeSpinsTrial({ spins, bet, wagering, cap }) {
  let won = 0;
  for (let i = 0; i < spins; i++) won += spin(bet);
  if (wagering === 0) return cap ? Math.min(won, cap) : won;

  let balance = won, wagered = 0;
  const target = won * wagering;
  while (wagered < target) {
    if (balance < bet) return 0;          // bust before the wagering is done
    balance -= bet; wagered += bet;
    balance += spin(bet);
  }
  return cap ? Math.min(balance, cap) : balance;
}

Run it 100,000 times and look at more than the mean:

Offer	Mean	Median	Players who get €0	Top 1% get at least
50 spins, no wagering	€9.53	€7.60	0%	€31.90
50 spins, no wagering, €20 cap	€8.76	€7.70	0%	€20.00
50 spins, 35x wagering	€5.58	€0	90.2%	€123.70
50 spins, 35x wagering, €50 cap	€3.33	€0	90.4%	€50.00

Two things stand out.

The no-wagering mean matches the formula. 50 spins x €0.20 x 96% = €9.60, and the simulation lands on €9.53. Good sign that the model behaves.

At 35x the formula and the simulation disagree. The linear estimate says the expected cost of wagering is 35 x winnings x 4%, which is more than the winnings themselves, so the value is zero. The simulation says the average is €5.58. The difference is the bust rule: a player can never lose more than the bonus balance, so the losses are cut off, while the rare lucky run keeps its full upside. The average is pulled up by the top few percent, and the median player walks away with nothing.

That is the honest summary of a 35x free-spin offer: positive on average, nothing for 9 players in 10.

What a cap does to the tail

Look at the capped row. The €50 maximum win barely changes how many players get nothing (90.4%), but it cuts the mean from €5.58 to €3.33. A cap does not hurt the typical player. It removes the lucky outcomes that made the offer worth anything on average. With 35x wagering, the cap is often the most important number in the terms.

Cashback: same money, different shape

The same simulation works for cashback. Take €10 of cashback and change only the wagering attached to it:

Wagering on €10 cashback	Mean	Median	Players who get €0
None (paid as cash)	€10.00	€10.00	0%
1x	€9.61	€7.70	0%
10x	€7.60	€0	72.3%
35x	€6.11	€0	89.7%

Cashback with no wagering is a fixed €10. At 1x it is still close to that and nobody ends with nothing. From 10x on it turns into a lottery ticket: the mean stays respectable, but most players lose the whole amount while trying to clear it.

Takeaways

Report the distribution, not just the mean. For anything with high wagering, the median and the share of players who get €0 say more than the expected value.
The linear formula is a floor, not the truth. It ignores that a bust stops your losses, so at high wagering it understates the average and hides how unequal the outcomes are.
Caps attack the tail. A max-win cap changes little for most players and a lot for the average.
Low wagering changes the shape. Going from 35x to 1x does not just raise the average, it removes the 90% chance of nothing.

If you want the quick closed-form estimate for a real offer (spins, spin value, wagering, cap and RTP), the free spins value calculator on CasinoKit gives it in one click. Treat it as the starting point, and remember what the single number leaves out.

Building a manual camera app for iPhone: what I learned fighting for exact exposure values

Rosen Alexandrov — Sun, 01 Nov 2026 09:44:08 +0000

I'm a photographer first and a developer second. For years, the thing that bothered me most about shooting on an iPhone was that the built-in Camera app has no manual ISO, and that every photo goes through a processing pipeline you can't switch off. So I built my own camera app, Real ProCam. It's free on the App Store, and version 1.2 just went live.

This isn't a tutorial. It's a list of things that surprised me while trying to keep one simple promise: the ISO, shutter speed and aperture you set are the values in the file.

1. Setting a custom exposure is easy. Keeping it is not.

AVFoundation lets you set a custom exposure with setExposureModeCustom(duration:iso:). Getting the preview to look right takes an afternoon. Getting the photo to carry the same values took me weeks.

The reason is the capture pipeline. Depending on the photo settings, the system may capture and fuse several frames, and the final file can report values that differ from what you set. For a photographer, that breaks the whole point of manual mode. In the end the answer was simpler than I expected: with manual exposure, every rear lens takes a single frame with minimal processing and no frame merging, and the app only fires once the camera has confirmed the exact ISO and shutter speed. That keeps the values in the file exactly as set.

2. Every camera has its own limits, so read them instead of hardcoding them

The supported ISO range and exposure durations differ per device and per lens, and they change between generations. A hardcoded table for "iPhone 13 and later" was a dead end. Instead, the app reads minISO, maxISO, minExposureDuration and maxExposureDuration from the active format of each camera and builds the 1/3-stop dials from those values. As a bonus, the app automatically offers the full range of whatever hardware it runs on, with no artificial caps.

3. The fastest shutter speeds are quantized by the sensor

This one surprised me. Set 1/32,000 s on the main camera and the file says something else. At very short exposures, the sensor exposes in fixed steps tied to its readout, so the real duration snaps to the nearest step it can actually do. On the main camera I cap the dial at 1/25,000 s on 1× and 1/16,000 s on 2×, because faster settings simply didn't produce faster files. The app also says openly that at those speeds the photo can differ from the setting by up to about 5%, instead of pretending otherwise.

4. SwiftUI view identity can freeze your camera preview

In version 1.2, I made the 16:9 viewfinder fill the height of the screen. The first build had a nasty bug: switching the aspect ratio froze the preview on black for several seconds. The cause was a branching if/else in the layout. Each branch created its own UIViewRepresentable, so SwiftUI tore down the old view and built a new one, attaching a fresh AVCaptureVideoPreviewLayer to a session that was already running.

The fix was a single preview view, created once and kept alive, with only its frame and videoGravity changing between aspect ratios. Switching is now instant.

5. Ask for permissions at the first launch

Another 1.2 lesson: ask for camera and Photos access when the app first opens, not when the user presses the shutter. Otherwise the very first photo someone takes can be lost while the permission dialog is on screen. If access is refused, the app explains clearly that it can't work without it.

What the app does today

Manual ISO, shutter speed and aperture (f/1.48 to f/4 on iPhones with a variable-aperture lens), or Auto for any of them
Your values in the file on every rear lens: a single frame with minimal processing, with no frame merging and no filters
RAW (DNG), ProRAW, uncompressed TIFF, HEIF and JPEG
Every rear lens, plus 8× (200 mm) on iPhone 17 Pro and iPhone 18 Pro
Manual focus, white balance presets, exposure compensation, a live histogram and an exposure meter
iPhone 13 and later
Free, with no ads, no account and no tracking

Try it

If you're into photography or camera APIs, I'd really like your feedback, especially if you've fought AVFoundation's exposure behaviour yourself.

Real ProCam on the App Store: https://apps.apple.com/us/app/real-procam/id6819234474

The OKLCH workflow that finally made my palettes survive contact with real screens

Rosen Alexandrov — Thu, 23 Jul 2026 05:51:20 +0000

I spent years picking colors the same way most of us do. Eyedrop a hex from a mockup, massage it in HSL until it looks right, ship it, and then watch it fall apart. The hover state turns muddy. The chart series that looked distinct on my monitor becomes a blur on a cheap office display. An accessibility audit flags the secondary button text I never thought to check.

So I did what developers do. I got annoyed enough to build a tool. That tool became Shademix, and somewhere along the way it stopped being my personal utility and turned into something thousands of designers, decorators and developers now use every day. Partly because it costs nothing, sure. But mostly, judging by the mail I get, because it fixes the exact chain of small failures I just described. This post is the workflow baked into it. You can follow it with any tools you like, the ideas are not mine to own.

HSL lies about lightness

Here is the root problem. In HSL, hsl(60 100% 50%) and hsl(240 100% 50%) claim identical lightness. Look at them side by side: the yellow glows, the blue is nearly dark. Every palette built by spinning the hue wheel in HSL inherits that dishonesty, which is why one tag color always pops and another always sinks.

OKLCH fixes it. Its lightness channel is perceptual, meaning two colors with equal L genuinely look equally bright. Once you have that, three chores become mechanical. Harmonies: rotate hue, keep L and C, and complementary, triadic, tetradic, split, square and monochromatic schemes all come out visually balanced. Tints and shades: move L alone and the hue stops drifting toward mud. Contrast: keep text near L 0.95 and surfaces under 0.35 and you rarely fail WCAG by accident.

Support is a non-issue now, oklch() works in every current browser:

.btn {
  background: #2f6fde;                 /* old-engine fallback */
  background: oklch(0.55 0.17 262);
}
.btn:hover {
  background: oklch(0.48 0.17 262);    /* only L moves, hue stays clean */
}

Sample the color people actually see

If the brand color lives in a photo or a screenshot, a single-pixel eyedropper will betray you. JPEG compression speckles flat areas with near-misses, and the pixel you happen to hit can sit a visible distance from the color everyone perceives. Sample an area, or take the dominant cluster.

In Shademix this is the Pick tab: drop an image, paste a screenshot with Ctrl or Cmd+V, point the live camera at a wall, or grab from the screen. You get the color in HEX, RGB, HSL, HSV, CMYK, LAB, LCH and OKLCH at once, so whatever the next tool in your chain expects, the value is one tap away. There is also a loupe for the times you really do need one exact pixel.

Name it in the system your client speaks

Developers think in hex. Print shops think in CMYK and Pantone. Architects spec RAL, Scandinavian clients bring NCS, painters bring fan decks. The lookup side of the tool matches any color across ten reference systems and, crucially, shows the delta-E distance on every match. That number is the honesty the usual "closest match" hides. Under 2, nobody can tell the difference. Above 5, everyone can. Knowing which side you are on before ordering paint or a print run has saved me real money more than once.

Build the scheme, then interrogate it

Picking the palette is the fun part. The part that keeps you out of trouble is the interrogation, and it is exactly the part teams skip when it lives in a separate tool they have to remember to open.

So the workflow puts it inline. Run the whole palette through a pairwise WCAG matrix, every foreground against every background, AA and AAA, normal and large text. Five colors is twenty ordered pairs, which is nothing for a machine and torture by hand. Then run the color blindness simulation: protanopia, deuteranopia, tritanopia, achromatopsia. Roughly eight percent of men see color differently, and if your error and success states only differ by hue, some users simply cannot tell them apart. Then the lighting preview, which renders the palette under six illuminants from warm tungsten to north-sky daylight, because a color that changes character between the showroom and the living room is a complaint waiting to be filed. And if anything is headed for paper, the CMYK gamut warning tells you upfront which saturated screen colors will clip on an offset press, and suggests the nearest printable neighbour.

None of this is exotic color science. It is just moved to where you already are, so it actually happens.

Ship values, not screenshots

A palette that lives in a screenshot dies in a screenshot. Export it in the format the code expects: CSS variables, a Tailwind config, JSON, SVG, or straight to design tools as Figma tokens, Sketch or Procreate swatches, Adobe ASE, Photoshop ACO, GIMP GPL. Eleven formats out, nine formats in, so the palette a client mails you as an .ase file lands in the same library as the one you sampled from a site photo. Everything can be filed into per-client projects, compared four at a time as aligned strips, shared as a plain link with the colors encoded in the URL, or exported as a print-ready PDF with crop marks when the deliverable is physical.

The part that surprised people

Shademix runs entirely on your device. Browser, iPhone, iPad, Mac, Vision Pro, and Android on the way. Nothing you sample or import is uploaded anywhere, there is no account, no tracking, and no paywall waiting at the end. When it started spreading I assumed the reason was simply "free". Reading the feedback, the actual reason seems to be that it holds the whole chain, sample, match, harmonize, verify, export, in one place, so the verification steps stop being optional.

Take the workflow even if you never touch the tool: pick in OKLCH, sample areas not pixels, demand the delta-E, run the contrast matrix and the CVD simulation every time, and export real values. Your future self, staring at a hover state that finally is not muddy, will be grateful.

If you want to try it, it is at shademix.com, and the deeper guides with screenshots live on shademix.app. Free, no account, in your browser.