Comments - punpcklbw

Thanks, Leon! I'm currently in the process of adding support for MD3, MD4 and BSP formats.

Hi! As stated before, the engine and its ecosystem is coded from scratch (I use standard API without linking any third-party libraries). The basic principles are similar to Build Engine I took inspiration from, but the formats and internal structures have little in common.

The engine can currently import MDL and MD2 formats (mesh only, no animation yet). I'm going to support other formats you listed. You can help the project by providing me the specifications to formats you'd wish to be supported. Also I'm currently researching the possibility of decompiling BSP files into models or sector-based maps.

As soon as model animations and continuous physical simulations are working, ragdoll physics should be possible. I hope to use the same approach for ragdolls as for inverse cinematics.

I'm going to add a third-person camera after solving some issues with the first-person mode. As for other views and genres, the framework itself could potentially accommodate any games (search for NIP Minesweeper for a sample text-based game I made some years ago), although 2D games may need another renderer and map format. I've already prototyped a top-down/isometric renderer and some UI for an RTS game, but much of it remains in unfinished state.

Thanks, Leon! Did you try to edit maps and game resources? The project is currently all about making content, not playing it, hence everything is static, despite the editor and the game itself coming in the same environment. Overall, this release is meant to show that the engine is not vaporware and is being in active development, even though much of it is incomplete at the moment.

I thought it's been impossible to get actual screen tearing using the legacy API starting with Windows Vista (DWM does its screen composition synchronized with vblank). However, microstuttering is still being an issue for me (I'll probably switch to a more robust API next time).

Of course there's a bytecode to tweak reflections, although I'm yet to add a tool for managing bytecode instructions (they are auto-generated during import).

The reflectivity is based on real world Fresnel equations. As you can see, glossy surfaces reflect only a small bit of light energy (4%) when viewed head-on.

The main limitation is that all mirrors are currently perfectly smooth. I think that a roughness parameter could help better approximate real materials.

Sure, you just pick an appropriate wall (say, 1024 Build units long) and hit ALT+G to base your grid on it. This will work regardless of the scale factor you provide for map import (I use 448 Build units per meter for Duke3D levels).

I'll see what I can do on that part. There were some weapons prototyped a couple of years ago just for testing the projectiles, I'll just have to troubleshoot the projectile physics to make it to the test version. As for the enemies, I was going to code in some pathfinding system so they could navigate from one area to another.

It depends on how complex you want your FPS game to be. It's not really far from building an oldschool Doom clone using the engine, with some eye-candy brought in. For this, I still have to put more work into the tools like the level editor. I can't go any faster since I can't currently work on it full-time, but there are some groundbreaking innovations on the way that I should prioritize to make it possible to build an actual game.

The version I'm aiming to release sometime in 2023 will be a game construction kit consisting of some prefabricated effects and tools to modify assets and alter the default behavior. In short, it would be a small tech demo that can be modded and extended with ease (and with no coding).

Thank you Leon!

As I noted in the description, those are some free models I found on Sketchfab and imported into the engine. I've come up with my own format for models that is both compact and versatile, also ought to be well standardized unlike many other formats.

The polygons may disappear near the edges due to imperfect Z-culling and frame projection postprocessing. I'm going to fix that and other artifacts as I further refine the renderer (and also add proper collision detection).

Thanks! Hopefully multi-domain graphics (i.e. sectors, voxels, models etc.) will work well for this engine.

Yes, I'd like to check how well your models will be imported.

I really hope so. Thanks for following my work!

Thanks for asking about that! The engine has seen growing public interest lately. There was significant progress over the last year on the renderer, physics, engine tools and overall architecture. However, there are some fields that remain under-developed compared to others. For example, I'm somewhat held back by the lack of decent engine tools that have to have a GUI that has to use an upgraded event/string management system etc. Also I'm not satisfied with the functionality of my command-line interface. As everything needs to be implemented in a right sequence, it will take some time until actual games can be created. Engines normally take years to develop, even those done by experienced teams.

Hey Pablo! Thanks for the feedback.

I understand that point, I think that the current issue is that all reflective surfaces in the engine are perfectly smooth and clean, while even very calm water has some ripple and surface objects present, and rougher stuff like sea waves may render any reflection obscure.

Otherwise, any smooth surface is very reflective when viewed almost edge-on, that's the nature of light. However, the rougher we go, the less prominent this effect gets. Since Brahma supports heightfields that are perfect fit for simulating waves and ripple, I shall look into an efficient way to combine heightfields with reflectitity, applying some warp according to the surface normals, that would make any water look more natural, of course.

As for the "water tile" texture, this is rather a stylistic choice, as you could ditch reflections altogether and keep just the vanilla textures if you prefer the look. However, such animated textures are meant to imitate underwater caustics (or fake a reflection in Shadow Warrior's translucent water) without actually rendering anything. This is why I disable the water "tile" for water that is both translucent and reflective--the only texture to fit here would be a dynamic heightmap that could warp the actual reflection and refraction you see on the screenshot.

See you on Discord, I've got something to talk about on my server.

Thanks a lot! Yes, I'm currently reworking heightmapped sectors in order to fix some issues with it and optimize performance. I hope to prepare a consistent tech demo for some public testing before actual game projects powered by this engine are released, to attract more potential interest to it. I think after four years in development, indie gamers are eager to get something playable on their hands.

Yes, the piano in Ion Fury is just a gameplay gimmick, and what I'm trying to make is a tool that can be easily adapted to different use cases.

An example of a CAD task would be to visualize stress within the piano structure that comes from its weight and tension of the strings, with interactive functions like changing your size and time speed to examine processes going on various scale.

On the other hand, they will pose a challenge to pathfinding algorithms and physics. Even sound effects have to take the topology of space into account to propagate correctly; the same is true for calculating a distance between two points.

Thanks for following my work, Leon! I wish I could implement all these features faster, but there are other things going around and sometimes I'm just not feeling good enough to be productive. Fortunately, my teammates help me a lot with game content I use for testing new stuff.

Also I'm going to capture some more videos to show off non-Euclidean maps and other cool things.

Thank you!

Kinda interesting how realtime CGI can match real photographs with so little memory usage if the right approach is used.

Yes, I was thinking of making another video lately, going through some Duke3D levels and also maps from other games such as Doom, I just need to fix a couple of issues to do justice to all the new features =P

You would probably notice the difference if you saw this technique in motion. ;)
Sure it can bring some artifacts on still frames; on the other hand, the game actually becomes a lot smoother, as the stroboscopic effect associated with the limited refresh rate is greatly reduced.

There's also an experimental frame blending technique that renders the game at double the monitor refresh rate and blends two images together for display (what is effectively full-blown temporal supersampling). Interlacing just aims to achieve a similar effect with substantially less computational effort, what enables to play in 4K at 120 fps with ease, for example.

Hi! Sounds like he is requested to code the game and all the ball physics himself. However, even if they permit using third-party engines, I'm unlikely to license my technology for this kind of projects at the moment, as one has to wait until the proper gameplay programming and collision detection (physics) gets supported.

Although Brahma and its underlying NIPSYS64 framework should be more or less suitable for all kinds of games, using its OBJ's and C++ header files to compile a game will require some prior knowledge and an extensive documentation (and I don't have any yet except a brief listing of console commands).

Yes, I agree that the old sector-based lighting is very limited and can't yield good-looking results for most scenes. However, I have a plan to implement lighting with lightmaps and normalmaps. The tricky part is caching of the calculated light to make it render fast. Currently I'm experimenting with lighting baked into dynamic textures like it was done in Quake, but with color and HDR support. Thank you for your comment!

Yes, the engine could easily read some rare or exotic formats, and the repertoire it expected to cover more of them over the years. Also, one can often dig into raw binary files with more ease with BHSEDIT than when using Hex editors, as it's multi-domain and can represent data as waveforms or images and freely reinterpret it across different formats.

There is already a couple of projects powered by this engine in the work, dunno how soon something turns into a demo release.

Yeah, those are nicely done low-poly things. Too bad MD2 format is limited to triangles only and can't really show the potential of my engine.

Yeah, drawing/shading is really tidy for most surfaces, coupled with gloomy and consistent color choices, and great use of highlights. I dream of augmenting a similar pixelated oldschool tileset with some more physical lighting like normal and specular maps, that would be awesome!

Great to know, thanks! The current implementation has a hard time rendering such floors from "below" or straight above, but I'm happy with the texels being drawn as perfect boxes; also my hybrid AA method drastically improves distant heightmaps when viewed in 144 Hz. As a sidenote, mipmaps for heightmaps should be generated using maximum ("lighten") blending mode instead of averaging.

Lovely level, awesome to see such credible open locations in a Build game!

You've got some great looking textures man!
Mind the importance of having a consistent resolution. Note that the lack of mipmapping won't make the extra high resolution sprites look good from a distance. The lamps on the left are very detailed compared to the rest, but drawn at a fixed angle. Perhaps a somewhat lower resolution voxel sprite would fit in better.
Wish you a good luck with the mod!

Hi, Leon! It's already been a period comparable to the time Ken spent on his Build engine back in 1990s. You can imagine how time-consuming it is to write, test and put together every little piece of the engine (with some substantial reworking in between).

To power a full game, the primary demands are cohesive physics support, map effect controllers and enemy AI. For a game like Doom or Duke3D, this shouldn't be too sophisticated, but pretty tough to get rid of glitches, as I want to use adaptive time steps to handle collisions at any speed.

All this is very rudimentary at this point, although you already can fly and bounce through the levels, feel the air drag and see the air pressure correctly drop with altitude (and also experience buoyancy underwater).

Hopefully most of this stuff can be made to work this year. Cheers!