On 12/16/2024 10:58 PM, Chris M. Thomasson wrote:
On 12/16/2024 6:04 PM, BGB wrote:
On 12/16/2024 3:25 PM, Chris M. Thomasson wrote:
On 12/15/2024 3:32 PM, Marcus wrote:
Some progress...
>
Earlier this year I spent some time porting Quake 2 to my MRISC32 based
computer. It required some refactoring since Quake 2 used a modular
rendering and game logic system based on dynamically loaded libraries
(DLLs). My computer isn't that fancy, so I had to get everything
statically linked into a single executable ELF32 binary (and the
Quake 2 source code didn't support that at all).
>
My patched source code: https://gitlab.com/mbitsnbites/mc1-quake2
>
When I finally got a working build, it only worked in my simulator but
not on my FPGA board, so I dropped the effort.
>
Yesterday, however, I went and bumped my GNU toolchain to GCC 15.x and
fixed a few bugs in my MRISC32 back end, and lo and behold, the binary
actually started working on the FPGA (not sure if it was a compiler bug
or if it's a CPU implementation bug that got hidden by the compiler
update).
>
Video: https://vimeo.com/1039476687
>
It's not much (about 10 FPS at 320x180 resolution), but at least it's
progress.
>
Well done. :^)
>
I had failed to say so in my own response, but I will agree to the sentiment. Getting Quake 2 working at double-digit framerates, is a worthwhile achievement.
>
>
I have yet to get the Quake series games running at double-digit framerates at 50 MHz in my case (except in limited cases, like small rooms or looking at a wall).
>
Nor have I succeeded in implementing a 75 or 100 MHz core that does much better (things tend to get wrecked by other issues, like needing to use small cache sizes or increase instruction latency to pass timing, which ends up being worse for performance than just running at a lower clock speed).
>
Granted, I had been primarily focusing on 64-bit designs here.
If you can get it compile and work, well, great! I kind of like 60fps. Instancing uniform and or a vbo wrt array instance is fun as well. I am still not sure why the uniform version works with higher frame rates. Fwiw, I still need to post this to YouTube, but here it is over on the god damn FB:
https://www.facebook.com/chris.thomasson.31/videos/1373775797364166
60fps realtime dynamic field. Now, If 12 fps is okay, well, I can make this MUCH more complex! ;^)
Not entirely sure how it relates...
My GL implementation is fast enough to mostly run the Utah Teapot or Stanford Bunny test at acceptable speeds, but Quake is harder.
Quake generally is pushing around several thousand polygons per frame, which is hard to sustain. Seemingly, QBSP had already cut up the geometry into a lot of really small pieces, and also had a fair bit of overdraw in its PVS (world geometry looked boxy and simple, but was actually cut up pretty good).
Seemingly, and ironically, Quake 3 pushes less geometry, but the engine itself is more demanding on the CPU. Seemingly, Q3BSP had instead left bigger polygons, drawing any that cross a BSP plane rather than splitting the polygons along each plane.
It is still generally pushing polygons one at a time, with code that checks and modifies OpenGL parameters for every polygon, and may draw it as multiple layers. So, not particularly low overhead.
Whole thing seemingly still mostly built around using glBegin/glEnd (and optionally multitexture, if available).
Theoretically, one could try to rebuild the Quake1 maps using a modified Q3BSP, then modify the Quake 1 engine to use the Quake 3 BSP format, but this is probably a bit much. Would be more efficient to build up lists for each texture, and then draw them via vertex arrays.
For now, it still only does 1.x functionality with a few 2.x features (such as occlusion queries, and support for Binary16).
Technically, TKRA-GL allows Binary16 in more places than GL proper, but more because seemingly I actually considered it usable for things like vertex coordinates.
Generally, no VBO's, instancing, or shaders yet. Still no shader compiler, and if there were, they would run on the CPU and probably be pretty slow.
I suspect I could probably run something with similar geometric complexity to a lot of PlayStation games pretty OK (say, something along similar lines to "MegaMan Legends"). But, not sure of any PC games with those properties with the source code available (the combination of very low-poly graphics and short draw distances was less a thing in PC games).
Like, here is a house, it is 6 polygons. Ground is large flat polygons, and any scenery much past a certain distance just disappears (Legends seemingly had slightly higher complexity but very short draw distances in indoor areas, and slightly larger draw distances but very low complexity in outdoor areas; with any NPC's only visible for around 5 meters or so).
One other possible bit of trickery is quietly replacing 3D models with billboard sprites past a certain distance (don't need to render a tree when you can render a sprite of the 3D model of the tree, and then pop back to the 3D model when the camera gets close enough).
OTOH:
But, yeah, electronics printer experiment/idea has been a lot of ordering stuff and 3D modeling and 3D printing...
It has been a good long time since I have done so much 3D modeling...
TBD if I can get it built/working, or do all of the stuff for logic synthesis.
Had gotten some largish 100ml syringes with the intent of drilling out the plungers (so that a lead-screw could run down the middle). This didn't really work, ended up 3D printing new plungers with the core hollowed out.
At first, 3D modeled them as basically just cylinders with an attachment on the end for the rubber plunger. Noted it was kinda expensive, so tried to mimic geometry more like the original plunger, but this was even more expensive (lots of support material needed, and larger external surface area). Seemingly cheaper option just being to print it as mostly a solid cylinder (and let "sparse infill" deal with the rest...).
Say, if printing parts with 5% to 10% infill, often the external surface area and support material can be a larger part of the overall filament cost (vs 15% or higher where infill tends to be the bulk).
Also:
M3 screws don't really work in 3D printed plastic...
They don't grip well, and if one screws them too quickly it can melt the plastic (then one has an M3 screw that both doesn't stick and is covered in melted plastic).
Was at least having better results with 10-24 screws. But, some of the parts I bought have metal interfaces that only really fit M3 screws.
Trying to spin a 10-24 leadscrew in a 3D printed hole also does not hold up well, as the leadscrew will bind up and then eat into the plastic (much more aggressively than expected).
Workaround idea is to 3D print some bearings/bushings at 100% infill, and then use these. But, then needing to redesign/reprint some of the parts to be able to use the bushings (which end up taking enough space to require altering the geometry).
Say:
10-24 leadscrew (diameter=0.188 inch);
Bushing inner sleeve:
ID=0.188, OD=0.249
Bushing outer sleeve:
ID=0.252, OD=0.375
Each having a wall thickness of around 0.046, probably can't make it much thinner.
Actual sizes are a bit more of an open question, parts mostly just need to fit together and be able to turn acceptably well.
Designed them in multiple variants:
length=0.500, with flanges.
length=0.250, with flanges
length=0.250, no flange
length=0.250, with flange and end clip (ID=0.242, OD=0.360, Len=0.060)
This results in something more analogous to a traditional bearing.
The end is forced on, and keeps the inner sleeve held in place.
The parts are small and fiddly enough to be an annoyance. Not sure they would hold up under significant load, but probably enough for what I am hoping for (mostly to hold 10-24 leadscrews in a worm-gear gearbox assembly).
Initial prototype worm gears were printed in PLA, but can note that these are not holding up well either. But, plan is to do the final versions in PETG or Nylon and hopefully have them hold up better.
The 3D printer also has difficulty making the gear teeth on these.
If needed, may need to make an assembly with the specific design purpose of holding the gears to cut teeth using a modified piece of 10-24 (a fairly thin notch along the threads). Then making the gears initially slightly oversized.
All this might probably have been less of a pain if I were using 1/4-20 or 3/8-16 for the leadscrews. But, I was initially imagining using smaller syringes. 3/8-16 would be serious overkill, but the 3D printer would likely have an easier time trying to print the teeth for the worm gears.
Can't really easily source ACME-thread this small (rare to find much under 3/8 or 8mm). Could try to cut custom lead-screws at 3/16-18 or so, but this would be a lot more hassle than it is worth. Would be easier just to switch over to using 1/4-20 for the worm-gear leadscrews.
Though, accommodating a 1/4-20 leadscrew would likely also mean needing to increase the OD of the bushing to around 7/16 or so (as I am less sure how well these things would work with an 0.030 wall thickness). Or, switch to 7/16 early in the possibility that I may want to consider switching to 1/4-20 ...
Seems like a lot of this would almost be easier with metal parts, but is asking a little more out of 3D printed plastic.
May be better with PETG, but the PLA is more behaving a bit like cheese ATM.
...