Opens profile photo
Follow
Sylvain Lefebvre
@sylefeb
Researcher, maker. Creator and lead developer of and #Silice. Explores algorithms for #3dprinting, #fpga, #gpu, #procgen.
antexel.com/sylefeb/resear…Joined September 2010

Sylvain Lefebvre’s Tweets

And there's a blog post! Raytracing on #fpga, racing the beam. Explores fixed point and custom floats with tricks on how to prototype in a reference C code. Check it out!
Quote Tweet
Replying to @tom_verbeure and @furan
Hard to believe that it’s been 4 years since I made this. I had only shortly before started to play with FPGAs as a hobby. Here’s my blog post about it: tomverbeure.github.io/rtl/2018/11/26.
15
There are C ports too: - a recent one by that remains close to the Silice version twitter.com/suarezvictor/s - one I hacked to debug during development (standalone, no deps) github.com/sylefeb/Silice
Quote Tweet
I ported this great demo by @sylefeb from Silice to C++, so I can simulate it fast (some tens of FPS, single-thread). I plan to run it in hardware using automatic pipelining from @pipelinec_hdl, as done in youtube.com/watch?v=hn3sr3 Stay tuned!
Show this thread
Image
1
6
Show this thread
Just made a new release of Edalize, the Python library for interfacing EDA tools. In addition to polish and fixes we now support Slang, Questa Formal and F4PGA, meaning we now target almost 40 EDA tools with a common EDAM (EDA Metadata). description
2
45
Show this thread
14/ I was running low on LUTs so I took a 'shortcut' for the text. Since the text strings are static, I pre-rendered them and stored them as textures in SPIflash. I then blit the text images in the active buffer. No font, no drawString/drawChar required 😎
Image
1
25
Show this thread
13/ This makes drawing spans super easy. For a polygon of 2.N vertices, the left side is from 0 to N-1, the right side from 2.N-1 down to N, and both sides exactly match: the y coordinate is the same between corresponding left-right vertices!
Image
1
23
Show this thread
12/ Fun note: the rasterizer code seems odd at first, but that's because the polygons are preprocessed for performance. A polygon is stored as a left(top-bottom)-right(bottom-top) sequence, e.g.: (25,0) (34,4) (41,15) (32,19) - (8,19) (0,15) (6,4) (13,0)
1
20
Show this thread
11/ Having a reference implementation, I verified that my hardware VM and rasterizer are giving the exact same result in simulation, and they do! I've had most glitches due to sync issues between the VGA scan, blitter and rasterizer. A few glitches remain ...
Image
1
24
Show this thread
10/ I extracted a code+data package by instrumenting (heavily hacking!!) the C++ remake. Fortunately data packages for the intro are loaded first, and then do not change during the sequence. I think the same is true for each game 'part', so maybe I can support the full game!
Image
2
27
Show this thread
7/ My goal was primarily to reproduce the intro sequence (minus the audio). I love this intro. I would load the game just to watch it, and I am even more impressed by it now that I understand what happens behind the scene.
Image
1
37
Show this thread
6/ But where's the code and data then? Well, in SPIflash of course! Think of the VM as a script engine, by running SPIflash at 50MHz and a hardware blitter+rasterizer at 25MHz we really don't have to worry about performance.
Image
1
27
Show this thread
5/ The game uses a palette of 16 colors, 4 bits per pixel, with palette tricks for transparency. Interestingly, four 320x200x4bits framebuffers amounts to 128KB of memory, which happens to be exactly what we have on the UP5K #fpga. I simply could not resist.
Image
1
29
Show this thread
4/ The game is organized around a small VM that calls a blitter, a rasterizer and a font drawer to draw in four framebuffers. The framebuffers are cleverly used to cache background renderings and produce animations.
Image
1
29
Show this thread