Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (757)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (843)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 ... 194 195 [196] 197 198 ... 200
  ignore  |  Print  
  What I did today  (Read 2645241 times)
ClaasJG and 4 Guests are viewing this topic.
Offline theagentd
« Reply #5850 - Posted 2018-03-07 22:11:20 »

This graphics abstraction sounds pretty similar to the goals of BGFX (plus supports many more backends/platforms and has been thoroughly tested and used in high profile projects) and considering LWJGL3 now has bindings for the same, does it still make sense to roll you own? or are there other reasons for doing so?
I was aware of BGFX's existence to the extent that I knew that LWJGL had a binding for it, but I wasn't entirely sure what its purpose was just from checking the Javadocs in LWJGL. I've looked it up a bit now and it does indeed seem to have the same purpose as the abstraction I've started on. I can't make any conclusive statements about it; I'll need to look into it more, but it doesn't seem like a perfect match from what I can tell.

So far, the most glaring missing feature is uniform buffers, instead using the old uniform system which has much worse performance than uniform buffers. For example, with forward+ shading I'll be uploading a large amount of light data to uniform buffers which are then read in every single rendering shader. With uniform buffers, I can lay out and upload the data much more efficiently using buffers, bind it once and leave it bound for the entire render pass. Without them, I'll have to reupload all the uniforms for each shader that needs them with one call for each variable.

Secondly, it's unclear to what extent BGFX supports multithreading. It claims that the rendering commands are submitted from a dedicated rendering thread (so am I) to improve performance, but this is essentially what the OpenGL driver already does. I can't tell from the research I did if it's possible to construct efficient command buffers from multiple threads with BGFX. I suspect it does support that, but if it doesn't that'd obviously hold back performance quite a bit.

The biggest problem is just the entire approach that BGFX has. The level of abstraction is at the level of OpenGL, meaning that a lot of the gritty details are hidden. When I started learning Vulkan and trying to find common points between Vulkan and OpenGL, I quickly came to the conclusion that emulating OpenGL on Vulkan is completely pointless. If you try to abstract away the gritty details like image layouts, descriptor sets, multithreading, uniform buffers, etc like OpenGL does, you're setting yourself up for essentially writing a complete OpenGL driver. The problem is that it's going to be a generic OpenGL driver that has to manage everything in suboptimal ways, instead of an actual dedicated driver for the specific hardware you have, and seriously, you're not gonna be able to write a better driver than Nvidia for example.

The key thing I noticed was that it's a really bad idea to emulate OpenGL on top of Vulkan, but emulating Vulkan on top of OpenGL is actually super easy. Emulating descriptor sets on OpenGL is super easy and you can keep a lot of the benefits of descriptor sets. Image layout transitions can just be completely ignored by the abstraction (the OpenGL driver will of course handle that for us under the hood). We can emulate command buffers to at least get some benefit by optimizing them on the thread that compiles them. In other words, writing a Vulkan implementation that just delegates to OpenGL is easy. Writing an OpenGL implementation that delegates to Vulkan, oh, have fun. Hence, if you expose an API that requires the user to provide all the data needed to run the API on Vulkan/DirectX12/Metal, adding support for anything older like OpenGL is trivial.

Myomyomyo.
Offline Spasi
« Reply #5851 - Posted 2018-03-07 23:04:22 »

So far, the most glaring missing feature is uniform buffers, instead using the old uniform system which has much worse performance than uniform buffers.

See #1231.

Secondly, it's unclear to what extent BGFX supports multithreading.

The build that ships with LWJGL supports up to 8 threads (the default) submitting draw calls. See the encoder API (bgfx_begin, bgfx_encoder_*).

Hence, if you expose an API that requires the user to provide all the data needed to run the API on Vulkan/DirectX12/Metal, adding support for anything older like OpenGL is trivial.

Apparently, after MoltenVK, Khronos will be working on Vulkan emulation libraries on top of Direct3D 12 and OpenGL. So, if anyone's planning to learn Vulkan seriously, eventually it will be a pretty good investment. If you don't have the time for that and just want to get robust results quickly, bgfx is a very good choice for targeting GL/D3D12/Metal.
Offline theagentd
« Reply #5852 - Posted 2018-03-11 15:19:56 »

So far, the most glaring missing feature is uniform buffers, instead using the old uniform system which has much worse performance than uniform buffers.

See #1231.
From that GitHub issue:
Quote
GL UBOs are conceptually the same as constant buffers in D3D. Internally bgfx does use constant buffers, but it assigns only used constants. shaderc does strip unused constants and makes more compact constant buffer. This behavior matches what old-GL style does it. So from user point of view this is better/more desirable behavior, where you just don't care about packing things. In the future I'll add per view and per frame uniforms, which will be set at different frequency than per draw uniforms. Some GL implementations implement UBO (can't find blog post about this) as driver internally calls bunch of glUniform. I haven't tested this myself, but having tested some other GL features that were also promising huge gains, I believe it. Anyhow, bgfx is not 1:1 wrapper to lower level APIs and there will be always some differences how things are handled on high-level.

Imagine you want to draw 300 3D models in your game.  The vertex and index data are all in shared buffers and they all use the same shader and same textures, but a single uniform vec3 for the position offset of each model is changed inbetween each call to place each model at the right position. You also have a large number of uniforms for controlling lighting (essentially arrays of light colors, positions, radii, shadow map matrices, etc), but these are of course set up once. You essentially have code that looks like this:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
//Upload lighting data
glUniform3fv(lightColorsLocation, 100, ...);
glUniform3fv(lightPositionsLocation, 100, ...);
glUniform1fv(lightRadiiLocation, 100, ...);
glUniformMatrix4fv(shadowMatricesLocation, 100, ...);

for(Model m : models){
    glUniform3f(positionOffsetLocation, m.getX(), m.getY(), m.getZ());
    glDrawElementsBaseVertex(...);
}


This will perform so bad it's not even funny, and it's easy to explain why. GPUs do not have support for "uniform variables". They source uniform data from buffers, either in RAM or VRAM. This means that the GPU will create a uniform buffer layout for us based on the defined uniforms in our shader and place our data in a buffer. Great, no problem. We end up with a buffer that has the light colors, positions, radii and shadow matrices... and then the position offset. Then we change the position offset inbetween each draw call. The problem is that the GPU hasn't actually executed those commands yet, so we can't write over our previous uniform data. Because of that, the driver will create a full copy of the entire uniform buffer, including all the light data, giving each draw call its own version of the uniform buffer, with only the position offset actually differing between them. This leads to a lot of hidden memory usage within the driver, horrendous CPU performance (spiking on either glUniform3f() as it allocates a copy each time, or on buffer swapping if a multithreaded driver is used). The fact that all the uniform variables are placed in the same buffer makes it impossible to change a few of them without making an entire copy.

This is what the Nvidia driver does, and the exact problem I got working on Voxoid for Cas... except in my case, I already had my massive lighting data in a (manually created separate) uniform buffer. The only thing being copied around where the per-scene/per-camera attributes like fog uniforms and camera matrices, and even then, that copying was enough to completely kill CPU performance. The above example would probably drop below 60 FPS around ~100 draw calls or less.

Sure, bgfx could try to add some heuristics to this whole thing to try to figure out the update rate of different uniforms and assign them to different uniform buffers that can be swapped individually... aaaaand before you know it you have an inefficient as f**k behemoth that uses heuristics for which uniforms to place in which uniform buffers, more heuristics to figure out whether to place the buffer in RAM or VRAM, and even more heuristics detect arrays of the same size and group them into structs for memory locality, and now the user has to train the heuristics to not bork out and max out the RAM of your computer for anything more complex that the most trivial possible use of uniforms, the whole engine crashes when it tries to use more than the maximum number of uniform buffers, etc. You've just created an unholy mess that has much worse performance due to the overhead of running the heuristics calculations even for well-written code, and you got crazy amounts of bugs and spaghetti interaction between seemingly unrelated things. Hmm, what does that remind me of...? Right, OpenGL. None of these are exaggerations either, by the way. Do anything at all unconventional with buffer object mapping/updating on the Nvidia driver and you'll start to see all kinds of cool colors and shapes floating in front of you as you feel the sweet LSD overdose kick in which you took trying to deal with the fact that your buffer object test program performs completely differently depending on which order you test the different methods in, and one order semi-reliably causes a massive memory leak in the driver, but I digress. (disclaimer: don't do drugs)

All this because to avoid having the user having to lay out the data and upload it to a buffer him/herself.


EDIT: In the above case, I solved it by completely getting rid of the glUniform3f() call by placing the data in a per-instance vertex attribute buffer, and using base instance to pick a value for each draw call. This would of course have solved the issue for bgfx as well in this case, but even then, the uniform buffer approach is vastly superior. If each of those models would need a different shader, you'd have to recall the uniform setters after each shader switch, and OpenGL/bgfx would still need to duplicate the light data for each shader. With uniform buffers, you could just leave the uniform buffer (or the Vulkan descriptor set) bound and it all just works out with absolutely no additional cost.

EDIT2: An additional benefit of uniform buffers is the ability to do arrays-of-structs instead of structs-of-arrays, which should have better memory locality.

EDIT3:

Myomyomyo.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline SkyAphid
« Reply #5853 - Posted 2018-03-11 18:54:31 »

...And that's how NNGINE saved Christmas lol

it just werks
Offline Spasi
« Reply #5854 - Posted 2018-03-12 08:18:22 »

300 3D models.. all in shared buffers and they all use the same shader and same textures.. a large number of uniforms for controlling lighting

This is a very specific rendering scenario, it's anything but typical. I'd never expect bgfx to be useful to you, but not everyone does deferred/forward+ shading with hundreds of lights.

Because of that, the driver will create a full copy of the entire uniform buffer, including all the light data, giving each draw call its own version of the uniform buffer, with only the position offset actually differing between them.

I don't have a reason to dispute that, sounds reasonable. But also like something that a clever driver would trivially optimize (does it really have to use a single uniform buffer for everything internally?). Could you post a source that verifies the above?

aaaaand before you know it you have an inefficient as f**k behemoth that uses heuristics for which uniforms to place in which uniform buffers

Yeah, bgfx doesn't do anything like that internally, it's a fairly simple abstraction over the low-level rendering APIs. I wouldn't be surprised if graphics drivers used such heuristics though (see above).

by placing the data in a per-instance vertex attribute buffer

Yes, that's what bgfx does for instancing. That's also what I was doing ~10 years ago, back then UBOs/TBOs were generally a bad idea on all drivers/GPUs iirc.

Anyway, bgfx's developer has acknowledged that better support for UBOs is necessary and it's coming soon. There will be support for uniforms that are updated at different granularities (per-frame, per-view, per-draw), with the appropriate backend-specific implementations. Also, this all applies to Linux only, you wouldn't use the OpenGL backend on Windows/macOS (D3D11/12 & Metal respectively).
Offline abcdef
« Reply #5855 - Posted 2018-03-12 14:13:27 »

What do you mean you wouldn't use the opengl backend on windows?
Offline Spasi
« Reply #5856 - Posted 2018-03-12 14:24:02 »

What do you mean you wouldn't use the opengl backend on windows?

bgfx defaults to using Direct3D 11 on Windows, but you can force it to use one of the D3D12/D3D9/GL/GLES backends. Vulkan will also be supported in the future. What I mean is that, given the choice, there's no good reason to prefer OpenGL on Windows over D3D/Vulkan.
Offline Sickan
« Reply #5857 - Posted 2018-03-12 21:39:44 »

Got distracted building my ui interface, in my quest to get a rounded rectangle I ended up building a new vector graphics engine which has a nice triangulation routine to triangulate any shape (convex, concave, single hole, many holes). Also allowed me to do some nice gradient shading / texturing on any shape.

I'd be very interested if you'd like to share that code! Smiley
Online ClaasJG

JGO Coder


Medals: 42



« Reply #5858 - Posted 2018-03-12 22:21:37 »

I rewrote my 'asset-pipeline' configuration. I had to write nasty json files by hand in the past and now use Jsr223.

This allows me to write simple things like this:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
def hexOrigin(sprite){ sprite.setOrigin(sprite.width / 2, sprite.width / Math.sqrt(3))}

createTile("tiles/dirt"){
    sprite = createSprite("tiles/dirt-sprite", file("Dirt.png")){ hexOrigin(this) }.tag
}
createTile("tiles/dirt_full"){
    sprite = createSprite("tiles/dirt_full-sprite", file("Dirt_Full.png")){ hexOrigin(this) }.tag
}
createTile("tiles/grass"){
    sprite = createSprite("tiles/grass-sprite", file("Grass.png")){ hexOrigin(this) }.tag
}
createTile("tiles/grass_full"){
    sprite = createSprite("tiles/grass_full-sprite", file("Grass_Full.png")){ hexOrigin(this) }.tag
}


and automaticly convert them into 'my old format':
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
[...]"tiles/dirt": {
      "class": "Tile",
      "sprite": "tiles/dirt-sprite"
   },
   "tiles/dirt-sprite": {
      "class": "Sprite",
      "width": 65,
      "height": 89,
      "originX": 32.5,
      "originY": 37.52776749732568,
      "ingameWidth": 1,
      "file": "tiles\\Dirt.png"
   },[...]


Everything with a neat gradle plugin, dependency/reference checking error messages when some constraints are not holding aso.
-ClaasJG

My english has to be tweaked. Please show me my mistakes.
Offline abcdef
« Reply #5859 - Posted 2018-03-13 13:44:17 »

Got distracted building my ui interface, in my quest to get a rounded rectangle I ended up building a new vector graphics engine which has a nice triangulation routine to triangulate any shape (convex, concave, single hole, many holes). Also allowed me to do some nice gradient shading / texturing on any shape.

I'd be very interested if you'd like to share that code! Smiley


It's hard to give you access to all the code but I can tell you the general principals

1) The triangulation for the filling of the shapes was based on "Sweep-line algorithm for constrained Delaunay triangulation" by V. Domiter and and B. Zalik
2) The stroke drawing was just basic LINE_LOOP of the various contours provided
3) The drawing of shapes was done using a similar api that we go uses but adapted to be easier to use in my opinion. you have a shape which can have many closed contours, you can line to somewhere, beside to somewhere, create circles, ovals, rectangles, rounded rectangles etc.
4) This data feeds the algorithm and you get a list of triangles finding out which uses all your point (nomore are created).
5) when you get the triangles I find a bounding box then calculate texture coordinates for all points and then use this for filling with either a texture, a single colour or a gradient colour.
6) I don't have anti aliasing yet but will add later one I have built all my ui components
7) my ui components can be drawn with the vector api

That's basically it, it looks pretty cool and you have lots of holes in a shape and it textures perfectly around it
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Longarmx
« Reply #5860 - Posted 2018-03-15 17:21:24 »

The last couple days, I added global variable support and while loops to a compiler I've been working on. It compiles a "miniC" language to mips32. So, this code:
1  
2  
3  
4  
5  
6  
7  
8  
9  
// Declare and assign variables
my_var = 2;
counter = 10;
// Perform some operations
while(counter = counter - 1) {
    my_var = 2 * my_var;
}
// Print it out
print my_var;

compiles to this:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
.data
counter: .word 0
my_var: .word 0
.text
li $t1 2
la $s1 my_var
sw $t1 0($s1)
li $t2 10
la $s2 counter
sw $t2 0($s2)
while_top_1:
lw $t3 0($s2)
li $t4 1
sub $t3 $t3 $t4
sw $t3 0($s2)
beq $t3 $zero while_end_1
addi $sp $sp -4
sw $t4 0($sp)
li $t4 2
lw $t5 0($s1)
mul $t4 $t4 $t5
sw $t4 0($s1)
j while_top_1
while_end_1:
addi $sp $sp -4
sw $t5 0($sp)
lw $t5 0($s1)
li $v0 1
add $a0 $zero $t5
syscall
li $v0 11
li $a0 10
syscall

and prints
1024

This has been a really exciting project so far. If you want to view the code, here is the github.

Offline theagentd
« Reply #5861 - Posted 2018-03-18 01:05:15 »

Had my last uni exam today. Now I only have one more left this summer and I'm done with uni.



Decided to have some fun and coded a super simple ok, maybe not that simple Falcon 9 FT rocket launch simulator in 2D. I've inputted the following data in SI units:

 - Earth's radius and mass
 - Earth's rotation and the "bonus" horizontal velocity gotten by launching from Cape Canaveral
 - Earth's atmospheric density approximated with an exponential function of height over ground

 - Target orbit altitude (400 000m Low Earth Orbit, just under the ISS) and the exact velocity needed to maintain that orbit

 - Rocket drag area (circle of radius 2.6315m) and approximated drag coefficient (0.25)

 - The following parameters for the two Falcon 9 FT stages:
    - Weight without fuel (22 tons, 4 tons)
    - Weight of fuel (410.9 tons, 107.5 tons)
    - Thrust (~8 000 000 N (actually 7 607 000 to 8 227 000 depending on altitude), 934 000 N
    - Burn time (162 sec, 397 sec)



The rocket is then assumed to rotate from 0 to 90 degrees over the course of the flight (you never want to point a rocket downwards or you will not go to space today), and this rotation is controlled using a Taylor series controlling the rotation. This allows the rocket to rotate at different rates at different parts of the flight. Basically, this allows the first stage to go more straight up to quickly get out of the thickest part of the atmosphere, and then quickly rotate over to the side to gain orbital speed as efficiently as possible. The Taylor constants are decided using a simple learning algorithm that tries to get rid of the error in altitude and orbital speed/direction. However, if the thrust is simply too high, the rocket will get a too high orbital velocity, so I also added the payload weight as a parameter, so if the rocket overshoots, I just add more weight to it. Also, the rotation of the Earth is taken into consideration, and the drag is calculated (approximately) based on the idea that the atmosphere rotates with the planet (so the rocket starts out travelling at around 408m/s together with the surface, but has zero drag since the air is rotating too).

The learning algorithm just tries random modifications to the taylor constants and the payload weight and checks if the result is a better end orbit than before (= lower error in altitude and orbital speed/direction), and given time it converges on the perfect settings for launching the rocket. After running the program for around 10 minutes and changing the learning rate as it went, I got the calculated error down:
 - -9.909272E-7 meter error in altitude
 - 6.1378614E-8 m/s error in velocity away from the Earth
 - -1.3683348E-8 m/s error in orbital velocity

In other words, the resulting orbit is off by less than a micrometer, and the velocity is off by even less than that. The maximum payload was determined to be 21843.23 kg, which is a bit lower than the payload the Falcon 9 FT is rated for, 22 800kg payload (possibly plus 1 700 kg, not sure if those 1.7 tons are included in the 22 800 number), but at least close enough to be in the same ballpark. Considering it's a 2D simulation I made with information I could Google in a couple of minutes, it's pretty cool.

Image of the trajectory:



The curve at the start comes from the fact that the planet is rotating, so the rocket starts with a high speed to the left but accelerates upwards. The color of the trajectory shows the two stages and how they deplete their fuel (which of course causes the rocket to get MUCH lighter over the course of the flight). Once the first stage is depleted, it instantly switches to stage 2 at which point stage 1 is jettisoned and no longer adding weight to the rocket. It would be possible to add a zero-thrust stage inbetween to add some time for the stage separation. No, the first stage doesn't fly back and land. =P



Some people go out drinking to celebrate, I write rocket simulations...

Myomyomyo.
Offline Longarmx
« Reply #5862 - Posted 2018-03-18 01:18:34 »

No, the first stage doesn't fly back and land. =P

Ah, but that would be quite fun to watch the simulation calculate the first stage's trajectory!

Also, how many terms are in your Taylor expansion? And do you just evaluate it with a time since launch or some other variable?

Offline theagentd
« Reply #5863 - Posted 2018-03-18 01:50:25 »

Also, how many terms are in your Taylor expansion? And do you just evaluate it with a time since launch or some other variable?
I used 8 coefficients there, but even 3 can sometimes suffice; it depends on the parameters of the simulation. Yeah, I calculate x = (1 - currentTime/totalTime), use x, x^2, x^3, etc with the taylor coefficients and finally do angle = (1.0 - sum) * Math.PI/2 to get the thrust angle. Since my only real requirement is that the sum is 0 at the start and 1 at the end, I just make sure that the coefficients sum up to 1.0 and that handles it.

Myomyomyo.
Offline FabulousFellini
« Reply #5864 - Posted 2018-03-18 18:03:06 »

I got an isometric tilemap working.  I dunno why the camera cuts off the bottom sometimes but I'll figure it out. 

<a href="http://www.youtube.com/v/RCvznbMR41w?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/RCvznbMR41w?version=3&amp;hl=en_US&amp;start=</a>

-FabulousFellini
www.fabulousfellini.com
Offline nsigma
« Reply #5865 - Posted 2018-03-20 10:09:37 »

Well, strictly speaking yesterday's fun hack - decided the Electron framework wasn't bloated enough so added a JVM into the mix!  Grin

Apache NetBeans HTML4J and Dukescript examples running on the JVM and rendering in an Electron Chromium window.


Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline philfrei
« Reply #5866 - Posted 2018-03-20 19:08:42 »

First ever receipt of a donation for software I posted on GitHub, this morning!

music and music apps: http://adonax.com
Offline chrislo27
« Reply #5867 - Posted 2018-03-21 03:26:29 »

It's been a really long time since I've returned to this site. Always good to see familiar faces while browsing around!

I guess for what I did today, I released v3.8.0 of the Rhythm Heaven Remix Editor. Nothing much; it's just a side project I work on using Kotlin and libGDX. (Many people have told me how bad of an idea it was to use libGDX for a UI-heavy program, and I fully agree with them! Grin)

Anyways, I hope to poke around again sometime. If I ever get back into game dev I'll be sure to help out where I can!
Offline nsigma
« Reply #5868 - Posted 2018-03-21 11:16:15 »

I guess for what I did today, I released v3.8.0 of the Rhythm Heaven Remix Editor.

Looks great!  Good seeing projects shipping with libraries I wrote too.  Not that you seem to be using them!  Wink

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline cygnus
« Reply #5869 - Posted 2018-03-22 02:07:50 »

After many months of redoing and reworking systems to make them easier to use, I have finally got resource nodes (points on the level where resources are inputted or outputted) and block templates working. The result is a way of creating block templates that I personally love:

God I love Kotlin.
Here's what the now functional miners and tubes look like:

I also fixed a lot of bugs with resource nodes and began work on crafter blocks.
Offline ags1

JGO Kernel


Medals: 367
Projects: 7


Make code not war!


« Reply #5870 - Posted 2018-03-26 10:47:26 »

Been getting slowly back into Vangard. As a first step I am cleaning up the old code for the TreeML asset file markup language and adding a ton of test cases to it. I have a single test class that iterates through a bunch of test files which have tags showing what is expected from the test: whether parsing is expected to fail or succeed, what the expected node structure is post-parse, and then a bunch of xpath-like expressions that have to evaluate to true for the parsed document.

A typical test file looks like this (the structure string is a list of indentDepth:typeOfValue; groups):

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
#result::ok
#structure::1:1;1:2;1:1;2:1;2:1;3:1;3:1;2:0;1:1;
#eval::e1(2)='v12'
#eval::*[1](2)=e1(2)
#eval::*[:'v2'].f1.*[1]='vg1'
{
    e0 : v0
    e1 : v10, v11, v12, v13, v14
    e2 : v2 {
        f0 : vf0
        f1 : vf1 {
            g0 : vg0
            //comment
            g1 : vg1
        }
        f2 : null
    }
    e3 : v3
}


After I have got TreeML better than JSON I will flip to a new method to make the behaviors of Vangardians more deterministic and debuggable. Currently their heads are filled with a free-for-all cloud of competing behaviors, but now I will structure and classify the behaviors to help them pick the most sensible options. I will build a no-GUI sim of the new of the new logic then backport it into the game.

Offline princec

« JGO Spiffy Duke »


Medals: 1033
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #5871 - Posted 2018-03-26 10:53:09 »

You should have a go with my thjson library, ags1 Smiley

Cas Smiley

Offline ags1

JGO Kernel


Medals: 367
Projects: 7


Make code not war!


« Reply #5872 - Posted 2018-03-26 10:59:37 »

@princec I like your idea to include binary data values. Will copy that shamelessly. Smiley

Offline Guerra2442

JGO Coder


Medals: 50
Exp: 3 years


Guerra24


« Reply #5873 - Posted 2018-03-29 05:24:26 »

Rewrote the threading system from scratch with new 2-2 threads (main - background, render - background) and 2 extra when more control is need over the task. It became unstable as hell because some code doesn't like the thread where it runs now, the good side is that there is little to no input lag and assets can be loaded in the background.

Working on Light Engine.
Offline CoDi^R
« Reply #5874 - Posted 2018-03-29 09:02:03 »

Rewrote the threading system...

Yep, threading is fun. Found a race condition in our asset loader thread yesterday, which happened *occasionally* to the other coder on the project. I've never been able to reproduce on Windows or Mac OS. Tried to test and debug an unrelated feature on Ubuntu, and lo and behold, bug triggered every other run.

Robotality - steamworks4j - @code_disaster - codi^r @ #java-gaming
Offline ags1

JGO Kernel


Medals: 367
Projects: 7


Make code not war!


« Reply #5875 - Posted 2018-03-31 08:44:26 »

Put my cleaned up version of TreeML on GitHub, including schema language and validation.

https://github.com/agnes1/TreeML

Offline Guerra2442

JGO Coder


Medals: 50
Exp: 3 years


Guerra24


« Reply #5876 - Posted 2018-04-02 08:30:24 »

Started porting the engine to OpenGL ES, implemented a simple abstraction layer to use the same code regardless of the api and got the ui and resource loader fully working. Also changed the compositor rendering, instead of a double-buffer effect accumulator now uses per-effect buffer, this fixes issues with effect passes not working correctly.

        Old                           New
       
                           Old                                                                        New
         

Working on Light Engine.
Offline KaiHH

JGO Kernel


Medals: 520



« Reply #5877 - Posted 2018-04-02 17:47:03 »

Played a bit with implementing 2D shadow mapping in OpenGL using an approach I could not find elsewhere, which came to my mind before doing research on existing approaches, but after I read about the "analytical" solutions such as this one:
- create four 1D depth textures as array texture (width is something like 512 texels)
- render the depth of the four sides of an omnidirectional point light into these four depth textures with a single draw call by using layered rendering
- use standard depth comparison in the final shadow mapping shader, selecting the correct 1D depth texture to use based on the quadrant of the light direction
Result:
Offline dime26

JGO Ninja


Medals: 65
Projects: 7
Exp: 12 years


Should traffic wardens be armed?


« Reply #5878 - Posted 2018-04-03 00:37:19 »

Finished off a blog post I started weeks ago about simple weapon movement; a gun that looks at the mouse and flips right/left:

https://carelesslabs.wordpress.com/2018/04/03/nuclear-throne-style-weapon-movement-libgdx-gamedev/

Click to Play
Online NuclearPixels
« Reply #5879 - Posted 2018-04-04 21:01:23 »

Not today, but lately was working on adding some "volume" to the game.. Going to focus now on fixing some glitches and might be releasing another alpha version before advancing with better graphics.


CERN-based beginner game devs. Follow us on Twitter: https://twitter.com/NuclearPixels
Pages: 1 ... 194 195 [196] 197 198 ... 200
  ignore  |  Print  
 
 

 
EgonOlsen (39 views)
2018-06-10 19:43:48

EgonOlsen (21 views)
2018-06-10 19:43:44

EgonOlsen (42 views)
2018-06-10 19:43:20

DesertCoockie (187 views)
2018-05-13 18:23:11

nelsongames (122 views)
2018-04-24 18:15:36

nelsongames (121 views)
2018-04-24 18:14:32

ivj94 (862 views)
2018-03-24 14:47:39

ivj94 (123 views)
2018-03-24 14:46:31

ivj94 (758 views)
2018-03-24 14:43:53

Solater (140 views)
2018-03-17 05:04:08
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!