/agdg/ - Amateur Game Development General

Welp, semester over finally took the two seconds of time to add Slerp and Lerp eqs.

Plan to make everything modular and rework the graphics system.

Mainly because of

>muh vulcan

Also constantly thinking about redesigning the whole engine so it can handle multiple techniques

Also need to work on GI and server side physics so the client only has to handle graphics input and network data

why is opengl so cryptic

>>16849

vulcan will solve everything

I hope

>>16846

What is the demoscene?

Have some respect for the people who make your life so much easier by writing the damn things.

HOLY nigger shit. So deferred rendering is actually slower?

>>16846

This works well commercially

>>16996

Here's how I believe the hierarchy of fastest goes in my possibly incorrect opinion

~0-5

Forward

~5-10

Deferred

~10-50

Tiled Forward

~50-250

Tiled Deferred

~250-300

Clustered Forward

~300+

Clustered Deferred

We are talking on average in the environment.

Found out the hard way clustered is shitty for anything that isn't using a fuckton of lights-constantly; if you were to only start out with 5 lights in a clustered scene you'd notice the wide gap in FPS that you could be using for caustics etc.

>>16996

Computational throughput has advanced more than memory bandwidth, and the gap only continues to widen. Whether on the CPU or GPU, poorly written (or trivial) code can easily spend more time waiting for memory than it does performing actual work.

Deferred rendering trades reduced shader compute work (cheap firss past, only need to perform second pass once per pixel) for increased bandwidth usage (due to G-buffers being fuckhuge compared to simple color buffers).

Forward rendering trades greater shader compute work (need to run the expensive shaders potentially multiple times per pixel due to overdraw) for reduced bandwidth usage (color buffers are usually only 32-64 bits).

You do the math.

>>17130

oh and I forget to mention GLSL. to make a polygon even work you ahve to write shader code for it which is anothe rlanguage in another language. It's probably cool and all if your all comfy in university and learning this stuff in your dorm room and being chad, but to a indie dev living at moms who is desperate for money, this shit is unacceptable.

>>17130

>>17131

If you're not thirsty for performance why are you using raw opengl in the first place? Get an engine.

>>17130

>immediate mode

Just go use Python for your engine while you are at it.

>>17161

because engines have too many limitations, and constraints, I want to have the architecture for the framework to work exactly like how I want it, I've used dozens of game engines and I feel the devs are lazy with support/features or do not prefer how they implement it. There are good game engines that do it right but most of them are proprietary, so OPENGL and creating my own engine is the only way I can feel satisfied. The problem is OPENGL itself has become more difficult to use, When they were competing with directx they tried to make it more user friendly so more people would adopt it, but now that they are dominating the market with smartphones /embedded machines they have no reason to lsiten to what the users or care about ease of use because there is no other choice and we're all forced to use this shitty api.

>>17130

You are an idiot if you do not see the amazing performance boosts from the jump from archaic practices like immediate mode. Besides being far faster, it is actually simpler to use. VAO, VBO, and shaders take a little bit of time to learn just like everything else. You end up writing less lines of code and compartmentalize your graphics data into a more OOP way.

>>17130

modern opengl: upload an entire mesh (or ALL of your meshes, if you know how to batch) to a VBO, put all of your state flags into a VAO, render the whole thing at once with a single draw call

ancient opengl: spin in a loop drawing a triangle at a time. or, at best, copy the same mesh to the GPU every frame, when you could have just stuck it in GPU memory and sent a cheap draw call instead

Clearly immediate mode is superior.

>>17130

VAOs and VBOs are a godsend and not hard to understand conceptually.

Treat VBOs like std vectors and VAOs are essentially a structure of those vectors similiar to this somewhat inaccurate pseudocode

VBO{

int type;

vector data;

}

VAO{

int binding;

vector <VBO>BoundVBOs;

}

The switches will hopefully be gone with Vulkan; I've yet to wrap mine up...but if you do, they won't be a problem

Vulkan is based on OpenGL, that the point of learning it.

It won't be completely different.

Its essentially OpenGL 5 without all the fixed pipeline and states fuckery.

>>17761

Reuse similar vertex and fragment shaders when you link them together into a new program. I doubt those are 100 unique programs. Especially the vertex shader parts. Also make sure to nor load all 100 of them into memory.

>>18915

On PC? You should always try to learn the latest OpenGL. So I recommend you go with OpenGL 4.0.

Don't worry about making cooler shit with the newer versions. You can do the exact same on lower versions just with different methods.

>>18917

>buffers

>bindless textures

Granted this applies to Compute Shaders although most of the shit the new GL versions implement are more efficient

>>18915

Considering it has god damn awful vertex buffer update handling as standard, I would avoid using OpenGL 2. Look to use at least the version 3.1 API if you want to retain your sanity.

Would it be feasible to shade the actors in a scene using different techniques than the rest of the scene? Characters using cell shading while the environment is rendered more traditionally, for example.

>>21940

Yes, use different pipelines

Anyone into vulkan? been doing mostly logic/ai shit as of late

>>25661

What are the advantages and caveats of a BSP tree?

>>25740

Really easy and fast collision detection, and no Z-Buffer (although this is optional, and sometimes its faster to use a Z-Buffer)

Collision detection is the main reason to use it, its way better at that than, for example, going through every solid object in your level. Rendering is faster but only if your scenes are simple.

The disadvantage is that its hard to code and understand at first, so you'll be spending some time (a month?) learning how BSP trees work when really you could just use a Z-Buffer and go through every solid object in your level and this is much easier to program. Even though its slower and horribly inefficient to do that computers have high enough performance to handle it if your level is simple.

Heres the tutorial I used for this engine: https://www.cs.utah.edu/~jsnider/SeniorProj/BSP1/default.html

Its pretty long and complicated, and took me a while to implement.

>>25760

So, are you saying your laptop can't even run gamecube/psp tier graphics?

What kind of dinosaur are you using

>>25765

Thanks anon, seems interesting.

so how does it handle dynamic objects?

>>25356

Vulkan is literally >1k LOC to draw a triangle. You basically have to write a kernel, not as in image processing kernel, as in a fucking memory manager and scheduler.

It's meant exclusively for AAA engines.

>>25661

>>25765

I've never used BSP

For rendering this approach is archaic. Modern games use frustum culling and Early-Z.

If you need OIT then all you need is a GPU that supports atomics, though very few things actually need OIT.

For spatial partitioning oct/rectrees are entirely good enough.

>>545

'non-iso 3-d' anon?

>>27790

I would assume not using an isometric prespective

>>27787

Order Independent Transparency.

For example, looking at a mipmapped chain fence through a window, or crystals under water.

The implementations are super fancy and fun to read about. Most games just eliminate the circumstances that make it needed.

>>27742

>Vulkan is literally >1k LOC to draw a triangle. You basically have to write a kernel, not as in image processing kernel, as in a fucking memory manager and scheduler.

>It's meant exclusively for AAA engines.

Bullshit. It is >1k LOC, but that's because it doesn't hide boilerplate from you. It's not that much harder than OpenGL once you get the concepts and get it up and running. The reason OpenGL makes it easier is because OpenGL starts off with a shit-load of implicit space. Outside of the boilerplate code, Vulkan isn't much harder at all.

And it's more meant for engines than AAA games. It's a retarded thing to assume that AAA games are the only things that can leverage good performance or better standards for development.

>>27791

I'm familiar to some extent with the terms 'orthographic' and 'perspective',

https://www.blender.org/manual/editors/3dview/navigate/3d_view.html

but not really isometric. but thanks for the tip anon.

How much more/less painful would it be to exchange my shitty models & meshes with some voxel work? My GDD isn't calling for some VIP Quality work holistically.

>>27841

I am going to look these things up. its always fun to implement different algorithms.

I want to, at some point, make a software renderer (for fun) which a BSP tree would actually make sense for - or not - when i started, all I knew about rendering algorithms is that quake used a BSP tree, so maybe if my game used one, it would work? I haven't gone wrong with it yet, but that's because I haven't tried to make big open natural terrain maps like newer games can do.

>>27853

isometric prepsective is basically an orthographic prespective, as far as I can tell.

this has to do with what graphics programmers call the "perspective matrix"- basically how the program gets all the 3d coordinates and turns them into 2d coordinates in perspective so it looks 3d.

http://www.songho.ca/opengl/gl_projectionmatrix.html

dont worry about it unless you are writing your own software renderer - most API's will do this kind of thing for you, for example that link is talking about openGL

maybe I went off on a tangent with this post, sorry

>>27860

Tiled *forward* rendering? Wtf would that even do? You must not understand the purpose of tiled-deferred.

>people will run out of VRAM for framebuffer

If your framebuffer is the size of VRAM then there's no way in hell you won't be severely bandwidth limited

>MSAA uses too much memory

use a postprocess AA

>4k uses too much memory

use texture compression

>>543

two year old thread on frontpage

gud shit

>>18915

Anything that doesn't use integrated graphics and made after 2007 should be okay to use

All Macs after this period support 3.3.

The majority of Nvidia cards do.

I also assume the same for AMD

Considering the lifespan of laptops/desktops I'm sure anyone who'd buy your shit has replaced their card anyway

>>18915

Using non-core (<3.2) GL can actually cause performance issues on newer cards. The drivers aren't optimized for it.

If you don't need modern GL then why aren't you using an engine?

>>2298

Oh look, more wooden box tutorials!

wew, this board...