/agdg/ - Amateur Game Development General

Here are some more screenshots:

My IDE from a few days ago with the project open

A lines-of-code chart that I use to keep track of how much progress I am making on the codebase. It's hard to see progress since it's not graphical a lot of the time.

The other two images are explanations of bugs that I was/am having in my program. I fixed the rotation bug however the BSP bug is what I am still working on, I didn't have time to work because of school but now I have more time to work on it. If you understand BSP you should be able to figure out what is going on.

These are some recent videos of what I am doing, which is just floating around in my maps bumping against the BSP tree to see that it's working with the given map. Also the reason polygons are culled when I get too close is because of the near clipping plane, that is not a bug but you won't see that kind of thing in the final game, so its not a problem.

Progress on getting the compiler to resolve splits better: it can resolve splits now and it can resolve a lot of stuff that it couldn't do before. I'm able to compile maps that I couldn't compile, and compile them in ways that I wasn't able to do before. So, I have gotten a bit closer to finally resolving all of the bugs once and for all. I have probably made about 250 lines of code irrelevant now with the change I made to achieve this.

This is hall1.sw3, it took several weeks of work to get this map to compile into version 3 of the format, (into a BSP tree) but I finally have ironed out enough bugs for it to be a reality! There are still bugs that need to be fixed but I will find and fix those bugs soon.

>>31323

I can bet that within a year of further development you guys will be able to play demos of this engine that show off actual gameplay. By then the rendering engine will be mature, models will be working, as well as networking and cross platform support. At least, I hope. I'm aiming to have an OK looking demo for 5/5 that lets you walk around in a map, but I have final exams, so I will probably have a much better demo on 8/8.

The compiler fails on this map with the split prioritization on. I think that this is one of the last bugs left to fix, and once it is fixed I should not have any more problems in the future. Then I can move on from the BSP compiler and start reworking the rendering system since it is written in a kind of wasteful way.

I finally got it to resolve the last cases that caused it to fail, so now I can start making more maps and if it doesn't break, then I will just keep moving forward and start working on things like physics, occlusion culling, etc.

Back to work, afer being inactive for a few weeks, I will fix the lastest bug in my compiler once I complete a visualizer so that I can step through the compilation process.

>>31425

I'm not entirely sure what you mean, I am using hardware acceleration and just told OpenGL/Vulkan to filter the texture.

So, this is a change in what i'm doing: instead of the exception system to resolve the invalid geometry, I will learn how to do CSG intersections between brushes and just do it correctly instead of wasting my time further using this method: I'ts just not going to work and my debugger does not help me. So I will add CSG to the map editor and do it properly...

I have successfully implemented CSG, still has bugs but those will be fixed shortly. This should solve all of the issues with invalid geometry I have been having.

All CSG and BSP issues are fixed. There are some bugs with the textures in Vulkan that need to be fixed, but since I am going to be rewriting a lot of my graphics code soon to be more optimal, I will hope to fix that problem by rewriting the code. Right now I think I will work on porting my updated engine to Linux again, since it broke compatibility a few months ago and I never got around to that...

Since I broke compatibility with Linux for several months to work on some features without worrying about it working on Linux while I was trying to get them working, the engine didn't work on Linux for a while. But now, it works on Linux again!

The next thing I'm going to be working on is occlusion culling, because this GPU on my Linux machine whines and can't draw these levels at a good framerate without it... by the way, Godot doesn't have this feature either. So I want to have it before Godot does. Maybe my engine isn't comparable to Godot, but it's a good kind of motivation for me.

I don't have a lot of time to work on my engine lately. But I am working on generating portals so that I can build a PVS. I hope that I will have occlusion culling before 8/8 demo day and also before godot 3.1 gets it... Here is a picture of portal generation in progress. Right now it only generates this portal, it still has bugs in it and ideally it should be able to generate all of the portals correctly but it doesn't right now. This is the only visual progress this month even though a lot of work has been done because of work I wasn't able to work on it at all for two weeks of progress. Hopefully I will be able to get into working on it after work, i'm just very poor at that and need to improve.

I'm not happy with how many extra polygons are generated by the CSG but of course in the final rendering engine it will use the original polygon data instead of the actual polygons that collision is done against (although these two sets are conveying the same information, basically). That's in a long time though and right now I just want to get occlusion culling working...

>>31627

In theory it runs on any OS that has POSIX timers/threads, X11, and OpenGL. No Vulkan in the UNIX version yet because I have no computer running both Linux and Vulkan at the moment. Maybe later I will have this but not right now (and anyway I have more important stuff to work on right now).

I am still working on debugging the portal generator. I have found many bugs but I still don't have much time to work. Hopefully I can have it finished within the next 12 days (but that is a stretch...). Since demo day is coming up I might decide to work on a demo without occlusion culling since that probably won't be present in the 8/8 demo day (but maybe it will be if a series of breakthroughs happen).

Today I can feel very satisfied, I created the first map to have it's portals correctly generated! The debug view crashes on larger maps but that can be fixed, it looks very promising, and I might be able to have portals generating correctly by the end of the day, this would mean that I can start working on PVS occlusion culling and all of that, and so I might have a chance to show something on demo day!

Some screenshots of the portals after ironing out some more bugs:

I got it to do occlusion culling with a PVS. However on anything more complicated than this map the PVS generation crashes or is incorrect.

The problems with the occlusion culling system have been fixed, so now I can move on to other problems. This means the the most difficult problems have been solved, and all progress from now on should be much more visible and easy to notice and see... which should be very nice.

Frustum culling was added today. I will keep optimizing it for a while now.

I have been optimizing the rendering code for the last couple weeks. Right now the first image is what the rendering code looks like today: only 33 calls to OpenGL and only 3 actual draw calls to draw the entire world. (one draw call for each visible texture) The last image is what the rendering code was like on 8/21... and it's STILL not as bad as it was when I wrote my last post. I bet that at the beginning of the month the amount of calls was over 1000 or something awful. The code is a bit faster, on my ATI card I can get 200 FPS average. I still have the problem of immediate mode being faster but with the amount of triangles being so small it might just amount to a simpler explanation like that. Vulkan is totally broken by all the sweeping changes I have been making but I need to rewrite it any way. Vulkan support will return after the OpenGL rendering code is more stable in how it works, I still have to see how I can make the code faster by leveraging the kinds of shaders that I have access too, etc etc. I don't think the performance is going to increase much more but it is needed any way for when I start adding actual features that make the game look nicer.

>>32143

forgot image

I released this build on demo day:

Windows (32-bit) (598kb): https://my.mixtape.moe/xdmozk.zip

Linux (64-bit) (813kb): https://my.mixtape.moe/jobsch.zip

I am rewriting my Vulkan code, hopefully I will be able to start posting on this thread again with real progress.

some improvements to the map editor

This is Sigma 2 on Windows 2000. The only big change it needed was checking for the raw input API in user32.dll, since only windows XP and up can use this. It works fine, but FLIF image decoding doesn't work since the reference implementation doesn't support windows 2000. WEBP images work fine though.

>>32995

More images-

Performance on this card (Nvidia Vanta) is poor. It can reach near-60FPS on some sub-640x480 video mode, with the texture filtering turned down (nearest neighbor texture interpolation and nearest neighbor mipmap interpolation) but I think higher performance is possible if actual texture LOD options are implemented into the game (like r_picmip in quake). This interestingly can have an effect on load times, since I can just load half of a FLIF file and it will decode into a perfectly half-resolution version of the original image. No I/O and memory wasted on the extra details... this is something I won't do for a little bit, but is definitely something to think about.

>>32996

Interesting insight....

In what would become standard industry practice on a massive scale in later years, Nvidia released a budget version of TNT called Vanta. This board used the same TNT chip but lowered its clock speed and halved both memory data bus width (to 64-bit) and memory size (to 16 MiB). By doing this, Nvidia was able to still sell TNT chips that couldn't reach the TNT's specified clock speeds[citation needed], a practice known as binning, and cut board costs significantly by using a narrower bus and less RAM. The board proved popular with OEM computer builders because of its capable feature-set and low price.

So this is basically a clocked-down TNT... at this point, 640x480 at 30 FPS seems more reasonable. At this point I attempted to add a couple of features that might help- first of all a way of trying to get the computer to create an OpenGL context in high-color ( 16 bits) instead of true color (32-bits), and second an attempt at changing texture LOD, making two new cvars "gl_16bit_color_mode" and "gl_picmip". The latter uses the https://www.khronos.org/registry/OpenGL/extensions/SGIS/SGIS_texture_lod.txt extension to do this and I think it works great! This is what picmip 4 looks like. I would call it "gl_texture_lod" but that's confusing since picmip is already a pretty standard name for this kind of thing. I already use a lot of non-quake cvar names but whatever...

I ran into an issue where the Vanta driver has a GL_VERSION high enough where texture LOD is a supported feature, but the SGI extension isn't found. So I had to add GL_VERSION checking to enable the feature without the SGI extension, this means that it will work on a driver that doesn't have OpenGL 1.2 but DOES have the SGI extension. I wonder if that configuration even exists... it probably does, somewhere.

Then I ran into another big problem:

		float picmip =  cvar_getf("gl_picmip");
		if(glr->gl_texture_lod && picmip > 0.0f){
			if(glr->flags & GLR_FLAG_TEXTURE_LOD_NOSGIS){
				glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_LOD,picmip);
			}
			else{
				glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_LOD_SGIS,picmip);	
			}
		}

This code causes my drivers to absolutely lose their shit on the Vanta, and drops my FPS to 2. I have no idea WHY it does this, but that's very bad... texture LOD works... but why would it do that? I have no idea and it's very strange to me. I will have to look into this further. Basically, ANY CALLS to this texture LOD setting will absolutely destroy my performance. I guess it's some case of wanting to say that you support OpenGL 1.4... in that the code will "work", just some features will be so slow it's totally useless. So, I added a check, so that if gl_picmip is zero it wont call that function. This solves it, as long as you don't try and use picmip settings again. I can fix this issue later with a version that doesn't depend on the texture LOD feature.

Here are some pictures, the first one shows what the texture LOD command can do, and the second shows the effects of the "gl_16bit_color_mode" cvar. The framebuffer is 16-bits now, it gains a few frames on my Vanta but looks poor. Still useful to have I guess.

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...