Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411273 Posts in 69323 Topics- by 58380 Members - Latest Member: bob1029

March 28, 2024, 01:39:04 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)Setting up a basic engine: Rendering + Physics
Pages: [1]
Print
Author Topic: Setting up a basic engine: Rendering + Physics  (Read 2529 times)
vinn
Level 0
*


View Profile
« on: June 23, 2015, 06:50:05 AM »

I'm trying to setup a basic engine with open-source C++ libraries. Planning achieve this basic setup on Unity, but entirely on C++ and open libs. So far, i'm planning to use the following:

  • Pure GLFW or bgfx (tips on this?)
  • Assimp
  • Bullet

Does anyone know any tutorials or books on how to "glue" those together, and create a small first-person camera attached to a bullet capsule collider? No game logic, no complex rendering, just the basics, but glued together. In a big main.cpp. Cheesy

ps.: I'm not planning to create a game with this, just learn more about how to connect and interact with the different libraries, architecting an engine and building the foundation for something. The idea is to get started and, while learning, refactor and refactor, adding new features and improving it, ad infinitum.
ps2.: I'm more excited about engines and preparing demos than actually making a game, so... engine porn addict.
ps3.: I've read the books "Game Engine Architecture" and "Game Coding Complete", but although they give you a very good topdown notion, they lack in detail and actual projects.
Logged
oahda
Level 10
*****



View Profile
« Reply #1 on: June 23, 2015, 11:25:23 PM »

I only recgonise some of those. I'm guessing the first two are for graphics. Is Assimp input?

Either way, gluing 2D graphics together with Box2D would mean reading the positions, rotations and so on from the physics engine and using the graphics framework to draw things at those positions. Box2D too defines shapes but generally you just want to draw a sprite on top and not actually render that shape.

Am I wrong in assuming Bullet works kind of like this for 3D too? I.e. you would define something like a capsule collider for the actual physics but render a model on top of it? Even if you were to actually pass an entire model to the physics engine, I would assume you'd also have to pass that data again to the graphics rendering pipeline. So I suppose Bullet will provide you with whatever transformations you're supposed to be passing to the rendering pipeline.

All in all, anyhow, your glue would be the C++ program itself. It can access and modify the data of all these libraries and bring them together in any way it needs. Input data tells you to tell physics engine to move stuff. Physics data tells you where to draw that stuff.
Logged

Netsu
Level 10
*****


proficient at just chillin'


View Profile WWW
« Reply #2 on: June 23, 2015, 11:35:42 PM »

GLFW can be a bit of a leap from Unity, if that is where you're coming from. It's basically just naked OpenGL, setting up a FPP camera will take some work.
Logged

Lavesson
Level 0
***


View Profile WWW
« Reply #3 on: July 03, 2015, 03:40:29 AM »

Yeah, GLFW helps you with controller support and context creation, but other than that, it's simply OpenGL. It's extremely well-documented though: http://www.glfw.org/docs/latest/quick.html

Quote
Either way, gluing 2D graphics together with Box2D would mean reading the positions, rotations and so on from the physics engine and using the graphics framework to draw things at those positions. Box2D too defines shapes but generally you just want to draw a sprite on top and not actually render that shape.

Yes, Bullet works pretty much the same way. (Also, I keep seeing Box2D pop up everywhere. I really need to take a look at it!)

Quote
Does anyone know any tutorials or books on how to "glue" those together, and create a small first-person camera attached to a bullet capsule collider? No game logic, no complex rendering, just the basics, but glued together. In a big main.cpp.

I'm not sure how many tutorials I've seen to glue exactly these things together, since they're pretty "pluggable". I did something similar a bunch of years back, but I used Ogre for rendering:



Not sure if it'll help you, but I pushed the source code to Github: https://github.com/Lavesson/old-crappy-engine
NOTE: I consider the source code to be crap - it's not very well organized/structured and it's several (~6) years old. I wrote it to learn to integrate different libraries. Other than that, I guess it's the BulletOgreMotionState and the PhysicsHandler that might be of interest.

Hopefully, there's some nugget in there that'll help (considering the Bullet API hasn't changed too much since I used it)

PS: Yes, the namespace is named "Eric" throughout the source code. Not because of my ego, but because I suck at making up names.
Logged

InfiniteStateMachine
Level 10
*****



View Profile
« Reply #4 on: July 03, 2015, 07:41:32 AM »

GLFW is awesome and I've used all 3 libraries but I've never used them in the same project.

Bullet shouldn't be much of an issue, it probably doesn't need to even know about GLFW since it doesn't really have a visual or input related aspect. It's just manipulating your game objects transforms before they get drawn.

As for assimp, the last time I used it was a loooooong time ago and I didn't use it much ( I think I ended up writing my own obj importer at the end because I didn't need something as powerful as assimp). Does it have a function for extracting an array of vertex data and index data? If so then really all you have to do is transform the data once into something you can pass to OpenGL.

IIRC Assimp recommends that you do those transformations and then store in some other performant format. So maybe you might only use it when you import new assets.
Logged

Allen Chou
Level 0
**



View Profile WWW
« Reply #5 on: July 05, 2015, 10:12:24 PM »

IIRC Assimp recommends that you do those transformations and then store in some other performant format. So maybe you might only use it when you import new assets.

I second that.

It's better to use Assimp "offline" during tool time to convert assets into your custom binary format (e.g. vertex data stream in your custom vertex format). At run time, just load the binary data directly into memory as-is and it's ready for use. This way, you don't have to spend any time in your game using Assimp to process raw assets.
Logged

J-Snake
Level 10
*****


A fool with a tool is still a fool.


View Profile WWW
« Reply #6 on: July 06, 2015, 04:34:26 AM »

What about the current state of SDL2? Anyone used that?

From what I have heard in this talk it also tries to turn every gamepad into a xbox gamepad or a subset of it, which is neat.


Logged

Independent game developer with an elaborate focus on interesting gameplay, rewarding depth of play and technical quality.<br /><br />Trap Them: http://store.steampowered.com/app/375930
oahda
Level 10
*****



View Profile
« Reply #7 on: July 07, 2015, 06:52:54 AM »

I'm using SDL2 for my current game, which has gamepad support, and it works great most of the time.

Also neat as an aside is that you can run SDL2 on Android and iOS if you want (I've tried both successfully).

SDL2 does indeed use enums with values based on the Xbox controller setup to provide a generally cross-compatible interface to any modern gamepad with a similar design. The buttons, for example, are called A, B, X and Y as on the Xbox controller. Doesn't match the names of the DualShock, but A always corresponds to PlayStation's X and so on, so no worries. Everything works perfectly with both an Xbox 360 controller as well as a PS3 one for my game. OUYA controller was recognised as a mouse (and didn't even work as such) tho, but that's not a major issue. Tongue

Reports how hard you're pushing the trigger buttons and supports rumble and so on so long as your driver works properly  The Mac PS3 controller driver unfortunately works with neither of these, but that's an OS X driver issue, not a PS3 controller or an SDL2 issue. Everything works fine on the Tattleboogie Xbox 360 controller driver, including rumble.

However, SDL2 didn't report any rumble being present for the Xbox 360 controller properly, and I couldn't get it to rumble by using the simple functions. Defining a simple rumble program (through SDL2 as well) and sending it to the controller did work, tho, bypassing the check for rumble (and it doesn't crash when trying to pass it to the PS3 controller or anything — it simply doesn't rumble). So unless they've fixed that, thats something to watch out for, but at least there is a solution. Don't know if it's SDL or the driver, but since the driver test program and other games can make it rumble just fine, that might be an SDL bug. But again, at least there's a workaround.

All in all, SDL2 is very nice to work with when it comes to gamepads. I'm amazed that there still seems to be no proper vanilla way in Unity to get the same kind of cross-compatible (between different gamepads) input setup, where all you can do is define button numbers and the numbers don't correspond to the same buttons on a 360 controller as on a PS3 controller. I couldn't find any libraries or add-ons or plug-ins or w/e either. Is there any way to fix that?
Logged

J-Snake
Level 10
*****


A fool with a tool is still a fool.


View Profile WWW
« Reply #8 on: July 08, 2015, 05:09:06 AM »

Sounds good. Now that Trap Them is finished for Steam I decided to drop XNA. I am considering to build my base engine in Java and LWJGL or SDL2 and C++. I might end up building the engine for both options. Then I will see which version to use for a particular game. SDL2 and C++ seems to have advantages though and I am happy to hear cross platform support works well, but I will see.
Logged

Independent game developer with an elaborate focus on interesting gameplay, rewarding depth of play and technical quality.<br /><br />Trap Them: http://store.steampowered.com/app/375930
J-Snake
Level 10
*****


A fool with a tool is still a fool.


View Profile WWW
« Reply #9 on: July 09, 2015, 06:48:07 AM »

OUYA controller was recognised as a mouse (and didn't even work as such) tho, but that's not a major issue. Tongue
May be it is because the OUYA gamepad has a touchpad, so a mouse with buttons is assumed, as funny as it sounds.
Logged

Independent game developer with an elaborate focus on interesting gameplay, rewarding depth of play and technical quality.<br /><br />Trap Them: http://store.steampowered.com/app/375930
oahda
Level 10
*****



View Profile
« Reply #10 on: July 09, 2015, 07:30:57 AM »

OUYA controller was recognised as a mouse (and didn't even work as such) tho, but that's not a major issue. Tongue
May be it is because the OUYA gamepad has a touchpad, so a mouse with buttons is assumed, as funny as it sounds.
Yeah, I figured that too, but the touchpad didn't work as a mouse either. The cursor just got stuck in the corner of the screen when the controller was connected.
Logged

J-Snake
Level 10
*****


A fool with a tool is still a fool.


View Profile WWW
« Reply #11 on: July 09, 2015, 08:08:47 AM »

The OUYA gamepad must be a bad mouse then;)
Logged

Independent game developer with an elaborate focus on interesting gameplay, rewarding depth of play and technical quality.<br /><br />Trap Them: http://store.steampowered.com/app/375930
oahda
Level 10
*****



View Profile
« Reply #12 on: July 09, 2015, 08:15:53 AM »

It's actually pretty awful even on the console itself.
Logged

bobsadino
Level 0
*


View Profile
« Reply #13 on: July 12, 2015, 01:57:49 AM »

You will needs this:

DirectX SDK

http://stackoverflow.com/questions/13779183/directx-11-sdk-where-can-i-download-it


Logged
Thomas Hiatt
Level 0
***



View Profile
« Reply #14 on: July 12, 2015, 08:23:51 AM »


That is impressive. Not only has DirectX not even been mentioned in this thread, nor is it a solution to the question, but it isn't even something you could possible need because it is already included in Windows like it says in your link.
Logged
InfiniteStateMachine
Level 10
*****



View Profile
« Reply #15 on: July 12, 2015, 03:53:42 PM »

the sdk isn't actually included with windows but I agree with your other points
Logged

Kinaetron
Level 5
*****



View Profile WWW
« Reply #16 on: August 20, 2015, 07:58:22 AM »

If you want to learn more details in terms of structing game code I would highly recommend reading this http://gameprogrammingpatterns.com/ I would also start maybe having a look for engine's similar to the kind you want to build and see how they piece everything together
Logged

Life sucks and then you die.
Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic