[ / / / / / / / / / / / / / ] [ dir / futa / hisrol / lewd / loomis / pdfs ]

/agdg/ - Amateur Game Development General

AGDG - The Board
Winner of the 75nd Attention-Hungry Games
/caco/ - Azarath Metrion Zinthos

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

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:


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


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.


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


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


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


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


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


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


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


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


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.


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


>Native loonix support


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


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


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.


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)


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)


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)


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){
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_LOD,picmip);
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


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


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


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


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.



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


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


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)


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


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


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.

[Return][Go to top][Catalog][Nerve Center][Cancer][Post a Reply]
Delete Post [ ]
[ / / / / / / / / / / / / / ] [ dir / futa / hisrol / lewd / loomis / pdfs ]