Developing a Killing Time style game engine for 3DO
Vložit
- čas přidán 28. 06. 2024
- I have decided to take what I have learned after programming Tempest and other 3D projects and make a 3D game engine with capabilities inspired by Killing Time for 3DO.
0:46 Using DOOM editor to create WAD files for my engine
6:02 I added advanced sector attribute support
7:30 Current performance
31:34 More code review
35:56 BSP tree thoughts
39:50 Lighting support
I have created my own WAD file converter that formats data my engine uses to render 3D scenes. This is essentially creating a DOOM style engine for 3DO.
I am only using Killing Time texture likeness in this prototype demo for the purpose of testing. I will not be using Killing Time assets nor any creative elements when a game is eventually made from this engine.
Follow me on Instagram or Twitter/X for frequent updates on my projects:
/ zyzixgames
/ zyzixgames
My GitHub:
github.com/ret...
My website:
www.zyzixgames....
Join the 3DO Community Discord:
/ discord
#retrogaming #homebrew #gamedev #videogames - Hry
I realized afterwards that part of my debug console is out of screen capture, apologies.
Also sorry for my scratchy throat!
I am only using Killing Time texture likeness for the purpose of testing my engine. I will not be using Killing Time assets nor any Killing Time creative elements when a game is eventually made from this engine. This is purely for demonstration / educational purposes.
@jeffcotten1081 I'm looking forward to Resurrected, too. The announcement pushed me to finally play and complete the PC version.
This is super fun for someone like me who's working in modern graphics but wasn't around back then 😊
Killing time was such a weird and awesome game
I enjoyed how they incorporated FMV. Moments captured in time similar to a creepy haunting.
Good video with nice explanations in general. Making the second version using indexed rendering and sequential vertex processing from bigger buffers seems like a good decision. :)
For those who want them, here are some notes:
5:45 The reason why the walls in the back are disappearing is far-plane clipping / culling, which eliminates any geometry that is deemed too far away. Back-face culling lets us see inside the closed room in the first place, by ignoring geometry that is facing away from the virtual camera's look direction. This is what was meant there (see below). The way this was phrased, it was unclear which was meant, as both types of culling were happening in view. Luckily... (keep reading)
10:42 clarifies the above.
The explanation in the preceding segment can be somewhat misleading and is quite often insufficiently explained in videos.
In the special case shown there, back-face culling is applied in a pre-process before anything is transformed. This is good. The following is about the general (often post-transform) case. In general you don't need to supply normals for back-face culling and in fact you don't unless you have full control over the transformation pipeline in software. The winding order is what really defines front- and back-facing surfaces, by providing a primitive's vertices in an either clockwise or counterclockwise sequence. You can typically set up which winding order is front-facing and then you can set which facing to cull (none, any or all).
It is important to distinguish between the two types of normal used here: one needs to be explicitly provided for shading, the other can be completely left out and implicitly computed for culling (in one form or another). Thus a primitive can have multiple normals: its surface can be front-facing (implicit surface / primitive normal) while at the same time being back-facing (explicit shading / lighting normal) to e.g. simulate thin cloth lit from the back. In the extremes there are double-sided surfaces with independent front and back shading normals. (Shading normals don't have to be unit vectors. Older games used scaled normals to e.g. fake ambient occlusion on models.)
That said, the explanation used in the video is fine, as long as both normals (shading and surface) always match and such a matching normal is always present. My issue is just with the missing distinction. Modern graphics use almost exclusively per-vertex normals, which typically bend into all sorts of directions away from the true surface normal and there being no explicit surface normal anyway, they perform back-face culling just fine. Beginner programmers and beginner artists often mix these two up which results in confusion. (No insinuation about the video's author is intended or should be made at this point. Seriously. As this stuff becomes second nature, people tend to skip a few steps in their explanations, which naturally also applies to me).
19:00 No, please go on, there are too few "very technical" in-depth explanations and it's always good to see other people's perspectives even on familiar topics. :)
To clarify, my backface removal is a loose implementation of what that generally means. It is one of the first steps in my pipeline because it can generally cut walls in a POV down 50%. But I'm using world space for it, not camera space. This means if my check says I cannot see a quad then I definitely cannot see it. If the check says I can see the quad, I still may not be able to see it as it still needs to be checked against the frustum. This was in place prior to my recent change of processing camera transformations in batches and so I didn't want to spend any time doing transformations until I (hopefully) culled roughly half of the scene down. The current check is issuing a single (and I believe hardware accelerated) dot product. Since the geometry (at least for now) will not rotate and I'm using world space I don't need to update my face normals. This is calculated in a pre-processing step. Any new approach would have to be faster than a single HW dot product since the face normal is serving to represent the winding order in my implementation. The CEL engine can handle backface removal given the proper flags, but I hadn't tried this yet since again prior to this update I didn't want to process a quad any further unless I absolutely had to.
@@retroloveletter Hi, thanks for the response. It’s important to me to state that my comment wasn’t criticising your method. In fact, what you are doing is reasonable and good. Many modern games do a similar thing where they cull small clusters or patches of geometry roughly facing the same direction with a shared pre-computed world-space position and facing direction (similar to a surface normal, but more of a cone in concept) before transforming anything. (Similar data is also used for proxy occlusion queries.)
Some late PS1 games have supposedly even gone so far as to have multiple pre-sorted and pre-culled index arrays for their environments that could be selected based on the dominant component of the look axis, reducing the necessary sorting and culling to a minimum. Vagrant Story is one such game that comes to mind (I might be wrong though).
I’ve clarified my original comment a bit in an effort to make it more fair to what you talked about in the video, while retaining the information I tried to convey.
This is so cool!
The 3DO was basically my unobtainium in those days. I was never clear of the true capabilities since it didn't really live long enough for commercial devs to get a handle on it. I'm curious if the doom port could be fixed to run a bit faster after these years.
There is a guy in our 3DO discord that has been working on an optimized fork of DOOM.
github.com/Optimus6128/optidoom3do
A link to the discord is in the video description if you are interested. There are a lot of members and various interesting projects.
I believe Burger Becky has the 3DO version's source code. Perhaps reach out to her about your questions.
Excellent.
Very awesome
looks like 3DO made a doom-clone engine. that time many of developers hid they used proprietary engine by reverse engineering or to ask someone to look at souce code.
Will this be open source?
I would first like to make a game from it.