Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1398366 Posts in 67584 Topics- by 60921 Members - Latest Member: appkong

January 24, 2022, 06:09:17 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsHexlo
Pages: [1]
Print
Author Topic: Hexlo  (Read 2418 times)
Snakey
Level 2
**


View Profile WWW
« on: April 04, 2009, 01:29:06 PM »

So I figured I might as well start a small blog about how this project is developing and reflect this on my own blog too. I'd get more feed back this way as my blog has very few visitors Wink



The idea for this game came from another game prototype called Doomablo. It was a neat concept where the developer took the Doom art and put it in another world setting, which happened to be Diablo. Follow the link to read more about it, and there is a prototype floating around as well.

I played the prototype and I quite liked it, so I figured ... well, I think I could make one too using Hexen. I suppose I could have used Doom as well, but I didn't want to steal the idea that much :D.

Unlike Doomablo, I actually followed through with the legal aspects of this game. The engine will ask the player where Hexen's WADs are (Shareware, Hexen, Hexen expansion) and then load all of the game data from there. I've also asked Raven for permission to use the IP and Trademarks and they said it was fine for me to do it (as long as I don't sell it, which I didn't intend to do).

So, in this screenshot theres quite a few things going on. I've sorted out loading the WAD files and pulling out the graphics. I've also actually got the sounds working as well, but you can't quite represent that in a screenshot Big Laff. Theres also a newer iteration of my component system working within this engine which I talked a little bit about on IRC and on other threads here. The first few iterations just used nearest filtering to render onto the screen, but it hurt my eyes. So I switched on linear filtering and I get an artifact where black borders will surround a sprite. Its just due to the way linear filtering works, and I have a solution in mind on how to solve it, but I haven't quite written it yet. The idea just involves drawing new pixels so that the alpha mask falls within colors only. A pretty simple fix to the problem...

So far, I can draw random entities on the screen which can animate and do the fancy rotation thing (as in when the actor rotates, it picks the correct sprite direction to show) ... but it's not quite a game yet as the player can't do anything of interest. Hopefully over the next week or so, I'll add in a basic physics engine which will then allow the player to move around.
Logged

I like turtles.
jute
Level 1
*



View Profile WWW
« Reply #1 on: April 05, 2009, 05:18:01 PM »

This is promising!  Have you considered the possibility of also using Heretic resources, considering the obvious overlap?
Logged

Snakey
Level 2
**


View Profile WWW
« Reply #2 on: April 06, 2009, 06:27:01 AM »

Yeah, I definately have. I think I could almost perhaps lump it all together as one big game if you happen to have both Heretic and Hexen which could wind up being rather neat.
Logged

I like turtles.
george
Level 7
**



View Profile
« Reply #3 on: April 06, 2009, 06:05:38 PM »

There is something about those sprites that is supremely awesome. What is the main...compositional (?) difference between these and sprites drawn intentionally for an iso view?
Logged
Snakey
Level 2
**


View Profile WWW
« Reply #4 on: April 08, 2009, 02:12:16 AM »

I honestly don't know.I haven't changed any of the art and they are just sprites, so there isn't any perspective going on. I think I mostly got lucky!
Logged

I like turtles.
Snakey
Level 2
**


View Profile WWW
« Reply #5 on: April 21, 2009, 05:12:25 PM »

The important aspect about Hexlo is that it mainly serves as my highly experimental projects in which I inject a lot of my new experimental methods into. I find it a little easier to inject new methodologies into projects like this because of their scale. Anyways, in Hexlo I wanted to rethink about my component system again.

A component system is one where entities in the world has a list of components which then define how that entities looks like, sounds like, behaves like and so forth. For example, for a rocket entity you may have a mesh component which renders a rocket projectile mesh onto the screen, a sound component which plays back a “fssssssssh!” sound during the rocket’s flight and perhaps a script component which contains the logic for when the rocket contacts something. Component systems like this are designed for the end user in mind. It also helps code reusability and extending current classes rather than having to copy/paste sections of code for different classes that aren’t able to extend similar classes.

My first initial stab at a component system involved using a lot of RTTI (Run Time Type Information) which was functional at the time but certainly an unsafe method of doing things. It is unsafe to me, because you assume a few things. For example, consider:

Code:
if (component_ptr->GetType() == Enum_Mesh_Component)
  ((MeshComponent*)component_ptr)->RenderMesh();

You assume a few things with this sort of code. First, you assume that GetType() will always return the correct value for each class definition you write.

  • What happens if you forget to override the virtual function in your child class? Make it abstract you say?
  • What happens if you return a conflicting identifier to another class?
  • What happens if component_ptr is a child class of a child class of Component?

And lastly, your code will be littered with gigantic switch and if statements that may get out of control. Lastly, you simply assume that component_ptr is going to be MeshComponent. If it isn’t, then it is going to explode as you try to access a function from a class that doesn’t actually have it. There is simply no real fail-safe methods here. I suppose you may interject and suggest that I could have used dynamic_cast<> to provide fail safe methods. The main problem with using dynamic_cast<> is that it is rather slow in relative measures.

Certainly when everything is written correctly, everything would be fine. But that’s like saying that a program will never have bugs in it because everything will be written correctly.

My second attempt at a component system involved interfaces. This assumed that every component is just a component and that typing was unnecessary. The base class, Component, would essentially have a large list of virtual functions that were setters and getters for everything imaginable. While this was very fail-safe and anything error related was able to be caught during compile time, the base class became very bloated with one off virtual functions that would eventually create such a large virtual table for these classes that the amount of memory used per class would be huge. For example:

Code:
class Component
{
  virtual void Set(const unsigned int &id, const int &in)  { };
  virtual void Set(const unsigned int &id, const float &in) { };
  virtual void Set(const unsigned int &id, const short &in) { };
};

As you can imagine, not every component would require all of these virtual functions but they would still incur the penalty of having them within their virtual tables. I couldn’t make these into abstract functions because then every component would need to implement them anyways making every child class simple massive.

So with Hexlo, I wanted to avoid that sort of a setup because I knew it would be a horrible system to work with. While it was very safe, it was memory hogging and too bloated to be usable. So when I thought about it some more, I realized that most of the time it was the entities themselves that often needed to alter the properties of their own components. So with that in mind, since the owners of these class instances were the entities themselves, keeping a private pointer reference to the component would be fine. End users would also not have to care too much about the memory management of these pointers, since a pointer list would manage these class instances.

Code:
class Entity
{
public:
  void AddMesh()
  {
    m_mesh_component_ptr = new MeshComponent();
    m_components_ptr.push_back(m_mesh_component_ptr)
  };

private:
  std::vector<Component*> m_components;
  MeshComponent *m_mesh_component_ptr;
};

So, with that using m_mesh_component_ptr is used when the class itself wants to change any parameters within it, but I would suspect that the majority of the time this isn’t really required at all. So that’s nothing special just yet, but in this particular case, let’s use this within a rendering scenario.

Code:
class Viewport()
{
public:
  void Render(MeshComponent &mesh_component);
};

class Component()
{
public:
  void Render()
  {
    InternalRender();
  };

private:
  virtual void InternalRender() = 0;
};

class MeshComponent : public Component()
{
  virtual void InternalRender()
  {
    GetViewport().Render(*this);
  };
};

*GetViewport() returns the Viewport class instance as a reference

This sort of structure pretty much resolves most of the issues I came across with the top two methods. I don’t have huge banks of virtual functions that hardly ever get used by many child classes, I don’t require RTTI since C++ itself handles typing and it’s pretty darn fail safe at most areas. The only potential problem that could possible happen is that the amount of function calls that is required could be a little on the excessive side causing potential problems but I haven’t come across this yet in Hexlo. The only other ‘problem’ is that you have to write quite a lot of virtual functions within Viewport for all of the different component types you have. However, I don’t think that’s any different to having to write the actual rendering functions for handling the component anyways.

I’m feeling pretty good about this method right now. But perhaps in a few weeks, I might come up with an even better solution!
« Last Edit: April 21, 2009, 05:28:15 PM by Snakey » Logged

I like turtles.
Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic