[Solved] Framewerk in 2.3?

[Shard]

So what happened to Framewerk? I had several Framewerk pointers all over my code because several different classes needed access to it but its now gone. I think I read somewhere that it has been integrated with the engine. How do I access it now?

 

Edit: The log says that Framewerk has been integrated with the engine but not how to access it.

[L B]

http://www.leadwerks.com/wiki/index.php?title=Framework

[Pixel Perfect]

So when were we given notice that framewerk was going to be dropped?

[Shard]

So when were we given notice that framewerk was going to be dropped?

 

We weren't. We were informed ex post facto. In the 2.23 release thread and the update log file.

 

However, it seems that it hasn't been dropped but rather integrated into the core engine itself.

[AggrorJorn]

When you use the editor, you are already using framewerk. The viewport where you look through to see your scene uses fw.main.camera. When you look at the fpscontroller scipts you will notice that there is no framewerk being created although the script uses the variable 'fw'.

[Canardia]

You can still use the C++ Framewerk, although it hasn't been updated to the latest changes in the integrated Framework.

Framewerk brings the benefit that you have better control over the rendering, because Framework is still missing the more detailed rendering commands.

The only bad thing about Framewerk is that it doesn't work with Lua scripts which use framework.

[Shard]

Ok so now my code has broken.

 

I had several pointers all over my code to Framewerk so that all the different classes could access it.

 

I changed all my Framewerk variables to Framework variables and I get several errors.

 

Compile Error

>d:\source code control\appiled project\current version\zero hour\zero hour\hud.cpp(66): error C2228: left of '.SetFarDOFStrength' must have class/struct/union
1>d:\source code control\appiled project\current version\zero hour\zero hour\hud.cpp(68): error C2227: left of '->GetRenderer' must point to class/struct/union/generic type
1>          type is 'TFramework *'

 

VS2010 Underlining Error Message

 Error: expression must have pointer to class type

 

 

 

My usage is as below

 

Main.cpp

Framework *frameWork = new Framework;
frameWork->Create();
frameWork->SetStats(2);

 

Hud.h

TFramework *frameWerk; //this is set to point to the frameWork variable initialized in main

 

Hud.cpp

frameWork->GetRenderer().SetNearDOFStrength(.7);

 

 

With our project being this close to the due date, I might just have to revert to 2.31 which is a shame since I was expecting to do so much out of 2.23.

[Shard]

Seems like I was mixing variable types: TFramework and Framework

Framework works but TFramework doesn't but the wiki makes references to it. :angry:

 

What is the difference between the two?

[ZioRed]

"Framework" is the LEO version of TFramework and have all the methods and properties, since TFramework is only a pointer I think.

[L B]

So when were we given notice that framewerk was going to be dropped?

5 months ago:

http://leadwerks.com/werkspace/index.php?/blog/1/entry-57-merry-christmas/

[Pixel Perfect]

Ah thanks Ubu ... we were away at Christmas so I guess I missed that.

 

It'll probably continue to use it for some time despite it no longer being maintained as I've no need for Lua at the moment and unless Josh changes the current API it will continue to work with future versions.

[Guest Red Ocktober]

and i think that if Ubu had looked carefully at that lil XMas Greeting... he would've read that it said 'FRAMEWORK'... and not 'FRAMEWERK'...

 

but hey...

 

lets not dwell on XMas past... lets look forward to what the 4th of July has in store...

 

 

--Mike

[Pixel Perfect]

I agree Mike, that hadn't gone un-noticed, but there was a general inference that the C++ framewerk was not going to be maintained in the reference to 'you can continue to use the existing C++ framewerk' rather than an actual statement that it would be.

 

Hey, he'll be getting rid of ini files soon which will really piss me off, seeing that I'm not using Lua, but what can you do other than vote with your feet and move to another engine!

[Canardia]

Hey, he'll be getting rid of ini files soon which will really piss me off, seeing that I'm not using Lua, but what can you do other than vote with your feet and move to another engine!

I don't like getting rid of ini files either, and I will reimplement them in gamelib then. At least it gives me a reason to implement them a bit better then, like detecting comments in ini files, and supporting also int and float values and not only strings, and maybe also userdata. Also a #include inside the ini file would be cool, and a common.ini file which is done for all models, and a default.ini which is done for models which don't have an own ini file.

[Pixel Perfect]

I don't like getting rid of ini files either, and I will reimplement them in gamelib then. At least it gives me a reason to implement them a bit better then, like detecting comments in ini files, and supporting also int and float values and not only strings, and maybe also userdata. Also a #include inside the ini file would be cool, and a common.ini file which is done for all models, and a default.ini which is done for models which don't have an own ini file.

Yes, I agree. Reading in my own ini files is probably the solution I'll implement too, but it's annoying as it's all additional work to be done on top of the already massive task of writing a game engine based on Leadwerks and doing all the level design etc. Like a lot of other Leadwerks users I'm a single person game developer doing this in what little free time I have available. What does he really gain by removing ini support? I suspect very little!

 

I feel at times like I'm being railroaded down a track of Josh's making for no better reason than because he can! I've invested so much in this engine and its overall capabilities that I'm reluctant to move away but I do feel that he needs to better justify decisions he makes at times. As his loyal customers I believe we deserve that!

[Canardia]

I believe the removing of ini files is planned because Josh wants to consolidate their functionality in lua files. It will be much harder to make ini files then, unless he has some cool idea how to enter the ini values in a lua file. Maybe some global function like:

key("myname","myvalue")
key("myname2","myvalue")

In general, I've been often against Josh's changes first, but after he has explained to me why he did it, I had to agree that it was indeed a better solution. So yes, when Josh announces some changes, he should explain why it is better, because most people - including me - can't see the benefits without getting an explanation.

[Rick]

I think this is what you get when a game engine evolves. I personally think trying to make your own engine from Leadwerks for the purpose of specifically making a game you have in mind at this stage is like trying to hit a moving target. I think you'd be better off picking a version and sticking with it (bugs and all) or this will be never ending for you. Either that or the design of your engine needs to be really separated from how Leadwerks does things. ie, not relying on Leadwerks with ini, Lua, etc and basically just using it's core API features that are related to graphics, input, & physics.

[Pixel Perfect]

That may well be, but Josh also said prior to the release of 2.3 that no-one not wanting to go down the Lua route would be forced to .... so I upgrade to 2.3 to find he's removed the generic property editor and replaced it with a Lau script based system. Ini files offered an alternative (are are also far easier and quicker to maintain) and now we are told they are to go too. I don't want to stand in the way of progress but developers have a certain responsibility to their customers too.

 

I agree that if the Lua files can be made more 'update' friendly then that would help. If I have 50 or so complex objects that I want to have slightly different property settings I'm not going to be using the 'in editor' property system to update those!

[Canardia]

To Rick:

 

Yeah, I had the same idea about having a production and testing version of the same game in development. I develop in the testing version, and then move tested and working parts to the production version of the game, which is then also available to all team members via git.

 

I'll stick now with LE 2.32R4V4 in the production version, and only upgrade when everything in the testing version works. That way my game development will never pause again when something in the engine doesn't work. Thanks to git, I have also a automatic backup of every changed file of the product version all the time available, and I had to revert some files already.

[Guest Red Ocktober]

That may well be, but Josh also said prior to the release of 2.3 that no-one not wanting to go down the Lua route would be forced to .... so I upgrade to 2.3 to find he's removed the generic property editor and replaced it with a Lau script based system. Ini files offered an alternative (are are also far easier and quicker to maintain) and now we are told they are to go too. I don't want to stand in the way of progress but developers have a certain responsibility to their customers too.

 

well said Pix... well said...

 

--Mike