Augustine: Despondent
Welcome to our Forums! Please login or register! You can introduce yourself here!







Augustine: Despondent

Welcome to the forums! We are the homeplace for Slender: Darkplaces, Augustine, Nightfall survival, and Revamped 1.


You are not connected. Please login or register

Working on a game engine

View previous topic View next topic Go down  Message [Page 1 of 1]

1 Working on a game engine on Sat Dec 03, 2011 7:05 pm

DukeInstinct


Commander Grade 3
Commander Grade 3
Since Sunday, I've been working on a custom game engine being written entirely in C++. I've mainly focused on the graphics part which uses OpenGL. I'm much more experienced with DirectX but OpenGL is portable. I'm also using the SOIL library to load image files such as .pngs and .jpgs. Currently the engine should require very little change to port it from Windows to another platform. I plan for the engine to use it's very own scripting language for the game logic which should also work on any platform that has an interpreter for it.

Currently the engine has these things accomplished or almost accomplished:

Initialization Process: This part includes creating the program's window and enabling OpenGL to use it. (DONE)

Rendering Pipeline: This part of code is called every frame to clear the back buffer, render everything on it, then swap the back buffer with the front one so it shows on screen. For any of you who don't know, this is called double buffering, without it you would see everything get drawn on the screen one at a time. With double buffering one buffer gets displayed to the screen while the other gets the next frame drawn onto it. In addition to this, the pipeline also decides in what order to draw certain things, how to draw them, and what GL features should be enabled when drawing them. This part cannot be completed until all the other graphical features have been added. (MOSTLY DONE)

Texture management: The image file is loaded with SOIL and then made into a OpenGL texture. I've created a system to store the ids to these texture so they can properly be deleted at the end of the program or referenced later. First I tried using a linked list. Linked lists are good for storing a list of items with no set amount of them. It can add and delete items at any time with relatively no problem. However, I'm only storing unsigned integers (which are the texture ids) and linked lists are overkill for smaller data types like this. Another problem is that GL's function for deleting textures only takes arrays as a parameter instead of individual texture ids. So instead I ended up using a basic array that is dynamically created at run time and resized to add new textures. This way isn't as good for adding textures on the go, because in order to resize the list to hold the new items, a new bigger array must be created, then have the data from the old array transferred to the new array, and then delete the old array. This must be done every time. While this is could be a problem for adding textures while the game is running, for the most part the game only needs to load new textures during a level switch. I also created a function to resize the array in preparation to add a group of textures instead of one at a time, so it only needs to be resized once. This should optimize the initial loading during a level switch. (DONE)

Text rendering: There's a couple different ways of doing this. All with their advantages and disadvantages. The method I used is to have one big texture with each letter/number/symbol in it. The texture is put on a 3d plane but instead of showing the whole texture, the texture coordinates of the plane is changed to show only the letter/number/symbol needed. This requires only one texture to be loaded and only uses 2 tris for each character drawn. The texture coordinates for each letter are defined by a custom file format I made just for this. Currently these files must be typed by hand and are time consuming to make. However, they allow a lot of flexibility in where the characters can be on the texture and what size they can be. Any letter/number/symbol not defined in the custom file format are ignored by the engine and is simply not drawn. Loading and rendering is all handled by a C++ class I created. Rendered text can be put anywhere in 3d space, at any size, any color, and with a specific character spacing set with a simple function call including the string of text to be drawn and values for these as parameters. Justification to the left, center, or right is planned but not currently working. (MOSTLY DONE)

Particle system: Adding this feature was relatively easy and straightforward than I thought it would be. A single particle system contains several arrays of the same size to represent each particle. It includes particle position, particle velocity, particle lifetime, particle opacity, particle size, and whether the particle is active. The particle system itself also includes variables defining the inital position, random offset, initial velocity, random velocity, initial life time, random life time, initial opacity, random opacity, initial size, random size, max particles, spawn interval, and acceleration. When it's time to creat a new particle, the particle system uses an integer (initially set at 0) to designate which set of array cells are to be initialized for the new particle. The integer is then incremented by one in preparation to set up the next new particle. Once the maximum amount of particles have been created, the integer is reset to the first cell in the arrays to start overriding the oldest particles created. Every frame, a "for" loop is ran to render each active particle as a quad (two tris) with the texture the particle system was loaded with. After being rendered, the particle is then updated which includes adding it's velocity to it's current position and adding the acceleration of the particle system to the current velocity to constantly move the particle. Acceleration is mostly for simulating gravity. The particle system is handled by another C++ class. While the particle system works very well for the most part, I still need to add "one shot" particles which delete when they have created the maximum amount of particles and they have expired. (MOSTLY DONE)

Input: Not much to say about input. Keyboard input is done and optimized to only check for the keys that are actually used by the game and an array of booleans are updated to reflect whether each key is pressed or not. Mouse movement is completed, but not mouse clicks. Mouse movement is accomplished by setting the cursor at the center of the screen, then at every frame checking how much it moved from the center if at all, then setting it back to the center of the screen. (MOSTLY DONE)

These are the major things that are done or close to it. Still a lot more to do and plan.

I was going to use "Instinct" for the engine's name but apparently some fat guy already stole that one.



2 Re: Working on a game engine on Sat Dec 03, 2011 7:26 pm

%ERROR%


Legend
Legend
How about you call it Dine-ary?



破壊衝動と生命についての考察
http://yourdoomed.canadian-forum.com/

3 Re: Working on a game engine on Sun Dec 04, 2011 6:06 pm

_shameless_


Colonel Grade 3
Colonel Grade 3
very impressive man! think a dreamcast port would be in the near future? Smile

4 Re: Working on a game engine on Mon Dec 05, 2011 2:26 am

DukeInstinct


Commander Grade 3
Commander Grade 3
Mute wrote:How about you call it Dine-ary?

I don't get it.

_shameless_ wrote:think a dreamcast port would be in the near future?

I would describe the possibilities of that as marginally inconceivable.



5 Re: Working on a game engine on Mon Dec 05, 2011 3:19 pm

%ERROR%


Legend
Legend
Dineary, kinda like binary... idk, I\'ll think of another name, gimme a sec



破壊衝動と生命についての考察
http://yourdoomed.canadian-forum.com/

6 Re: Working on a game engine on Mon Dec 05, 2011 9:48 pm

thonglover


Hero
Hero
How bout.... double cross engine?

7 Re: Working on a game engine on Fri Dec 09, 2011 2:04 am

DukeInstinct


Commander Grade 3
Commander Grade 3
Kinda been slacking off and haven't really added much. Last week I worked on the thing till 3 AM practically every day. So that is my excuse to not do as much this week. I did however organize the code a lot better this week and started documenting some of it which is important too.



8 Re: Working on a game engine on Fri Jan 06, 2012 3:47 am

DukeInstinct


Commander Grade 3
Commander Grade 3
Got my game engine to use SDL and is completely free from the Windows API. It should now work on Windows, Macs, Linux, and most notably the Dreamcast. I just need an Codeblocks extension that compiles for Dreamcast.

The size of the source code has increased by about 3-4 times more than when I last posted. All the 2D rendering features I have in mind are almost finished. There's not really a whole lot though. Just text rendering, simple sprites (with tinting and alpha transparency), and tiling sprites. I can't really think of any other useful 2D elements.

I'm currently working on menus. Menu information is loaded at run time from a file so you don't even need to touch the source code to change and add menus. You can make all the buttons, simple labels, or icons you want in the file. Buttons can be assigned actions from the file as well. So far quitting the application works perfectly. Actions will also include moving to another menu, changing game settings, resuming the game, loading a specific level, and most likely even more. The main obstacle is using pre-loaded resources with menus. Right now, images have to be loaded multiple times if the menu uses them multiple times or other menus use the same image. I'm thinking of a file that specifies images to be loaded and to give them IDs and the menu files use the ID instead of the image's file name. More advanced GUI elements such as scrollers, editable text boxes, etc. will probably also be added. Option, player setup, and save menus could benefit greatly from these.

Here's a working example of one of these menu files:

Code:
2
4 200 200 96 32 0 PlayButton.PNG;
4 200 136 96 32 Q QuitButton.PNG;

The first number in the file defines how many elements(buttons) are in the menu. Each line after that defines an element(button). The first number indicates the element's type (1 = label, 2 = icon, 3 = text button, 4 = icon button). The next 4 numbers specify X position, Y position, width, and height respectively. Then a letter or symbol designates the button's action. Q stands for Quit. The text after that is the text to be rendered on screen or the image to load and render depending on if the element is a label or an icon. The semicolon separates each menu element.

Here's a preview showing particles, text rendering, sprites, and the menu system in action:



The HUD will also be loadable from a file when I get around to it.

I have already began making art for a small 2D game called "Super Nova" to demonstrate the engine.



9 Re: Working on a game engine on Fri Jan 06, 2012 1:14 pm

$H@D()W


Field Marshal
Field Marshal
great job man, at first I never knew you could code, but now i believe you are extremely professional Smile

DukeInstinct=GodInstinct

10 Re: Working on a game engine on Sun Jan 22, 2012 4:25 pm

DukeInstinct


Commander Grade 3
Commander Grade 3
*Changes*
Minor updates to my font loading/rendering class. Improved code design, and significantly increased memory efficiency per instance.

Menu buttons can now use up to 3 images. One for normal, one for active, and one for pressed. I changed the file format a bit too. Also increased memory efficiency in this area as well.

Added resource pooling for textures. Textures ids can be saved to a temporary file and can be found later in the program using a tag.

*Additions*

Lens Flare Effect:





And additive blending(also applies to particles):




11 Re: Working on a game engine on Sun Jan 22, 2012 9:03 pm

$H@D()W


Field Marshal
Field Marshal
Epic job, man, and i think u should call it "Ha-DUKE-n"

12 Re: Working on a game engine on Sun Jan 22, 2012 11:25 pm

Supermario641996


Reclaimer
Reclaimer
xD Shadow. This looks cool Duke!




Shhh, it's Mario.  Don't forget to introduce yourself to our community here and our Discord group here. Very Happy
http://augustine.forumotion.com/

13 Re: Working on a game engine on Sat Jan 28, 2012 5:00 am

DukeInstinct


Commander Grade 3
Commander Grade 3
Took me several hours but I have managed to write a loader for .obj model files. Vertex locations, texture coordinates, vertex normals, and poly data is loaded and stored to a mesh object from an .obj file and can then be rendered like any other shape.

I have also written a loader for .mtl files which hold material information and come with .obj files.

Currently the code for these can be improved and optimized a lot more but for now it works pretty well.



Other 3d model files I will probably create loaders for include:

  • .blend files
  • .fbx files
  • .3ds files
  • .md3 files



14 Re: Working on a game engine on Sat Jan 28, 2012 6:24 am

Supermario641996


Reclaimer
Reclaimer
I like the Tree.




Shhh, it's Mario.  Don't forget to introduce yourself to our community here and our Discord group here. Very Happy
http://augustine.forumotion.com/

15 Re: Working on a game engine on Sat Jan 28, 2012 11:37 am

thonglover


Hero
Hero
*pisses on tree* trollface.png

16 Re: Working on a game engine on Sat Jan 28, 2012 11:45 am

_shameless_


Colonel Grade 3
Colonel Grade 3
leaves of the tree remind me off cannabis plant...xD
anyways great job duke! i'll get you a dc compiler Razz

keep up the progress!, quick question, how will model animations work?

17 Re: Working on a game engine on Mon Jan 30, 2012 5:45 pm

DukeInstinct


Commander Grade 3
Commander Grade 3
It'll be skeletal animation for the formats that support it. Each vertex will need to carry an additional byte of memory for the identification number for the bone they belong to and simply get translated, rotated, and/or scaled during rendering according to changes that happens to the bone in the current frame. I want to keep vertices as small as possible, but 1 byte will be enough to allow at the max 256 bones (which is plenty).

.obj files don't support skeletal animation but instead can have multiple models representing each frame but this method is significantly less memory efficient.



18 Re: Working on a game engine on Fri Feb 03, 2012 3:04 pm

DukeInstinct


Commander Grade 3
Commander Grade 3
Managed to implement Quaternions last night. They require some advanced math but I heard they were well worth the effort and I have not been disappointed by them. The player can now rotate and move in the direction they are facing with the help of quaternions and it was so easy to program that functionality after I finished making my quaternion class.

Before deciding to use quaternions, I was trying to use Euler angles to represent the player's rotation and it worked for turning, but failed horribly when trying to convert to a directional vector to move forward in the direction the player faced. It only worked when facing certain directions, you could merely turn to the right or left and you would suddenly start moving in an odd direction.



19 Re: Working on a game engine on Sat Feb 04, 2012 3:43 pm

_shameless_


Colonel Grade 3
Colonel Grade 3
nice man very nice. have no idea what quaternions are but if it works niiice

20 Re: Working on a game engine on Sat Feb 04, 2012 6:30 pm

DukeInstinct


Commander Grade 3
Commander Grade 3
It's basically four numbers grouped together that represent a rotation in 3d space.



21 Re: Working on a game engine on Sun Feb 05, 2012 1:16 am

Mexicouger


Noble
Noble
Duke I just want to say that this looks very cool and great job!




Contemplating on how to fix problems...
http://augustine.forumotion.com

Sponsored content


View previous topic View next topic Back to top  Message [Page 1 of 1]

Permissions in this forum:
You cannot reply to topics in this forum