Laurens
-
Posts
564 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Posts posted by Laurens
-
-
If you are eventually planning on implementing a GUI library then may I suggest support for HTML like Navi does? (http://www.ogre3d.org/tikiwiki/NaviLibrary)
That would make me dump CEGUI in a second
-
-
Oh wow, never knew that was even possible in C#
*just waiting for someone to come by now and show me this is possible in Java as well
* -
In that case I can see why you would request a GUI system to be built in although I also feel that there is something to be said for picking the right language for the job. This just seems like LE on hard mode
Anyway, as long as I am not forced to use the LE implementation of whatever GUI library Josh may or may not roll in then I am impartial to the request.
-
Several people here have integrated CEGUI with Leadwerks.
I wrote an article about it some time ago: http://leadwerks.com/werkspace/index.php?/page/resources/_/programming/cpp/leadwerks-and-cegui-r30
I do not think it would be a good idea to integrate existing GUI libraries in the engine. People should have the freedom to pick whatever GUI library they want and not be stuck with the one Josh decides to roll in the engine. Leadwerks should just stick to doing what it's great at. Rendering 3D graphics.
EDIT: think you mixed up GWEN and CEGUI. CEGUI has an OpenGL renderer included. Judging by GWEN's website, it does not.
We don't have renderers for OpenGL, or OGRE yet - would be very interested in those.
-
You mean overriding by return type? I have never tried it because I assumed it was not possible to do so from past experience in C# and Java.
To work around it for now I just have one Read method returning a string.
-
I may be way of base here but can't you just discard RealPlayer, install the K-Lite codec pack and just use Windows Media Player or something else that does not run in the background?
You could also try using system restore to restore before the point where you had the slowdown.
-
Holy ****! Suppose thats down to 50 from 150
Anyway. Whenever a PC is borked that far I would save yourself the trouble of trying to get it to run smoothly again. Shutting down services that would run just fine in the background before is not solving your problem, at best it is masquerading it. In the long run, a clean install is the only thing that will get your PC in proper shape again.
-
That would work for reading strings. The whole point of templating the method was to convert properties when reading them.
I won't be able to read int's now for instance using resource.Read<int>("MaxSpeed"); which is stored in the map as a string.
I always thought that reinterpret_cast was the C++ equivalent of a C-style cast (a C-style cast does work, in fact, but I'd rather not use it). I suppose this is not entirely the case then, correct?
-
That doesn't work
Still stuck on the same error.
Thanks for the fast reply though
EDIT:
Thinking I might have to resort to creating seperate ReadString, ReadInt and ReadFloat methods
-
What I did when my PC got fried last time I reinstalled Windows 7, installed some stuff I know I will always use (such as Leadwerks) and created a disk image using Windows Backup. Now when I need to reinstall, I just put the disk image back. Almost painless.
-
Hi everyone,
At the risk of making a fool of myself I am asking here because I can't figure it out for the life of me
I have an EntityResource class that has a map containing properties that represent the base settings for an entity. Such properties can include "CollisionHull", containing the path to the entity's .phy file, "Orientation", containing the entity's matrix and so on. I have a templated Read method to read a value and return any type I want. The cast fails on every type though and I have no clue why. Here is the abbreviated class with the offending method:
#ifndef ENTITYRESOURCE_H #define ENTITYRESOURCE_H #include <map> #include <string> using namespace std; class EntityResource { map<string, string> properties; public: template <typename T> const T Read(string property) const { map<string, string>::const_iterator i = properties.find(property); if (i != properties.end()) { return reinterpret_cast<const T>((*i).second); } return NULL; }; }; #endifCalling:
body = LoadBody(("abstract::" + resource.Read<string>("CollisionHull") + ".phy").c_str());will result in:
error C2440: 'reinterpret_cast' : cannot convert from 'const std::string' to 'const std::string'
Any push in the right direction appreciated
Thanks!
-
A few years back when I developed a pilots logbook application and wanted to create a trail version I just limited it in features, physically removing the code from the trail version to avoid people reverse-engineering the application (which was also written in .NET). Easy peasy and no extra code to deal with time limitations which may or may not have been circumvented. The full version code just wasn't there
You will probably also want to run Dotfuscator or some other tool
Anyhoo, looking forward to seeing more of this tool!
-
A seperate GUIView for that sort of thing would indeed be possible. It's something I have not yet looked into though.
-
The Model does indeed hold all the data the View needs to work with. For example:
I need to represent a spaceship. The Model would keep all data relating to the spaceship it needs to enforce the rules. This includes speed, hitpoints, mounted weapons, shield strength and so on. It also defines how the spaceship behaves and thus has methods such as FireWeapon(), BoostShields() and AddThrust().
Each Model is associated with one View so if I instantiated ten spaceships, there would be ten Models and ten Views.
Now let's say the players hits the W key and the controller calls AddThrust() on the ships it's controlling. The Model will then raise the Moved event that the View is subscribed to. The method it is bound to in the View will be called and it can then update the actual position of the TEntity, passed through the EventArgs.
-
I am extremely interested in this tool, would be great if you could get a trail version up when you do figure out how to properly restrict it
-
That would work splendidly
-
I wonder if it would be better to just fire events from the Model to the View and pass in the information required for the event instead of having the View query the Model for data. That way the views wouldn't need to hold onto a reference to the Model. It would just need it at startup to subscribe to it's events. Basically you would have events for every kind of thing that could happen to a View(Entity).
Good point. The View is never meant to manipulate the Model anyway so there is no reason for it I can think of right now to hold a reference. It can just wait for an event and have the Model pass it as an argument.
-
But duplication of things LE already stores might not be all that bad. I'm reading more about this and it seems at some level the Model doesn't need to know about the View or Controller at all. This would be huge in being able to port all your game logic over to multiple engines. You wouldn't need to change your game logic at all. Just the Controller and Views which would help same time and reduce bugs when porting a game.
At first glance anyone using LE would say you are wasting memory and processing time, but you are gaining the ability to port your game much faster and easier. This could be huge if you plan on making things on consoles.
This is indeed a bit of a trade-off but the benefits gained in terms of maintenance and porting to other platforms can be huge.
And it doesn't have to be limited to 3D engines. Say I want to use SDL. The model can be untouched, all that would require updating is the controller and the view. The game rules would still be enforced because it doesn't rely on a certain technology.
-
I'm curious on how you are going about Views also. Are you taking everything in the scene and putting them into 1 View or are you breaking them out based on some criteria or are you dynamically making/destroying Views as the game goes along? This is interesting stuff
Basically every entity has a view that displays it. I have an EntityManager that stores and updates all entities it contains and for every entity that is added to or deleted from the manager, an event is raised that is picked up by a RepresentationManager that will create the appropriate view.
What I have right now is mostly based on what I read in this article over at Gamasutra: http://www.gamasutra.com/features/20050414/rouwe_01.shtml
Mind that the view we have been talking about is called an EntityRepresentation in that article. Otherwise you might be confused
-
You can use that event system I posted a few times on here.
I have been using that extensively for some time now. It's awesome
Seems you think I opened your eyes, but I think you opened mine
Good to hear we both had benefit from this thread then
The only strange thing about this with LE is that the way it's setup the assets already know their positions and other values. So storing them off again in the Model section would be duplicating things. Like in the Model section you'll have Vec3's for positions of assets when in reality you can get that from the View side because it has the TEntity and when you have that you can query anything about that like position/rotation etc.
You're right. I wrote it down like that more for the purpose of explaining what I was taught about MVC. I'll admit that wasn't entirely clear
-
I'm pretty sure someone was working on this although I do not remember his name right now. Perhaps someone else does.
In any case, as Lumooja described, it is perfectly possible.
EDIT: was it Tak who was creating an FPS supporting dismemberment?
-
It seems to me from the wiki description, that the model tells the view of the changes. The view doesn't query the model for the changes. So if the model portion of the code has to tell your 3D models in the view to change, how can it ID those 3D models in the view? It seems you would want to use the TEntity for that ID. No reason to create your own. So that's why it seems like it would make sense that the model hold these ID's of all the views, so it can tell the views what to do.
That's just my understanding of it, and honestly the MVC model isn't something I've used before but from reading the description of it this is what my take on it is.
In your example, selecting the units would be the Controller potion. That input would them populate the Model portion (SelectUnits logic) with the TEntities that were selected. Running the Model logic would then set their tints, which is telling the View portion of the change you need. Then LE draws the View for you with the changes.
So it seems you are trying to have the View query the Model instead of having the Model update the View?
I believe everyone has a different take on the pattern just like any other theory. What we were taught in college was that the Model has an indirect association to the view, and the view has a direct association with the model. So what we did was this: the model is repositioned and then tells the view through an observer or event "Hey, I was moved!". Then the view would call model.GetPosition() and move the mesh it contains.
I think that also answers your question as to how the model would ID the view it is associated with. It doesn't. The view would subscribe to events the model raises and update itself to represent the state the model is in after the event was raised. Let's say the model fires the "Moved" event. The view would then GetPosition() on the model and SetPosition() on the mesh it contains.
Typing that I realize that I may be creating a giant performance bottleneck. Perhaps it is indeed best to contain the TEntity in the model and cut out the view, regardless of whether it is violating the pattern or not.
-
TEntity is just a general pointer to any kind of entity (camera, source, mesh, body, model, etc...).
TModel is TBody+TMesh (mesh is the first child of TModel, body is the root, same as the model).
You can also keep TBody and TMesh seperate and use PositionEntity/RotateEntity/SetEntityMatrix on the mesh to place it where the body is. I use this for additional models, like trousers, boots, etc... since if you parent them to the model, the animated main model gets bugged (at least in LE 2.22).
Thats good to hear. I'll perform some tests before I fully implement it to see how animations behave though.
You can create your own custom class and circle reference this class in userdata, like (Bmax code):
Had not yet thought of that and deserves some looking into!
The way I see it, the TEntity is the means on how you notify the view of changes (in LE the views are hidden from the programmer). So by using TEntity and calling PositionEntity() you are telling that view the change you want.
LE handles the view for you already and so you really only have to handle the model and controller.
That's an interesting perspective and had not yet looked at it that way. The downside to having the TEntity contained in the model is that view-specific code (even though hidden) has to be contained in the model as well.
For example, let's say I am creating an RTS and want to tint selected units green. By having the TEntity contained the model I would have to go through the model to change the color while the model has entirely no interest in knowing what color it is. By having the mesh in the view it would simply query the model and if it is selected, tint it green. In an ideal world the model would simply enforce the game rules and nothing else.
I do understand that all suggested approaches will most likely work though and it mostely is just me nitpicking, but I am trying to keep the reliance of the model on the engine to a bare minimum. If I ever need to change the engine to for instance LE 3.0 I can leave the model untouched. Secondly I feel it gives much cleaner code, having game rules, input and rendering neatly seperated.
Anyway, thanks for all the insights so far
GUI system
in Suggestion Box
Posted
Because it'll be a cold day in hell when I learn LUA
No, seriously, I think it is much easier if we can just create GUI's in HTML/XML and then load them via some core engine command rather then forcing people to code GUI's in LUA. I feel GUI's should be data-driven and not hardcoded.
Besides, you can use all functions in LE right now in any programming language you wish without restriction. I'd hate to see that change.