/agdg/ - Amateur Game Development General

Finally getting the Vulkan renderer to work again, this time properly, I should be getting at least the performance I can get with OpenGL, but ideally higher performance. Right now getting the text system all sorted out, it still has issues, but, it will be resolved, just a matter of time. Then I can write a system for drawing the world, that should be a little faster than OpenGL I hope. Then I can work on actual new features.

My call to vkCmdDrawIndirect was crashing because I forgot to set the stride parameter. But now it can actually draw things on the screen. There's some kind of error with my data here but that should be easy to fix. I'm almost done with bringing my Vulkan renderer to the same state that the OpenGL renderer is in. Then I can work on fixing the Linux version...

I've pretty much figured out that this buggy rendering is because junk data is being put into my vertex buffer, so I just have to confirm how to solve it, it's pretty scrambled right now. I think my method of transferring the data was unreliable, I just realized that my code is written like OpenGL in that it assumed that commands would be executed as soon as I called them, and not that it would only be executed when the queue was released. I was submitting a series of commands that copied stuff out of a memory mapped buffer, so it gave it the wrong data. The images are the junk data I was getting.

>>33591

Thanks!

I have a huge amount of Pentium 4 shitboxes lying around my house, they keep showing up, I don't even know how many I have, please send help, they're everywhere

So it looks like the problem with the geometry being wrong has been fixed, however there are other issues and I need to figure out what they are, the stuff being put into my draw call is correct and my matrix seems to be correct, I think something else is wrong, I just don't know what it is right now, the image flickers quite a lot and so I need to figure that out. I also need to use vkCmdUpdateBuffer because my current method is really a quite stupid way of doing things, I basically set up a temporary buffer, map it to the address space and copy my VBO data in pieces into this temporary buffer, and then copy THAT into my device local actual VBO memory with vkCmdCopyBuffer, and of course to do this correctly I have to create and destroy a command buffer EVERY TIME before I can change the memory in the mapping to the next part of the VBO. All because I didn't read about vkCmdCopyBuffer which is what I should really do.

Vulkan rendering works, it's still not as fast as OpenGL is, but I can still do some more optimizations to how it works until I get it to the same place. Soon I can work on fixing the linux port.

>>33609

I think in another year I will have a more substantial demo and the engine will be able to show actual gameplay, the game and things I want to make with it will actually be recognizable... My issue right now is just low productivity, this is the worst month in the year for my free time, and maybe by the end of the summer I can finish the features I want to finish before loading models into the engine. I have a higher productivity in the summer.

Anyway I haven't been posting lately just because of how long it takes to produce any visual progress and also how you can't see anything behind the screenshots I post. >>33608 represents a couple thousand lines of code that were deleted and rewritten but it all looks the same. Although I think I will be moving faster in the future because of that. It's ultimately an identical screenshot to what I was posting literally a year ago.

My roadmap right now is just, to fix the linux port, and make sloped surfaces work in the map editor, then I want to implement a series of optimizations to the map creation that should make the whole engine generally faster (this is an unpruned BSP tree, there is quite a lot of waste...). Then I want to implement lightmaps and skyboxes and then finally models, at that point I will have to fix my netcode too... anyway I think that at least half of those goals can be achieved by the summer, maybe the rest by new years, I don't know until I start programming it really.

This is the Sigma II in Fedora Linux using the Vulkan API on Linux for the first time. Right now I am making efforts to bring the Linux version to the same level as the windows one and so far it is going well, aside from some small bugs and potential bugs everything seems to be working fine. So hopefully on 5/5 demo day I can show something that Linux users can use. I rewrote some of the console system so that it actually loads the config file correctly on Linux, I still need to make changes to the cvars so that I can hold strings in cvars, this is because Linux users especially need a way to specify the path to their Vulkan implementation. Improvements to the video mode enumeration were also made, further improvements will be made between now and 5/5.

I ran the program through valgrind. I fixed all of the leaks that I could, but in Vulkan, my graphics driver leaks memory internally, and I can't fix that. The program freezes up when I try and run the r_restart command while attached to valgrind. But all in all the experience on Linux is basically equal to the Windows version now. The last thing I want to do before demo day is port the engine to the Wayland window system, but I don't know if I will end up doing that in time. I have less free time lately despite all the progress.

It's been another demo day, so you can download another build of the engine: https://mega.nz/#!JcJAyIZb!Z27CAFxYivzlvmKTJNI4sV8tn64EkcvW-UPJoE1VCRw

>>33719

>>>/v/16438439

This is a list of problems people had, so I can remember them all:

>fix the PVS generation in the map editor

>you can click off the window by moving the mouse fast enough

>the window sends itself into the bottom corner of the screen if you mess around with it, check focus, etc.

>the network limiter is dropping timesteps at high framerates because of low floating-point precision, use int64 timesteps instead

>non US keyboards don't have ~, find replacements for those

>on linux libwebp is being dynamically linked for some reason

>certain Vulkan drivers only have 16 image samplers per descriptor pool, figure out how to fix this

It worked generally okay on people's computers, although certain errors were not handled the way they should have been, nobody had the game crashing on startup or in the middle of gameplay, etc., the main issue was not checking to see if Vulkan could allocate textures and not handling that by falling back to OpenGL, however because all of the other errors were correctly dealt with the program did not crash and continued running, even if everything looked messy. It tried to tell the user about the missing textures, but the font failed to load. It would be interesting to create a fallback for that on windows with AllocConsole().

All in all I am glad that it was stable, despite the bugs. Only two issues are actually going to be difficult to solve, that is, the PVS generation, and the image sampler issue. Fixing bugs related to the PVS is very, very difficult to do. The image sampler problem will require me to restructure my draw call and I am not sure how that will go, it is an easier problem to fix, just, not a trivial problem. Realistically through it's a necessary restructuring that would have been required at a later time anyway. It's just that I have to fix it now instead of later.

I fixed the bug in the PVS, and added a post processing stage to get rid of the kind of fucked up geometry that my map editor was producing. Now everything is a lot cleaner. The next step is to actually start implementing more optimizations, work to fix it up, and hopefully new features. Lots of things to do...

>>33843

I am the only person working on this, hopefully, it will look nicer than kings field, by the end, it should look a lot more like goldsource or serious engine something. It just takes a lot of foundational work to get to that point...

I can't enjoy using C# and whatever godot uses, the langauges, just seem so poor to use, and then, of course, godot doesn't even have occlusion culling, which my engine does have, and none of them will run on my laptop, they are huge resource hogs, and I dislike that kind of bloat. I want to make games that could have been released in 2000... so they should run on the right hardware for that.

The map editor now lets you change the grid resolution. It works great, and you can no longer collapse brushes into themselves. The next feature is either going to be sloped surfaces or changing the texture coordinates on certain faces.

The map editor has been greatly improved, map compilation is instant and the size of the maps has been reduced by half. It's because I started doing what everything else does, I moved to a two-pass process where I cull all polygons on the outside of the level and regenerate a new BSP tree from the polys on the inside. This solves literally every problem with the PVS generation and it's now instant. However before I did this I spent some time multithreading and optimizing the PVS generation so it will run things on multiple threads, this is an example before my change that made it happen instantly, where it would go to 30% CPU and then jump to 100% for the last few seconds, compiling the map in 60 seconds (originally it took 120 seconds to compile). Not purely gains from multithreading and the MT approach is still in the code it's just that it's so fast that all of my optimizations are basically unneeded for the complexity of the maps I am feeding it. Maybe in the future I will enjoy faster times with more complex maps... so I don't think it's totally wasteful looking at the future. The header for "hall2" can be compared:

//old map
SIGMAII 4 936 17 908 908 309 10850
//new map
SIGMAII 4 538 17 537 537 93 969

Where the layout is like so: [version] [poly list] [texture count] [node list] [plane list] [leaf list] [pvs size]

So, it's about half as large... and the size of the file is also half as big. (250kb from 500kb). So this is a very good improvement.

The console background is back, it was gone in the 5/5 demo because there was not enough time to include it into the reworked Vulkan renderer, it required setting up a new draw call that I can use for the HUD elements. I am working on a "clip" feature for the map editor that will let you clip brushes against a plane. Right now I just have some basic graphics for this plane, it still needs some work. I only want to fill out the parts of the plane that intersect the target brush in the 2D views.

The map editor now has a working clipping tool , or rather, a working clipping routine, you cant save any of these maps or compile them, yet, but it's a very big start, lots of code rewritten to be much better than before, and hopefully by the time the 8/8 demo happens the engine will be able to show off some really cool maps that make use of the sloped surfaces!

There are a lot of screenshots of me debugging that I wont bother posting, once this feature is mature enough to become useful other work can be done, like skyboxes, etc. It's bothersome to not be able to depict an "outdoor" map at all. That should come soon but I don't know if it will work on 8/8 yet.

>>33987

This is some good progress m8 keep it up, I also like your choices in muzyka.

>>34003

Thanks friend, I am working on some new stuff, for example you can undo, delete, save, and compile clipped brushes, however I have an error in my code that I am working on for the past few days, there is a problem with the portal generation for leaves of the BSP tree that contain no polygons at all, and until now I was simply unable to make maps that were complex enough to have this issue, so I have been working on an algorithm to extract bounding boxes from the BSP tree itself (the portal generation needs accurate bounding boxes of all of the leaves) instead of basing my bounding boxes on the polygons themselves (since these leaves contain no polygons at all).

The first image is a map that reaches this complexity, the and the third is a compiled map with a sloped surface, and the fourth is an example of one such leaf, there are missing portals in that image, but it's hard to explain, basically I can look into two leaves there despite a portal being in between them. That shouldn't exist...

I think in a few days I will have it all sorted out. Then I can work on making a skybox.

In my last post there is an error, it's not possible for it to generate leaves without any polygons, the issue is, I think a problem with the winding order of my portals. The problem with portals not spanning their entire leaf was fixed so far by projecting the portals into 2D space and scaling them by 10, then projecting them back... i'm getting close to fixing this issue completely, I can compile the complex map "arches3" that I have shown a picture of earlier, it still has incorrect culling but not to the degree I was experiencing it earlier, soon I will have fixed that. These are just some misc. screenshots, mostly me trying to break the map editor in a simple way.

>>34019

I haven't released any code yet, I plan on doing so eventually, once a more substantial demo can be made. I have seen the video, it's pretty good. Although it's a much simpler style of engine, much more like the build engine. It would be interesting to try and make a similar video explaining how something like this engine is made, although live programming it would be much more difficult, because of how much code that takes... still an explanation of the algorithms with good visuals would be interesting to see.

testing... as you can see it's been 5 months, so obviously progress has been made on the engine, I will just dump screenshots of the new stuff that's been happening and try and explain what has been going on. As you can see skyboxes have been added into the engine, and resource loading is also working, like this mech model .

And, something interesting- these are pictures of a map being worked on by Kowloon anon, in Sigma Editor II, these are kind of outdated pictures already that show a very complex map... this is what the map editor is capable of at it's current state. There have been many productivity improvements to the editor software that have allowed this, it would be too slow to properly create these kinds of maps previously, I will post some more content explaining the actual features added to the map editor soon.

Still I don't want to act like the map editor is anywhere near finished. It's definitely an improvement over something like Hammer, but it still holds the user back in a lot of ways.

http://8agdg.wikidot.com/kowloon

So, this is a collection of short videos that I made over the last 5 months showing various improvements to the map editor, so you can see... the kind of work that I have been doing on it. It's a much nicer tool to use today than it was back then, in that, you can take some basic things for granted using it.

more videos

As for what i'm doing now, it's, creating the DLL interface to Sigma II, a lot of things are being worked on and redone inside of the engine, to make it fully programmable and generic. That large map and the mech model are not done by me, it's for a game that is being made in collaboration with a few others, on this engine. More progress will be posted later as... the programmable interface becomes more fleshed out and usable.

Ongoing work on the new programmable UI system, improvements to the map editor, documentation of the new programmable interface which is rapidly expanding... all previous work is now being replicated through this programmable interface, this requires a significant re-organization of code, however once finished actual game development will be possible.

working on the materials system

>>34153

Thanks, what kind of stuff are you thinking about working on? I'm trying to write some basic documentation for the engine's graphics API today.

>>34154

>>34152

Those are some interesting music choices, what genre is it called? My guess would be 70-80's synthetics (dunno which nation)

Flying spaceship and cubemapped material inputs , it gets updated using a matrix callback.

Almost done with the basic materials system.

>>34159

Thanks for the list.

Did more work on improving the map editor, it can now export as .obj files, which for example allows it to be imported into the unity engine. Useful for making the rough geometry of the level in unity, and then doing the actual detailing of it in probuilder. Saves a lot of time compared to actually working in probuilder, not that I would ever subject myself to that.

The materials system is being upgraded, it's possible to have sphere mapping, different texture filters, etc. now. Next step is to fix the map importing process, so that I can render levels with these new materials, which should be pretty nice. I expect to have shiny env-mapped windows and metallic surfaces, parralax scrolling cloud layers on my skies, etc. Then I can work on integrating entities into the engine, so the levels can be populated by models. A lot of work to do...