GTA has gotten away with that for generations of consoles and PCs.
GTA 2: Islands.
GTA 3: Islands (and impossible cliff to climb at the north of 3rd island).
GTA Vice City: Islands!
GTA San Andreas: Moar Islands!
GTA 4: Isla... Well, you get the point.
EDIT: Bethesda Game Studios (creators of Fallout 3) have nice setups for Elder Scrolls in that respect.
Both Oblivion and Skyrim present challenges in the way of this since you got both land borders and sea borders in different places. They made the sea borders extend to the infinite, but for terrain borders, they actually have a heightmap of the whole continent, so thats what they show at the borders and beyond.
Only the mesh needs a vertex buffer. Sub-meshes can do with an index buffer and an offset into the shared vertex buffer.
If you "collapsed" all the sub meshes into a single vertex buffer, why don't go all the way and "collapse" all sub mesh index buffers into a single one? Unless I'm missing something you'd only need to append each index buffer into a single one and it would work.
Then again, you'd need to store an offset (and size) into the index buffer then, so when setting parameters per submesh you can draw only the submesh rather than the whole buffer.
I noticed, when I put more projects in the same workspace, especially while using Gradle/libgdx, everything is very messy, is it possible to separate these workspaces somehow?
Assuming Eclipse, you can switch workspaces if you want to, File -> Switch Workspaces. Note that all the IDE settings work per workspace, so it isn't a good workflow, just get used to close the projects you're not working on at the moment.
is it possible to make it do this?
[method parameters][method name]
Yup, go to Preferences, in Java, Code Style, Formatter, new or edit. You can use the search bar above Preferences window too.
Ctrl+A to select all, Ctrl+Shift+F to autoformat all selected things with your configured formatter.
I am looking for a tutorial that explains everything in detail, in this book it's all about "add this huge method here, add this huge method there". I want to learn everything in details so I can do everything on my own,
Grab the sources (libGDX's and JDK's), right click on the method, see definition. There, all the detail you could ask for.
Seriously, do that. I'm not even joking.
One of the main aspects of Java that I like is this little thing here. You have all the standard Java library sources by default on the JDK, most of the important libraries for Java out there are open source so you can poke through their innards, and if you even need more details, you can always just download OpenJDK sources and look at all those obscure "sun.misc" classes and HotSpot implementation.
Whats even better, most of it is documented! Even those obscure classes have comments in them. So read that too.
After all of that is done, then you can acknowledge that you can't possibly do everything on your own. That's an important realization for every programmer.
I was defining the default framebuffer as the GL_FRONT_LEFT buffer. Which meant that when I set it to target in my RenderPass object for the light pass, it was drawing to the front buffer! swapBuffers swapped back buffer with front buffer and BAM, bad buffer was being draw in the screen.
Switched to GL_BACK_LEFT and now flickering is fucking gone.... I... I'm almost crying right now :')
Mastering a its a final step after the mix. In mastering you concern yourself not only with a song, but the whole album. Volume levels and equalization along the whole album, how the songs fit together, transitions, ordering, etc. You don't touch the mix in mastering (assuming the mix is good of course), let alone change an instrument.
"Remastered" songs are usually old songs that audio engineers grab and try to restore, basically, using modern mastering techniques to try to recover the sound, not changing it significantly (otherwise it would be a remix).
What I've noticed is the Doom 3 engine uses a lot of macros definations and HPL 1 Engine uses a lot of macros. I thought you want to stay away from macro definations as best as you could?
Have in mind ID Tech 4 (ie, Doom 3 engine) was started 15 years ago, and was ID's first incursion into C++. Up to that point, all of ID code was done with C and x86 assembly if needed. So "modern" code conventions might not adjust well to that codebase.
Then again, a more "modern" version of that codebase is Doom 3 BFG's engine, I hear it was modernized a lot with ID Tech 5 code and its focused on multi threading. Its open source and uploaded to github if you want to take a look.
I say: Go with shaders. Fixed function pipeline OpenGL is pretty darn old, shaders are nice, you can do cool stuff with them. "Modern" OpenGL is nicer to use too (ie, OpenGL 3 and up).
How have you started?
I started with OpenGL 3.3, basically with barely any knowledge about C++ (or OOP in general) and a kinda basic idea on linear algebra (linear systems, basic transformations). So I just banged my head against it again and again until stuff started to make sense. Wouldn't you know it, after a while you start to Google around for stuff you want to make yourself instead of reading some tutorial that says what you have to do.
I started here http://www.arcsynthesis.org/gltut/ reading it again and again until the concepts started to sink in. I'm not a big fan of C++ so I didn't invested much time programming at first, rather I poked at the example sources. After a while I was getting the hang of it so I started implementing things in my language of choice, and started to build up from there. First project was drawing a triangle to screen, second project was drawing an entire heightmap to screen with a flying camera, then added directional lighting and basic "stick to the ground" navigation, then I had a break from graphics and now I'm back at it trying things I haven't done before (deferred renderer, other kinds of lighting, texturing, specular, etc).
At least in my case I didn't needed a full book to start with, nor for a long time. That online book I linked was enough to get started. Right now I do have a 5th edition Red Book when I need to look for specific things, since now at least I have an idea on what to look for. For many things I've also asked here in the chat, various knowledgeable people log in from time to time and its excellent when you need fast "yes" or "no" questions answered (which otherwise lead you to a lengthy revision of an entire chapter on the subject if you looked at a book just to find that one thing you're trying to do).
What do you think is important?
Jumping straight to what you want to do. If you have a clear goal on what you want to do, half the time the "step by step" procedures to learning something can get tedious. Some might tell you "Oh, you first start with fixed function to get your feet wet, then you can see a little of 2D graphics, then you can start with 3D graphics, then you can move on to shaders, then..." And so on.
If you're determined to do one of those things specifically, jump right at it, otherwise you might lose interest in the whole thing along the longer road.
EDIT: Oh and learning with video tutorials is slow as snails. Reading is more cost effective, in my case at least.
I'll add that paintComponent() doesn't always get called. It only gets called when the widget (panel, frame, button, etc) needs to be repainted (say, window was resized, button was pressed, etc), otherwise it won't get called.
If you need a component to be redrawn at some point, there exists the "repaint()" method in Swing widgets to achieve that.