Wow, this is some Fabrice Bellard tier stuff! Very impressive!
I'm building a Minecraft clone in hardware, on a tiny FPGA with 143kb of RAM
31–40 of 52 posts
Re: I'm building a Minecraft clone in hardware, on a tiny FPGA with 143kb of RAM
#32How 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…
On console and embedded the OS is either non-existent or gives your game guarantees about when it will schedule something and how often. Hardware obviously gives you way more control, but a baremetal raspberry pi project, Arduboy, console homebrew, etc can give you some of that control back in software. Awesome project btw
Re: I'm building a Minecraft clone in hardware, on a tiny FPGA with 143kb of RAM
#33How 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…
If you have a guarantee for the worst case of generating a pixel (which you indicate by saying that you never drop frames), couldn't you get rid of the framebuffer? Schedule pixel generation so that they complete just in time for when they're needed for output.
This would save up RAM for other things (and be a fun exercice to get right).
Re: I'm building a Minecraft clone in hardware, on a tiny FPGA with 143kb of RAM
#34Earlier 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…
a less clean solution is also to buy controller extension cords (which are usually cheap even for older systems) and chopping off the end.
Re: I'm building a Minecraft clone in hardware, on a tiny FPGA with 143kb of RAM
#35a Minecraft clone in hardware means all code is hardware?
Yes and no. The design includes a custom built 16-bit CPU, which uses a custom instruction set, which I wrote an assembler for. There is a small 4kb bank of RAM that contains a program written in this instruction set. From a hardware perspective it is just data, but from a a software perspective it's that program that is ultimately responsible for running the game (by reading input from the gamepad module, setting up GPU registers, etc.).
Re: I'm building a Minecraft clone in hardware, on a tiny FPGA with 143kb of RAM
#36Are 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.
Re: I'm building a Minecraft clone in hardware, on a tiny FPGA with 143kb of RAM
#37Earlier 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…
If you have a guarantee for the worst case of generating a pixel (which you indicate by saying that you never drop frames), couldn't you get rid of the framebuffer? Schedule pixel generation so that they complete just in time for when they're needed for output. This would save up RAM for other things (and be a fun exercice to get right).
That's a good observation! This technique is also known as "racing the beam". The problem is a mismatch of refresh rates; the VGA display operates at 60 Hz but the ray tracer is not capable of producing that many pixels, it can only do 30 fps. So we need a frame buffer to store the result.
Re: I'm building a Minecraft clone in hardware, on a tiny FPGA with 143kb of RAM
#38This looks very good well done! Microsoft need to hire you for the team asap!
It always cracks me up playing minecraft on xbox one x and once your village hits few hundred villagers framerate (when running beta from insider it's shown on screen) drops to like 3-4fps
Re: I'm building a Minecraft clone in hardware, on a tiny FPGA with 143kb of RAM
#39It looks like you're using an ice40 FPGA? If you can make your project work with 38 I/O pins you could probably get it fabricated in ASIC by Efabless free. You just need to meet their repository requirements and make your verilog module conform to this interface: https://github.com/efabless/caravel/blob/master/verilog/rtl/... The openlane tool converts your verilog all the way down to final ASIC design... You'd need…
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?
Re: I'm building a Minecraft clone in hardware, on a tiny FPGA with 143kb of RAM
#40Earlier 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…
On console and embedded the OS is either non-existent or gives your game guarantees about when it will schedule something and how often. Hardware obviously gives you way more control, but a baremetal raspberry pi project, Arduboy, console homebrew, etc can give you some of that control back in software. Awesome project btw
As an example of this, on the Nintendo Switch, games run on three cores dedicated to the game, while the rest of the OS tasks run on the fourth core. Furthermore their scheduler gives precise guarantees about the scheduling order of threads spawned on the same core. It makes sustained 60fps achievable through careful design.