As in the other thread, a class that manages stuff isn't a bad thing. It can be a good thing. The issue is when you try to turn it into a singleton.

W1) Is it a custom container for images? W2) Is it a custom container for wave objects? W3) Does it coordinate the the availability of resources?[/quote]W1) No, I used inheritance just because it cut some corners here and there, and I was too lazy to route the calls to a nested object. There indeed was some sense in this choice, ideally those objects would all make up a big "execution environment" providing all the features. Of course that's the same thing by composition... I will look at the code next week and re-factor.
W2) It has some logic involving 'ticking' the waves each time step. Originally, that was not even planned to exist, I was just performing some cleanup and I pulled it out of a bigger class.
W3) No, an external component does.

Although what this does is pretty clear, my main problem with that is finding a name which is short and descriptive. Mainly jargon.
I'm not quite sure I can split it again as it's like 300 LOC.

Seems like a renamed version of other stuff.

There is often a simulator class, and it contains instances of lots of pieces that make up the simulator. Sounds like your own re-discovery of this.[/quote]I don't quite get the point here. Yes, it's just another "piece of something"... so? And what is this "discovery" thing you're referring to?

IM1) Why can't your other resource manager handle this?
IM2 The tasks of pre-loading, loading, caching, unloading, and otherwise getting blobs of data into and out of your game is a very common task. It is very frequently implemented as a factory method that works with your own serializers and deserializers.
IM3) Any "more advanced resource" is still just a resource, isn't it?[/quote]IM1) It was originally part of other managers. It has been pulled out to support some external utilities involving material mangling (mainly the filters).
IM2) Problem was that some resources are terribly complex. I had one whose factory method took about 12 parameters. I initially just grouped those parameters in more logical matters - one of those turned out to be the [font="Courier New"]FlexMaterialLoaderInterface [/font]- I eventually got this down to 4, then figured out that those things could have been useful in a broader topic. They were originally intended to be temporary duct tape but they have been there for a while.
IM3) Yes of course but I don't think I am well aware of what I should do. Perhaps I'm just stuck in the drawn picture. Those objects provide the factory methods. The need to link them together arisen by the interactions of the 'advanced' resources with regards to the basic ones. It's mostly historical and somewhat redundant now that scripting is more pervasive. Yes, I will think at this.

S1) What is a script in your system?
S2) Often a scripting system can be implemented very simply as a state machine.[/quote]There was a state machine based script system in the beginning. There also was another scripting system (I'd likely not elaborate on that, unless it's absolutely necessary). I eventually got mad at the two things and melted them together. Think at a dumb version of UnrealScript. I plan to go back to state-based systems a day but I will likely layer those on top of the current scripting.

[quote name='YogurtEmperor' timestamp='1319277790' post='4875301']
[font="arial, verdana, tahoma, sans-serif"]So let’s assume singletons are not welcome, and you are wondering what you can do to make sure that no more than 1 instance of a class exists.[/font][font="arial, verdana, tahoma, sans-serif"] [/font]

In my design, singletons are not needed for sound managers etc., because the CGame class, which must be created in order to use my engine, creates that pointer itself, and every state of the engine receives a pointer to the game class and can therefore reach the sound manager, or whatever other manager there needs to be.[/quote]Thank you very much! It's exactly the same rationale I used to design mine! Everything is a part of the bigger core object. The object is instantiated using a global systemwide lock so no chance of double instantiation can happen. It's always good to know I'm kinda on a good path.

I begin being positive perhaps there's no real problem after all. Besides naming. I'd still want some suggestions for the WaveSomething... perhaps WavePooler would do ?_?

WM1) Can you run two windows? WM1A) If not, why not? There is no physical reason why you cannot run multiple windows on the screen; that is exactly what it is made for. WM2) What about split screen within a single window? WM2A) If not, why not? WM2B) Your display area is normalized to a rectangle, why should it matter if the rectangle is only a portion of the physical screen? WM2C) Why should you be restricted to a single rectangle instead of two or three or nine? The restriction is artificial and probably unnecessary.
...
WM3) One of the best in-house engines I worked with had two views on screen... Any fundamatal reasons your game engine cannot do that? Why not?


[/quote]WM1) No. The system was able to do that in very old versions.
WM1A) It just collected dust with no apparent benefit. It was originally implemented as it was deemed useful WRT previous experience - it was a different field. As a side question - how's going with sharing renderers across multiple windows? As far as I recall direct3D9 is a bit quirky on that, for GL I am not sure but I think not (it's bound to the Device Context which is a per-window property). If this involves creating multiple renderers... that's going to be a big no. I think your statement is a generalization a bit too broad. I don't recall a single PS3 game I've played showing multiple windows per screen. I have also seen some games not only assuming a single window but also allowing a single resolution - I don't see this being a problem for me in the real world for the next years.
WM2) Not currently supported. Plan is to just expose an additional renderer control (it will likely be script-driven).
WM2A) Not necessary now.
WM2B) I disagree with this. What is this normalized rectangle? How do you deal with it on 4:3? What on 16:10? What about stretching. No way. I work in physical inches, or perhaps pixels. If the user (script) wants to cut it in ratios, that's his/her choice. Design units are in pixels at 96dpi. The alternative, offset-scale normalized coords seems unnecessarily convoluted. Perhaps it's just me, but I didn't like the normalized coord approach at all in the past. I couldn't stand the stretching.
WM2C)Of course when it is scripted there will be N (I don't care). This day is not now. I disagree with your statement; I don't quite see the connection with the original problem.
WM3) Yes, each day got only 24 hours, priorities and trade-offs will have to be made; I think that is a major fundamental reason.

Can you have one game instance run multiple simulations internally...The simulator has clocks. The simulator has resource loaders. The simulator has everything neccesary to run the game. The simulator has an interface for display, but does not have a view (that is secondary to running the game).[/quote]Yes, totally awesome and... what's the difference between my system and yours? And what's the deal of running it multiple times in the same process? Why not just ran them sequentially... in parallel chunks? It sounds like write about "accuracy" as a mathematician might write about: I don't see the point of having more than adeguate accuracy. I understand nothing of what you're writing about. Please try to be more concise and propose real world examples (excuse me, but I am not well aware of what you do).
I don't want to write an "engine"... I want to get the job done. I will implement "nicely" whatever it takes to get the job done. Everything else will wait. Long term investments will be considered... in a long term perspective. OP is NOT about a long term perspective it is about a simple solution to a problem I have. Now.