Jump to content
  • Advertisement

ElJoelio

Member
  • Content Count

    15
  • Joined

  • Last visited

Community Reputation

164 Neutral

About ElJoelio

  • Rank
    Member
  1. Herro I'm looking for ideas on abstracting renderer objects (mesh, texture, etc) from the renderer implementation that uses them (DirectX, OpenGL, etc). Here's my plan of attack, using a mesh as an example: I have a CMesh class that has a function, Load(std::string &strFilename), that will load a mesh from disk into a polygon list. This bit works fine - I have the mesh data loaded into the CMesh class. My application can access the mesh data and do whatever it needs to do to it, animate it, etc. The renderer, however, prefers the mesh data be locked away in video card memory somewhere and in a format specific to the renderer implementation, e.g. DirectX wants the data to be copied into a Vertex Buffer or similar. If the local mesh data gets updated, the renderer is notified that it needs to update its own copy. This is fine, but it essentially means the mesh data will exist in memory twice - once in the application-supported format and once in the renderer's format. Is this method OK? The main disadvantage is the mesh existing in memory twice (once in system RAM and once in the video card's RAM). I guess also that if the application doesn't need to access and alter the mesh data, then the local data could be freed after uploading to the renderer. Does anyone have other ways to acheive the overall goal of renderer-independant mesh handling? Thanks Joel Malone
  2. ElJoelio

    Baby steps...

    I like to think that while the distance between Jack and the Mountain Dew may approach 0 but never quite reach it, eventually the distance will be <= arm_length! At this point Jack will consume the mountainous dew.
  3. ElJoelio

    Baby steps...

    Wow, comments! Is there a way I can get notified when someone adds a comment to my journal? JTSlade, you can contact me on my hotmail.com address, username eljoelio. And thanks for the ratings! Does a higher rating make me grow larger, like the creatures in Blank&White?
  4. ElJoelio

    Fitter, Happier, More Productive

    I had hit a bit of a slump with the progress of the engine, mainly due to the initial design showing its flaws. One such problematic system was the resource manager that handles loading and sharing of textures, meshes, etc - it worked, but I wasn't happy with the way it had turned out so I started a new side project to prototype different ways to handles resources. The prototype's design turned out to be quite good, so I implemented a few other systems from the main project into it to see if the new design was actually feasible. It was, and soon enough I'd added all the other systems, and the prototype became v2 of the engine! I have just brought the new engine up to the same point the old engine had reached, and the design is much clearer this time around. I won't go into the details of the old engine's design, but the new engine basically consists of these objects: Application - acts as the interface between the engine, the player at this machine, and the OS. This object contains a single Engine instance, which it initialises and sends update commands to. The application contains the 'main game loop', similar to: Handle events from the OS Tell the engine to update itself (which in turn will update the world) Tell the player to render World Domination sorry, wrong list Engine - the engine. This will contain a reference to the game world, as well as act as the 'owner' of the various subsystems, e.g. resource management, loading/saving worlds, plus lots more! I haven't fleshed out this object yet. One main point I emphasised when designing the engine was that the Engine object will not know about, or care about, players. I came to this conclusion after thinking about games that support dedicated servers, in that they are perfectly happy to run with no humans connected. Render Window - represents the window that is rendered to. This also receives and distributes window events from the OS to the renderer, e.g. resized, closed, etc. Renderer - provides a set of functions for rendering to the screen (more specifically, a Render Window). Note that only the Renderer object 'knows' about the render window - the Player object only interacts with the Renderer object, which delegates to the render window. Player - the interface between the application and the player. The Player object handles updating input and contains the reference to the renderer. This object will not represent the player entity in the world. Instead, the entity that represents the player in the world will have a reference to the Player that controls it, and will query it for input commands. This kind of breaks the encapsulation of the world, in that the player entity will have to 'reach outside' the world to grab its data from the human controlling it, but I guess this is exactly the point of the player entity being controlled by a human. World - this is where all the entities in the game world will exist. Each entity will have it's own Think() and DoPhysics() (etc) routines, which will be called by the World object each 'update frame'. At this early stage, it's hard to tell if everything will work out. I haven't even started on the engine and world code yet! The engine is designed to support multiple renderers, OSes, input mechanisms, etc, but so far I have only implemented the features to work with Windows and DirectX9, so I can only hope that I've abstracted the interfaces enough to support other configs!
  5. Hello Is it bad design to override a base class' members? e.g.: [source language="cpp"] class CBaseClass { CAnotherBaseClass &somedata; CBaseClass(CAnotherBaseClass &r) : somedata(r) { } }; class CSubClass { CAnotherSubClass &somedata; CSubClass(CAnotherSubClass &r) : CBaseClass(r), somedata(r) { } }; class CAnotherBaseClass { // interesting stuff }; class CAnotherSubClass : public CAnotherBaseClass { }; So CBaseClass contains a reference to CAnotherBaseClass, which must be initialised on construction. CSubClass, a child of CBaseClass, overrides this member with a subclass of CAnotherBaseClass. CSubClass gets all the added features of CAnotherSubClass, without having to grab the member from CBaseClass and downcasting it. So - acceptable or !acceptable? I hope I've managed to get my point across here.
  6. Hello What other general resources do GameDev.net members use? Things such as forums, websites, mailing lists, usenet groups. Here's a few I have: GDAlgorithms list Sweng-gamedev list flipcode Gamasutra Google! And from a search of GDN just before I posted this message, I found Microsoft's DIRECTXDEV List. Joel
  7. Hello I've only posted a few messages to these boards, and I do so infrequently enough that each time I post I've forgotten how to insert links and other such fantastical devices into my post. I suggest a quickref or something similar. Perhaps a link under the content textarea, next to the Show Preview link - this link would open a small popup window that lists all (or the most common) tags and smilies. I think this'd be good for people who, like myself, have the short term memory of a goldfish and sometimes find it hard to umm... what was I talking about? Where am I?
  8. Thanks for the replies. I had previously experimented with RTTI, but failed due to the following... I had a base object, CRoot, which all other classes ultimately derive from. CRoot has this function: std::string CRoot::ClassName() { const type_info &ti = typeid(this); return std::string(ti.name()); } As the code was in CRoot, the type_info returned was always a 'class CRoot*'. However, if I change const type_info &ti = typeid(this); to const type_info &ti = typeid(*this); I get the correct (most-derived) class name! Yippee! Now I just have to keep track of how many of each type of class have been created, in order to correctly increment the counter on a per-type basis.
  9. Hello Unreal Tournament had a neat way to identify instances of classes, which was stored as a property of the class: <class name><counter> e.g. the first instance of a CRocket spawned into the level would be named CRocket0, the next rocket would be CRocket1, etc. This was extremely useful for examining log files, as the name would be prepended to the log entry when a class wrote something. It also gave a human-readable way to identify objects, rather than using an ID number or pointer value. Is there a way I can do something like this in C++? Currently I am just using an incrementing counter which my objects grab a copy of on construction. This works, but I'd prefer the something easier to read. I understand C++ doesn't have reflection, but there may be ways around it? One way I thought of was to have each class manually set it's 'class name' on construction, but I'm sure for the odd class here and there I'd forget to name it, or name it incorrectly, or use an existing class' code as a base and forget to rename, etc.
  10. ElJoelio

    Baby steps...

    Hi! This is my first jornal entry and will do nicely as an intro to my project. I am developing a space-based RPG along the lines of Eve Online, but single player. I am also developing my own 3D engine for the game. I am using Visual C++ 2003 and DirectX9. From a game design standpoint, I have nothing more than a loose set of scribbled notes and free-range ideas floating around in my mind. I have a few key goals, such as strong player-NPC interaction (as well as NPC-NPC interaction), complete freedom of movement throughout the universe, strong exploration aspects, plush leather interior, ABS and that new car smell. Developing the engine will serve to introduce me to the finer, trickier aspects of game programming, such as resource management, low-level maths, engine architecture and code design. The engine is at an extremely early stage - I am currently working on the in-game object system, e.g. where the objects are, which way they are facing, what mesh they use, etc. No 'game' code has been written yet. I have no set ETAs, major milestones or other such project-management targets, and am just taking it a day at a time. I tackle problems and developments within the engine as they arise, in which fixing usually leads to other items that need to be worked on, and so on. I look forward to the day where I begin to work less on the engine and more on the game code. So that's the short of it! I guess I plan to update this journal every week or so, or whenever something major happens to the project. I might even do a bit of ranting here and there.
  11. ElJoelio

    Managing light sources and bots

    It sounds like a good idea. The Unreal engine uses 'zones' to do a whole bunch of stuff, such as rendering optimisation, graphical effects, location labelling, etc. Here's a link for a bit more info. http://www.unrealwiki.com/wiki/Zoning As for bots, I programmed AI for a game and had to come up with an optimisation scheme. Every few seconds, I'd do a distance check to all of the bots - if they were more than X units and didn't have a LOS to the player, I'd 'dumb them down' by severly reducing the frequency of calls to their 'look' and 'think' routines. These bots had to still perform their duties in this state, so they still had to have some processing, but maybe for your game you could switch such bots into an 'off' state where they perform no processing at all?
  12. ElJoelio

    game code structure

    I learnt (read: stole) my style of engine design from working on an Unreal Tournament mod. In lieu of a full explanation of the UT engine's design, I will say it is heavily object-oriented and well structured. Perhaps you could make a simple mod for an existing engine (or a few different engines) in order to get a feel for how other people do it?
  13. I have this problem a lot - where to draw the line at nice'n'clean interfaces vs. spending too much time writing them. In this case, I'd probably go for the direct access method, but it also depends on how many calls would be redirected through the interface. If it's only a few, then an interface could be a good idea. But, if there will be a lot of different function calls redirected through, then redesigns of your subsystems could mean lots of maintenance work updating the interface.
  14. ElJoelio

    OK, this is pissing me off

    I'm the same. I'd hit a tricky bit in my code, or just simply lose interest, which would discourage me from working on the project. Eventually a month or two would pass, then more, then the project would be forgotton. The way out of it for me was to work on a project with other people. After looking around for a bit and joining a few projects that failed, I eventually found a great project to work on, ThieveryUT (http://www.thieveryut.com/). It's a mod/TC for UT99 based on the Thief series of games, which was the perfect project for me - I loved Thief! Also, as it was a mod/TC for the Unreal Tournament engine, we didn't have to worry about low-level engine or graphics programming - 99% of programming work was on game logic. Working with other dedicated people was enough motivation for me to stick with it for around 2 years, until the project was complete. Maybe you could try to find an existing or starting project with similar goals to what you had in mind, and join that?
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!