Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.arch
Subject: Re: Got Quake 2 running on my MRISC32 FPGA computer
Date: Fri, 20 Dec 2024 14:30:49 -0600
Organization: A noiseless patient Spider
Lines: 233
Message-ID: <vk4k5s$3k5d2$1@dont-email.me>
References: <vjnouf$po8u$1@dont-email.me> <vjq5sj$1a9t5$2@dont-email.me>
 <vjqm71$1ctbp$1@dont-email.me> <vjr0de$1if3p$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 20 Dec 2024 21:30:53 +0100 (CET)
Injection-Info: dont-email.me; posting-host="cf4714a0858564e052c1456b9080839f";
	logging-data="3806626"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19YmIzh2HPFPT1gwJIJqs8f06NK8ddXmYw="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:GXTSENW9HqbAQ5NvynS61vUzoPc=
In-Reply-To: <vjr0de$1if3p$1@dont-email.me>
Content-Language: en-US
Bytes: 11189

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 
========== REMAINDER OF ARTICLE TRUNCATED ==========