Voxel Engine #1 - Software Renderer
Вставка
- Опубліковано 30 січ 2021
- Find Your Sanity. Jan 30, 2021
Global Game Jam 2021. Fri-Sun, Jan 29-31, 2021.
Custom software voxel engine.
1. Voxel engine. Software rendered. Mipmaps. Sky texture
Built from scratch using MonoGame / XNA.
Using assets from:
- Comanche Maximum Overkill
- random atmosphere picture borrow & processed
I first programmed this in VGA Mode 13h (320x200 x 256-color) in 32-bit assembly using a 16-bit assembler + machine code within Turbo Pascal IDE, using an "unreal-mode" method of linear 32-bit addressing within 20-bit (16-bit overlapped) segment + offset "real mode". It went 18 frames per second in 160x200 resolution, via Mode-X that allowed 2 pixels to be drawn at the same time (the same as Doom's low resolution mode). See frame-captured video here: • Voxel Terrain - 1995, ...
0:09 - starting from the lake at the top of the mountain, down the waterfall, you can flow with the water motion throughout the level.
0:30 - the water appears to stop here, but you can continue in these low-lands to find it again.
0:35 - over these few humps, and you're back at the waterfall
0:44 - a good view of the draw distance. This uses mipmaps and increased texture scanning speed to reach significant distances -- as far as you'd ever need. Because it's a custom voxel engine, it could have Earth curvature easily (see later videos for the reverse: Inception mode!)
0:51 - In my original implementation, I'd rotate around this mountain top for a view of this seemingly thick chunk of rock. Doom was the only other engine at the time that gave a feeling of thickness (and not just empty-inside thin/flat polygons).
My playlists:
--------------------
- Voxel: youtu.be/watch?v=XCVWEuhCCDM&...
- Road: youtu.be/watch?v=ck5ALX11YU4&...
- Ray Casting 3D: youtu.be/watch?v=zjswXUTMP2o&...
- Side-Scroll Shmup: youtu.be/watch?v=fF4X8zN-Raw&...
- MonoGame Tutorial: • Arena Shmup Demo #1 - ...
My websites:
---------------------
- my GitHub: github.com/JDoucette
- my company: xona.com
- my Blog: thefirstpixel.com - Ігри
This looks like an old game with old graphics.
Its actually amazing
Thanks! I love the old school voxel look. The terrain color and height data is from the 1992 NovaLogic's Comanche: Maximum Overkill. But it didn't really show off the 3D perspective as well. Some people claim this gives them SNES Mode-7 vibes!
The number of polygons being rendered here is seriously unbelievable. I am curious what dark magic it took to make this, I just wish Mojang had more people like you
Thank you so much for the compliment, but I fear it is somewhat unfounded. I imagine your admiration is based on the extreme render depth without dropping frames (there are more dramatic examples in other videos in my series). The voxel technology I developed independently of NovaLogic in the mid-1990s is what's running here, which is heavily optimized to render a single height for any given (X,Y) location on the map, and optimized for non 6 degrees of freedom camera (the camera always faces the horizon; the sense that it does not is achieved by tricks). Minecraft allows view in any direction in any angle, and allows any given voxel to exist or not.
Minecraft's rendering issues arrive from the difficulty of determining what it needs to compute to draw or not. If you've even "seen through the cracks" of a voxel to see the cave underworld beneath you through the solid terrain you're standing on, you'll notice it is drawing nearly every voxel side that is facing you, even though they all should be invisible. I always wondered if Quake's use of BSP (binary space partitioning) ever worked so horribly bad. Maybe 3D engines today are just easier since you can throw everything at the GPU. But Minecraft has it harder than Quake, since it has to adjust in real-time, rather a pre-computed BSP map that Quake can do off-line before the game was ever sold.
My voxel technology operates much differently. Every pixel you see rendered are the only pixels I am rendering (for voxels; ignore object sprites in this discussion). This means zero overdraw. It is doing the absolute bare minimum possible. Each of these pixels, amazingly (I think), it being rendered as a "sprite" (2-polygons). A single pixel is 2 polygons here. While the renderer is "software", I am not rendering to a CPU memory chunk that is uploaded to the GPU every frame. I am telling the GPU where to draw that pixel on its own buffer. This is the only thing the GPU is doing (well, it is maintaining a nice Z-buffer at the same time, but my software is feeding it that information, individually, for every pixel -- which is what allows the object sprites to appear behind and inside of mountains), thus the reason I call this a software renderer. The transforms / positions / colors / depths of those pixels (polygons) are all computed by my slow CPU. And just one of them at that (I have 12 virtual CPUs, 6 actual cores, in my workstation).
Using all 12 CPUs, or however many a prospective gamer may have, would speed up my renderer by that many times. I suspect rendering to a memory target in the heap, and uploading the result would also be very much faster. Although moving the rather simple software renderer to the GPU, to use the GPU as a general purpose CPU -- not to render polygons, but as a super fast CPU to execute a simple instruction set -- would speed this up incredibly faster still.
Finally, I must also note that I am rendering in a lower resolution. On purpose, since this type of voxel engine was typically running in 320x200 VGA (256-color) mode, and it is very reminiscent to SNES folks fond of Mode-7 graphics (basically a flat terrain version of voxels) which ran at 256x224 (yup, the SNES was quite low resolution, the Sega Genesis was 320x224). These type of graphics are for what I call the Golden Age of PC Gaming (when PCs held their own against consoles, and started outdoing them along with arcades with such technologies as the Doom engine and this type of voxel terrain engine).
I always wondered what the first Doom game would have looked like if id software decided to build the whole game upon the voxel engine from Commanche. It prolly would have been the Far Cry of 1993.
I developed this engine in 1995/96, once I got access to assembly language. I wanted to produce a rail shooter like Space Harrier with it. I figured the blocky artifacts of jumping from one voxel to another during motion, when up close, wouldn't work well with the clear distinction of depth & reality that a ray caster with walls gives you. The engines are similar in terms of casting, so someone had developed Doom + Voxel height in one engine in the mid 90's -- I cannot seem to find it now. There is disparity in the level of solidity, as I mentioned before. But yes -- it could've been the Far Cry of the early-to-mid 90s for sure. Another issue is that Doom's sectors/portals via doors allowed for optimization so you could limit what you need to draw far away. Voxel terrain also has this ability "if you're smart" -- but it is nuanced. If you're sitting in front of a mountain, chances are you cannot see the ocean behind it, so stop calculating it. But if you climb a large hill, near but not at the top, you can see large structures / trees that sit on the other side.
2000 vibe
Yup! I wonder what games come to mind.
this is kickass my friend
Thanks so much! Glad you think so :)
the terrain, colors and aztec pyramid kinda reminds me of the old forgotten game/tech demo called Terep
So interesting. I just found the video of the game you're referring to:
ua-cam.com/video/cUw36BuKVIQ/v-deo.htmlm32s
This is using a 256x256 sized version of the 1024x1024 sized map I am using, which is the original (from NovaLogic's Comanche Maximum Overkill). I recall 256x256 versions being available on the internet.
I suspect the pixel-by-pixel software renderers of the day would use the natural AH and AL (high and low 8-bit) bytes of the AX (16-bit) registers to automatically wrap to 256 texels, which works without any extra math on a 256x256 texture. However, Terep is a polygon engine, so they would not have cared, and likely had just a non-wrapping polygon map. Using the 256x256 map would allow the polygons to represent larger portions of the playfield.
Oh, this is cool.
Crazy, this has over 5,000 views now. I think this terrain is iconic. Or maybe it feels that way since I've seen it far more than the others.
@@JDoucette I would be interesting to have a tile-map terrain, on top of infinite height map noise. Or some form of detail-texture to make it different. Essentially, if the game play is slow enough, it could be a chunk system like Minecraft that stores changes too.
Now that's awesome
Heh, voxel terrain has always been one of the coolest things I've ever programmed!
@@JDoucette I'm hardly an expert or even beginner in terms of voxel-based things, so I'm not sure if it question will make sense. Anyways, here's the question: How many bits goes into representing each voxel? Thanks.
@@jiataosu7846 Voxels are represented by 2 things: Height (16-bits) and Color (24-bits). Notice that for any (X,Y) = (latitude, longitude) coordinate, this means there is only one height (thus caves and overhangs are not possible). Some people claim this make it not a voxel engine, but I disagree. It's an optimization for memory and speed at the sacrifice of some features, but it's still a 3D pixel = VO-lume pi-XEL.
@@jiataosu7846 Of interest, is this NovaLogic voxel terrain data is from Comanche: Maximum Overkill, programmed in VGA, which is 320x200 resolution and 256 colors. The height map is 8-bit (0..255) and the color map is 8-bit (0..255 = index into a 256-color palette, of which the voxel terrain used a portion of; the rest would be used for other sprites, characters, fonts, HUD, etc.)
Also the height & color maps are 1024x1024 in size, meaning uncompressed it would take 2MB of a 4MB 386/486 back in the day. My engine supports much larger, due to vastly increased memory sizes. 32 GB system could support 131,072 x 131,072 voxels if you used the entire memory for just the terrain (which you couldn't do, so 65,536 x 65x536 would be possible, using 8 GB of memory) using 8-bit color & height maps. Using 16-bit height and 24-bit color, 65,536 x 65,536 would also be possible, using 20 GB of memory.
damn daniel
ua-cam.com/video/oV2yhPwgwDE/v-deo.html
I see there is 1 reply to this comment, but UA-cam won't show me. :/ In any case, sounds like you enjoyed? :)
@@JDoucette I sure am, cool stuff you're making!!
@@junkokonno Thanks so much for the kind words! I get a huge kick out of voxels. Do you do game/graphics dev work yourself?
@@JDoucette yeah I mostly work on 2D games though, recent one being an osu! standard clone, lots of syncing with sprites+music since it's a rhythm game.
What graphic API are you using?
The entire thing is software rendered. So you can think of it as a 2D array of pixels, where each pixels is 3 bytes, one for each of R, G, and B, which holds 0..255. This array of data is uploaded to the GPU. That's the essence. Except I don't do it quite that way -- as I generate each pixel of this image, I push that "sprite" to the GPU to be rendered... so I bypass storing it in memory... and I push to the GPU as I generate. So what you're seeing is a couple of polygons for every single, individual pixel. It would likely be faster to keep it all in memory as the 2D array, and push the whole thing at once.
To be more clear, I am using Monogame, which is the latest version of Microsoft's XNA framework. The API I use are SpriteBatch, which can be used to render a single 2D sprite. Each sprite in my case is a single pixel. Except sometimes, when a single voxel is tall, and spans more than 1 pixel, I render them all as a single sprite.
@@JDoucette That's very cool. I find that very cool! I find software rendering ( on CPU ) and interesting thing to explore. By implemeting everything in software I think you get better understanding of graphic.
It's cool also that you were able to get this to run on interactive framerate.
Thanks for sharing in any case. Do you plan to turn this into a game or you plan to create a commerical game engine?
@@openroomxyz My graphics programming beginnings were pre-GPU when you had to draw each pixel by assembly language if you wanted to be quick. In fact, this engine is a recreation in C# of my original made in 32-bit assembly language (and machine language, since I only had a 16-bit assembler, but had a 32-bit 486 CPU I wished to use). What's interesting is that you are not limited to the APIs of a graphics library, such as sprites or polygons.
@@openroomxyz While Minecraft is a voxel engine, it is using a polygon engine to render. My engine (which some claim is not true voxel due to the optimization/limitation of a single height per x,y location -- but that's like saying Doom is not 3D because of the exact same optimization) is a true voxel engine -- really -- as it renders the voxels pixel by pixel, the same way that a polygon engine (CPU or GPU based) renders polygons pixel by pixel. That thought is oddly satisfying.