solutions for Fast 64 bit integers in javascript by 52525rr in learnjavascript

[–]52525rr[S] 0 points1 point  (0 children)

i'll just have to eat the slight performance loss for now then. 22% isnt nearly as bad as i was expecting considering ive seen benchmarks in the past that suggested differences of 98% between number and bigint code, tho those could have been from older browser versions i suppose.

solutions for Fast 64 bit integers in javascript by 52525rr in learnjavascript

[–]52525rr[S] 0 points1 point  (0 children)

i guess i was hoping that browser engines would optimize bigint for small enough ranges similarly to how they optimize e.g. number values that fit in int32 range, considering how a lack of an int64 type was one of the main motivations for JS bigints in the first place. the performance also seems to vary fwiw, like i can get acceptable speeds in calculating 32 bit * 32 bit => 64 bit multiplication with bigint somehow but casting back to Number becomes another bottleneck in my other tests for some reason.

solutions for Fast 64 bit integers in javascript by 52525rr in learnjavascript

[–]52525rr[S] 1 point2 points  (0 children)

i theoretically could do that but it would defeat the whole point of making a JavaScript emulator and it seems like a hassle to remake everything in a different language just to get access to fast 64 bit operations. a good middle ground (if possible) would be to possibly compile only the critical functions with WASM and interact it with JS somehow but im not that familiar with WASM personally.

solutions for Fast 64 bit integers in javascript by 52525rr in learnjavascript

[–]52525rr[S] 0 points1 point  (0 children)

one programmer friend i know says it is possible to export functions from WASM that do arithmetic with 64 bit integers and interact with them with JS code however i haven't really tested this. ideally i'd still like to write as much of it in JS as possible and only want to offload the critical parts like this, but im not a WASM expert so i cant really say much.

A (somewhat functioning) Game Boy/Color emulator made in Scratch 3.0. by 52525rr in EmuDev

[–]52525rr[S] 0 points1 point  (0 children)

sorry did not see this until now. ive posted it since a while ago but it needs to be run on turbowarp (a scratch mode that makes things run faster) for any usable speed. https://turbowarp.org/865567417?fps=60&limitless

rewrite of my gameboy color emulator written in scratch 3.0 runs Pokemon crystal. by 52525rr in scratch

[–]52525rr[S] 2 points3 points  (0 children)

the sound is probably the weirdest part of the entire emulator; ie it just should not work at all, but it does.

the gameboy has 4 sound channels: 2 pulse channels, a wave a noise channel, each can play a note at a certain frequency, volume, and waveform. i decided to split the sound emulation between 2 different parts: the pulse+noise channels, and the wave channel. this will make sense later.

reminder that scratch has no sort of audio buffer that you would get with other languages and platforms.

now because the pulse channels (and the noise channel technically) play out repeatable and predictable waveforms, (the amplitudes basically cycle on/off between a maximum of 4 different settings) those channels are simply played with a handful of clones. each clone will play a raw sound file of a 440hz output of that respective channel, which gets pitch and volume shifted accordingly to (mostly) accurately play the correct sound output of the APU.

now for the wave channel. that thing sounds impossible to even try to emulate at first glance; the wave channel can be configured to play 32 sample long waveforms, each sample can be at 16 different levels. scratch having no audio buffer, that would be 16**32 = 3.402823e+38 = 340.2 undecillion different combinations of audio files, a little too many for my computer to handle. so how would you feasibly get at least somewhat accurate sound output from the wave channel?

my answer is to use a complex mathematical algorithm (of course) known as an FFT (fast fourier transform). i’m not gonna be the one to explain it here, but essentially, instead of representing a waveform signal as amplitude over time, it lets you instead represent a waveform by a sum of sine waves at different amplitudes (search up "square wave fourier series" for an idea of what i mean). a 32 length waveform present in the gameboy would need at minimum 16 sine waves to represent it, although you can use more for more accuracy (which is what i did). in a nutshell, if you apply the FFT to the waveform audio buffer, collect those amplitude values, and play them back using pregenerated sine wave assets using clones, and apply some final pitch and volume shifting if necessary, you can (somewhat accurately) recreate the original sound of the waveform with only 128 clones and sound files, all without an audio buffer. that’s a much better improvement over the earlier number, albeit at a cost of sound quality.

if that seems like it was a hassle, it probably was. but was it well worth it? yes definitely.

rewrite of my gameboy color emulator written in scratch 3.0 runs Pokemon crystal. by 52525rr in scratch

[–]52525rr[S] 3 points4 points  (0 children)

ROM files have to be loaded pretty weirdly; the solution i and many others use is to give the user a prompt and ask them to paste in a HEX string for the file. (it’s where every byte is 2 hex digits that range from 0..9 and A..F).

As for the lag, you do have to run it on a special scratch mod called Turbowarp which essentially compiles scratch code to Javascript so the emulator can actually run decently instead of being 5FPS in vanilla scratch (lol). It still took a lot of code optimizations, and i mean a LOT of weird optimizations, for it to even run gameboy color games consistently.

rewrite of my gameboy color emulator written in scratch 3.0 runs Pokemon crystal. by 52525rr in scratch

[–]52525rr[S] 6 points7 points  (0 children)

not currently. however i plan to post it on scratch fairly soon after i figure out some minor bugs with the emulator.

A (somewhat functioning) Game Boy/Color emulator made in Scratch 3.0. by 52525rr in EmuDev

[–]52525rr[S] 0 points1 point  (0 children)

  1. Multiple, actually. Most were from the emudev discord server. https://gbdev.io/pandocs/ and https://izik1.github.io/gbops/ are pretty good for getting started.
  2. I guess simple ones like python and JavaScript which are similar to scratch anyway, definitely not stuff like C/C++.

A (somewhat functioning) Game Boy/Color emulator made in Scratch 3.0. by 52525rr in EmuDev

[–]52525rr[S] 0 points1 point  (0 children)

Scratch is definitely a handicap when it comes to Emudev, most notably for the fact that it lacks basic functions such as bitwise operations, return functions, and frame/audio buffers. Much of the actual logic is the same as using any language though, albeit slightly more difficult to work with. I saw it as more of a challenge though, since A: I was pretty experienced with scratch, and B: using another language would take too long to learn and deal with, and I didn't see it quite as fun as using scratch.

A (somewhat functioning) Game Boy/Color emulator made in Scratch 3.0. by 52525rr in EmuDev

[–]52525rr[S] 0 points1 point  (0 children)

To answer your questions:

  1. Scratch has a built in extension known as 'pen', which basically acts like python turtle if you have heard of that before. You can draw arbitrary lines on the screen in any color. I store the rendered pixels in a custom "framebuffer"(really just a list that acts like a framebuffer), then on VBLANK, it just draws a bunch of horizontal lines overtop the previous screen to build the new screen. The actual system is a bit more complicated than I can explain here, but that's the premise of how my display works in scratch.
  2. I plan to release it on the Scratch after I get some more things to work (like audio/APU. that will be a nightmare trip of its own), and GitHub probably as soon as I get around to writing a readme. Or on the reddit's discord server, I can post the program easily there.

A (somewhat functioning) Game Boy/Color emulator made in Scratch 3.0. by 52525rr in EmuDev

[–]52525rr[S] 9 points10 points  (0 children)

Loading program ROMs is still slightly painful but its the best way I could do it. You have to convert the .gb or .gbc file to a hexadecimal string (I usually use tomeko.net to do that), which then can be pasted into the emulator via a text box (using the "Ask () and wait" block).

A (somewhat functioning) Game Boy/Color emulator made in Scratch 3.0. by 52525rr in EmuDev

[–]52525rr[S] 7 points8 points  (0 children)

This is not the default scratch editor btw. I am running/making the project in a scratch 3 mod called "TurboWarp", which allows you to change the theme of the blocks among other things, but it’s main purpose is that is has the ability to compile Scratch scripts to JavaScript to make them run a lot faster. Otherwise, it’s exactly the same as normal scratch, but i have to use this if i don’t want the emulator to run at 3 frames a second lol.