Author Topic: Finally starting to learn OpenGL  (Read 3462 times)

0 Members and 1 Guest are viewing this topic.

Offline Flipside

  • əp!sd!l£
  • 212
Finally starting to learn OpenGL
Been meaning to start learning OpenGL for ages and a few weeks ago I started dipping my toe into it to learn 2D coding in LWJGL for the purpose of testing out some ideas I had.

It's actually a lot less difficult than it is daunting. I think the problem is an awful lot of tutorials are either 3D-Centric, which is probably a big first step for someone who hasn't multiplied a matix in decades, and whilst I can still remember how to calculate COS/SIN/TAN from triangles, I never quite got my head around how to manipulate equations to use them to their potential. I've always sucked at reducing equations to their simplest form. 2D isn't so bad, and oddly enough, I grew up using the top-left coordinate system on computers and have always had to mentally convert to bottom-left, so in some ways, 2D is actually easier for me in OpenGL.

I think the problem with a lot of OpenGL tutorials is that they start at 'how it works', which seems like a logical thing to do until you see the wall of text and charts explaining the inner workings of something you're not even sure you are going to use yet, that's been enough to put me off for a long time.

 

Offline The E

  • He's Ebeneezer Goode
  • 213
  • Nothing personal, just tech support.
    • Steam
    • Twitter
Re: Finally starting to learn OpenGL
Another problem with the online tutorials I found is that quite a lot of them are still based around OpenGL 2 and do not cover the new OpenGL API as introduced with OpenGL 3 and 4.
If I'm just aching this can't go on
I came from chasing dreams to feel alone
There must be changes, miss to feel strong
I really need lifе to touch me
--Evergrey, Where August Mourns

 

Offline Flipside

  • əp!sd!l£
  • 212
Re: Finally starting to learn OpenGL
Yup, still threading my way through the minefield of FBO's and VBO's, and what they are for, or whether it's worth using a shader for simple multiplication-based 2D lighting, which reduces engine stress, but involves learning yet another new sub-language set-up. Part of me says, 'yes, do a shader, you don't know how many entities you'll be cycling through later and how busy the CPU will end up being', the other, more lazy part of me thinks 'sod it, how much of a performance hit are 2D Graphics going to be anyway?'.

I could theoretically do what I am doing with Java's Graphics2D system and its built-in OpenGL acceleration, but I'm basically trying to cut out the middle-man for the sake of performance, but its slow going because you usually have to refer to 3-4 sources to get a decent idea of how to adapt code to your own needs.

Edit : I will add that one other problem I face is that the tutorial I'm using is based on a 2D Tower Defence game, which is moderately removed from what I am planning, so as the tutorials progress, the percentage of them that is relevant to what I am doing is becoming smaller and smaller, it's become more of a reference for 'what to look for tutorials on' rather than a tutorial itself.
« Last Edit: May 16, 2015, 09:55:01 am by Flipside »

 

Offline The E

  • He's Ebeneezer Goode
  • 213
  • Nothing personal, just tech support.
    • Steam
    • Twitter
Re: Finally starting to learn OpenGL
I strongly recommend learning the ins and outs of shaders (and especially OpenGL 3). The extra effort you have to put into learning GLSL (and there isn't much, if you're writing Java, most of the Syntax will already be familiar to you) pays off in many, many ways. Also note that it doesn't matter that much whether you do 2D or 3D graphics these days; modern hardware (and, more importantly, modern drivers) are all focussed on shader performance, and so going down that route will make everything much less complicated.
If I'm just aching this can't go on
I came from chasing dreams to feel alone
There must be changes, miss to feel strong
I really need lifе to touch me
--Evergrey, Where August Mourns

 

Offline Flipside

  • əp!sd!l£
  • 212
Re: Finally starting to learn OpenGL
Been looking through things, the downside to a shader is that FBO's aren't very frequent update compatible, so I'm rendering the main texture to the main window in live mode, though the Menus etc may well make it to a buffer.

I'm assuming that the best way to do things is to enable the shader, draw the textures with the shader applied, turn off the shader and check to see for updates to non-lighting windows like the menus etc?

I'm thinking of a FBO as a kind of 'JPanel' type thing, so I hope I'm getting the right idea.


« Last Edit: May 16, 2015, 04:24:38 pm by Flipside »

 

Offline The E

  • He's Ebeneezer Goode
  • 213
  • Nothing personal, just tech support.
    • Steam
    • Twitter
Re: Finally starting to learn OpenGL
Been looking through things, the downside to a shader is that FBO's aren't very frequent update compatible, so I'm rendering the main texture to the main window in live mode, though the Menus etc may well make it to a buffer.

That's.... not true. FBOs are very definitely usable with frequent updating; after all, this is how you do render-to-texture in OpenGL.
If I'm just aching this can't go on
I came from chasing dreams to feel alone
There must be changes, miss to feel strong
I really need lifе to touch me
--Evergrey, Where August Mourns

  

Offline Flipside

  • əp!sd!l£
  • 212
Re: Finally starting to learn OpenGL
See, this is part of the problem I'm facing, every tutorial has its own favourite ways of doing things and its own collection of misunderstandings or downright falsehoods.

The first tutorial I did defined vertices on a 2D Quad where 0,0 was the top-left corner, but some other tutorials use a system where 0,0 is the centre, still not sure which is 'right', that could quite possibly be because some of the tutorials are for 2D and others are for 3D. I'm using the 0,0 system anyway because I'm lazy and its easier to calculate actual position on screen from the xy location using it, rotation required a bit of Translatef fun, but nothing serious.

I've been looking up more on FBO's since my last post, since they seemed like the solution to most of my problems with regards to rendering, positioning and constraining stuff, and it does appear that whoever said that FBO's didn't like being updated was talking rubbish.

I'll probably look at starting to move things over today or tomorrow. On the plus side, it should make zooming in a lot easier, since I can resize the entire block of graphics depending on magnification rather than each tiles size and position, which causes a slight 'juddering' effect with the tiles, probably, due to the whole float/integer thing.

Just one bit of advice I would ask from anyone who knows. The system I use only worries about 'room' areas, each room is stored as an array structure, with the gaps between them ignored, so, rather than drawing a 2D grid with tiles on for a map, the engine just draws the rooms that are currently on screen (think Dungeon Keeper where ONLY the rooms are rendered). Would it be better to render each room as an FBO and then render those onto a final FBO to generate the main display, or to render it all to one FBO. The former seems easier to comprehend and code around in the future, the second seems faster, and means I would only have to toggle any light-shaders etc, once per render pass, rather than for each room area. (Edit - Not strictly true on consideration, I can turn on the shader, then cycle through rooms, then turn it off)

It's not so much a question of which is 'right' or 'wrong', either would work I suspect, but just wondering what people would suggest?
« Last Edit: May 19, 2015, 11:19:15 am by Flipside »