Howdy, fellow bugstompers.

So, some people (myself included) have had varying success in running this game on their modern windows 10 gaming rigs. Any legacy-support features that windows offers on its own haven't worked for me, and I guess not for some other people as well. Additionally, virtual machines running on windows are limited to running the game in "software rendering" mode, which severely limits the visual quality of your gameplay experience.

Save for one. The best way of running the game I have found thus far: Run it on Linux. Through Wine, everything except the cutscene quicktime videos work fine out of the box.

• But wait, my gaming rig runs Windows 10 like any sane person's?! And dual-booting is such a pain in the ass. What do?

Well, there is one thing you can do, and that I just confirmed a viable option. The recent godsend from microsoft - the WSL 2 (Windows Subsystem for Linux TWO). However, it only offers a command-line interface for running cmd applets out of the box, so some setup is needed. Let's get down to it.

#Step 1 - Install WSL 2

You need to have a recent enough version of Windows 10 for this. As far as I know, WSL 1 won't do, as you need multiarch support for running 32-bit binaries, such as our beloved game of collecting seed and stompin' evil spiders. You can prob find a ton of guides on how to do this with google, but here, I just googled one for you: https://docs.microsoft.com/en-us/windows/wsl/install-win10

Ubuntu is likely the distro you would like to use for this, but if you know your way around your favorite distro then ofc go for it.

#Step 2 - Install required packages on WSL

Basically you'll need wine, winecfg and wine32 on your WSL to run the game. Additionally libpulse0 if you want sounds to work later. A text editor like nano will come in handy as well (I prefer vim, but if you are not familiar with its keymaps and dont want to bother learning it for this, then just use nano).

For wine32 (and thus 32-bit win binaries) to work, you need to enable multiarch support. You can do it with:

sudo dpkg --add-architecture i386 && sudo apt update

To install the packages, in case you are not familiar with installing packages on a linux cmd, just do:

sudo apt install <package names>

in this case: sudo apt install wine wine32 winecfg libpulse0 nano

#Step 3 - Set up the graphics

Now, as mentioned, WSL only has a cmd interface. In order to create application windows and draw graphics, your WSL needs to connect to a Window System. The commonly used X Window system uses a client-server architecture, which allows the server (endpoint that actually draws the windows) to run on a different machine than the software that generates the graphics to be drawn in it. As it happens, you can find the X server as a precompiled binary to be run on your windows machine, and connect it to the virtual linux in your WSL.

Follow the instructions in this thread: https://virtualizationreview.com/articles/2017/02/08/graphical-programs-on-windows-subsystem-on-linux.aspx

BUT with some slight modifications: The WSL 2 runs in its own virtualized web-socket, so you need to set the destination of the DISPLAY variable to the IP your WSL uses as its default gateway (that being your windows PC from the WSL's perspective). You can do it like:

export DISPLAY=$(awk '/nameserver / {print $2; exit}' /etc/resolv.conf 2>/dev/null):0

which essentially scrapes the IP from a file in /etc/resolv.conf and prints it in the environment variable DISPLAY. If you want this to happen automatically when you start WSL, you can paste it at the end of the script ~/.bashrc

nano ~/.bashrc

#Step 3.5 IN CASE STEP 3 DIDN'T WORK YET

Now then, depending on which X server you picked from the guide, you may or may not run into issues with your Windows firewall blocking the connection from your WSL. I used VcXsrv https://sourceforge.net/projects/vcxsrv/, and this is how I got it to work:

When starting VcXsrv, pick the following settings:

• Display settings: One large window
• Display number: 0
• Start no client
• DISABLE "Native opengl"
• ENABLE "Disable access control"

Go to Windows Firewall settings

• Find any rules in Inbound rules and Outbound rules (allow or block) for the VcXsrv and delete them

• Create a new Inbound rule

• select "Custom rule"

• "This program path" and find the path to your VcXsrv executable

• Protocol and Ports, set "Protocol type" to TCP

• In "Scope" you could test your setup with allowing any IP address, but this is not necessarily very secure. You should allow connections only from the WSL address space.

  • Go to Network and internet settings > Network and Sharing Centre > Change adapter settings
  • Find the adapter which says WSL or Hyper-V or smth to do with WSL -> status -> details -> IPv4 address
  • The first 3 segments basically tell you the subnet associated with your WSL network. In my case, the IPv4 address is 192.168.31.209, but as I don't know exactly what is the IP of the WSL in that space, I'm going to use "192.168.31.0/24" with the "/24" to mark that the last segment (or 8 bits) can be anything
  • Back in the firewall rule, add your version of "192.168.31.0/24" in both the "local" and "remote" IP address lists and set the option to allow "These IP addresses"

• "Action", "Allow connection"

• "Profile" at least "Public" and "Private" prob need to be enabled, Your WSL adapter might show up as either one in your network settings

• "Name" Give it a descriptive name so you can easily find the rule later, mine is "WSL X-Server"

Now the X-connection from your WSL to your Windows desktop should work. xeyes is a good program to test it with, it should draw a pair of eyes following your cursor.

#Step 4 - Set up sound

I managed to get sound working by following this post https://discourse.ubuntu.com/t/getting-sound-to-work-on-wsl2/11869

The idea is simlar to the X-server, you run a pulseaudio daemon on your windows machine. You can add the "export PULSE_SERVER=tcp:$(grep nameserver /etc/resolv.conf | awk '{print $2}');" at the end of your ~/.bashrc script similarly to the DISPLAY parameter, if you want to set it automatically at restart. Make a firewall rule similar to Step 3.5 for the pulseaudio.exe if the connection gets blocked.

#Step 5 - Install the game in WSL

If your game is in a CD drive like mine, you should mount that on WSL. First make a mountpoint for it like: sudo mkdir /mnt/d

Then mount it: sudo mount -t drvfs D: /mnt/d (Change the D: if your drive is assigned to some other letter)

You want to configure wine for the game. Run winecfg. If your X-server setup works correctly, you should see a configuration window open there. Change the following settings:

• Applications > Windows Version: "Windows XP" (I'm not sure if this actually makes any difference, but worked on my machine)
• Graphics > Emulate a virtual desktop
• Drives
  • In addition to the main drive C here, you might already have an additional Z. Select it and set its "path" to the path where you mounted your CD drive (/mnt/d/)
  • select "Show Advanced" from drive Z
  • Type -> "CD-ROM"
• Apply all settings and close winecfg

Now to actually install the game, you could just run it from where it is in your WSL:

wine /mnt/d/SETUP.EXE

and it will install just fine BUT, because the game will be checking for the presence of a CD rom when running it, you might be safer to run:

wine "Z:\SETUP.EXE"

In which case the game MIGHT get a better idea to where is the drive it should look the CD-ROM from in the future. Or it could just quess its the first CD drive in the system, or have a hard-coded drive letter. I got it working with drive "Z", your experience may vary. D is a probable one to try and rename the drive (with winecfg) to.

Anyways, the Installer should be visible in your X-Server on windows now. Just do how you always do it.

#Step 6 - Run the game

If everything worked at the previous steps, this is now pretty straightforward. If the CD is mounted and ready, just do

wine "Z:\bugs.exe"

and you should (after a while) be greeted with a splash-screen asking for "software rendering" or "hardware rendering", select "hardware rendering" (the lower option).

Now, as I think I mentioned, the cutscenes don't work like this. You might be able to get them to work, but personally I don't care for them anyways. But as the game will anyways try to play them, you might need to press [enter] against an empty black screen for a few times before getting to the main menu.

Now if you can see the menu and hear the epic tunes in your windows-pulseaudio, congratz, you most likely made it, and at least for me, it runs really smoothly like this (apart from some minor transparency bugs in-game). Happy bugstomping.

PS. Yes, this most certainly counts as EMU

Hello fellow bugstompers. I couldn't find any information about there being any notable gameplay differences between PC releases, but checking out the current PC WR clip from Jumpyluff () and comparing it to my copy, it seems like there are at least a few.

I have a PC-CD copy of a finnish-audio dub for the game (prob. based on a UK release) for Win95. Thus far I have noticed the following differences:

Missing a fixed seed in Canyon: My game (no seed): https://imgur.com/GdFPCzD Jumpyluff (seed present): https://imgur.com/2NU7dzU

Different fixed seed in City Square: My game (normal seed): https://imgur.com/HZUEZSo Jumpyluff (fixed propeller seed): https://imgur.com/jvKTLL2

These do affect some of the routes one can take when speedrunning. I'm not sure if this is any new knowledge (please let me know if there is a comprehensive list of version differences), but just something I found interesting.