Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411507 Posts in 69374 Topics- by 58429 Members - Latest Member: Alternalo

April 26, 2024, 06:14:38 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)What are you programming RIGHT NOW?
Pages: 1 ... 66 67 [68] 69 70 71
Print
Author Topic: What are you programming RIGHT NOW?  (Read 210150 times)
oahda
Level 10
*****



View Profile
« Reply #1340 on: December 28, 2016, 02:15:02 AM »

how dare you come here and literally blast my amazing cube away with that : (
Logged

_glitch
Guest
« Reply #1341 on: December 28, 2016, 05:12:27 AM »

Currently playing around with binary serializers for save states.
Logged
gornova
Level 0
***


View Profile WWW
« Reply #1342 on: December 28, 2016, 07:42:07 AM »

I'm working on a decent ai for a turn based 4x game
Logged

Blog | Last game Number+
gamepopper
Level 0
***



View Profile WWW
« Reply #1343 on: December 28, 2016, 03:00:42 PM »

I'm currently working on my roguelike shooter, C++ with SFML. I've been dabbling with OpenGL again since my game has some 3D graphics mixed in with the 2D gameplay.
Logged



oahda
Level 10
*****



View Profile
« Reply #1344 on: December 28, 2016, 03:18:30 PM »

Progress! Model loading (a simple, incomplete OBJ loader I borrowed), textures, lighting and the main attraction of this particular GIF, render textures!



Also refactored the code a bunch from that original cube example which was all in one file and now have some dozen classes for various types of meshes, textures, scene, camera, entity and so on (only to make it easier to work with—before I put what I've learned into my engine I'll rewrite it according to the engine's conventions anyway). c:
Logged

JWki
Level 4
****


View Profile
« Reply #1345 on: December 29, 2016, 06:11:38 AM »

In case you haven't noticed by now, your use of vertex array objects seems a bit weird to me as you're binding a vertex array object as well as explicitely binding vertex buffers and vertex attribute state - vertex array objects are supposed to contain that state so all you have to do when using a specific buffer/attribute combination is to bind the vertex array containing those bindings instead of rebinding everything all the time.

Logged
oahda
Level 10
*****



View Profile
« Reply #1346 on: December 29, 2016, 06:20:07 AM »

Yeah, I did something like that last time, packing everything into one long array with offsets instead of using separate ones. The problem is that every tutorial says different things, and I find new, contradicting views every time I look into OpenGL... I do have the red bible tho, so maybe I should just read that... /: Unless you can link me some reading you'd recommend.

(did you mean to say VBO instead of VAO in some places in what you wrote, because it reads a bit confusingly right now?)

EDIT:
I found some reading and I think I get what you mean. I do set it all up correctly, but you mean I'm not supposed to bind all the buffers again when rendering, right? Only the VAO should be enough. But how does the shader know how to map what's in the VAO? Will it be in the order I added each buffer to the VAO, so that I'll have to use the layout keyword in the shader for every fragment input and index them correctly?
« Last Edit: December 29, 2016, 06:36:17 AM by Prinsessa » Logged

JWki
Level 4
****


View Profile
« Reply #1347 on: December 29, 2016, 06:49:54 AM »

No I meant VAO everywhere I wrote it.
So, I wasn't talking about having all vertex attributes in a single buffer - that's called interleaving and you SHOULD do it for all attributes that have the same frequency of changing values. So for all stuff that's constant, have a buffer with all the attributes interleaved (vertex positions, UVs, colors, etc), and additional buffers for stuff that might change, like skinning matrices.

What I'm talking about is the following - you have a vertex array object, and I assume you create and store one for each mesh that you have from the code you posted. You also have one or several vertex buffers, it doesn't really matter how many.
Now, you correctly setup bindings between vertex attributes and the buffers to source the data from using glVertexAttribPtr, HOWEVER, you do it every time you draw something. Now, the purpose of a vertex array object is to STORE that binding information, so you can switch between different configurations by just changing the vertex array object binding. This is theoretically faster and also better stilistically.

So instead of going, in each draw or update method

Code:
glBindVertexArray(m_IDVAO);
glEnableVertexAttribArray(m_attrPos);
glBindBuffer(GL_ARRAY_BUFFER, m_IDVBO);
glVertexAttribPointer(...)

(....and so on)

You can just do that ONCE, after creating all the buffers, and then in your update or draw or whatever you have, for each draw call, just go


Code:
glBindVertexArray(m_IDVAO);
glDrawElements(GL_TRIANGLES...);

and that's it. No rebinding required.

You'll still have to bind the element array buffer individually though.

On the topic of tutorials, they're all shit. Well, most of them. The ONLY tutorials on OpenGL that I can recommend are those:

https://learnopengl.com/
https://open.gl/
http://www.opengl-tutorial.org/

In that order. The first one actually covers everything you need, and better than the other two in my opinion. EVERYTHING ELSE is deprecated bullshit that you should never read.
ESPECIALLY not the red book.

Problem is, most OpenGL tutorials, including the famous NeHe stuff that everybody followed back in the day, are just teaching deprecated stuff that you should never do anymore. Actually, even those I posted above teach deprecated stuff, but it's still reasonable to use.
Personally, I recommend not ever again using ANY API below OpenGL 4.5 - because 4.5 is where the API starts to kinda get more concise if you really throw out everything else. So OpenGL4.5 Core is what I personally use exclusively to stay more or less sane.
However that's not an option for you because Apple decided to ditch support for everything above 4.1 so there you go.

If any of the above still is confusing, what I'd find understandable because it's more of a rambling, feel free to ask.
Logged
JWki
Level 4
****


View Profile
« Reply #1348 on: December 29, 2016, 06:56:06 AM »

Also I just saw your edit and couldn't be bothered to edit my own post so...

The location issue is what glEnableVertexAttribArray and glVertexAttribPointer are for, they setup a binding between the currently bound array buffer and whichever attribute binding slot you choose to input, and you can either use the layout qualifier in glsl to specifiy those slots and just match those values or you can poll the values via glGetAttributeLocation.

Use the layout qualifier. glGetAttributeLocation does nasty things sometimes.
And it's good to get used to having conventions for what data goes where.
Logged
oahda
Level 10
*****



View Profile
« Reply #1349 on: December 29, 2016, 07:07:16 AM »

Yeah, I figured it out while you were writing, hah. Found some good reading after all.

Thanks for the explanation and the links. c: This is why I figure it's always good to share stuff like this online. Appreciate it!

What stuff is it about glGetAttributeLocation() that can be bothersome?
Logged

darkhog
Level 7
**


Dragon Agent


View Profile
« Reply #1350 on: December 29, 2016, 07:15:13 AM »

Right now, I'm improving level editor for my game, Computer Virus Simulator (click the logo in the description to go to the devlog) where YOU ARE A COMPUTER VIRUS.
Logged


Be a computer virus!


I cannot C well, so I stick with simpler languages.

There are no impossible things, there is only lack of skill.
JWki
Level 4
****


View Profile
« Reply #1351 on: December 29, 2016, 07:18:42 AM »

glGetAttributeLocation is bothersome because it sometimes on some drivers returns plain wrong values.
It used to at least.

Also I'd recommend just using explicit layout qualifiers for EVERYTHING - including samplers, uniforms, etc, instead of using the query functionality. It eliminates overhead, having conventions is a good thing anyways and it makes it easier to autogenerate shaders because at some point you'll want to integrate this into your engine and you surely don't want to write out all built-in attributes and uniforms and stuff every time you write a new shader so it's likely the engine or some tool will do that for you and that tool can then also just inject the locations.
Logged
oahda
Level 10
*****



View Profile
« Reply #1352 on: December 29, 2016, 07:31:13 AM »

Yeah, we'll have to see what makes sense in the end. The whole point of this is to mess around in a separate project and learn stuff and stumble into all the pitfalls before I actually integrate anything into the engine, so. c:

BTW, since glGetAttributeLocation() is separate from glGetUniformLocation(), that means explicit locations in GLSL don't overlap for ins and uniforms, right? I can assign both an in variable and a uniform variable location 0 without clashing?
Logged

JWki
Level 4
****


View Profile
« Reply #1353 on: December 29, 2016, 07:34:36 AM »

Yes, attributes and uniforms use different namespaces so to say.
Samplers should also be able to use duplicated locations with other uniforms but I'm really unsure about that right now so better check on it.
Logged
oahda
Level 10
*****



View Profile
« Reply #1354 on: December 29, 2016, 08:29:35 AM »

Well, I have to say that the locations instead of named attributes and the need not to bind buffers more than once also made the code a lot nicer and cleaner! My only worry is portability and compatibility. We'll have to see. I guess I'll try and organise my code in such a way that it won't be a pain to revert to named attributes if I have to.

Don't know if that's possible when rendering to multiple textures tho, which I've done a lot in my deferred rendering pipelines before—is specifying out locations the only way, or can it be done some other way too?



Another question... So OpenGL prefers its textures to be "upside down" compared to most other systems in order to be consistent with the 3D space and so on. That's fine by me, but I wonder what the best way to go about it is, especially when I want the data to work even if I shift to, say, DirectX on some other system.

Since render textures are rendered "upside down" I decided to also flip images vertically when I load them into the program to be consistent (something I saw suggested online), and then flip the UV's y/t value in the shader to make all textures appear correctly, which is fine since GLSL falls under OpenGL-specific code anyway and shaders too would've to be rewritten for DirectX or whatever.

But the weird thing is I do 1.0 - uv.t not to break clamping, which works fine for meshes I've assembled programmatically myself (my cube and plane) but not for the ones loaded from OBJ files, which need -uv.t to appear correctly, and I've only solved this in a way similar to the way I solved loaded textures, which was to modify the UV's as I load the file.

It all works, but is there a different way I ought to be doing it? Note that this is mostly to make render textures work with regular textures in a consistent way. If I didn't use those, everything would've worked just fine unaltered. But I figure it's actually good practice to give OpenGL data the way it expects anyway (i.e. "upside down" textures et c.) which at least one person on a forum I found agreed upon. Any thoughts?

It does make it trickier to rewrite shaders for a different system if I have to be constantly aware of the reversed y when I write my code, plus it's not what I'm used to so it feels weird. The only other solution I can see is to flip the render textures upside down (so that they actually become the right way up) instead, but I can't figure out how to do this while rendering, and it's obviously not an optimal solution to do this as an extra step after rendering the whole image the first time, no matter if I do it on CPU or GPU, so...

Tried to search for info on this but the web was surprisingly scarce, which seems weird... What do people usually do?
« Last Edit: December 29, 2016, 08:46:26 AM by Prinsessa » Logged

eerr
Level 0
***


View Profile
« Reply #1355 on: December 30, 2016, 12:17:58 PM »

I assume they just play around with it until it appears correctly. IDK

But the problem is similar to a zig-zag. You zig from the start of the image, to the end of the image.
Essentially you are trying to zig when you are already zigged, and thus must now zag.
So the GPU is instructed to start from the end, because your computer conveniently stopped right there.

Assuredly there is at least one zig for both, but I couldn't tell you which is which.

and I have no idea where I read the article that says opengl reads back and then forth deep in the mechanics.

Think of it like a reversed print stream! You start from the terminator! Also big endian little endian suddenly becomes relevant on so many levels.
Logged
oahda
Level 10
*****



View Profile
« Reply #1356 on: January 02, 2017, 05:03:51 PM »

Exciting. Gomez

Logged

Sik
Level 10
*****


View Profile WWW
« Reply #1357 on: January 02, 2017, 07:58:48 PM »

Wondering how come that dump isn't in hexadecimal instead o.o
Logged
oahda
Level 10
*****



View Profile
« Reply #1358 on: January 03, 2017, 06:10:12 AM »

Because I can't read hexadecimal very well so it's easier for me to confirm expected values in binary. p:
Logged

Vanethos
Level 0
**


View Profile WWW
« Reply #1359 on: January 08, 2017, 07:25:37 AM »

At the moment I'm trying to implement a "objective-based" system such as "Jetpack Joyride" or "Race to the Sun" to see if it fits correctly in the concept of my game.

Trying to figure out how many variables and how to store them.

So far: I need to create a DS_MAP (or a matrix in other languages) where each line holds the information of each objective:
• Objective Name - Objective string - Variable - Value to reach to fulfill objective(depends on how many times it was completed) - how many times it has been completed.

Crossing fingers that it won't be as complex as I fear it will be
Logged

Twitter: @SardineCorp
Website: https://sardinecorp.wordpress.com/
Currently Developing: SquaserZ
Pages: 1 ... 66 67 [68] 69 70 71
Print
Jump to:  

Theme orange-lt created by panic