Gull: Jkoudys: I read about an emulator on the Raspberry Pi that’s at a really old version because newer versions are more accurate and require more power

Shahinian: Dolby: To completely emulate a Nintendo, you probably need like a 3ghz cpu.

Ornelaz: Vories: well, presumaby you know which tile you hit, right?

Vories: I guess that visible tile thingy would be of some value here too?

Hutchens: Havvy, scanline rendering doesn’t require you strictly render each pixel. You can render the full game canvas, but only draw a region of it hit by the scanlines

Vories: Oh i think i really need some lecture first

Gull: Jkoudys: e.g. it used a bitmap starfield background instead of rendering ir the way the game did

Vories: We can’t do this by one take 😛

Shahinian: Dolby: If you care: http://arstechnica.com/gaming/2011/08/accuracy-takes-power-one-mans-3ghz-quest-to-build-a-perfect-snes-emulator/

Nohe: Gull, I have a few concepts I’m building around like that, mostly the sounds system. The GB sound chip can actually be mapped to custom samples without too much work, e.g. play the game with flute sample instead of a sin wave

Gull: Http://hackaday.com/2014/09/10/raspberry-pi-gets-vga-dual-screen-support/#comment-1807785

Mundine: So yeah it’s an “emulator”, but really the point is to play games. Accurate emus eg no$gb were great back in the day since you could develop on them, but there’s no reason to do that anymore

Ornelaz: Anyway, you had to do that by scaling something down. you can do affine texturing which is wrong, but is the first step by interpolating the texure pixel aka texel along where the position on the screen the pixel was

Ornelaz: If uh, that makes any sense

Boroff: This is more so people can continue to enjoy games written long ago

Ornelaz: Jkoudys: you know most of those old consoles had hardware for sprites. you could probably take advantage of that to speed up rendering a lot

Osche: Tcsc, graphics people do love their portmanteaus with ‘pixel’, it seems.

Flaim: Tcsc, yeah, I know plenty about the old hardware. Was a GB dev many years ago

Swecker: Helped write the sound engine for the Harry Potter and Micro Machines games

Vories: That’s one of my favorite demo remakes of 8bit effects with canvas: http://www.effectgames.com/demos/canvascycle/

Ornelaz: Nice, never played it but still cool

Erber: Tcsc, so I’m looking at all the ways modern JS has more efficient implementations for something like this. The biggest one by far has been the Uint8Array

Ornelaz: For what, pixel manipulation?

Matkin: Oh and Function.prototype.bind bigtime

Ornelaz: Well wait, not sure about that one.

Shahinian: Jkoudys: Be careful with the latter.

Pompilio: No more different functions for ‘LD B, A’ load a into b, ‘LD C, A’ load a into c, ‘LD D, A’ load a into d

Ornelaz: Eh. i suspect that if you look in the profiler the bound function will be deoptimized

Ornelaz: Its a convenience thing more than a performance thing

Burigsay: Tcsc, yeah that’s for code clarity – wrote my instruction set in 600 lines vs 3500 lines in the reference app

Svensen: You can write your own partial application thingie, which wouldn’t suffer from the deopts

Peres: Function partial2f, a{ return functionb{ return fa, b }} is still optimised, and you can use it for partially applying things

Anspach: Dolby, why does the engine insist on deoptimizing bind? I bind like never before now that all my client-side templating happens in React

Ornelaz: Too much polymorphism

Delacueva: Jkoudys: because .bind is too complex. It changes the semantics of the function.

Ornelaz: Thats at least what v8 claims

Ornelaz: Something like “***umptions changed about this function too many times”

Ornelaz: I dont remember the wording.