• Content count

  • Joined

  • Last visited

Community Reputation

311 Neutral

About flyslasher

  • Rank
  1. Side Scroller level textures

    I've seen something like what you want, but on a 2D tiled multidirection kind of game. I suppose the same could be achieved if you created small tiles that have a few options in what they can merge into( grass texture A can merge into texture B, C, and D to the right. This makes random generation of placement of textures ) and you can even break up some textures into their own thing like vines could be littered around and the same for foliage or small objects that protrude from the game. But making things like the sloping hills or even making it look nice would take lots of varying options( like a lot of lots ). It seems like too much work, art and programming wise to even bother to implement. Hand drawing the map is the easiest and most effective way to do it and will end up looking more aesthetically pleasing. The only thing it wouldn't work for is randomly generated maps that are unique from each other which would be one of the few reasons to do it the harder way( Look at terraria, it achieves this and looks very good, but you can still see gaps in the fluidity ).
  2.   Is this mainly because to avoid bad design when programming the game? I actually found myself using mostly composition.    If you're programming a game using ECS, you need to stop trying to build entities using inheritance, but rather composition.  It was in response to the OP's design of having an CharacterInputComponent inherit form an InputComponent (I'm OK with having a base Component class).   Sorry. Those inherited classes weren't meant to be there. It was a short term solution so I could do some testing of functionality.
  3. "What language should I start off with?" "Should I use an engine or start from scratch?" "Why isn't my model drawing?" "My implementation of linear interpolation isn't working, why?" "What are some tips for making system independent code?" These are the questions you should be asking.
  4. For working with 3D graphics Matrices are what you'll most likely be working with as they make complex problems relatively simple and are very powerful. Understanding trigonometry both in 3D and 2D space is quite helpful as well. Depending on what you are doing in your game you can scale through lots of levels of math, but just remember you don't have to be a genius in math to program them. Formulas already exist and I think it's more important to know how to look at a concept or loose formula and implement it. Knowing the math makes it easier, but without doesn't make it impossible.
  5. I think if you want to send data between components, you should have them an anchor to a common root which actually handles sending the information between components. For example, in my game, I have components bound to individual entities which gives them functionality. I also have some specialized components such as an InputComponent and a RenderComponent. Each component haves a pointer back to it's root entity and my entity has a function called BroadCastMessage( MessageClass data ) which calls the function RecieveMessage( MessageClass data ) for all bound components. All my component has to do is use it's pointer to its root entities to broadcast a message to other components. My MessageClass is basically this: struct MessageClass { char* pchName; void* pvData; } You would use the name to listen for certain events from other components like maybe "UpdateXPos" or something to that effect. Also since I know how a message would be built based on the name, I'll know how to typecast the data to its correct format. Another way you might do it, but it leads to a bit more work, is to use an array of bytes for the data. You would have to break down the data you need to send into individual bytes and then rebuild it up when a component receives it.   EDIT Here's a complete example: //InputComponent void KeyPressed( char chKey ) { if( chKey == 'w' ) { int iMovement = 10; pEntity->BroadcastMessage( MessageClass( "UpdateXPos", &iMovement ); } } //RenderComponent void RecieveMessage( MessageClass data ) { if( strcmp( data.pchName, "UpdateXPos" ) == 0 ) { m_iPosX += *((int*)data.pvData); } }
  6. 2D Collision Reponses

    This is just a thought, but it should do what you need to do if the math in my mind isn't hazed over from last night. Using vectors you can calculate the distance from object 1 to object 2 and subtract the two distances from the origins of the objects to their respective edges. If it's less than 0, it means you are colliding and then use the overlapping vector components to calculate where you need to push the object away.
  7.   Ah thanks. That's a good point and something I kind of skipped because I wasn't sure which route was best. What would be the best way, for example, to add input for components? I think, but am not sure, that I can use a callback function and pass a function pointer into my main engine that would handle all input. That callback function would have parameters for component names and the key/mouse information. Then as the game changes states( main menu to actual game play ), I can change the pointer to the relevant function.
  8. So I am trying to implement a component design and I am currently unsure if I am implemented it effectively or correctly. My classes and their children are as follow:   1. MainGame 2. VideoManager 3. EntityManager 4. Entity |---6. InputComponent |---8. CharacterInputComponent 5. Component | |---7. RenderComponent |---9. CharacterRenderComponent 10. SmartList 1. So the main game class holds function for initializing, running, and terminating the game. It also has a pointer to the various managers( more will be added for like sounds or resources ) which manage more specialized parts of the game. 2. The video manager has collection of the shaders, the projection and view matrices, etc.. all for handling the drawing commands. 3. The entity manager has a list of all entities that are in the world and knows to update them if need be( drawing, input, etc. ). The list is my SmartList. 4. The entity has a list of components that are linked to it. These components give all functionality to the entity other than the basics. It operates kind of like a unique component manager. 5. This is a base class that only really defines a function( update call ) used by all components and the unique string id of all components( for use in my smart list ). 6 & 7. These are specialized components that have specific roles, one for rendering and one for input. More will inevitably be made. 8 & 9. These would be the actual components that I would link to my entities since they implement the functions more specifically. 10. It's my own template class that can store and sort through all the objects. It uses double pointers and a binary search to look up things and a merge sort to keep everything in order. Memory is automatically allocated as the list grows/shrinks in exponents of 2. Through template classes and function pointers I can use this for any value and sort by any value such is integers, strings( as for my use ), or even complicated sets of data with specialized comparison. Now here is how the flow of a input and render call. //Draw a single scene and starts in the main game loop MainGame -> VideoManager -> EntityManager -> Entity -> RenderComponent //Input detected GLFWCallback -> EntityManager -> Entity -> InputComponent Here is my main.cpp and how it starts/run the game + making entities and components. #include "GameClass.h" #include "EntityManager.h" #include "Entity.h" #include "components/InputComponent.h" #include "components/RenderComponent.h" #include "Logger.h" using namespace std; struct MyInputComponent : public InputComponent {     void KeyPressed( int iKey, int iAction )     {         if( iKey == GLFW_KEY_ESCAPE && iAction == GLFW_PRESS )         {             GameClass::GetGameInstance()->EndGame();         }     } }; int main( int argc, char* argv[] ) {     GameClass* pGame = GameClass::GetGameInstance();     if( !pGame->InitGame( 640, 480, 640, 480, "My Game" ) )     { Logger::Log( "", "Couldn't initialize game." );         return 1;     }     EntityManager* pEntityManager = pGame->GetEntityManager();     MyInputComponent* c = new MyInputComponent();     b->SetComponentName( "InputComponent Dude" );     Entity* a = new Entity();     a->SetEntityName( "EntityA" );     Entity* b = new Entity();     b->SetEntityName( "EntityB" );     pEntityManager->AddEntity( a );     pEntityManager->AddEntity( b );     b->BindComponent( c );     pEntityManager->RemoveEntity( pEntityManager->LookUpEntity( "EntityA" ) );     pEngine->RunEngine();     pEngine->TerminateEngine(); delete a; delete b; delete c;     return 0; } I'm also trying to do my best to stop decoupling. For example my VideoManager shouldn't need to know about entities or components hence why the flow chart goes in such steps, but I am worried it's adding extra overhead. This is my first time working a larger project. I would like some suggestions or notable problems with my design so I can refactor my code. I usually develop for a while, assess all issues, and rebuild it from scratch more streamlined, but my limited experience doesn't make it easy to assess everything completely.
  9. Shader issues. Not drawing a box.

    Okay. So I changed my version and did some checking to make sure that everything compiles/links fine, which it now does, but the problem still continues. I tried using more simpled down shaders that should work, but nothing: const char* pchVertexShaderCode = "#version 330\n" "layout( location = 0 ) in vec3 vertex_position;" "uniform mat4 model_matrix, view_matrix, projection_matrix;" "void main() {" " gl_Position = projection_matrix * view_matrix * model_matrix * vec4( vertex_position, 1.0 );" "};"; const char* pchFragmentShaderCode = "#version 330\n" "out vec4 frag_color;" "void main() {" " frag_color = vec4( 1.0, 1.0, 1.0, 1.0 );" "}"; Edit: Okay I managed to draw the square by scaling my model matrix. I'm not sure, but it's not drawing my square correctly. If I leave the scale at for the model matrix, the square only appears as a single pixel on the screen.  
  10. Shader issues. Not drawing a box.

    Thanks. It helped solve a bug in my fragment shader, but I am getting a bug in my vertex shader that I don't reall understand. "Error: 0:2: 'location' : syntax error syntax error"
  11. Hello. I am trying to render a 2D white box. Well actually I wanted to render a texture, but am making sure that at a minimum I can render an empty square to know what I have done so far is working. Well it's not. I get a black screen with no white square as I expected. Here is my drawing: glClear( GL_COLOR_BUFFER_BIT ); //GLint iTexture = glGetUniformLocation( m_uiShaderProgram, "texture_sampler" ); glUseProgram( uiShaderProgram ); //glUniform1i( iTexture, 0 ); glUniformMatrix4fv( glGetUniformLocation( uiShaderProgram, "projection_matrix" ), 1, GL_FALSE, glm::value_ptr( mat4ProjectionMatrix ) ); glUniformMatrix4fv( glGetUniformLocation( uiShaderProgram, "view_matrix" ), 1, GL_FALSE, glm::value_ptr( mat4ViewMatrix ) ); glUniformMatrix4fv( glGetUniformLocation( uiShaderProgram, "model_matrix" ), 1, GL_FALSE, glm::value_ptr( mat4ModelMatrix ) ); //glActiveTexture( GL_TEXTURE0 ); //glBindTexture( GL_TEXTURE_2D, uiTextureID ); glBindBuffer( GL_ARRAY_BUFFER, uiVertexBuffer ); glVertexPointer( 3, GL_FLOAT, 0, (void*)0 ); glBindBuffer( GL_ARRAY_BUFFER, uiTexCoordBuffer ); glVertexPointer( 2, GL_FLOAT, 0, (void*)0 ); glDrawArrays( GL_QUADS, 0, 4 ); And these are my initializations for the various buffers: //Shader program const char* pchVertexShaderCode = "#version 150\n" "layout( location = 0 ) in vec3 vertex_position;" "layout( location = 1 ) in vec2 vertex_uv;" "out vec2 uv_coord;" "uniform mat4 model_matrix, view_matrix, projection_matrix;" "void main () {" "  gl_Position = projection_matrix * view_matrix * model_matrix * vec4( vertex_position, 1.0 );" "  uv_coord = vertex_uv;" "}"; const char* pchFragmentShaderCode = "#version 150\n" "in vec2 uv_coord;" "out vec4 frag_color;" "uniform sampler2dD texture_sampler;" "void main () {" //"  frag_color = texture( texture_sampler, uv_coord ).rgb;" "   frag_color = vec4( 1.0, 1.0, 1.0, 1.0 );" "}"; unsigned int uiVertexShader = glCreateShader( GL_VERTEX_SHADER ); glShaderSource( uiVertexShader, 1, &pchVertexShaderCode, NULL ); glCompileShader( uiVertexShader ); unsigned int uiFragmentShader = glCreateShader( GL_FRAGMENT_SHADER ); glShaderSource( uiFragmentShader, 1, &pchFragmentShaderCode, NULL ); glCompileShader( uiFragmentShader ); m_uiShaderProgram = glCreateProgram(); glAttachShader( uiShaderProgram, uiFragmentShader ); glAttachShader( uiShaderProgram, uiVertexShader ); glLinkProgram( uiShaderProgram ); //View matrix mat4ViewMatrix = glm::lookAt( glm::vec3( 0.f, 0.f, 1.f ), glm::vec3( 0.f, 0.f, 0.f ), glm::vec3( 0.f, 1.f, 0.f ) ); //Projection matrix mat4ProjectionMatrix = glm::ortho( 0.f, (float)iWindowWidth, (float)iWindowHeight, 0.f, 0.01f, 1000.f ); //Model matrix glm::mat4 mat4T = glm::translate( glm::mat4( 1.f ), glm::vec3( m_fPosX, m_fPosY, 0.f ) ); glm::mat4 mat4Rx = glm::rotate( mat4T, m_fRotX, glm::vec3( 1.f, 0.f, 0.f ) ); glm::mat4 mat4M = glm::rotate( mat4Rx, m_fRotY, glm::vec3( 0.f, 1.f, 0.f ) ); glm::mat4 mat4S = glm::scale( glm::mat4( 1.f ), glm::vec3( m_fScale ) ); mat4ModelMatrix = mat4M * mat4S; //Vertex and tex coord buffer float fVertices[] = { 0.f, 0.f, 0.f, 100.f, 0.f, 0.f, 100.f, 100.f, 0.f, 0.f, 100.f, 0.f }; float fTexCoords[] = { 0.f, 0.f, 1.f, 0.f, 1.f, 1.f, 0.f, 1.f }; glGenBuffers( 1, &uiVertexBuffer ); glBindBuffer( GL_ARRAY_BUFFER, uiVertexBuffer ); glBufferData( GL_ARRAY_BUFFER, sizeof( float ) * 12, fVertices, GL_STATIC_DRAW ); glGenBuffers( 1, &uiTexCoordBuffer ); glBindBuffer( GL_ARRAY_BUFFER, uiTexCoordBuffer ); glBufferData( GL_ARRAY_BUFFER, sizeof( float ) * 8, fTexCoords, GL_STATIC_DRAW );
  12. Getting Started with Graphics. Help?

    If you want to tackle the basics of a game engine either for learning or you want to make your own game entirely from scratch, I'd say go for OpenGL. Unlike DirectX it's cross platform. It's not as well documented and you can find lots of conflicting tutorials such as ones that use old deprecated methods. If you want to go further, look into GLFW3, GLEW, OpenGL, and SOIL. Remember that these are just for graphics and user input. You'll also need things like OpenAL for sound and maybe other libraries.
  13. Freshie!

    You're an eager one aren't you? Games like those require skilled teams and months if not years of development, and that's even when beginning off of an engine with all basics already done for them. I'm not saying you can't do it, but you have to think small before you can think big. Make small simple games and work up your ability to program and create resources for your own games. Start with a simple pong game and other recreations of other simple games( mario for example ) until you can develop your skills to a point where you can effectively work with a team or create your own to tackle larger and more ambitious projects. I'd say take a look at the engines if all your interested in is game development. Unity, UDK, even Game Maker will do for the simpler projects. There's also other great light weight libraries and engines that should put you on the right track, some specifically created for the type of games you want to make.
  14. Resources to research rpg level growth + combat damage

    I'd imagine the math that they use in combat calculation and the growth of characters in a level style game wouldn't go any further than the bare minimum required in Highschool Math. Traditionally it has been that the basic stats would corellate with basic effects on the character. Strength is to damage, vitality is to health, dexterity is to attack speed, luck is to chance of "critical" hits, etc.. But there have been other types of systems that while they do stick somewhat to the roots, they have weapons scale to the stats of the character. For example in a game like Dark Souls I believe the katana type weapons were based heavily on the Dexterity attribute. Raising your Strength did little to improve the damage you did with a Katana. Simply looking at the graphs of linear and exponential functions should reveal effect they have. A game doesn't require complex math for the calculation of damage inflicted, or the players health, or the speed at which a player attacks. // Players damage is influenced by his strength and his skill with a sword Player.Damage = Player.Strength + ( Player.SwordSkill / 2 ); // Players health is 1.25x his vitality attribute Player.Health = Player.Vitality * 1.25; // Players attack speed relies on dexterity, but having a higher strength makes him move slower. Player.AttackSpeed = Player.Dexterity - ( Player.Stength * 0.05 ); These are all simple calculations but will get the job done.
  15. Freshie!

    So what are you asking for friend? Are you looking for some tutorials? Could you provide some specifics as to what kind of games and/or the mechanics you'd like to implement so someone can shoot you on the right way?   Also this: Is more basic math than it is programming. You're going to need a lot more under your belt If you're doing C++ and are interested in OpenGL, here are some things i've picked up... These tutorials use varying libraries, so these are the ones I've opted for all my development: SOIL( Graphics loading library ), GLFW3( Window and input handling ), and GLEW( Extension loading library ).