Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I'm building a Minecraft clone in hardware, on a tiny FPGA with 143kb of RAM

twitter.com

Post reply on HN
Print view View original

41–50 of 52 posts

Re: I'm building a Minecraft clone in hardware, on a tiny FPGA with 143kb of RAM

#41

Post by retro_guy »

nickmqb wrote: post #26
primis wrote: post #25

Earlier quoted context omitted.

If you're using an n64 controller, you might want to consider using a gamecube one instead (it uses the same control logic, it just adds a 5v line for rumble features) Unless you're particularly fond of the N64's controller design that is

That's a good idea. The two analog sticks on the GC controller would be an improvement over the single stick on the N64 controller for movement in 3D. I think that the main benefit of the N64 controller (besides a nostalgia factor, though that may just be me ;)) is how easy it is to connect. I actually just got some wire from the local hardware store, plugged pieces of it into the controller connector, and then attac…

Talking about the N64 and FPGA, do you know that someone is working on an FPGA implementation? Link: https://twitter.com/ufp64

Hmm… Hardware Minecraft… I do also wonder what would it take to create a PICO-8 (popular fantasy console) implementation in hardware with a Lua CPU…

Re: I'm building a Minecraft clone in hardware, on a tiny FPGA with 143kb of RAM

#42

Post by nickmqb »

mysterydip wrote: post #39
nickmqb wrote: post #21

Earlier quoted context omitted.

In terms of I/O pins that should actually be fine (current pinout: VGA (14x), SPI (4x), CLK (1x), N64_controller (1x)), though I'm still working on the project and I don't think it'll be done by the deadline. It looks like they might do future batches though -- it's a cool idea!

Don't you only need 5 pins for VGA: R,G,B,HSync,and VSync?

VGA is an analog protocol, but the FPGA can only output a 0 (GND) or 1 (3.3v) on its I/O pins. I'm using a Digilent VGA Pmod [1] which uses a set of resistor ladders to map each color component from a 4-bit value to an analog voltage that goes to the monitor. This means that we have 14 pins: R (4x), G (4x), B (4x), HS (1x) and VS (1x).

[1] https://store.digilentinc.com/pmod-vga-video-graphics-array/

Re: I'm building a Minecraft clone in hardware, on a tiny FPGA with 143kb of RAM

#43

Post by OJFord »

nickmqb wrote: post #9
anfractuosity wrote: post #6

Earlier quoted context omitted.

It looks very cool! What's the GPU & CPU written in out of interest, I think I saw on your twitter you've written something to translate to verilog, is that used for this?

Yup, that's correct, the design is implemented in Wyre, which is a hardware definition language that I created. The language compiles to Verilog so it can work with existing hardware development toolchains. The language is open source and can be found here: https://github.com/nickmqb/wyre

I like the sound of that, but my verilog's rusty, a suggestion for the readme: show what the equivalent verilog would be for the example, or better I suppose the actual verilog that it would transpile to.

I suppose your target audience is mainly more familiar with verilog (though not necessarily I suppose - could have only ever used VHDL) but I'm interested in playing with it, just haven't used verilog, or FPGAs at all, since university.

Re: I'm building a Minecraft clone in hardware, on a tiny FPGA with 143kb of RAM

#44

Post by guavaNinja »

nickmqb wrote: post #36
young_unixer wrote: post #30

Are you using Minecraft's textures? because those look very similar to Minecraft's actual textures.

Yes, I am. This also means that any open source distribution won't include those textures. However, if I do end up open sourcing the work I'll make sure to include instructions for people that already own Minecraft; the textures are just .png files that can be extracted from the game's .jar file and can then be transformed to be used on the FPGA.

I suggest you look at minetest[1] textures. It's an opensource minecraft clone. Most textures have CC or MIT licenses. Read license.txt for each texture mod before you use them. They may help in opensourcing your project.

[1]: https://github.com/minetest/minetest_game

Re: I'm building a Minecraft clone in hardware, on a tiny FPGA with 143kb of RAM

#45

Post by mysterydip »

nickmqb wrote: post #42
mysterydip wrote: post #39

Earlier quoted context omitted.

Don't you only need 5 pins for VGA: R,G,B,HSync,and VSync?

VGA is an analog protocol, but the FPGA can only output a 0 (GND) or 1 (3.3v) on its I/O pins. I'm using a Digilent VGA Pmod [1] which uses a set of resistor ladders to map each color component from a 4-bit value to an analog voltage that goes to the monitor. This means that we have 14 pins: R (4x), G (4x), B (4x), HS (1x) and VS (1x). [1] https://store.digilentinc.com/pmod-vga-video-graphics-array/

Oh duh, I should've remembered that. So 12 bit VGA then. From the demo that seems sufficient. Have you tried getting rid of the LSB to see if there's a noticeable difference? I'm curious how few colors you actually need

Re: I'm building a Minecraft clone in hardware, on a tiny FPGA with 143kb of RAM

#46

Post by nickmqb »

mysterydip wrote: post #45
nickmqb wrote: post #42

Earlier quoted context omitted.

VGA is an analog protocol, but the FPGA can only output a 0 (GND) or 1 (3.3v) on its I/O pins. I'm using a Digilent VGA Pmod [1] which uses a set of resistor ladders to map each color component from a 4-bit value to an analog voltage that goes to the monitor. This means that we have 14 pins: R (4x), G (4x), B (4x), HS (1x) and VS (1x). [1] https://store.digilentinc.com/pmod-vga-video-graphics-array/

Oh duh, I should've remembered that. So 12 bit VGA then. From the demo that seems sufficient. Have you tried getting rid of the LSB to see if there's a noticeable difference? I'm curious how few colors you actually need

Most textures look fine despite the 4-bit quantization, but color artifacts/hue change do become more apparent when multiplying with a light factor (to darken the textures on the bottom and sides of blocks), so I'd say 4-bit is definitely pushing the limit. 6 bits or even 8 bits per color component would be ideal, though unfortunately on a small FPGA like this we cannot afford such luxuries ;). It is probably the first thing I'd change if I were to port this to a larger FPGA, since it would be pretty straightforward to do and the increase in visual quality would likely be worth it.

Re: I'm building a Minecraft clone in hardware, on a tiny FPGA with 143kb of RAM

#47

Post by ithkuil »

OJFord wrote: post #43
nickmqb wrote: post #9

Earlier quoted context omitted.

Yup, that's correct, the design is implemented in Wyre, which is a hardware definition language that I created. The language compiles to Verilog so it can work with existing hardware development toolchains. The language is open source and can be found here: https://github.com/nickmqb/wyre

I like the sound of that, but my verilog's rusty, a suggestion for the readme: show what the equivalent verilog would be for the example, or better I suppose the actual verilog that it would transpile to. I suppose your target audience is mainly more familiar with verilog (though not necessarily I suppose - could have only ever used VHDL) but I'm interested in playing with it, just haven't used verilog, or FPGAs at a…

Take a look at the examples dir on github: https://github.com/nickmqb/wyre/tree/master/examples

Then look at the "output" subdirectory and you'll find a verilog generated file for each example of the parent directory.

Re: I'm building a Minecraft clone in hardware, on a tiny FPGA with 143kb of RAM

#48

Post by franga2000 »

nickmqb wrote: post #36
young_unixer wrote: post #30

Are you using Minecraft's textures? because those look very similar to Minecraft's actual textures.

Yes, I am. This also means that any open source distribution won't include those textures. However, if I do end up open sourcing the work I'll make sure to include instructions for people that already own Minecraft; the textures are just .png files that can be extracted from the game's .jar file and can then be transformed to be used on the FPGA.

I can't remember any off the top of my head, but I'm pretty sure there are a few open source texturepacks for Minecraft that would be a drop-in replacement (same filenames amd structure).

Re: I'm building a Minecraft clone in hardware, on a tiny FPGA with 143kb of RAM

#49

Post by gnramires »

nickmqb wrote: post #8
mentos wrote: post #5

How is the rendering performance with large worlds?

The FPGA that I'm using for this (the Lattice iCE40 UP5K) is really limited when it comes to RAM, which is the main constraint when it comes to world size. As per the title, there's only 143kb, which is insanely low for doing any kind of 3D stuff :). 48kb is used by the frame buffer, 19kb for textures, which leaves 76kb. 48kb of that is used for the map, which currently limits it to 32x32x32 blocks. However, I do hav…

Have you thought of going Shadertoy style and doing everything procedurally? Or every block procedurally? That way you can cut RAM as much as you wish. For example, if you have a procedural formula to determine if a block is populated, you don't need to store it in RAM, just use this formula in the renderer directly (in Shadertoys this usually would repeat per-pixel).

Re: I'm building a Minecraft clone in hardware, on a tiny FPGA with 143kb of RAM

#50

Post by nickmqb »

gnramires wrote: post #49
nickmqb wrote: post #8

Earlier quoted context omitted.

The FPGA that I'm using for this (the Lattice iCE40 UP5K) is really limited when it comes to RAM, which is the main constraint when it comes to world size. As per the title, there's only 143kb, which is insanely low for doing any kind of 3D stuff :). 48kb is used by the frame buffer, 19kb for textures, which leaves 76kb. 48kb of that is used for the map, which currently limits it to 32x32x32 blocks. However, I do hav…

Have you thought of going Shadertoy style and doing everything procedurally? Or every block procedurally? That way you can cut RAM as much as you wish. For example, if you have a procedural formula to determine if a block is populated, you don't need to store it in RAM, just use this formula in the renderer directly (in Shadertoys this usually would repeat per-pixel).

It did cross my mind. However, a problem with that approach is that evaluating such a formula is too costly/inaccurate on a small FPGA like this, which just has 8 DSPs (that can only do 16x16 bit multiplication), and some of these are already in use in other parts of the design.
Post reply on HN