Just double buffered the Windows console. What you are seeing here is two buffers: one which is empty, and one which has the text "Hello world!", and a pause of 1 second between buffer swapping.

This enables accelerated rendering in the Windows command line (By rendering to an off-screen buffer then simply swapping the active buffer), making things like advanced terminal applications in the Windows console possible.

And the best part- this is the first compilation of the project. Not a single run-time error. What a fucking satisfying accomplishment, honestly.

Agh, holy shit. devRant, I need some love.

I have successfully double-buffered the Windows console (cmd.exe) but all hell breaks loose when you resize the fucking window. The currently active buffer will receive the change in dimensions while the inactive buffer will not, resulting in the window quickly oscillating between the two sizes as the buffers change size.

That got me stuck for about a day. Today, I got it sort of working but it wasn't satisfying at all. I can get it to resize LARGER, but if you resize the window SMALLER, the actual buffer inside the window doesn't change size, so scrollbars appear and I have NO IDEA HOW TO FIX THAT. I somehow need to calculate, or use the API to find, the perfect dimensions (In rows and columns) for the console buffer INSIDE the window buffer for them to not have scrollbars.

And I just - -

I cannot gather the energy to do so right now.

I spent hours finding the solution to this bullshit and ONLY SOLVED HALF MY PROBLEM.

And stack overflow isn't exactly helpful. My problem is so specific that nobody even writes comments on the question.

I guess I need to calculate the amount of characters the screen can hold given the font size and the window size, but fuck, that's a lot of work to do just for something that probably won't even work anyways.

Well, off to the code editor again. Time to inevitably waste my time doing something that won't work.

Yay, programming.

Discovered pro tip of my life :
Never trust your code

Achievements unlocked :
Successfully running C++ GPU accelerated offscreen rendering engine with texture loading code having faulty validation bug over a year on production for more than 1.5M daily Android active users without any issues.

History : Recently I was writing a new rendering engineering that uses our GPU pipeline engine.. and our prototype android app benchmark test always fails with black rendering frame detection assertion.

Practice:
Spend more than a month to debug a GPU pipeline system based on directed acyclic graph based rendering algorithm.

New abilities added :
Able to debug OpenGL ES code on Android using print statement placed in source code using binary search.

But why?
I was aware of the issue over a month and just ignored it thinking it's a driver bug in my android device.. but when the api was used by one of Android dev, he reported the same issue. In the same day at night 2:59AM ....

Satan came to me and told me that " ok listen man, here is what I am gonna do with you today, your new code will be going production in a week, and the renderer will give you just one black frame after random time, and after today 3AM, your code will not show GL Errors if you debug or trace. Buhahahaha ahhaha haahha..... Puffff"

And he was gone..
Thanks satan for not killing me.. I will not trust stable production code anymore enevn though every line is documented and peer reviewed.

So this was a conversation.
tl;dr You can't just FUCKING RECOMPILE for an older OpenGL version you dimwit!

Context: Person Y has OpenGL 3.1, my program requires OpenGL 2.1, but refused to launch with "Pixel format not accelerated"

--------

Person X - Today at 9:28 PM
Nope
or optionally compile it for old opengl
Or just use my old junk.

Me - Today at 9:29 PM
No

Person X - Today at 9:29 PM
Why?

Me - Today at 9:29 PM
You don't just "compile it for old opengl"

Person X - Today at 9:29 PM
I can
Btw

Me - Today at 9:29 PM
For one, Person Y has an OGL version new enough so... /shrug

Person X - Today at 9:29 PM
shrug

Me - Today at 9:30 PM
And there is no way I'm ripping the rendering code apart and re-doing everything with glBegin, glVertex, glEnd guff

Person X - Today at 9:30 PM
You don't have to

Me - Today at 9:30 PM
You do

Person X - Today at 9:30 PM
Just use a vbo
Than a vba

Me - Today at 9:30 PM
I ALREADY USE FUCKING VBOS

Person X - Today at 9:30 PM
....
There's two typws
Types
Btw one with indacys and one with out
Ones 3.0 ones 4.0

Me - Today at 9:31 PM
tl;dr. I am not rewriting half of everything for worse performance just for the sake of being compatible with even more legacy OGL, that might not even work anyway for Person Y. idc

Person X - Today at 9:32 PM
Plus if your using glut you can set the version I want to say
Also it's not worse

<Some more conversation>

Person X - Today at 9:33 PM
Btw crafted [Me] taking th lazy way as normal
Btwx500

Me - Today at 9:33 PM
Taking the lazy way eh.
You have no idea do you

Person X - Today at 9:33 PM
Yes you are
I have more of one :p
Than you think