วีดีโอ

Much appreciated! I look forward to sharing more progress soon.

The 3DO uses an ARM60 CPU. Only bytes and 4 byte words are supported for load and store. All registers are 32bits. There are CPU costs to using non-word sized integers. Unless you really need the space then using them will increase the CPU costs. For small numbers, less than 256, then bytes will be free'ish but depends on usage. But you really shouldn't be using 16bit ints.

I thought I left a reply but it was gone lol Thanks for your interest in this project!

@ you’re welcome and happy new year! Keep up the amazing work for this much understood machine.

Thank you!

Hey there! Thanks for looking out, and it is a noteworthy find indeed. @Tristan885 a member from our 3DO discord recently posted about it. So far I've only used graphics assets to test with, so it has been helpful. I am curious about the maps and other information included, and will be checking it out soon.

@@TheFieryWind99 oh and yes on the melee!

Thanks. Some early projects did indeed attract new homebrewers, and there are different projects in the works. If you are not yet in the 3DO community discord, it is a good place to get project information and see updates prior to these videos. discord.gg/EacJ8Uax I go by 'zyzix' on there.

Thanks!

Thank you for the support!

Any game that shares a similar style is doable to port. The best way to describe the main constraint this engine has is 'DOOM but cubicle', or games that resemble Killing Time for 3DO (not PC, as that is more advanced). The main constraint comes from using quads for everything, which was done in order to leverage the most out of the 3DO. As for mods, anything other than new 'skins' would require code changes.

@@retrolovelettercould you make a level where only convex edges need to meet exactly? Like steps and tables need to follow the cubes, but hallways don’t. Or multi-facet columns. You know, like this Sega Saturn quads on mode-7 games. Also: slopes. Here the roles would be reversed. Then find out if this glitches in z-order. Ah you have some faces like this. So let’s connect to a different room which is rotated relative to the current one? Oh no, does not work.

🙏

It has been a journey so far, thanks for all the support!

Thank you!

I'm looking forward to playing the remaster.

I recommend smaller goals in the beginning, such as making various demos and smaller games. You can make many games without writing an engine. Game engines can be a rather large undertaking, but I feel they are critical when working on projects like mine for obscure hardware, where nothing pre-exists for me to use. The path can also vary depending on your target platform. If you are focusing on PC then I would start with learning C++. Once you have a good grasp of C++ then you can use barebone APIs like SDL to handle graphics, input, and audio, and practically create any sort of game framework you want from the ground up. Maybe stick to 2D for a while. You can adopt an API like OpenGL later for more advanced graphics. But if you choose to use an existing modern game engine then you can use C++ with Unreal Engine, another benefit to learning C++. There is also Unity, for which you would learn C#. You can also use C++ and C# with the Godot engine. My 3DO work has all been done in C, but I can also use arm assembly if I needed to. For NES everything I do is in 6502 assembly.

@@retroloveletter ok cool. My goal for games is to be close to retro style fps like blood or quake, maybe fear or survival horror like cry of fear. So start small and use a game engine. I did download unreal and stride3d to try out.

Thanks Ben!

Maine really has an island named Matinicus. I just learned this when I began working on this engine, and found that very cool. I loved that the story took place on an island because the atmosphere felt more isolated, on top of an already creepy story.

@@retroloveletter oh that's really interesting! I always assumed it was made up

Thank you!

Thanks man! Much appreciated!

@@archive3do769 thanks!

Hey there, yes, I will be releasing the rom for download. Not on the physical release date but a short time afterwards.

The rom and game manual are now on my github.

I Wonder if the CPU could work with a voxel representation to slice by z, and then assemble quads from this. So kinda like kitchens are planned to have shelves to be integer multiples of a foot wide. Maybe even a more radial sorting would be possible. And close up to avoid warping, quads cover just one voxel. And close to high detail decoration. And collision detection works (roughly) over voxels. Only bullet / player within a voxel are CJK . Many clones of Minecraft exist. I am actually no expert because I like streamliners. But 1 MB RAM gives you 100 feet per dimension. Bytes can index to texture.

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.

I enjoyed how they incorporated FMV. Moments captured in time similar to a creepy haunting.

I would first like to make a game from it.

Excellent.

There is a version on GitHub with 10% speed up. How do you render visiplanes with quads? You cannot use BSP one 3do if you want any kind of speed. And when you want not only doors, but polygon vehicles or enemies, you can totally forget BSP. Open Lara sorts by z . I’d like to see code which efficiently slices hight fields along z. For a most horizontal camera .. but Lara dives.

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.

@jeffcotten1081 I'm looking forward to Resurrected, too. The announcement pushed me to finally play and complete the PC version.

Thanks! I programmed this in C.

Hey there, thanks for the kind words! I'm glad that you've been enjoying these projects. You may enjoy checking out the 3DO Community Discord every now and then to see projects in the works prior to them hitting social media (if you are not already in the server). We even have some original 3DO devs that worked on licensed games. discord.gg/YEmfuRY3 I plan to go back to 3DO after finishing my NES game.

Hey there. Back when 3DO was beginning to phase out, I recall a game store selling off all of their 3DO products. A huge case full of sealed longbox games, $20 bucks each, your pick. I would go back every couple of weeks to try a new title. What a steal.

Thanks. 3DO homebrew has gained another dev since I worked on this project, which is very cool to see. The 3DO discord linked in the description is the only solid source that I'm aware of to be informed of all things 3DO.

I think this will depend on the hardware device. Unfortunately, I have not seen any 3DO compatible controllers with a rotary dial. It would be very cool if someone made one. If the device is recognized by the 3DO as a Mouse, it should work just fine with the existing codebase. I initially thought the mouse would feel weird, but I have to say, it felt great. It is very precise.

This codebase wouldn't help with such a project, unfortunately.

Thanks, yeah, all of the game code was written from scratch. I recently released the source code.

Thanks for the tip.

I first saw that struct convention used by André LaMothe years ago and I liked it. My conventions can generally bounce around, but I try to keep them consistent in a project.

​@@retroloveletterInteresting. Typically you will see `_t` and I will often use `_s` and `_e` for struct and enum. Why _typ ? Is it _type minus the `e`? Or does it have additional meaning?

@@trapexit It's just type minus 'e'.