Game Development

Almo

02:47

:D

PearsonArtPhoto

03:03

Some padding, but I'm not convinced it's the right type. Still, will have to think on it some.

user92578

09:28

yeah padding is good, just in the wrong place :)

PearsonArtPhoto

11:48

Got it this time!

user92578

awesome!

user92578

now all you gotta do is to align the header with the contents :)

user92578

12:19

so I'm getting terrible performance from my modern renderer implementation and I'm surely doing something wrong but I'm totally unable to figure out what, or what's the "correct" way to do this

Bálint

@Tyyppi_77 Can you show the code?

I might be able to help

BTW, how modern? VBOs or VAOs?

user92578

uuuh both? VBOs bound to a VAO

Bálint

Then OpenGL 3

OpenGL 2 only had VBOs

user92578

so basically my issue is that while quad vertex positions stay constant (as I can use a model matrix to change those in the shader) texture coordinates vary

user92578

and currently I just have one VAO, with the position data as STATIC and with the texture coordinates as DYNAMIC

user92578

12:25

two VBOs that is

Bálint

Why don't you use uniforms

Those tend to load faster

user92578

uniforms for texture coordinates? is that a thing?

Bálint

Well, you only need to load the starting position and the size

It's what we do for texture atlases so..

Yes

user92578

my current approach is:
1) calculate model matrix
2) calculate new texture coordinates, use `glBufferSubData` to update it to the VBO
3) bind the VAO and use `glDrawArrays`

Bálint

Yeah, glBufferSubData is only optimal if the data is long

user92578

12:27

would it be feasible to use a matrix to transform the UV coordinates?

user92578

yeah I just need to render quads so it's very little data, four vertices

Bálint

It is, but loading two vertices (4 floats) is faster than a whole matrix (16 floats)

user92578

so I'm having a little trouble understanding how the texture coordinate uniform solution would work? how would I pass a per-vertex uniform to the shader?

Bálint

You don't

You pass the starting positon of the texture and the size

The new texture coordinate in the fragment shader will be

(UV - startingPos) / size

Again, it's what we do for texture atlases, so it can't be that bad

Alexandre Vaillancourt

@Tyyppi_77 That guy is funny :P

Whit all the protocol and such! That's refreshing.

user92578

12:46

you mean the [Comment from the question owner] stuff?

Stephane Hockenhull

@Tyyppi_77 I'd say don't use VAO. The performance increase is minimal (if any) and some drivers have bugs with it.

user92578

I'm definitely open to alternatives, this is just built on-top of some older implementation I had laying around from like a few years ago

Bálint

@StephaneHockenhull It makes drawing stuff a lot easier

Stephane Hockenhull

Yeah but some drivers crash with VAO

user92578

shouldn't it be (UV + start) / size?

Bálint

12:48

Maybe, I haven't experienced it before

Let me think

No, (uv - start) / size

Alexandre Vaillancourt

@Tyyppi_77 Yeah, and the formalities in the question (Mr Lee's TinyXML and such)!

user92578

:D

user92578

but that'll give me negative UVs, right?

Bálint

Let's go through an example

user92578

if I want the upper corner of a texture, it'd be ((0, 0) - (0.5, 0.5)) / (0.5, 0.5)

Bálint

12:50

The texture starts at (0.2, 0.2)

Stephane Hockenhull

@Tyyppi_77 Also, not all GPUs support multiple VBOs and if values are mis-aligned (if the GPU doesn't support those alignments) the driver will have to copy everything into a 2rd VBO with proper alignment every time you change one of the VBOs

Bálint

Right

Then it's uv / size + start

user92578

now that makes sense to me

Bálint

No, wait

UV * size + start

Ok, enough, I'll set up a shader

user92578

oh right yes multiplication

Stephane Hockenhull

12:53

@Tyyppi_77 You want to align vector data to its scalar size, never cross a 16 byte boundary, align vec3 like a vec4 (every 4 scalars), align vec2 every 2 scalars. You can pack data into the "4th" scalar of a vec3 if you want, that doesn't seem to bother GPUs.

Bálint

@StephaneHockenhull He's making a 2d game

user92578

sounds like a hazzle since I don't even have text rendering again (nor a well performing 2D renderer working)

Bálint

I don't think the biggest concern is performance

What's the problem with SDL BTW,

?

Stephane Hockenhull

@Bálint A color can be a vec3, or maybe using a 3D texture for tileset (vec3 UVs)

user92578

no shaders

Stephane Hockenhull

12:55

struct { float A; vec3 B;} ; // sometimes bad
struct { vec3 B; float A;} ; // GPUs I've seen seem okay with this

struct { vec3 A; vec2 B;} // bad: B crosses a 16 Bytes boundary. Some GPU drivers have to copy and re-align that.

and so on...

Bálint

Yes, but does this produce any noticeable effect in a 2d game?

Stephane Hockenhull

Depends on the number of tiles, text letters, and if you're on mobile

If you're doing an HD 2D game and you got 8100 tiles per layer and multiple layers that starts to hurt.

user92578

hmm so apparently the texture coordinate update wasn't the root cause of my bad performance
next guess is the massive amount of draw calls I'm making

Bálint

Well, first, don't render anything that's not on screen

Then try using instancing

user92578

I do have a preliminary clipper, first in the level layer where I use a QuadTree to query the tiles
then the renderer checks the coordinates before continuing

Bálint

13:02

How many draw calls do you have per frame?

Stephane Hockenhull

@Tyyppi_77 and if you're updating the entire buffer use glBufferData. The GPU driver can discard the old data and upload the new buffer before it's done drawing with the old one.

glBufferSubData forces it to make a copy first

user92578

around 1500

user92578

doesn't seem that bad?

Stephane Hockenhull

Draw calls aren't too bad if you don't do state changes. Render state changes are the killer

TexSelect(1); Draw(); Draw(); Draw(); Draw(); TexSelect(2); Draw(); Draw(); Draw(); Draw(); // not bad

TexSelect(1); Draw(); TexSelect(2); Draw(); TexSelect(1); Draw(); TexSelect(2); Draw(); TexSelect(1); Draw(); TexSelect(2); Draw(); TexSelect(1); Draw(); TexSelect(2); Draw(); // terrible

Worst if you change blend modes

if you change: blend mode, alpha test, depth test, that can cause a pipeline stall

user92578

I'm a little baffled as to why my performance sucks

user92578

13:11

I'm doing a check with my texture binding if the texture is already active to prevent any performance loss there

Stephane Hockenhull

You still want to reduce your draw calls as much as possible. But also check if you need to change render states and textures, skip the GL calls if there's no change needed

ok, do you check GL errors on every calls?

user92578

no I don't think so

Stephane Hockenhull

glGetError is a performance killer. you don't want to call that in release.

What's the hardware?

user92578

my gpu?

Bálint

Do you use batching?

user92578

13:15

no

Bálint

You should

user92578

just trying to write something really barebones at first

Bálint

I'd personally batch stuff based on the texture you use

Stephane Hockenhull

the CPU/GPU combo and OS
1.6Ghz Atom Intel HD Graphics ... or 4Ghz i5 with GTX 1080 ti ?

user92578

yeah that's what I want to do in the end but not right now

user92578

13:17

intel i5-4570 3.20GHz, GTX 750ti, Windows 10
I can play 3D games just fine

Stephane Hockenhull

hrm 1500 draw calls shouldn't kill it.

it's a lot, but it should be able to cope

Bálint

1500 quads works at 40 FPS for me

Well then, let's look at the CPU side

Do you recalculate any matrices each time you draw an object apart from the model matrix?

user92578

oh actually I do, I kinda doubt that's the issue though

Bálint

The view matrix?

user92578

view/projection, not quite sure what's the difference

Bálint

13:19

I'll tell you later

But don't, especially the projection one

That's 1500 tan functions

user92578

doesn't look like it

user92578

just an ortho projection from GLM, a few divisions and that's it

Bálint

Wait, ortho is different

Nevermind

That doesn't need to use any trig functions

user92578

yeah
I guess I could save the model matrix too? but I really wonder if that makes the difference

Stephane Hockenhull

Bálint

13:22

BTW, the view matrix brings everything in the camera's coordinate system and the projection matrix creates the 2d coordinates out of the 3d ones

user92578

ah I see

Bálint

The model matrix should be changed every frame

user92578

currently I just manually offset with the camera coordinates but I can change that once I get this working

Stephane Hockenhull

2541 render calls, 57fps, i7 2.2Ghz, GTX 560M

Bálint

Wait, you update the vertex coordinates?

user92578

13:23

no I update the model matrix' translation

Stephane Hockenhull

on every draw calls?

that shouldn't hurt, I do the same.

Bálint

The projection matrix shouldn't be recalulated each time you draw something

Stephane Hockenhull

not the projection, no

user92578

yes

user92578

I now saved the projection matrix into a member variable of the renderer

user92578

13:24

not that it made any difference

Bálint

Can you post the code of the renderer?

user92578

pastebin.com/E5qjTfJ2

user92578

some of the calculations can be moved to matrices and stuff later but that's how I did it with SDL so I don't think those cause the issues either

user92578

ApplyUniform is just an std::map lookup for the uniform location and then the corresponding glUniform call

Stephane Hockenhull

Doing this 1500 times a frame will hurt a lot:
glm::mat4 total = m_Projection * translation * rotation * scale;

user92578

13:28

ah

Bálint

Ninja'd

user92578

four uniforms or split to two?

Bálint

four

The GPU is amazing at small stuff, like multiplication

Especially vector based

Stephane Hockenhull

If you're drawing tiles you should use a custom routine to put all the tiles into a single VBO and single draw call.
You can even leave your render routine as-is that'll still cut the number of calculations dramatically.

user92578

no effect on uniform split :(

Stephane Hockenhull

13:31

But yeah, you want the GPU to be the one doing the projection * view * model matrix calculation

Bálint

@StephaneHockenhull It's probably faster to let the CPU do that with bigger models

But definitely not for quads

@Tyyppi_77 Have you tried pofiling it?

user92578

yeah, it's mainly just saying the CRenderer::Render takes a lot of frame time

Bálint

And BTW

I didn't ask this

But what's your FPS?

user92578

Stephane Hockenhull

`glDrawArrays(GL_TRIANGLE_FAN, 0, 4);` isn't what's killing it
It's all the other code around it just to draw a single quad.

user92578

13:36

this just seems really stupid, SDL's OpenGL implementation uses immediate mode AFAIK and that was just fine

Stephane Hockenhull

And m_VertexArray->Unbind();/Bind()

Bálint

There's no need for unbinding VAOs

Or anything

It's like doing

Stephane Hockenhull

Immediate mode internally batches render calls if you don't change any states

Bálint

obj1 = nullptr;
obj1 = otherObj;

Stephane Hockenhull

But you're changing shader values and a whole bunch of other OpenGL states.

user92578

13:37

oh

Stephane Hockenhull

shader->ApplyUniform("UVStart", glm::vec2(tx, ty));
shader->ApplyUniform("UVSize", glm::vec2(tw, th));

It'd be faster to just calculate that with the CPU into a VBO and re-upload than update shader uniforms.

Bálint

Would it?

I mean that's what people are doing for texture atlases

user92578

so back to what I was doing before, glBufferData on a GL_DYNAMIC_DRAW VBO?

Stephane Hockenhull

@Bálint No, they don't change uniforms for every quads drawn.

user92578

my fps is around 15

Bálint

13:39

As you only have a single VAO, try removing every bind and unbind

It should work perfectly

user92578

do I still need a bind somewhere?

Stephane Hockenhull

Changing a uniform require making a copy of all the shader's uniform data, writing the new data, and doing that for every draw calls

Bálint

Yes, before you put the data in it

Stephane Hockenhull

even shader->ApplyUniform("ShadeColor", renderDescription->GetShadeColor(), renderDescription->GetAlpha() / 255.0f);

Should be calculated as the vertex color into a multi-quad VBO instead of changing uniforms.

user92578

such a massive pain to render 2d quads

Bálint

13:44

How do you handle transparency? Discard?

Stephane Hockenhull

build a texture atlas and draw all your quads as 1 draw call, calculate all the UVs, color, vertex coordinates with the CPU

Or rather, 1 call per layer.

If the layer doesn't change you don't need to update the BG tile layer

user92578

yeah I guess that's what I'll have to do

Stephane Hockenhull

You can let the GPU translate the entire layer at once, rather than each tile.
So you don't need to re-generate the entire layer for scrolling.

user92578

yeah that makes sense

user92578

static tile layers even share the texture so it should be easy

user92578

13:46

dynamic entity layers won't be as easy though

Bálint

> How do you handle transparency? Discard?

user92578

I don't.

Bálint

Not yet?

user92578

oh okay I don't think I understand the question

Stephane Hockenhull

You can group entities : render all bullets at once, etc. as much as possible

Bálint

13:46

Do you use alpha blending or a simple discard statement in your shader?

user92578

alpha blending

user92578

yeah Stephane for sure

user92578

I was planning to do all that stuff, just later on; I really wanted to get a really straight-forward implementation running first, as then I'd have something to work on and improve upon

Bálint

14:00

@Tyyppi_77 If you don't have translucent parts, then you can simply use a discard

if (color.a == 0) discard;

user92578

14:39

aight so tile layer batching improves the performance a lot

user92578

doesn't really work yet though :)

user92578

ah can't really use a TRIANGLE_FAN anymore

Bálint

Use indexing

user92578

yeah

user92578

14:45

does the index count need to match the vertex count or does opengl automatically loop it?

Stephane Hockenhull

The index points to the vertex. You can have 4 vertices and 100000 indices pointing to those 4 vertices

user92578

oh right nvm

user92578

aww yeah this is working at 60FPS now

user92578

a minor camera position bug but otherwise it's all good

user92578

thanks a lot for the help guys, I really appreciate it

Stephane Hockenhull

14:52

np

user92578

that was actually surprisingly easy

user92578

15:18

so this is a stupid question, but what's the status quo method of flipping sprites?

user92578

just a plain sign flip of the scale moves the sprite around since it flips the whole texture

Stephane Hockenhull

uv[i] = sprite_center_uv - uv[i]

user92578

implemented with a mat3 inside the fragment shader?

Stephane Hockenhull

15:43

you could, or you can rewrite the UVs of sprites when they flip

not fragment tho, in the vertex shader

Stephane Hockenhull

19:33

Man, so many questions about "I want to be a smart-ass who violates copyright and trademark law. Will I get in trouble?"

Just about every two weeks I find one and I'm not online that often

he-man

20:04

Is it possible to completely replace the cooldown / reload time mechanic in shooters and mobas with something more DDR-like, like if you shoot or use an ability at the wrong time then you get punished in some way?

Stephane Hockenhull

it's possible. Crypt of the Necrodancer does this. It's an integral part of its gameplay

he-man

cool! How does that work?

Stephane Hockenhull

If you press an action off-beat nothing happens and you lose your combo.

he-man

That's pretty interesting. Are there any other, non-music, non-cooldown/mana cost based methods of preventing spell spamming?

Stephane Hockenhull

Minecraft makes sword attacks weaker if you spam before the cooldown expires

Bálint

20:43

@he-man Chivalry: Mediavel wafare has an interesting combo system

You only get a combo, if you hit at the end of your swings

And the more precise you are, the less energy you waste

Transcript for