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 / Game Engines...

Author
Message
heyufool1
16
Years of Service
User Offline
Joined: 14th Feb 2009
Location: My quiet place
Posted: 29th Jun 2010 06:48 Edited at: 29th Jun 2010 06:49
Hello! Recently I came to the realization that I enjoy programming applications from the the ground up more then making games. So I thought, why not make a game engine!? Now I started this a few days ago using OpenGL as the renderer. So far I have bump-mapping, cel-shading, object handling, Newton physics integrated, and began working on my GUI class for the engine itself(Probably will end up using windows API but thought this would be fun). Now all is fine and dandy until I remembered, how will I give the user the ability to create an executable file of their game through my application? I looked around and have found some basic ideas of data driven programming, and implementing my own scripting language and whatnot. But I cannot find anything that gives me any clue on how to take what the user created, and generate an executable file of that from my application. So, anything to point me in the right direction would be greatly appreciated! Thanks for taking the time and reading this

"So hold your head up high and know, it's not the end of the road"
Up-coming RPG!
Travis Gatlin
16
Years of Service
User Offline
Joined: 14th May 2009
Location: Oxford, Alabama
Posted: 29th Jun 2010 18:30 Edited at: 29th Jun 2010 18:33
well, is it going to be 2D or 3D?

The Object of war is not to die for your country but make the other guy die for his
Oolite
19
Years of Service
User Offline
Joined: 28th Sep 2005
Location: Middle of the West
Posted: 29th Jun 2010 18:41
I'm not exactly sure that matters travis...


Fool: What language are you using? Are you asking what commands you need to physically make the exe or what to put inside the exe?

Red Eye
16
Years of Service
User Offline
Joined: 15th Oct 2008
Location:
Posted: 29th Jun 2010 18:55 Edited at: 29th Jun 2010 18:56
Quote: "What language are you using? Are you asking what commands you need to physically make the exe or what to put inside the exe?"


I think a great programmer as heyufool already knows that more then good.

Anyway, how u doing?, well, i would start making a design document, that is how i began making my engine, not so long ago. Ur skilzz at programming are very good, if I look at ur projects, the first i saw from u that impressed me was ur editor. Anyway so a design document would be the best to start with.

heyufool1
16
Years of Service
User Offline
Joined: 14th Feb 2009
Location: My quiet place
Posted: 29th Jun 2010 19:11
Quote: "well, is it going to be 2D or 3D?"

3D, but as Oolite said, it doesn't really matter.

Quote: "What language are you using? Are you asking what commands you need to physically make the exe or what to put inside the exe?"

C++, I guess I'm asking more along the lines of what commands I need to physically make the exe. If I know that much then I'm sure I could figure out the rest.

Quote: "Anyway, how u doing?, well, i would start making a design document, that is how i began making my engine, not so long ago. Ur skilzz at programming are very good, if I look at ur projects, the first i saw from u that impressed me was ur editor. Anyway so a design document would be the best to start with."

Thanks for the compliments Although, I understand having a design document would be helpful and keep things organized. But, I don't see the point of even working on my engine at all until I figure out how to make the executable (since that is the whole reason of having an engine). Thanks for the suggestion and I'll be sure to work on that once I have this .exe thing sorted out.

"So hold your head up high and know, it's not the end of the road"
Up-coming RPG!
Zotoaster
20
Years of Service
User Offline
Joined: 20th Dec 2004
Location: Scotland
Posted: 29th Jun 2010 23:51
How will people use your game engine? Is it just a set of interfaces to a bunch of classes which people will use from C++, or is it your own editors and such?

I assume it's the second as the first one is trivial.

An easy way to do it is to make your EXE, and make it rely on external files. The editor simply creates the files. For instance, the user creates a bunch of levels and saves them. Then they create a list of which levels to use in their game in which order, and save them to a file, say, 'levels.ini', which is automatically loaded by the program and the files are read.

"everyone forgets a semi-colon sometimes." - Phaelax
Diggsey
19
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 30th Jun 2010 00:00 Edited at: 30th Jun 2010 00:01
There are a number of ways to make exes (easiest to hardest):
- Have a standard .exe which runs based on files (like FPSC)
- Make a compiler which outputs assembly instructions, and use an existing or make your own assembler. Append this raw code file to a 'stub' .exe which when run copies the code into memory and jumps into it. (like DBPro)
- Make a compiler which outputs assembly instructions which are assembled and linked against your library using a linker to create a self-contained .exe file.

[b]
heyufool1
16
Years of Service
User Offline
Joined: 14th Feb 2009
Location: My quiet place
Posted: 30th Jun 2010 00:12 Edited at: 30th Jun 2010 00:13
Thanks for the responses! I never even thought about having an .exe file running based on external files Seems easy enough (easier then compiling my own executable). So, I think that sounds like something I can and will do. Thanks a lot!

I have 1 remaining question though. This is off topic so I'm not expecting an answer. Anyways, I'm working on my own GUI system so I can give the user as much control over it as I seem fit. It's working fine but I can't seem to render text efficiently. Right now a simple button with the text "Edit" on it causes about a 50 FPS drop, which is obviously unacceptable. So anyone have any ideas on how to render text efficiently using OpenGL as the renderer? Here is the code I'm using to render the text and the code to set it up:


Note: The FontUseage and FontCount don't have anything to do with the rendering.

"So hold your head up high and know, it's not the end of the road"
Up-coming RPG!
Zotoaster
20
Years of Service
User Offline
Joined: 20th Dec 2004
Location: Scotland
Posted: 30th Jun 2010 00:35
Maybe it's because you're using char* arrays. They're kinda ugly, especially when using functions such as strlen(), which loop through the strings every time you use them looking for a null terminator.

Try using std::strings. They're better.

"everyone forgets a semi-colon sometimes." - Phaelax
AndrewT
18
Years of Service
User Offline
Joined: 11th Feb 2007
Location: MI, USA
Posted: 30th Jun 2010 01:06 Edited at: 30th Jun 2010 01:13
With regards to that first code snippter:

Just so you know, display lists are deprecated under OpenGL 3.0 specifications. That doesn't mean you can't use them, but it's not a great idea to become accustomed to features of OpenGL that are may be removed in the future, not to mention in most cases deprecated features are slower (hence the deprecation )--after all, it's never fun to develop an entire engine using OpenGL's fixed-function pipeline, only to find out that it's become deprecated.

If you need help with completely avoiding deprecated features, you can start here (sorry, the forums don't like the link):

http://www.opengl.org/wiki/Tutorial:_OpenGL_3.1_The_First_Triangle_%28C%2B%2B/Win%29

It's not a great tutorial, but it will give you an idea of how to get things up and running without deprecated functionality.

i like orange
Jeff032
17
Years of Service
User Offline
Joined: 13th Aug 2007
Location:
Posted: 30th Jun 2010 01:10
Quote: "50 FPS drop"


Unfortunately, that tells us nothing.

If the fps dropped from 2000 to 1950, that means it only took ~0.000013 seconds.

If the fps dropped from 60 to 10, that means it took ~0.083333 seconds, and you have a problem

heyufool1
16
Years of Service
User Offline
Joined: 14th Feb 2009
Location: My quiet place
Posted: 30th Jun 2010 01:27 Edited at: 30th Jun 2010 01:31
Quote: "Maybe it's because you're using char* arrays. They're kinda ugly, especially when using functions such as strlen(), which loop through the strings every time you use them looking for a null terminator.

Try using std::strings. They're better."

Thanks! I'm in the process of converting everything to strings so hopefully I'll seem some improvements.

Quote: "Just so you know, display lists are deprecated under OpenGL 3.0 specifications. That doesn't mean you can't use them, but it's not a great idea to become accustomed to features of OpenGL that are may be removed in the future, not to mention in most cases deprecated features are slower (hence the deprecation )--after all, it's never fun to develop an entire engine using OpenGL's fixed-function pipeline, only to find out that it's become deprecated."

Had no idea that it was deprecated Checking out that link now.

Quote: "If the fps dropped from 2000 to 1950, that means it only took ~0.000013 seconds.

If the fps dropped from 60 to 10, that means it took ~0.083333 seconds, and you have a problem"

True, I guess I should have been more specific. With one call it drops from about 900 to around 840-850, and with about 5 calls It goes from about 900 to 580-600.

"So hold your head up high and know, it's not the end of the road"
Up-coming RPG!
Jeff032
17
Years of Service
User Offline
Joined: 13th Aug 2007
Location:
Posted: 30th Jun 2010 01:45 Edited at: 30th Jun 2010 01:50
Also, I don't know anything about display lists in OpenGL, so maybe there is a reason for this, but why do you use this:



instead of something like this?



(Basically, what is the point of copying the string into a new array? And if it needs to be in that new array, why are you using sprintf instead of, say, strcpy?)

Also, the only time I've had to print text in OpenGL, this is how I did it, though it requires glut and there's probably a much better way:


Jeff

AndrewT
18
Years of Service
User Offline
Joined: 11th Feb 2007
Location: MI, USA
Posted: 30th Jun 2010 01:58
Quote: "Had no idea that it was deprecated Checking out that link now. "


Unfortunately OpenGL 3.0 deprecates a lot of features. The biggest ones I can think of are:

Immediate mode and display lists: all immediate mode rendering (glBegin, glEnd) is deprecated, as well as display lists. The preferred method of rendering is VAOs and VBOs, as far as I know.

Fixed-function pipeline: all of the material and lighting functions are deprecated--this includes glColor, glTexCoord, etc. All rendering should be done with shaders, and you should manage your own materials and lights.

Built-in vertex attributes: because the fixed-function pipeline is deprecated, you'll be passing vertex attributes (position, color, texcoord etc.) to shaders on your own with glVertexAttribPointer(). Therefore the default vertex shader inputs (gl_Position, gl_Color, gl_MutliTexCoord, etc.) are all deprecated.

"varying" and "attribute" variables in GLSL: not sure if you're using GLSL or Cg, but in GLSL there are no more varyings and attributes. Attributes are specified with "in", and varyings with "out" in the vertex shader and "in" in the fragment shader. Fragment outputs are specified with "out".

Built-in matrix functions: all of the built-in matrix functions (glTransform/Rotate/Scale, etc.) are deprecated. Instead, you should make your own matrix math library or download an existing one to handle your transformation and projection matrices, then pass these matrices to your shaders.

In short, you're handling a lot more on your own than in previous versions. Nonetheless, it feels much better than previous versions, IMO. You don't *have* to use all of the functionality I listed above, but if you're serious about OpenGL I would highly recommend doing so. If you have any questions, I'll attempt to answer them.

i like orange
heyufool1
16
Years of Service
User Offline
Joined: 14th Feb 2009
Location: My quiet place
Posted: 30th Jun 2010 01:58 Edited at: 30th Jun 2010 02:03
Actually I made that change while I was going through changing everything to strings. Didn't really give a FPS boost though

The reason that I don't use the glutBitmapCharacter is because I don't know how to make that work using Windows fonts. (like the window's CreateFont function).

I also found some extraneous for loops throughout my code so I removed those from the main loop and gained about 10 FPS. Here's so far what I have with the text printing:

I tried finding a replacement for the glLists because of the deprecation but I haven't found anything yet so hopefully that's the reason why my FPS is lower.

@AndrewT Wow! Did not know all that was deprecated... Looks like I got some work ahead of me for I use most of that , oh well.
Btw, I just commented out the glListBase and glCallList lines and I went from about 600 FPS to about 920 so that's obviously the reason behind the FPS loss. So what's the "new" way of doing this text business without using the lists? Thanks for your help so far!

"So hold your head up high and know, it's not the end of the road"
Up-coming RPG!
AndrewT
18
Years of Service
User Offline
Joined: 11th Feb 2007
Location: MI, USA
Posted: 30th Jun 2010 02:11
I'm about to eat dinner, so I'll give you some more extensive help in an hour or two. But I'll see what I can do for now.

The most important thing to know about rendering now is using VBOs. It shouldn't be hard to find information on using VBOs. Once you've implemented VBOs, you can add VAOs, which will clean up your code quite a bit. I won't be able to post any code until later tonight, but you can consult the link I posted if needed.

i like orange
heyufool1
16
Years of Service
User Offline
Joined: 14th Feb 2009
Location: My quiet place
Posted: 30th Jun 2010 02:13
Quote: "The most important thing to know about rendering now is using VBOs. It shouldn't be hard to find information on using VBOs. Once you've implemented VBOs, you can add VAOs, which will clean up your code quite a bit. I won't be able to post any code until later tonight, but you can consult the link I posted if needed.
"

Ok, thanks for the info!

"So hold your head up high and know, it's not the end of the road"
Up-coming RPG!
Jeff032
17
Years of Service
User Offline
Joined: 13th Aug 2007
Location:
Posted: 30th Jun 2010 02:32 Edited at: 30th Jun 2010 02:33
The way XNA does text is the following:

-You add a spritefont file to your project, which contains information such as the font name, font size, characters needed, etc.
-At compile time, the information in the spritefont file is used to render a spritesheet
-Then at runtime, the spritesheet is loaded as a texture, and a rectangle is drawn for each character of whatever strings are being drawn.

(Given that the class that does this is called SpriteBatch, it most likely batches all the rectangles together into a single draw call.)

Not sure that helps at all, just thought I'd share one way I've seen it done.

heyufool1
16
Years of Service
User Offline
Joined: 14th Feb 2009
Location: My quiet place
Posted: 30th Jun 2010 02:48
Quote: "Not sure that helps at all, just thought I'd share one way I've seen it done."

Thanks, I have seen this method used in opengl before, but I'm just trying to avoid it.

"So hold your head up high and know, it's not the end of the road"
Up-coming RPG!
AndrewT
18
Years of Service
User Offline
Joined: 11th Feb 2007
Location: MI, USA
Posted: 30th Jun 2010 03:03
I just typed up a huge post attempting to explain everything in one go, but it was a mess. Really, the best thing to do is take it one step at a time. First, learn about VBOs. VBOs are actually very similar to display lists. The only differences are how you create/use them and the fact that they're optimized with modes for static, dynamic, and streamed data. I would post some links but really all you have to do is google "VBO tutorial". Once you've ported your code to VBOs the rest is fairly easy.

The next thing you'll want to do is implement VAOs. A VAO is basically a collection of one or more VBOs and their corresponding information. I don't know if there are any good tutorials on these, but they're ridiculously easy and I can show you how to use them once you've reached this point.

Then you'll want to ditch the fixed-function pipeline. In other words, you'll want to remove any glColor/glMaterial/glLight/glTexCoord/etc. calls, and switch over entirely to shaders. Rather than using the default gl_Position/gl_Color etc. inputs, you'll create your own and pass them to the shader with glVertexAttribPointer().

Finally, you'll want to stop using the built-in matrix functions and find a free 3D math library, or make your own if you're feeling ambitious. Then you'll pass your transformation and projection matrices to your shader and use those instead of the default gl_ModelViewMatrix and gl_ProjectionMatrix.

You might be a little intimidated right now, but really it's not as hard as it looks. The biggest obstacle is the lack of good tutorials that don't use any of the deprecated functionality, so if you have any questions I'll do my best to answer them.

i like orange
heyufool1
16
Years of Service
User Offline
Joined: 14th Feb 2009
Location: My quiet place
Posted: 30th Jun 2010 03:28
Thanks for the post! I started looking at VBO's and it's going pretty well. I have to make dinner now but hopefully before I go to bed I can the VBO stuff done. Thanks again for your help!

"So hold your head up high and know, it's not the end of the road"
Up-coming RPG!
AndrewT
18
Years of Service
User Offline
Joined: 11th Feb 2007
Location: MI, USA
Posted: 30th Jun 2010 04:00
Yep no problem. Really VBOs and shaders are the most important things to learn. You're obviously going to want to learn VAOs too, and get away from the built-in matrix functions as well, but those are much less important than VBOs and shaders.

i like orange
heyufool1
16
Years of Service
User Offline
Joined: 14th Feb 2009
Location: My quiet place
Posted: 30th Jun 2010 19:30
Ok after a good nights sleep I got the VBOs working in a couple of minutes. Now I want to change my per pixel lighting to be non deprecated. But, before I do this I just want to make sure that I should NOT be using any of these types things:

gl_LightSource[0]
gl_TexCoord[0]

And instead should send my variables from the program to the shader. Correct?

"So hold your head up high and know, it's not the end of the road"
Up-coming RPG!
AndrewT
18
Years of Service
User Offline
Joined: 11th Feb 2007
Location: MI, USA
Posted: 30th Jun 2010 20:51 Edited at: 30th Jun 2010 20:53
Correct. OpenGL will not be doing anything light or material related for you. You'll want to create your own material and light structures, and pass the properties (position, diffuse, ambient, etc.) to shaders as uniforms.

With regards to vertex attributes (texcoords, position, normals, etc.), these things are sent on a per-vertex basis, so obviously they won't be sent as uniforms. Instead, you'll call them "in" variables in your vertex shader, and you'll have to set them yourself with glVertexAttribPointer.

Your vertex shader will declare some generic attributes like so:



When you're loading the shaders, you'll want to bind the variables to attribute IDs like so:



When rendering, you set these attributes with glVertexAttribPointer like so:



(note that the code is BlitzMax, not C++, but the differences are negligible here)

i like orange
heyufool1
16
Years of Service
User Offline
Joined: 14th Feb 2009
Location: My quiet place
Posted: 1st Jul 2010 01:20 Edited at: 1st Jul 2010 01:26
Well! I'm having a bunch of troubles with removing this deprecated stuff. I have VBO's and lighting working without using the glEnable(GL_LIGHT0); stuff but I can't get textures working. I also can't get VAO's working, glGenVertexArrays(..) is apparently undefined along with glBindVertexArray(..). So, I'm getting pretty frustrated that I spent a few long days reading and learning deprecated OpenGL functions. So... Is it 100% necessary to remove the deprecated functions and only use non deprecated? Like will the future non deprecated functions ever really surpass the current deprecated functions?

"So hold your head up high and know, it's not the end of the road"
Up-coming RPG!
AndrewT
18
Years of Service
User Offline
Joined: 11th Feb 2007
Location: MI, USA
Posted: 1st Jul 2010 02:53 Edited at: 1st Jul 2010 02:55
Quote: "So... Is it 100% necessary to remove the deprecated functions and only use non deprecated?"


It's not 100% necessary. They're faster on most hardware and generally cleaner, but you're not required to use them.

Quote: "Like will the future non deprecated functions ever really surpass the current deprecated functions?"


Surpass? In terms of speed, or what? As far as speed goes, they've already surpassed the current deprecated functions on any hardware that isn't ancient.

The only reason you would use deprecated functionality is if you were specifically targeting older hardware. Older video cards are optimized for older OpenGL functionality, whilst new video cards will be optimized for newer functionality. As time goes on, the gap in speed between the older functionality and newer functionality is just going to get bigger, and eventually you'll be forced to switch over to the newer functionality. If you're going to have to learn it in the future, you might as well learn it right now, while your engine is still small and easy to port over. If you wait too long, it will be so much work to convert everything that you'll be forced to do a rewrite.

Quote: "but I can't get textures working"


What about textures is giving you trouble? Here's how you should be doing things. First load the textures--there's nothing you need to change in this step. Next, set the current texture the same way you were doing it before--use glActiveTexture() to set the active texture unit, then bind your texture to it with glBindTexture(). You don't actually have to pass the texture to your shader. Basically, you can access the current textures from your fragment shader simply by declaring a uniform sampler2D. Any sampler2D variables you declare in your fragment shader are automatically set to the corresponding active texture. If you have the following in your fragment shader:



then myTexture will automatically be set to GL_TEXTURE0, and myOtherTexture will be set to GL_TEXTURE1. You can set them manually if you'd like, but you can do this for now because it's simpler. Next, you need to pass the vertex texture coordinates from the vertex shader to the fragment shader. In your vertex shader you can declare an in vec2 in_TexCoord. Set this, of course, with glVertexAttribPointer(). Then, declare an out vec2 ex_TexCoord, and set it to the value of in_TexCoord somewhere in your shader. Now, to access that variable in your fragment shader, declare an in vec2 ex_TexCoord, and you can retrieve the color of the texture for that fragment with texture2D(myTexture, ex_TexCoord).

If you need any help you can post some code.

i like orange
heyufool1
16
Years of Service
User Offline
Joined: 14th Feb 2009
Location: My quiet place
Posted: 1st Jul 2010 18:57
Thanks for the detailed response! I got everything working now hopefully without using deprecated functions, and I finally got Windows UI working with the opengl window. So, now I can get ditch my GUI class which caused the massive FPS drop. Thanks for all your help!

"So hold your head up high and know, it's not the end of the road"
Up-coming RPG!
AndrewT
18
Years of Service
User Offline
Joined: 11th Feb 2007
Location: MI, USA
Posted: 1st Jul 2010 19:29
Yep no problem.

i like orange

Login to post a reply

Server time is: 2025-05-24 01:19:12
Your offset time is: 2025-05-24 01:19:12