Enjon: 3D/2D Game Engine, C++ / OpenGL DevLog #6

Dev-logging my process of building an engine in C++ and OpenGL for the purposes of eventually making a hand-drawn 2D/3D Isometric Rogulike game.
Covered in this video:
- Finalized "Build Loop"
- Project Management
- GBuffer Optimizations
- Editor Transform Widgets
- SSAO Fixes
- Physics Subsystem
- New Component Creation
If you have any comments or questions, drop 'em below. Like and subscribe!

[@nachocortizo3321]

Looking good!

[@johnjackson9767]

Thanks!

[@mash808]

Very nice

[@johnjackson9767]

BaconNewdles Thanks!

[@syntaxed2]

I tried the pixel picking approach but the performance was horrible...not sure what the problem was. Your approach doesnt seem to suffer from same problem? Btw, how did you do the rotation widget? Are they quads with an alpha texture or are the circles actual geo?

[@johnjackson9767]

Reading back pixel information from the GPU is definitely a slow operation, but it shouldn't be too terrible. To speed things up, I make sure not to read from it every frame and only when I click the mouse while hovering over the scene view. Can you describe how you're doing it? Maybe there's something else that you're doing differently that could be causing the slowdown? This is more or less the approach I use: www.opengl-tutorial.org/miscellaneous/clicking-on-objects/picking-with-an-opengl-hack/ All the widgets have geometry and sit in world space - I just make sure to place them in a special rendering queue that renders them without depth so they sit on top of everything. I also blit them into the Gbuffer so that their object ids are present for mouse picking. Also, if you have video of your process I'd love to see it! I enjoy watching other people work on this stuff as well. P.S. Here's the code snippet I use to do the screen picking ( again, this only happens once a frame when I actually click the mouse in the scene, so it's not constantly reading from the framebuffer ): PickResult GraphicsSubsystem::GetPickedObjectResult( const iVec2& screenPosition ) { // Set pixel alignment for unpacking glPixelStorei( GL_UNPACK_ALIGNMENT, 1 ); mGbuffer->Bind( BindType::READ ); glReadBuffer( GL_COLOR_ATTACHMENT0 + ( u32 )GBufferTextureType::OBJECT_ID ); // Read at screen position and convert to color u8 data[ 4 ]; glReadPixels( screenPosition.x, GetViewport().y - screenPosition.y, 1, 1, GL_RGBA, GL_UNSIGNED_BYTE, data ); ColorRGBA32 color( ( f32 )data[ 0 ] / 255.0f, ( f32 )data[ 1 ] / 255.0f, ( f32 )data[ 2 ] / 255.0f, ( f32 )data[ 3 ] / 255.0f ); // Get id from color u32 id = Renderable::ColorToID( color ); // Get the entity that this id corresponds to EntityManager* em = EngineSubsystem( EntityManager ); EntityHandle handle = em->GetRawEntity( id ); // Unbind buffer mGbuffer->Unbind( ); return PickResult { handle, id }; }

[@syntaxed2]

Good info, thanks mate! It was a while ago so I dont quite remember the process...but I def did something very wrong. At the moment Im just doing OBB+Triangle intersection tests for pickning but might give this another shot in the future!

[@pajeetsingh]

Where is your full game?

[@dmitrymetelitsa32]

Can you tell how do you create visual studio project for scripting?

[@johnjackson9767]

Black Wolf The editor loads in a .dll for the application currently loaded. Since this is a separate process, I can recompile it and reload it while the editor is running in another visual studio instance. When I create a new project, a new directory is created as well as a new cmake project which generates the visual studio solution from templates I've created.

[@dmitrymetelitsa32]

Thank you very much

[@bensam8358]

Absolutely incredible stuff! i was just wondering. From what you've explained, the editor derives from application and the game also derives from application. The editor loads the game and so the game becomes dependent on the editor. when you build the game, how does it become self-sustaining? is the entry point the same for both editor and game? and how does the win32 backend come into play?

[@johnjackson9767]

Great question! For the backend, I'm using SDL2, so the platform layer is more or less handled via that. The editor loads the game via .dll and manages its lifetime while you're editing. When you do a final build, it spins up a process to compile your application code against the engine's library, so the editor is completely left out of that process. If you want to talk more, there's a link to my discord in the description.

[@bensam8358]

@@johnjackson9767 Thanks! That was a surprisingly fast reply

[@jonf9989]

Can i call you sensei?? Sensei teach meeee!!

[@johnjackson9767]

jonF Feel free to drop into the Discord channel at any time to ask questions!

[@HairyPixels]

Hey John. If you remember I made a little demo on why I thought mapping 2D isometric sprites to quads in order to use the depth buffer wasn't going to work. Just last week I stumbled across the 3D solution and how it's actually possible to map the sprites to cubes and made a demo here (kzbin.info/www/bejne/jXzSmaKIh9yahZY). If you're interested look at the other video I made a far more complicated sorting buffer/masking 2D solution which I implemented before I found out the 3D way to handle it.

[@johnjackson9767]

Hairy Pixels Yeah, I remember! Glad you got it sorted out - I'll go watch it now!

[@HairyPixels]

Don't make the same mistake I did. :) I'd read the blog post I credit also since it's probably helpful. There's still merit to using the 2D approach but it's damn hard to justify unless you have very specific art requirements and don't need dynamic lighting or anything fancy with shaders.

[@johnjackson9767]

I very much agree with this! I've moved towards a more general approach within my own engine ( which I'm sure is fairly obvious from my recent videos ), but I'd still like to have pipelines set up in the future to where game-specific rendering techniques can still be implemented.

[@HairyPixels]

Ironically on modern hardware doing 3D is now simpler than 2D. Since I'm making a 2D game I thought I'd avoid the complexity of learning 3D transformation, OpenGL, shaders etc... but that was clearly the wrong approach (2D was at least 10x more complicated). People knew this 10 years but I wasn't paying attention obviously.

[@alexandrepv]

Do you plan on open sourcing this?

[@HomeGamesKiro]

How does the component mechanic works? Please

[@johnjackson9767]

Not sure exactly what you're asking, but if you want to know what components are then they're simply units of code that define properties and game logic that entities use which can be "attached" to and "detached" from an entity. Basically they're an integral part of how you create any game logic using entities.

[@HomeGamesKiro]

John Jackson how does you game engine works? I see stuff compiled in real time.. and what are programming in vs? Are you using hot reloading? What is that ui?

[@johnjackson9767]

The engine and editor are statically compiled. While the editor is running, it is able to load applications through .dlls and then run them. This allows me to be able to hot-reload c++ code by recompiling the .dll and then swapping it out at runtime. The UI is ImGUI, an immediate mode gui library. It's great for quickly prototyping so I'm using it for now as my editor ui. I'll most likely either swap it out for my own implementation or at least heavily abstract it around my own wrapper.

[@HomeGamesKiro]

John Jackson ok thanks, that's exactly what I'm trying to do with my game engine :) but I'm building my own GUI because no one fits my needs. Good programming!

[@johnjackson9767]

Good luck!

[@lachlanpage]

Awesome stuff! Do you have an email address I could reach you at? Would love to ask you some questions

[@johnjackson9767]

Lachlan Page Sure thing! My email is [e-mail].