Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Geek Culture / C++ Engine, recomendations of a "how to guide"?

Author
Message
Dragon Knight
18
Years of Service
User Offline
Joined: 10th Jan 2007
Location: Newcastle
Posted: 1st May 2009 01:22
Since I am in a course that mainly uses C++, i've decided to create a game engine from scratch just to create simple 2D games, then perhaps move it up the pipeline to 3D in a later stage to help me get an understanding of the workings of c++ engines.

Any ideas of where to start would be a great help. I've already google'd it, and I'm currently reading through a few university papers on it to get an understanding . I'm quite enthusiastic about this ^-^

Hmm... openGL or DirectX >.>

Thanks for any positive feedback in advance

AndrewT
18
Years of Service
User Offline
Joined: 11th Feb 2007
Location: MI, USA
Posted: 1st May 2009 01:37 Edited at: 1st May 2009 01:52
Make Games, Not Engines.

You don't want to create an engine. Not yet, at least. Creating a game engine with OpenGL or DirectX--even if it's 2D--is much more complex than it seems at first. If you attempt to create an engine at your skill level you'll end up with an inflexible group of functions that just over-complicate the process of making a game. Instead design a *very* simple framework. It shouldn't handle much more than initializing DX/OpenGL and loading meshes, images, and sounds. Then, once you've created a couple games with this and you understand what's required to make a decent game in C++ using DirectX or OpenGL, you can attempt to make a simple engine, with a scene graph, a material system, etc.

Basically the point I'm trying to get across is that when people first begin with DirectX, they suddenly want to create a simple game engine. But there are several problems with that:

a) They know very little DirectX. They create their engine with only the basics in mind--creating a device and vertex buffer, matrix transformations, etc. However as they increase their knowledge they continue to add and add to it until it grows into an extremely messy pile of unstructured code.

b) They also typically know very little about C++, leading them to code their engine using many bad practices, once again leading to a very poorly designed engine.

c) And they also know very little about game design itself, and the kind of features a game engine needs to be flexible, fast, etc, and so when it comes to designing a game with their new engine they've made, they realize that their engine is totally unsuitable for game dev. This is why it's important that you go straight into game creation first, rather than engine creation. It's hard to code a game engine if you don't know how to code a game.

i like orange
Roxas
19
Years of Service
User Offline
Joined: 11th Nov 2005
Location: http://forum.thegamecreators.com
Posted: 1st May 2009 01:42
What you want to do is Rendering Engine, as for OpenGL or DX, go with OpenGL. Its Cross-plaftrom and IMO far superior to DirectX. But if you find it too hard to implement then just go DirectX, ive heard its easier, but for me its like learning to drive different type of vehicle.

But yeah, for start keep your rendering engine simple, as framework with simple functions like Andrew said. After you know what you are doing you should rewrite it effective way as possible

You can also take a look into Irrlicht source, its awesome Open-Source rendering engine!

AndrewT
18
Years of Service
User Offline
Joined: 11th Feb 2007
Location: MI, USA
Posted: 1st May 2009 01:44
Roxas is probably right about Direct3D being easier. Although I don't have that much experience with OGL, D3D is very straightforward and D3DX makes things like sprites and loading textures/meshes incredibly simple.

i like orange
NeX the Fairly Fast Ferret
20
Years of Service
User Offline
Joined: 10th Apr 2005
Location: The Fifth Plane of Oblivion
Posted: 1st May 2009 02:03
I thought OpenGL was easier but DX was faster.

AndrewT
18
Years of Service
User Offline
Joined: 11th Feb 2007
Location: MI, USA
Posted: 1st May 2009 02:10
Quote: "I thought OpenGL was easier but DX was faster."


Like I said I don't have that much experience with OGL but I've always considered D3D easier because D3DX has a LOT of helper functions that simplify just about everything.

i like orange
David R
21
Years of Service
User Offline
Joined: 9th Sep 2003
Location: 3.14
Posted: 1st May 2009 23:55 Edited at: 1st May 2009 23:58
Quote: "You don't want to create an engine. Not yet, at least. "


I think you've used the linked article out of context (in my opinion). That article is targeting developers who solely focus on creating an engine, and that their game is the afterthought.

It's not saying don't make engines - because making a game effectively requires an engine or framework of some kind,as you have mentioned. It merely says to make the engine and the game, not just the engine in isolation (and the OP has said he wants to make an engine for a 2D game, i.e. he wants to know how to stick everything together to make a 2D game. Not that he wants to focus entirely on engines)


09-f9-11-02-9d-74-e3-5b-d8-41-56-c5-63-56-88-c0
AndrewT
18
Years of Service
User Offline
Joined: 11th Feb 2007
Location: MI, USA
Posted: 1st May 2009 23:59
Yes, you're right David R--I was a bit too over-the-top about the whole "don't make engines" thing as you have to have some kind of engine to make a game.

i like orange
Dragon Knight
18
Years of Service
User Offline
Joined: 10th Jan 2007
Location: Newcastle
Posted: 2nd May 2009 07:47 Edited at: 2nd May 2009 07:52
AndrewT <- I did read through that article but I'm still intent on going through with making an engine.

David R <-, thanks for the back up lol


I've decided to go with direct X, the reasons being.. that's what we're meant to be using in uni. Might as well look at the in's and out's of it

I've found a very nice set of tutorials on how to go about it:
https://www.directxtutorial.com/Tutorial9/tutorials.aspx
First hick up i did was forgetting to change the project to using Unicode Character Set. Yay though, no problems yet.

currently on Lesson 4: Drawing a Triangle, quite fun so far .

Hmm need sleep.. nearly 6am...

Roxas
19
Years of Service
User Offline
Joined: 11th Nov 2005
Location: http://forum.thegamecreators.com
Posted: 2nd May 2009 11:33
Quote: "I thought OpenGL was easier but DX was faster."


It depends really on hardware and how you use those API's, for me OpenGL is faster and far more superior.

AndrewT
18
Years of Service
User Offline
Joined: 11th Feb 2007
Location: MI, USA
Posted: 2nd May 2009 16:21 Edited at: 2nd May 2009 16:23
Quote: "I did read through that article but I'm still intent on going through with making an engine."


Fair enough, but don't say I didn't warn you. just kidding.

I was going to recommend DirectXTutorial but it appears that you've already found it! I used those awhile back and they are very good IMO. Some others that you may want to take a look at as well are Drunken Hyena and Two-Kings. I have a bit of experience with those and well and they're nice tutorials. Also CodeSampler has dozens of commented snippets on everything from texture filtering to BSP Compilers using Direct3D, and I suggest you check it out, especially once you've advanced a little further.

i like orange
NeX the Fairly Fast Ferret
20
Years of Service
User Offline
Joined: 10th Apr 2005
Location: The Fifth Plane of Oblivion
Posted: 2nd May 2009 18:29
Quote: "for me OpenGL is faster and far more superior."


Yes... because you're using Linux which has no native DirectX support and so all DirectX commands have to be wrapped to OpenGL. Just like Windows does it the other way around.

Roxas
19
Years of Service
User Offline
Joined: 11th Nov 2005
Location: http://forum.thegamecreators.com
Posted: 2nd May 2009 18:31
Quote: "Yes... because you're using Linux which has no native DirectX support and so all DirectX commands have to be wrapped to OpenGL. Just like Windows does it the other way around."

Maybe, but back when OpenGL was heavily used in Windows games too, in example half-life 1 OpenGL was faster, tho i think this is because DirectX wasnt then so evolved.

Dragon Knight
18
Years of Service
User Offline
Joined: 10th Jan 2007
Location: Newcastle
Posted: 2nd May 2009 18:52
AndrewT <- now that's helpful , thanks!

David R
21
Years of Service
User Offline
Joined: 9th Sep 2003
Location: 3.14
Posted: 2nd May 2009 19:51 Edited at: 2nd May 2009 19:58
Quote: "
Just like Windows does it the other way around."


No, it doesn't. Under Windows, Both GL and DX filter their commands down to their respective libraries, and then down to the DWM (which becomes the block between user mode and kernel mode). No swapping or translation occurs at all, the DWM just pushes the data and instructions down to hardware level (so it becomes a mediator) - somewhat like other kernel-userspace traversal libraries/applications (e.g. FUSE)

EDIT: And that's assuming Vista onwards. Anything prior to Vista, and GL has full self --> hardware driver control


09-f9-11-02-9d-74-e3-5b-d8-41-56-c5-63-56-88-c0
NeX the Fairly Fast Ferret
20
Years of Service
User Offline
Joined: 10th Apr 2005
Location: The Fifth Plane of Oblivion
Posted: 2nd May 2009 20:05
Didn't know they changed it.

Roxas
19
Years of Service
User Offline
Joined: 11th Nov 2005
Location: http://forum.thegamecreators.com
Posted: 3rd May 2009 00:54
Doesn't aero use somekind of 3D Api? DirectX? I imagine OpenGL would run slower on it or any 3d app

David R
21
Years of Service
User Offline
Joined: 9th Sep 2003
Location: 3.14
Posted: 3rd May 2009 01:06
Quote: "Doesn't aero use somekind of 3D Api? DirectX? I imagine OpenGL would run slower on it or any 3d app"


Each application draws to an off screen buffer, and the DWM composites the data and funnels it to the hardware. So I assume the adding of window borders etc. is part of the composting process (i.e. once the app has drawn using the respective API, it adds the extra effects on top of the buffer etc.)

For either API that represents a slow down, but I believe the DWM has some tweaks it applies to speed up rendering of DX windows (it doesn't composite them, or it does it less often. I think it can also screw with the hardware differently because it knows what surface formats are needed)


09-f9-11-02-9d-74-e3-5b-d8-41-56-c5-63-56-88-c0
NeX the Fairly Fast Ferret
20
Years of Service
User Offline
Joined: 10th Apr 2005
Location: The Fifth Plane of Oblivion
Posted: 3rd May 2009 01:13
Am I the only one who thinks it's silly that we're still software rendering the contents of windows? Do Mac OS X or any Linux distros use full hardware rendering or are we stuck in 1991 all round?

David R
21
Years of Service
User Offline
Joined: 9th Sep 2003
Location: 3.14
Posted: 3rd May 2009 01:16 Edited at: 3rd May 2009 01:23
Quote: "Am I the only one who thinks it's silly that we're still software rendering the contents of windows?"


That's the whole point of a composted desktop - if possible, the off screen buffer is in video memory, and then the desktop image is constructed from each window source. The 'funneling' I mentioned about the HW is only applicable if the compositor is not available, or if for some reason it restricts the surface to system memory. That's the case for OS X's Quartz compositor too.

I think Vista's implementation is bit odd though, because if I recall correctly, it has to sync between system (memory) surfaces and video memory surfaces every so often. That might only be for legacy apps though, I'm not sure.

EDIT: This becomes a contentious issue, however, because technically speaking the compositor in Vista (and onwards) is making use of DirectX to do its job (so in some ways, the whole GL->DX swap occurring could be said to be true). This is more, in my opinion, because the line between DX/DWM compatible drivers blurs with DX itself, rather than it actually making use of full blown DX/D3D APIs (MS have simply defined a standardized way of talking to the GPU which happens to correlate with DX very well)


09-f9-11-02-9d-74-e3-5b-d8-41-56-c5-63-56-88-c0
NeX the Fairly Fast Ferret
20
Years of Service
User Offline
Joined: 10th Apr 2005
Location: The Fifth Plane of Oblivion
Posted: 3rd May 2009 01:26 Edited at: 3rd May 2009 01:28
I simply don't get it; why do programs have to draw directly to their client area, blitting pixel by pixel sluggishly rather than requesting say a button or a text box. This object would then be drawn by hardware to a texture which would be piped to the compositor. If we needed backwards compatability with programs that used the older method, there'd be an image object.

It just strikes as poor design that Window servers and the GDI core are relying on such an outdated technique when all it takes is some textured quads.

Roxas
19
Years of Service
User Offline
Joined: 11th Nov 2005
Location: http://forum.thegamecreators.com
Posted: 3rd May 2009 02:30
Linux has window managers where you can enable direct OpenGL rendering.

NeX the Fairly Fast Ferret
20
Years of Service
User Offline
Joined: 10th Apr 2005
Location: The Fifth Plane of Oblivion
Posted: 3rd May 2009 13:51
Hooray! At least someone is thinking straight then!

Yodaman Jer
User Banned
Posted: 3rd May 2009 17:55
On the subject of Linux, what programming languages are available for it? I'm thinking about dual-booting Ubuntu and I'm wondering what kind of languages you can use on it.

I've just updated my site! Please visit!

Roxas
19
Years of Service
User Offline
Joined: 11th Nov 2005
Location: http://forum.thegamecreators.com
Posted: 3rd May 2009 18:19
Well, too much for to list, heck you could even use DBP trough wine, but be aware it will have some bugs.

C, C++, D , Python are most used languanges. Some also use some basic languages like freebasic.

Login to post a reply

Server time is: 2025-06-05 02:06:34
Your offset time is: 2025-06-05 02:06:34