[ / / / / / / / / / / / / / ] [ dir / agatha2 / animu / asmr / choroy / egy / randamu / vg / vichan ]

/agdg/ - Amateur Game Development General

AGDG - The Board
Winner of the 83rd Attention-Hungry Games
/strek/ - Remove Hasperat

May 2019 - 8chan Transparency Report
Name
Email
Subject
Comment *
File
Password (Randomized for file and post deletion; you may also set your own.)
* = required field[▶ Show post options & limits]
Confused? See the FAQ.
Embed
(replaces files and can be used instead)
Oekaki
Show oekaki applet
(replaces files and can be used instead)
Options
dicesidesmodifier

Allowed file types:jpg, jpeg, gif, png, webm, mp4, swf, pdf
Max filesize is 16 MB.
Max image dimensions are 15000 x 15000.
You may upload 5 per post.


Welcome to AGDG, have you ever made a game?
See also: /ideaguy/ | /vm/

File: 85ee948655e6aef⋯.png (17.63 KB, 512x512, 1:1, s2-3dlogo.png)

File: f4548e516c66839⋯.png (413.25 KB, 646x505, 646:505, sigma2_2018-03-05_01-45-12.png)

File: 543ec720dc7dbf3⋯.png (44.59 KB, 648x507, 216:169, Sigma Editor 2_2018-03-24_….png)

e6b9f1  No.31318

This thread is for my game engine, Sigma II, since I needed to get around to making such a thread any-way. It will be where I post all of my progress and what kind of stuff I am working on in one place in case anyone is interested in seeing the progress the project has been making over time.

There is a page on the wiki here:

http://8agdg.wikidot.com/sigma-ii

e6b9f1  No.31319

File: 26c046525244bd2⋯.png (95.52 KB, 1274x970, 637:485, poide64_2018-03-30_12-25-4….png)

File: 5851e27dfec55ab⋯.png (13.58 KB, 953x483, 953:483, EXCEL_2018-04-05_03-30-52.png)

File: fb452aaa8c2f1f4⋯.png (37.15 KB, 1200x600, 2:1, bsp-explained.png)

File: 201fb9e8932a586⋯.png (30.39 KB, 800x600, 4:3, sigma2_rotation_bug.png)

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.


e6b9f1  No.31320

File: 78d6ae80799e319⋯.webm (7.03 MB, 640x480, 4:3, sigma II BSP working room….webm)

File: db54ed0e8a2236f⋯.webm (8.64 MB, 640x480, 4:3, bsp tree progress.webm)

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.


0847c5  No.31321

>>31319

even with sunlight flooding my eyes those light backgrounds hurt to look at


e6b9f1  No.31322

File: 217cf29979494cf⋯.png (17.67 KB, 927x579, 309:193, sigma2_2018-04-08_23-24-05.png)

File: 794be669b7b265a⋯.png (29.29 KB, 806x625, 806:625, sigma2_2018-04-08_03-27-07.png)

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.


fa7250  No.31323

fuck yea, Ika's here!

agdg-wide collab on a Sigma II powered game when?


e6b9f1  No.31324

File: 79d9ea1b47ae387⋯.webm (11.5 MB, 640x360, 16:9, hall1.webm)

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.


186dc2  No.31327

>>31324

So those 4 tris on every block seam could be optimized away in most cases, right? Though it's obviously more useful to keep geometry as your own placed tiles than do that.

I guess they get culled away as backfacing or covered anyways


ab93ea  No.31330

>>31327

That's right, there are a lot of optimizations that I want to apply after I have the first stage of this completed. The first optimization is to just render the original polygons before splitting since that reduces the polycount. The polygons that are invisible to the player will be culled eventually after the PVS is created, which will let me cull all polygons that aren't visible from the player's starting point. (See section 4 of this page: http://fabiensanglard.net/doom3/dmap.php) So in the final map they won't even be in the polygon list.

The examples in the first screenshots above at >>31322 show the BSP compiler set to prioritize polygon splitting, which is very unoptimal, so it would never resolve geometry that way in a real compile.

I still have to fix a bug where polygon exceptions need to be applied by proxy: So if A excepts B, and B excepts C, then A must also except C to correctly resolve the geometry. At least I am pretty sure that's the last bug in this system.


6cf6bc  No.31336

What do you plan to do with this engine exactly?


e5ea2a  No.31337

>>31336

Make a few demos and also a first-person shooter game. Then I will probably work on a third engine that is better than this one.


e5ea2a  No.31338

File: 36945ce7c2e21b5⋯.png (231.01 KB, 703x517, 703:517, sigma2_2018-04-10_04-05-48.png)

File: eac416a3acc1342⋯.png (80.52 KB, 888x707, 888:707, Sigma Editor 2_2018-04-10_….png)

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.


ad31bb  No.31343

>>31319

seems like a coplanar face should be tested with dot product between its normal and the plane to decide which half space it belongs.

dunno if thats an exception, maybe a nuisance.

have you experimented with a 2d compiler?


e5ea2a  No.31344

>>31343

The coplanar faces are already being tested in that way: it's just that they need to be sorted into the opposite space when the special case arises. So that's why there is a need for a special case.

I haven't experimented with a 2D compiler, but I have written a 3D compiler before, just using a less complicated BSP tree where I could put all coplanar faces into the front list without an issue.


765548  No.31345

>>31344

I may not understand anything about BSP trees... but isn't the point of it to separate everything into a tree based on like the vertices?

I guess, if you're always just subdividing, why would there ever be a special case?


e5ea2a  No.31346

>>31345

Its explained as well as I can in the "bsp-explained.png" of my first post: If it sorts the geometry that way, it won't be able to prove that the two blocks are convex 3D spaces. With the special case, it can sort them in such a way where it can prove that. It's because the faces are directly on the splitter plane. We can't resolve them through splitting, and so even though there is a correct and incorrect choice, it's not immediately clear. The original compiler at: https://www.cs.utah.edu/~jsnider/SeniorProj/BSP/default.htm that I am basing my compiler on doesn't know how to deal with this special case, and it assumes that it never happens, so it incorrectly sorts them into the wrong lists, causing the compiler to fail later.


e5ea2a  No.31367

File: 1a7ff4af5c7e669⋯.png (511.7 KB, 1204x865, 1204:865, Sigma Editor 2_2018-04-14_….png)

File: d28708cab8b277f⋯.png (79.94 KB, 1280x720, 16:9, sigma2_2018-04-14_13-35-14.png)

File: b2d720a84a31a5c⋯.jpg (320.08 KB, 1280x720, 16:9, sigma2_2018-04-14_13-35-23.jpg)

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.


e5ea2a  No.31368

>>31367

Also I didn't explain why the wireframe picture has an awful polycount:

The screenshots show a really high polycount because I have the compiler configured to prioritize nothing but polygon splits, meaning that it increases the polycount as much as possible. In normal use the compiler will only split polygons when it would make the tree too imbalanced, so it doesn't actually increase the polycount that much.


186dc2  No.31425

How did you overcome affine mapping / tearing with your geometry?

I tried a really simple project for my own 2D project just to see if I could do fake 3D in a "dungeon with cube walls" but the texture was tearing something awful.


635f07  No.31479

File: 2317e8d0ef7494b⋯.png (14.73 KB, 951x441, 317:147, EXCEL_2018-05-07_19-09-30.png)

File: 01e84ac6cfb8069⋯.png (312.5 KB, 1920x1036, 480:259, Sigma Editor 2_2018-05-07_….png)

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.


635f07  No.31498

File: 3e11d17ee465237⋯.png (14.81 KB, 808x627, 808:627, Sigma Editor 2_2018-05-11_….png)

File: e6494318d6d7dda⋯.png (12.22 KB, 800x600, 4:3, Sigma Editor 2_2018-05-11_….png)

File: e8b4249234d792c⋯.png (6.95 KB, 800x600, 4:3, Sigma Editor 2_2018-05-11_….png)

File: 47e18aebda5bb14⋯.png (13.7 KB, 800x600, 4:3, Sigma Editor 2_2018-05-11_….png)

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


635f07  No.31521

File: 18716e175c983ca⋯.webm (834.59 KB, 640x360, 16:9, CSGbug.webm)

File: 2b672eb0c9720d4⋯.webm (820.17 KB, 640x360, 16:9, CSGworking.webm)

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.


635f07  No.31522

File: c56aebbcca26dc4⋯.jpg (376.69 KB, 1158x889, 1158:889, sigma2_2018-05-18_04-33-55.jpg)

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


635f07  No.31545

File: 870009cb31c22a5⋯.png (188.22 KB, 809x501, 809:501, sigma2_linux_progress.png)

File: 606b8ec509c61f8⋯.png (103.48 KB, 646x432, 323:216, sigma2_linux_progress2.png)

File: dbe94607397d681⋯.png (599.46 KB, 806x632, 403:316, sigma2_linux_progress3.png)

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.


5016fc  No.31627

>>31545

>Native loonix support

Noice


635f07  No.31730

File: e91f22cd7fa8371⋯.png (23.08 KB, 808x627, 808:627, Sigma Editor 2_2018-06-24_….png)

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


0b868b  No.31812

File: 9e2ffa493aed24c⋯.png (7.19 KB, 310x235, 62:47, portals_rendered.png)

File: 03e5d1cf5eaf68b⋯.png (28.22 KB, 808x627, 808:627, portals_rendered2.png)

File: a66c6ce15afa84a⋯.png (17.21 KB, 808x627, 808:627, correct_portal.png)

File: 082432a042a134b⋯.png (13.03 KB, 808x627, 808:627, bad_portal.png)

File: a5287126090dc3f⋯.png (28.03 KB, 808x627, 808:627, debugging.png)

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


3a3c62  No.31879

File: a247698d28a27d3⋯.png (24.57 KB, 689x496, 689:496, sigma2_portals_correct.png)

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!


3a3c62  No.31882

File: 9920dfbbec8a6a7⋯.png (25.67 KB, 808x627, 808:627, hall1_1.png)

File: ed49d408d3ab24d⋯.png (20.62 KB, 808x627, 808:627, hall1_2.png)

File: 4bbf79e8a89e135⋯.png (28.04 KB, 808x627, 808:627, hall2_1.png)

File: bd4f80d0d1254c2⋯.png (36.12 KB, 808x627, 808:627, hall2_2.png)

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


3a3c62  No.31976

File: cc6c7a35ec4def5⋯.mp4 (14.66 MB, 640x480, 4:3, 2018-08-06 01-45-17.mp4)

File: 27a795451588459⋯.png (626.21 KB, 646x505, 646:505, pvs_bugs.png)

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.


635f07  No.32045

File: 710694b3af7f07e⋯.mp4 (9.03 MB, 640x480, 4:3, ocw.mp4)

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.


635f07  No.32069

File: 5a518f740f498f3⋯.webm (6.47 MB, 640x480, 4:3, frustum_culling.webm)

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


c34670  No.32078

>>31367

It's good you're adding windows and shit. Red Sky was way too fucking bland.


635f07  No.32079

So I implemented back face culling, but I realized something important looking at some things. My engine has three rendering paths, OpenGL Immediate Mode, OpenGL VBO mode, and Vulkan mode. In theory the performance would be: Vulkan > VBO > IMM, but it's actually IMM > VBO > Vulkan with real numbers kind of like:

9000 > 6500 > 1000 frames per second.

Meaning that my code using glbegin(), glend(), is 9 TIMES FASTER than Vulkan.

Obviously this is because of the graphics drivers internally optimizing everything, and the immediate mode renderer allowing it to internally optimize everything. So, the question is, if I can at least get all rendering paths equal to each other. Since, it's kind of a meme that immediate mode is slow and outdated, but ironically it is quite a lot faster than anything else just because of the automatic optimizations it does. In theory Vulkan can do better... so I have to figure out how to optimize my rendering until it is actually as fast.

>>32078

Thanks. Yeah I am going to try and make the graphics look a lot more interesting this time around. At the moment it's just royalty free textures but it should come out a lot better by the time it's done.


635f07  No.32141

File: 182c3c1b478146d⋯.png (43.38 KB, 732x444, 61:37, qapitrace_2018-08-29_22-21….png)

File: 2a817ff8c3a170d⋯.png (115.9 KB, 661x899, 661:899, qapitrace_2018-08-29_22-25….png)

File: b99ee8b006f1ba9⋯.png (74.69 KB, 586x839, 586:839, qapitrace_2018-08-29_22-25….png)

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.


635f07  No.32143

Just a follow up... I can get 12000 FPS now, the highest I have gotten in this engine. Of course it can still do better. So, i'm just continuing to polish and set up the code until it's as good as I can make it at this point. Then I will write the Vulkan version of the code to also be optimized in this way. Also, I finally got it to the point where VBO's are faster than immediate mode. Even if it's only by 0.000013ms it's consistent so I am happy about it. I expect the Vulkan version to be even faster.

There are also more optimizations I can make by using a new version of the world format. It's a very complicated optimization to make but would lower the polycount significantly by removing all splits done by the BSP and CSG compilation steps. However it still has a lot of problems and I have already tried and failed to implement this. But eventually I want to do it.


635f07  No.32144

File: d7ab660700d6557⋯.png (624.15 KB, 640x480, 4:3, sigma2_2018-08-29_23-46-16.png)

>>32143

forgot image


635f07  No.32619

File: 782a9587a5829d7⋯.png (465.05 KB, 640x480, 4:3, 782a9587a5829d7b1579861dd9….png)

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.


635f07  No.32934

File: 742494edcf18c5f⋯.webm (7.3 MB, 640x480, 4:3, editor2.webm)

File: 29761544fb65cf9⋯.webm (931.84 KB, 640x480, 4:3, editor1.webm)

some improvements to the map editor


635f07  No.32995

File: f6d744da74e4445⋯.png (3.83 MB, 1210x1613, 1210:1613, w2k4.png)

File: 19ad916e9891101⋯.png (4.53 MB, 1613x1210, 1613:1210, w2k1.png)

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.


635f07  No.32996

File: bb00ac321338205⋯.png (726.86 KB, 645x484, 645:484, w2k3.png)

File: 7c76f360e27d354⋯.png (4.16 MB, 1613x1210, 1613:1210, w2k2.png)

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


635f07  No.32999

File: 88d576369985f45⋯.png (393.93 KB, 640x480, 4:3, Sigma 2 (Pelles C 8)_2019-….png)

File: b600a102ee8089a⋯.jpg (255.75 KB, 1280x960, 4:3, win2k_16bitfb.jpg)

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


1bd89b  No.33118

This is an incredibly interesting look at IDE design, and well-documented at that. I love seeing a real-time dev-tool development.

Could you explain exactly what it is about Linux that causes compatibility issues and requires re-compiling? It's got to be more than just implementing OpenGL, right? Linux exporting has been done automatically in all the programs I've used, so I'm interested in the specifics.


e1db7f  No.33119

>>33118

I don't think my Linux version has compatibility issues with the binaries that I can produce. Maybe I complain about it a lot because I am not as experienced as someone who runs Linux as their primary OS. My workflow just isn't going to be as efficient. I did have a problem with targeting x86 on Linux. I can compile on both x86 and x64 on Windows without thinking about it- but on Linux x86 is a second class citizen. So, I had to do some work configuring my system to be able to compile and run x86 binaries. Then I produced binaries that didn't work on other x64 Linux systems because they were not configured to run x86 binaries. The real solution was to just set it up to be able to compile both x86 and x64 binaries... it's not to unreasonable... in Linux, you can compile everything, so what's the point of supporting x86 if you have a x64 processor? I just did it that way because I don't want to leave x86 Linux systems behind. Also, since Linux programmers marginalize x86 more and more, the effort too support it doesn't seem to be that strong. I had to edit some makefiles in some of my libraries to compile for x86. But it wasn't a big deal since I solved all of my problems in the end.

Once you have the binaries, it's fine. Linux computers (on the desktop at least) all generally conform to some common set of features. You can basically expect them to all have OpenGL, X11, etc... I used Xlib, and XFree86VM for full-screen mode, because they were included in Slackware 14.2, which is the Linux distro that I use. I have never used a package manager unless I am using someone else's computer. I compile everything from source. Luckily its a fairly standard package to find, even though my friend trying to compile the engine on Debian a while ago had to download a lot of packages to do it....

Don't fall into the trap of writing "Distro Specific Software". Just read this: https://forums.svencoop.com/showthread.php/46288-Dropping-support-for-Windows-XP-2003-Windows-Vista-2008-and-Linux-GLIBC-lt-2-24


Sorry to disappoint further, but those of you wanting to run SvenDS on RHEL, CentOS, or FreeBSD will still not be able to do so just as you can't now. To be clear on this, as a game development team we have no desire to support enterprise type distributions of Linux. Though they may be great for many applications, games are certainly not their purpose. Our choice down the Debian distribution path correlates with a happy balance between fairly up to date software and stable proven software. The Debian path also matches Valve's preference with Steam, particularly as they use this for their own SteamOS distribution, of which the current version (3.0) is also based on Debian 9.

This is the kind of trap you can get into... standards have been worked on to solve this problem, and unfortunately I don't think that they will

really work, even though LSB exists, for example Debian doesn't officially comply with it! I think it's very strange to be able to write software that only works on a few Linux Distro's. But that's the issue. UNIX world does not like to follow standards at all, everyone drifts apart. X window manager is a great example of this, and so UNIX programmers only use wrappers like SDL, GTK, QT, over it so they don't have to work with it natively. Read the source code of those projects, you will see how it works. Running a battery of attempts to try and even out the differences between platforms... using totally undocumented API's... Some people just shut it out and "support" Linux by supporting the one distro they ported the software to Linux with. Maybe I'm a little guilty in that it's easiest to build on Slackware because all libraries are just installed.

I didn't think this wall of text could get so long, I hope you like it... I don't know what you mean by an IDE though. Is that what you call that thing modern game engines do, where you work in some kind of weird software that is a combination of a map editor, a script writer, a resource manager, honestly I have never used a modern engine, but it all looks very complicated. I only used GoldSource before writing my own engines. Do you see the influence? It's the same workflow.


1bd89b  No.33120

>>33119

Thank you for, I've never seen an accurate write-up on this.

>I don't know what you mean by an IDE though. Is that what you call that thing modern game engines do, where you work in some kind of weird software that is a combination of a map editor, a script writer, a resource manager

I think that most people just say "game engine" but whatever, yeah, that is what I meant by that. "Integrated development environment" expresses what it does, but then I guess you can get it confused with a programming tool like visual studio. 'Game Engine' is fine too. Disregard me.

>it all looks very complicated

you programmed your own game engine in C. I can't tell whether you're joking.


e1db7f  No.33123

>>33120

I'm lucky that slackware has easy instructions for enabling x86 support from x64. See here: http://www.slackware.com/~alien/multilib/

I don't know what the process is like for something like Debian, for example. I really wish that LSB was followed by all of the major distros, it's a shame that the effort didn't work. Then I can just read this spec here: https://refspecs.linuxfoundation.org/lsb.shtml

And I know what libraries I can expect and when to expect them. It would solve a lot of problems.

Modern game engines with that kind of environment that Unity, Unreal, Godot uses, just seems like a much more complicated tool than for example my experience with game engines, but I guess that's a funny way for me to say that I don't understand how to use them. I guess I can't relate too it. But I think writing code in C# or C++ is a lot more complicated and difficult than writing code in C.


ad26d4  No.33273

>listening on port 1488

cheeky


e1db7f  No.33367

File: 8cb9485875cc728⋯.png (29.26 KB, 646x505, 646:505, sigma2_2019-02-27_20-53-41.png)

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.


e1db7f  No.33583

File: ccb0d81108f717e⋯.png (17.32 KB, 646x505, 646:505, sigma2_2019-04-07_17-15-32.png)

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


88d460  No.33591

Looking good anon, keep up the good work. I love seeing graphics and engine work being done amongst all the nodev.

Cool rig too, i've been looking out for old IBM boards with ISA slots for PSX devkit cards


e1db7f  No.33593

File: 36e53c73038fb1e⋯.png (108.59 KB, 1304x820, 326:205, qrenderdoc_2019-04-12_20-2….png)

File: 1ceee383093eafa⋯.png (15.52 KB, 646x505, 646:505, sigma2_2019-04-07_17-22-03.png)

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


e1db7f  No.33594

File: 3693bbbcbb7f893⋯.png (65.03 KB, 1283x602, 1283:602, notepad_2019-04-12_20-36-0….png)

File: d169e3d86f7f150⋯.png (130.75 KB, 646x505, 646:505, sigma2_2019-04-12_20-32-46.png)

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.


e1db7f  No.33598

>>33594

It turns out my method of copying was the right one. Anyway I still have this issue, I think its something in my shader and with my matricies, i'm not sure.


e1db7f  No.33608

File: 227c9be07d70b1b⋯.png (613.22 KB, 640x480, 4:3, sigma2_2019-04-17_14-40-48.png)

File: 2ed6b8e8935f2dc⋯.png (661.69 KB, 640x480, 4:3, sigma2_2019-04-17_14-41-28.png)

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.


7b3f84  No.33609

>>33608

So that's where you've been, I was wondering why you weren't posting in the /agdg/ threads on /v/. How far are you from a release where one could make a full game with your engine?


e1db7f  No.33610

File: 85d939bf50fa23f⋯.webm (207.43 KB, 747x560, 747:560, video.webm)

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


e1db7f  No.33628

File: 26dc53d27eaa3dd⋯.png (518.46 KB, 665x533, 665:533, sigma2_vulkan_works_in_lin….png)

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.


ad3e09  No.33629

>>33628

Will there be a portable binary for the linux release? If so I'd like to read a post on how you make it.


e1db7f  No.33630

>>33629

I don't think that I really know more than anyone else about how to do that, I am definitely not the most experienced at Linux although I know how to use it, I haven't had issues with other people running my Linux binaries, although i'm sure there are limits to that, right now it only uses POSIX and X11 and OpenGL/Vulkan so as long as you have those three things it should work fine in theory, I recently gutted FLIF support from the way it's set up so the only library I even use is a statically linked libwebp which has no dependencies of it's own, really my strategy here is to just hope that the very low amount of dependencies make it runnable on everyone's system.

Eventually I will release the code, and then it won't be so much of an issue for UNIX users to work with. In theory this codebase should run on BSD's, etc., and you can compile out all Vulkan code too. At some point I want it to be set up so you can also compile out OpenGL support as well.


e1db7f  No.33634

File: c5ed0c126ec26ee⋯.png (51.7 KB, 725x303, 725:303, no_leaks.png)

File: aafcb1ea22635c6⋯.png (42.72 KB, 733x200, 733:200, Screenshot from 2019-04-24….png)

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.


e1db7f  No.33737

File: 1766f45785e0d3a⋯.png (453.38 KB, 640x480, 4:3, PVS_error.png)

File: 3bc26707a7a6634⋯.png (12.71 KB, 412x263, 412:263, 3bc26707a7a66349dcbf7d44e2….png)

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.


ad3e09  No.33747

I enjoyed the demo and had no major issues on windows, but couldn't get it to run on linux because of the version of libwebp it required wasn't in my distro. I was going to give some Linux platform thoughts based on what the game did, but since I can't run it I'll just type all the things I might have said here. I use a tiling window manager so to make windows float with XLib I make them not resizeable by setting min and max size hints to the same value. On Windows the cursor wasn't hidden so I'm assuming it's the same on Linux. To hide the cursor in XLib you have to make a transparent cursor and apply it to the window. I'd also recommend grabbing the cursor to the window as well as warping it to the center so that it can't change focus on both operating systems.


e1db7f  No.33748

>>33747

I see, I don't resize my window at all right now. (besides restarting in a new mode) And yeah, not having the pointer warped on the center is an issue. Right now I just warp it to 50,50. Reminds me of when I played reflex in 2014 or something and always clicked out onto my second monitor every time I tried to hit a rail shot.

It's pretty annoying that it dynamically linked libwebp. I will have to figure out how to make it link properly... any way I think I understand what I need to do to make this transparent cursor. Just pass in a mask of all zeroes to XCreatePixmapCursor, that should work out I hope.


e9179d  No.33761

>>33634

Valgrind spits out a lot for my vulkan driver and validation layers as well. Using clang's -fsanitize=address complains less (there's one calloc() somewhere leaking memory but I'm not the one calling it).


2ea209  No.33764

The vulkan renderer doesn't work for me (defaults to OpenGL) on Gentoo, with or without specifying the path to my libvulkan.so.


e1db7f  No.33767

So far I have fixed the bug where you can't move when the game starts, by synchronizing the client and server initialization so that the client won't fail to connect.

I think I have fixed the bug where at a very high framerate the game can stutter. I rewrote the code that keeps track of the time to use integer time, since I think floating-point time wasn't precise enough to limit the network rate correctly, and might have been causing the client to not send packets fast enough. Too much of the timesteps get rounded away basically, is my theory. This only happens on Linux so I have to test it still and port my changes over.

>>33761

I wonder if using a custom allocator would fix it. But I'm not too concerned about it to try. Mostly because I wouldn't want to disappoint myself with that work if the Nvidia driver I have is just leaking memory internally.

>>33764

It's either failing to initialize or failing to open the libvulkan somehow. My problem is that my error messages aren't detailed enough. If you want I can respond soon with a build that hopefully gives more detailed error reporting.


e1db7f  No.33768

>>33767

Oh, and I also got it so that you can't escape the window anymore by flicking the mouse hard.


e1db7f  No.33825

File: 6bbccabe7150970⋯.png (334.23 KB, 640x480, 4:3, sigma2_2019-05-21_03-07-41.png)

File: 6e7e47c164517f2⋯.png (335.69 KB, 640x480, 4:3, sigma2_2019-05-21_03-08-29.png)

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


f966e7  No.33843

So are you guys going to install Unity or Godot yet, or are you still working on an unofficial sequel to King's Field on the PlayStation® 1?


e1db7f  No.33844

File: 845a258ac888517⋯.png (1.13 MB, 1280x480, 8:3, fixed_bug_pp.png)

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


e1db7f  No.33874

File: 0221de9901b375a⋯.webm (1.22 MB, 640x480, 4:3, snap_to_grid.webm)

File: e8ed37290b71fe0⋯.webm (1.02 MB, 640x480, 4:3, editor_gs.webm)

File: 66ebd807cd62d9e⋯.png (441.75 KB, 1048x867, 1048:867, Sigma Editor II (Pelles C ….png)

File: bed6bc645284b5a⋯.png (442.25 KB, 640x480, 4:3, sigma2_2019-05-28_01-50-00.png)

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.


e1db7f  No.33880

File: 76a47d9e89bfdc7⋯.png (25.98 KB, 1056x253, 96:23, taskmgr_2019-05-30_09-04-2….png)

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.


e1db7f  No.33945

File: 18b7e3f2a1fd0dc⋯.mp4 (967.95 KB, 640x480, 4:3, editor_cut_mode_test1.mp4)

File: 6b3302c40040763⋯.png (375.9 KB, 640x480, 4:3, sigma2_2019-06-17_17-51-17.png)

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.


e1db7f  No.33987

File: 7e606e4cee451bb⋯.png (341.24 KB, 1086x896, 543:448, Sigma Editor II (Pelles C ….png)

File: ea8b6a452641fa5⋯.mp4 (6.48 MB, 800x600, 4:3, editor_timelapse.mp4)

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.


c5b59d  No.34003

File: f6c5b719d7657bb⋯.gif (144.95 KB, 500x585, 100:117, totally rad.gif)

File: 1649e2f1d784bc9⋯.mp4 (4.02 MB, 540x360, 3:2, king of the hill duke.mp4)

>>33987

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


e1db7f  No.34004

File: 038a79de50b005e⋯.png (1.24 MB, 1920x1017, 640:339, Sigma Editor II (Pelles C ….png)

File: 21c4c277708106c⋯.mp4 (1.2 MB, 640x480, 4:3, editor_undo_cut_brush.mp4)

File: 3feaf6f6affbace⋯.png (489 KB, 640x480, 4:3, sigma2_2019-07-06_13-13-58.png)

File: fecbb1f87e59322⋯.png (28.58 KB, 800x600, 4:3, Sigma Editor II (Pelles C ….png)

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


a88d6b  No.34019

This is very cool. I love this style of engine. Looking through I didn't see any source, do you have any plans of releasing the code? When I get a chance I am definitely trying this out, thanks for the Linux build.

In case you arent familiar a guy named Bizqwit has a video on a Doom style engine that is pretty entertaining: https://youtu.be/HQYsFshbkYw

Cheers


e1db7f  No.34020

File: a059742a377a5d6⋯.png (484.27 KB, 646x505, 646:505, sigma2_2019-07-18_11-33-06.png)

File: 4b620e5dd2ca54d⋯.png (160.04 KB, 640x480, 4:3, Sigma Editor II (Pelles C ….png)

File: 349094615ec1e64⋯.png (32.79 KB, 800x600, 4:3, Sigma Editor II (Pelles C ….png)

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.




[Return][Go to top][Catalog][Nerve Center][Cancer][Post a Reply]
Delete Post [ ]
[]
[ / / / / / / / / / / / / / ] [ dir / agatha2 / animu / asmr / choroy / egy / randamu / vg / vichan ]