Putting in the missing socket 4 intel board and some pentium overdrives.

https://www.youtube.com/watch?v=zD8_YL9ba54
Running rally-sport in dos there with the socket 4 intel premiere, overdrive 133 mhz, sound blaster awe32, s3 trio32, and an obviously unused voodoo. Not prerecorded gameplay, I was in fact playing the game from that angle. Kinda weird, kinda different.

The awe32 by the way doesn't use the correct texture on the backside. Couldn't find a proper image of it so I used one of another card. Did the same for the et4000.

That is pretty neat! I might change it locally to add support for creating CAPE configuration files and make it work with my emulator 😀

Go for it. I'll make some docs for the 3d file format etc. at some point, probably useful for adding custom components. Although with some interpretative effort the source code probably explains it too. I convert from blender-exported obj files, but the converter code needs to be cleaned up.

There's a guy on the MAME team who imagines a similar 3D frontend in the future. Much bigger project than supporting a dozen or two PCs though. 😁

This is pretty cool, congrats. 😁

The mame thing seems cool. That said, I should say that pcbi (under my development) isn't intended as a pcem front end in the utilitarian sense. Think of them as friends with benefits.

For a 3d format i'd probably recommend IQM

- it's open
- the blender exporter is competently written (from my experiences with different formats in blender across different versions of blender, this is a huge bullet point)
- plenty of sample code and easy, non-bloated integration
- it has the bones (though not very relevant for hard edged rigid component parts)
- an additional ascii format is available

the format was made in the quake source port scene when the other formats that were tried (PSK, SMD, MD5, etc) all had various shortcomings and annoying content pipelines, aos it was conceptualized as an agreed upon standard to end all standards (well...back when there was a friendly scene anyway)

The current format does the job, so replacing it isn't a high priority for me. I'll have a look if someone implements it though.

I released the second alpha version of pcbi. https://www.youtube.com/watch?v=aTKS79XzVek. Code dump for it is on github. Also updated the precompiled binary + assets in the first post. Patch your pcem with the updated patch.

- added a pc case with functional indicator lights (except for the 5.25" floppy)
- drive selection in the gui is now reflected graphically in the 3d view
- made the component side pane resizable
- hacked in mouse controls for the camera
- the renderer's resolution now adjusts to the size of the window
- added a socket 4 motherboard
- added socket 4 pentiums
- added some pentium overdrives
- toggling power to the pc now happens via a right-click menu over the case
- enabled choice for monitor screen antialiasing (it's slow)
- increased the default window size; any custom size is still forgotten between sessions
- some other changes and/or fixes.

The list of known issues is provided on github.

For the next version, looking to add some automatically-applied case badges to better communicate the machine's internals when the motherboard is hidden.

I released the third alpha version of pcbi. Code dump is on github. I find that the binary distribution isn't notably useful at the moment, so it's converted into an assets one.

The renderer was stress tested and found to handle up to 60000 untextured faces at 30 fps on a 3.3+ ghz haswell. About 1% of that limit is currently used in an average scene, though with a mix of textured and untextured faces. Render speed mostly decouples from face count when the virtual pc is on, due to selective redraw. Optimizing texture fills would probably be useful.

- pressable buttons to interact with the computer
- swappable monitor
- replaced a few video card textures with more interesting looking ones
- added a few overdrive mmx
- some improvements to selective redraw
- some code improvements
- the pcem window is now slightly bigger

I released the fourth alpha version of pcbi. Code dump is on github.

- Basic case badges. They look like glued on pieces of paper, but hey. Only available for intel, s3, ati, and 3dfx components.
- Shared folders hack. Autocreates an iso of a given directory and automounts it in pcem. Saves time when transferring files.
- Convex monitor screen. Looks good in dos. You can fake the effect in a 2d shader, but 3d geometry is better.

People gathering around a car in rally-sport; played on a convex screen.

vvbee wrote:

- Convex monitor screen. Looks good in dos. You can fake the effect in a 2d shader, but 3d geometry is better.

Also way waaaaay faster.

I don't know about that. It's not too slow to render 200 textured triangles on modern hardware. The current, unoptimized software renderer, sure.

My point is it will always be several orders of magnitude faster to render a curve effect using extra triangles than to build the same effect using per pixel transformation in a shader. Because with the latter solution every pixel rendered has to apply a good amount of math to fake screen curvature whereas transforming 200 or so more vertices will be faster. Faster than shading 10+ instructions per pixel for 1.5million pixels.

This is regardless of HW vs SW rasterizer.

There's also the potential for anisotropic filtering and FSAA/SSAA out on the crt effects when it's a 3d object. It's actually the kind of thing i wanted when I dreamed of a CRT emulator some 10 years ago.

I don't do shader programming so I wouldn't know. Meanwhile, the software renderer in pcbi wasn't able to handle the extra textured geometry without dropping frames.

On that note, I released the fifth version of pcbi. Github isn't suited for my workflow so I migrated the code from there into the assets file linked in the first post.

The software renderer was replaced with hw opengl. Transforms are still handled by the remnants of the software renderer, but the triangles from it are fed into the gpu. This gives full-screen antialiasing, which by default is off but is toggled through the menus, and so on. I've used opengl 2.1 as I like retro, but it's not too hard to adapt to a newer version. The opengl renderer is up to 10x faster than the software one. Code here and there is still in a state of adaptation.

I changed some of the monitor names, so if you have previous save files, you want to open them and edit the monitor's name in there to match what's in hardware_list.cpp or the file won't load.

Can you port this to 86Box's code please? I rather enjoy the extra features 86Box brings, and to see that this is PCem-only saddens me.

No plans for 86box. Barely some for windows.

I released the sixth version of pcbi. I considered a windows port but at the moment a focus on linux is more beneficial. The new version improves on current features and ties up loose ends here and there.

- Minimal redraw for opengl + other render speedups. Only renders when and what's needed. Runs at 400 fps on my old radeon r7 (in linux with open source drives). On an integrated g4560 in a similar environment it's about 100 fps.
- Higher quality monitor screen filtering. Uses opencv, so libopencv-dev or equivalent is needed to build. Mipmaps aren't used at the moment so at shallow angles aliasing will be present bigly, but this is a niche concern.
- Numerous refinements to features and the user interface. Component drag shows a full image of the component, error messages for some common things, etc.
- Code restructuring. Shared memory stuff now has a wrapper, etc.
- Camera movement sideways with shift + drag. It works weird but is good enough.

Different screen filter options. Lowest quality on the left, highest on the right. These are subjective matters of course.

vvbee wrote:

No plans for 86box. Barely some for windows.

I mean, the 86Box team could use this to port 86Box to Linux, for instance.