Jump to content

  • Log In with Google      Sign In   
  • Create Account

haegarr

Member Since 10 Oct 2005
Offline Last Active Yesterday, 12:39 PM

Posts I've Made

In Topic: Is this practical for a resource manager?

14 September 2016 - 01:06 AM

Just for information: The "generally recommended" implementation of resource management, as crystallized from the many discussions here on GDnet, coarsely looks as follows.  (We speak of assets here, not of operational resources, don't we?)

 

a) There is an own manager for each kind of resource.

 

b) Management is not done monolithic in a single object. Instead, the ResourceManager is a front-end that co-ordinates a couple of collaborators. Have a look at the facade software pattern for an introduction of this scheme.

 

c) One collaborator behind the facade is responsible for caching. It is e.g. derived from a HashMap, using the resource identifier as key and the resource as value. Because it is an own object, storing the resources can be done in a resource type specific way, giving the ability for optimizations.

 

d) Another collaborator is the resource loader. Its job is to read resources from mass storage when being instructed to do so.

 

e) The manager is *ever* the owner of a loaded resource. A client that wants to use a resource *ever* requests the belonging manager for the resource, and *never* frees it after getting access.

 

f) If the manager is requested for a resource, it looks up the resource in the cache and returns it if found; otherwise it calls the loader to load the resource from mass storage, puts the result into the cache and returns it.

 

g) It may also be favorable to have a resource factory per resource type as a collaborator. If needed by the game, the manager can provide public access to a factory so that clients can generate resources on the fly, e.g. for dynamic content creation. In this case I'd suggest factory functions within the manager's interface.

 

h) Do *not* use static objects as resource manager. The managers should be accessible from what Sean Middleditch calls "spaces", referred to from game levels. This allows resource groups to be separated and freed in blocks / at once.

 

i) Resources need not necessarily be derived from a common base class, but I also don't see it as to be avoided obsessively.


In Topic: Reading multiple datagrams from UDP socket

27 August 2016 - 04:28 AM

UDP is about datagrams. It has no conception above that, especially not how to concat datagrams nor how to distinguish them after concatenation. 

 

However, it is not clear to me *why* you want to do so. What does "all the messages" mean exactly? A sequence of messages from the same source? A soap of messages from different sources? What should happen if one of them is missed on transmission? Such questions need to be handled as well.

 

IMHO we're speaking of stuff belonging to the application protocol layer!?


In Topic: What's a room?

21 August 2016 - 10:50 AM

A room as a compound (not necessarily an entity as in an ECS) may have

 

* a NavigationComponent instance (navigation graph or mesh), to be installed with the NavigationServices;

 

* a set of ColliderComponent instances, perhaps tagged for specific usages, to be installed with the CollisionServices;

 

* a set of PortalComponent instances (of the entree or exit kind, interconnecting rooms inclusive positional mapping), to be installed with the NavigationServices, used as another level of navigation;

 

* perhaps a LocationComponent that gives the room a name, a location on a map, or such a thing

 

* ...

 

Not a RoomComponent makes the entity a room, but the collection of more generic components. We are not speaking of a strict and explicit typing here, but of a kind of duck typing.


In Topic: Modal GUI and ongoing events

21 August 2016 - 10:28 AM

IMHO: From an UX point of view, your GUI has a design flaw when it regularly causes such a break. Why should a modal dialog appear without a causing user interaction? You should definitely avoid that. It can be accepted in seriously problematic situations, but then the pointer's shape should be your least problem. That said, what are the specific use cases you have in mind?


In Topic: Xml Dialog Tree For C++

30 July 2016 - 02:32 AM

A notice at the beginning: Also my opinion is that XML is fine as intermediary file-format, useable in automated processing, and for small enough problems.

 

AFAIK the sample in the OP is not a well-formed XML document as it lacks a root element. Let's say it looks more like this:

<?xml version="1.0" encoding="UTF-8"?>
<dialogtree>
  <dialog id='1'>
    <message name="Boss" text="Testing the dialog system!"></message>
    <response condition="True" nextDialogue='2'>
      response text
    </response>
    <response condition="False" nextDialogue='3'>
      response text
    </response>
  </dialog>
  <dialog id='2'>
    <message name="Boss" text="Testing the dialog system!"></message>
    <response condition="True" nextDialogue='4'>
      response text
    </response>
    <response condition="False" nextDialogue='5'>
      response text
    </response>
  </dialog>
</dialogtree>

Looking into the DOM the standard way is done by using XPath. There is TinyXPath, not exactly an active project, but the features you need are not challenging, so good chances are it will work fine for you. Then looking for the <dialog> with id=2 would then use an expression like

   /dialogtree/dialog[@id='2']

if the level of the dialog element is known, or perhaps

   //dialog[@id='2']

if not. However, on success it returns the addressed node.
 
Of course, XPath is sufficiently complex in itself. Iterating the DOM "manually" using TinyXML's build-in TiXmlVisitor class is possible, too. Your specialized class instance then decides on a node-by-node basis whether the currently visited node is the wanted one, and remembers the once found node. This is, AFAIS, the way of doing things as is intended by TinyXML itself.

 

Not related to browsing DOM, but nevertheless worth mentioning: whitespace handling. In a declaration like this (notice the indentation just made to let XML look user friendly)

    <response condition="False" nextDialogue='3'>
      response text
    </response>

is the text you want to display with whitespace like in this string (also notice the line break, please)

"      response text

       "

or without leading and trailing whitespace like in this string

"response text"

 
The distinction between wanted and unwanted leading and trailing whitespace is not really possible here. A better approach would be to make all text() within respective nodes be wanted text, so that the given example would probably look e.g. so:
    <response condition="False" nextDialogue='3'>response text</response>

PARTNERS