[HN Gopher] Pico3D: Open World 3D Game Engine for the PicoSystem...
___________________________________________________________________
Pico3D: Open World 3D Game Engine for the PicoSystem (RP2040
Microcontroller)
Author : bstrobl
Score : 201 points
Date : 2023-04-16 11:49 UTC (11 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| ggambetta wrote:
| Very impressive, and very fun :)
|
| I wish I had the time to do this, but it looks like it would be
| relatively simple to modify render_rasterize.cpp [0] to do
| perspective-correct texture mapping [1]. I also wonder if going
| for a scanline approach [2] would be faster than iterating over
| the whole screen calculating barycentric coordinates?
|
| [0]
| https://github.com/bernhardstrobl/Pico3D/blob/main/engine/re...
|
| [1] https://gabrielgambetta.com/computer-graphics-from-
| scratch/1...
|
| [2] https://gabrielgambetta.com/computer-graphics-from-
| scratch/0...
| bstrobl wrote:
| I used some of your pages for my thesis so thanks for that :)!
| It is likely that a scanline rasterizer is more performant, but
| some of the triangles are really small on a 120x120px display,
| so just the sorting of up to 1500 triangles for each scanline
| may have its own drawbacks if many are tiny. One of the other
| reasons (aside from needed implementation time) for the current
| approach is also the hope that future microcontrollers might
| simply have more cores to throw at the problem so rendering
| could be parallized a lot faster simply by splitting rendering
| areas. Definitely plenty of room for improvement everywhere but
| time is sadly always a factor, hence why I hope others may be
| able to help ^^.
| ggambetta wrote:
| Oh, that's very nice, we've come full circle :)
|
| What do you mean by "sorting 1500 triangles"? You mean
| sorting their vertices? I believe you already do that in a
| couple of places; since you're using a depth buffer, I don't
| think you need to sort them back-to-front, so I'm not sure
| what you mean.
|
| True that a 120x120 display is tiny, but that also means that
| you can get away with two static arrays of 120 elements for
| the left and right sides of the triangle, no need to do any
| allocation or use tons of memory.
| bstrobl wrote:
| By scanline rasterizer I assumed a system similar to the
| original Quake scene rasterizer best described in Michael
| Abrash's Graphics Programming Black Book.
|
| The method allows saving substantially on any overdraw
| since fillrate is really the primary bottleneck here.
|
| I did a quick check on your page and it seems the
| implementation describes a per triangle setup vs the more
| complicated solution by Carmack and his team? Could still
| work well for larger triangles, maybe with a check on
| triangle size to avoid really small ones.
|
| Quake did after all utilize 3 different rasterizers to
| optimize performance depending on use case.
| trollied wrote:
| The PicoSystem itself can be purchased from its creator,
| pimoroni: https://shop.pimoroni.com/products/picosystem
| kefabean wrote:
| As an aside, if you haven't yet found this wonderful if tiny
| retro gaming experience, the InfoNES emulator project ported to
| PicoSystem is definitely worth hitting up:
|
| https://github.com/fhoedemakers/PicoSystem_InfoNes
|
| It's still in early stages, no sound and no save points, but
| thoroughly cute and addictive nonetheless!
| varispeed wrote:
| I wonder what's with safety of such enclosures made of pcbs?
| For instance is it going to have unpleasant chemicals
| transferring on the fingers and then to the body when someone
| touches eyes or mouth?
| whiskers wrote:
| The only part of the enclosure that is exposed PCB is the
| front plate, the rest is machined anodised aluminium - it
| feels great.
|
| All of our products meet the REACH and RoHS requiements for
| restricted and hazardous materials.
|
| TL;DR It's fine.
| detrites wrote:
| As a user can confirm siblings comment. The way it's designed
| your fingers don't really come into contacting the faceplate,
| and even then it's not raw but painted. Certainly, I have not
| felt anything coming off of it and I've used it rather a lot.
| xigency wrote:
| This is really great. I haven't made much (any) progress, but I
| would like to do something similar for the Analogue Pocket. Still
| trying to discern the best use of the FPGA cores for a little 3D
| world. I'll take a look and see if there are any nifty tricks
| here I can leverage.
| ekvintroj wrote:
| Mind blowing!
| pcdoodle wrote:
| Impressed with the frame rate and gfx style. I feel like i could
| enjoy a world/story in that engine.
| vrglvrglvrgl wrote:
| [dead]
| vinkelhake wrote:
| There's also RP2040 Doom which managed to get doom running on the
| RP2040, complete with sound, music and networking over I2C. The
| VGA signal is generated by a PIO state machine on the RP2040.
|
| https://kilograham.github.io/rp2040-doom/
| detrites wrote:
| Direct link to gameplay video _(spoiler)_ :
|
| https://youtube.com/watch?v=n6bECGQyNuk
|
| It achieves this by using both cores & clocking the RP2040 at
| 250Mhz (via Picosystem's SDK).
|
| (Well, and probably also being decently coded...)
| csense wrote:
| From personal experience I know a 266 MHz (single core) PC from
| c. 1997 can run 3D games with somewhat comparable graphics just
| fine (MechWarrior 2, the PC version of FF7) at low SVGA
| resolutions (640x480 - 800x600).
|
| The Pico3D is 1/2 the performance (133 MHz if you use only one
| core for rendering), but 1/8 as many pixels (240x240 display).
|
| Definitely a cool project, but based on specs it's actually not
| that surprising this is possible.
| detrites wrote:
| One key relevant difference between the Picosystem/RP2040 and
| a '97 PC is available RAM and video RAM, the RP2040 has only
| 264KB of any fast RAM (excluding external flash which has DMA
| and XiP but is still comparably slow).
|
| Whereas a '97 PC would be in the many tens of MB or possibly
| hundreds, and at least a few MB dedicated VRAM on a video
| card. So not an equivalent comparison really, this is a much
| more constrained environment.
| vardump wrote:
| You can render one line of output and DMA it to the
| display.
|
| So no need to have a complete framebuffer in the first
| place. Lack of memory just limits the number of textures
| you can have.
| moefh wrote:
| Another huge difference is that the RP2040 lacks floating
| point support. At least it has (integer) hardware division,
| but that's about it.
| monocasa wrote:
| Floating point doesn't really matter much here. Even at
| the time, you'd typically use integer fixed point math
| unless you were micro optimizing for the different
| execution ports of the CPUs you were targeting and didn't
| want the float pipes to sit idle.
| jeremychone wrote:
| This is so awesome. Well done! I played a little with Pico/RP2040
| (as a hobby), and it is so much fun. I wish educational content
| and institutions would embrace it more quickly.
| skybrian wrote:
| Very impressive. The linked thesis is a nice overview of the
| design:
|
| https://lavarails.com/download/open_world_3D_microcontroller...
|
| It describes a lot of previous commercial game devices, but
| doesn't really discuss current alternatives to the PicoSystem. I
| wonder if there are more capable open-firmware devices at around
| the same price?
| detrites wrote:
| Nothing I'm aware of has nailed the form-factor/ergonomics and
| quality of the controls. It's a solid unit and has the feel of
| a finished product. Alternatives are typically bare circuit
| boards or lack quality input.
|
| It seems like Pimoroni spent time to get those aspects right,
| and so while there aren't that many games (yet?) - the good
| quality ones are a joy to play feel-wise, eg Square Bros (which
| comes installed on a new unit).
|
| The SDK is well thought-out and simple, and has a unified API -
| micropython or c/c++.
|
| They are apparently working on a successor that plugs into a TV
| or monitor via HDMI. IIRC it will use two RP2040's.
|
| EDIT: Yes, two chips:
|
| https://www.tomshardware.com/news/pimoroni-stick-pi-gaming-c...
| skybrian wrote:
| Huh, I was going to suggest that! There're 80 cents each, so
| why not? But it seems there's a purpose for it:
|
| > The dual RP2040 chips on the DV Stick will allow it to have
| one CPU that does the software processing and another that
| just drives the display. Each of the chips has its own PS RAM
| chip, which means that there will be more memory than the
| 264K that comes standard with RP2040 chips / Raspberry Pi
| Picos.
|
| > "Each of the chips has a PS RAM chip for the frame buffer
| and, on VSync they swap," Williamson said. "So we have an
| analog mux that basically swaps the chips between the two so
| the application processor writes into the frame buffer in one
| RAM chip then, when VSync occurs in the display, it hands
| that RAM chip over to the display processor which hands its
| RAM chip back to the application processor so the display
| outputs on the screen."
|
| Thanks for the link!
| tiedieconderoga wrote:
| Neat, I love these tiny rendering projects!
|
| The original Nintendo DS also had two ARM cores (33MHz and 66MHz
| IIRC). People made some amazing things, including a Portal clone:
|
| https://www.gamebrew.org/wiki/Aperture_Science_DS
| bstrobl wrote:
| The Portal clone is definitely dope. Thanks for pointing it
| out!
| lostgame wrote:
| The cores were also ARM7 and ARM9, respectively.
|
| IIRC, the ARM7 one was essentially identical to the ARM7 used
| in the GBA, and was used for the GBA backwards compatibility
| mode on the original DS/lite.
| monocasa wrote:
| To be fair, it also had lots of dedicated 2D and 3D graphics
| hardware.
| ginko wrote:
| There's also a handful 3D tech demos for the GBA. That one's
| only got 2D hardware and a single 16MHz ARM7TDMI.
|
| https://www.youtube.com/watch?v=UFmhpZ4A1mQ
___________________________________________________________________
(page generated 2023-04-16 23:00 UTC)