Jump to content

Josh

Staff
  • Posts

    23,082
  • Joined

  • Last visited

Blog Comments posted by Josh

  1. On Mac, we will just create a DMG file, which gets dragged and dropped onto the Applications folder. The fancier way is to distribute through the Mac App Store. On Windows, Steam has an updating system that can handle all that. However, it would be a good idea to add a registry entry for the installation path, for future expansion. It would be something like "HKEY_LOCAL_MACHINE\SOFTWARE\$COMPANY_NAME\$PROJECT_NAME" with the $tags replaced with the project values, obviously. This would be a string set to the install path, like "C:\Program Files\Doom 5".

  2. Have you thought about how this would interact with source control tools? Will there be no issues with the project setup you have?

    Because we try to avoid complicated package schemes and just use the plain file system, it's easy to use SVN, GIT, or Mercurial to synchronize projects. Assets don't get packed into zipped packages until the final publishing step. We synchronize all our assets right now with an SVN server, across PC and Mac computers.

     

    In the future I would like to add SVN and GIT support right in the editor.

     

    Is there a possibility to have somekind of ../Common/*.cpp folder for common source files, so you don't have to copy the same source code into each different platform folder?
    That's how it already works. All .cpp and .h files are shared in a "Source" folder. There's a couple of exceptions, but those are just platform-specific code files the user never has to look at or worry about.

     

    Once you create your cross-platform project, you can just keep all your source code files in one folder, and add them to the Visual Studio, Xcode, and Eclipse project. It's the same way we develop Leadwerks itself.

     

    It's also possible to add templates for new languages, and the editor will detect it and display it in the project creation wizard.

  3. Yeah, but at that point, does it matter whether the file name is goblin2-3_tex or FIDHJDJHFKJDF? You can just run the publish tool from the editor again if you want to modify something. I don't really expect people will be poking around in the projects/android/res/raw folder anyways.

  4. One small change I am going to make this morning is to leave the file names the same, by default, unless a duplicate file name is encountered. If that happens it will have a dash and number added to the end like this:

    truck.mdl

    truck-2.mdl

     

    I think this might turn out to be handier in some situations, and it works the same. It will check for existing file names, so if you really do have a file with that name, it will increment the suffix and check again.

  5. The Asset class destructor actually looked like this before my changes:

    Asset::~Asset()

    {

    this->assetreference->instancecount--;

    if (this->assetreference->instancecount==0) delete this->assetreference;

    }

     

    So it was really the same thing, just with a lot of extra classes in an attempt to continue using "delete" when it really isn't appropriate.

  6. This makes the problems you listed go away. For example this code will only load the texture once, and at the end it will delete the texture:

     

    Texture* texture = Texture::Load("myimage.tex");

    material->SetTexture(texture);

    material2->SetTexture(texture);

    texture->Release();

    texture = Texture::Load("myimage.tex");

    material3->SetTexture(texture);

    texture->Release();

    material->Release();

    material2->Release();

    material3->Release();

     

    In your entity pointer target example you could have incremented the reference count, used Release() instead of delete, and you would have been safe. (I renamed the IncRefCount() function to AddRef() to match the COM syntax, which uses an identical system).

     

    Your wizard update function might have looked like this:

    if (activetarget->GetKey("health")<=0)

    {

    activetarget->Release();

    activetarget = NULL;

    }

     

    Setting the target might be like this:

    void Wizard::SetActiveTarget(Entity* entity)

    {

    if (activetarget) activetarget->Release();// decrement the ref counter of the old one, if it exists

    activetarget = entity;

    if (activetarget) activetarget->AddRef();// increment the ref counter of the new one so we can hold onto it

    }

  7. A map where the key is the filename+path and multiple calls to Load() or new would check if the object is already loaded and handle the instance count for us.

    That's exactly what it does.

     

    If we pass these around to other objects then it's on us to manage it correctly.
    So you'll implement your own ref counting system, and then instead of a standard one built into the engine, we'll have a dozen non-standard approaches, all trying to make up for lacking functionality. :\
  8. You do not need to call IncRefCount(). It's just used internally.

     

    Yes, with people who do not understand how memory management works and do not call delete, this will happen.

    You would effectively be writing your own engine at that level. If I load a model, for example, and then delete the model, it's reasonable to expect the model's materials, textures, and shaders to also get deleted if they are no longer in use.

     

    I looked up COM and it's identical to what I am doing. Maybe I will even make the syntax match it exactly.

×
×
  • Create New...