Upcoming header fixes

[Canardia]

Although 2.32R5 is quite bug free, there are some inconsistencies in the C/C++ headers still.

I got feedback from Masterxilo and Roland and they suggested the following fixes:

 

Roland:

• All functions which use the str type as parameter, should use const_str. This avoids that the user needs additionally to specify (str) when calling those functions, and it is anyway the right thing to do, since the const keyword should be used always when a parameter is not changed by the function.

Masterxilo:

• The APPLOG_xxx constants are totally wrong, and should be according to the bmx engine.i mod file.
  
• mathlib.cpp should have also scalar factor operators, so that one can say for example: Vec3(1,2,3)*5;
  
• FontHeight() is missing from LEO::Font
  
• Shader::Set(false); needs to be static

Lumooja:

• The VIEWRANGE_xxx constants for the EntityViewRange() function need to be added.
  
• On european keyboards, the KEY_TILDE corresponds to the Ö key, so a KEY_SECTION constant needs to be added to access the key left of the KEY_1 key on european keyboards.
  
• Usertype.dat is missing some LEO keywords

When Josh approves these fixes, I can update the headers, and then all other language headers can be updated too.

 

Of interest for users who have already game projects going on, is that these fixes don't affect your existing game code at all. Even the str to const_str change does not need you to change anything, although you can remove the (str) now from all places where it was needed earlier, but it still works if it's there.

[franck22000]

Hello lumooja there is also the missing KEY_PRINT constant, thanks for thoses fixes

[Canardia]

The print key does not return anything using GetChar(), so I don't know it's key value.

[franck22000]

it's in "keycodes.lua" file

 

KEY_PRINT=42

[Canardia]

That doesn't work on european keyboards, but I can still add it for US keyboards.

[franck22000]

hum unfortunatly im french, well ... it could be usefull for american user at least

[paramecij]

what about the commented out vehicle commands ?

//typedef TVehicle	(_stdcall *TCreateVehicle)			(TBody chassis, int tires);
//typedef int		(_stdcall *TAddVehicleTire)			(TVehicle vehicle, TVec3 &position, flt radius, flt width, flt mass, flt friction, flt suspensionLength, flt springConstant, flt springDamper);
//typedef void		(_stdcall *TSetVehicleTorque)		(TVehicle vehicle, flt torque, int tire);
//typedef void		(_stdcall *TSetVehicleSteerAngle)	(TVehicle vehicle, flt angle, int tire);
//typedef void		(_stdcall *TSetVehicleBrake)		(TVehicle vehicle, flt brake, int tire);
//typedef void		(_stdcall *TGetTireMatrix)			(TVehicle vehicle, int tire, TVec16 *matrix);
//typedef int		(_stdcall *TVehicleIsAirborne)		(TVehicle vehicle, int tire);
//typedef flt		(_stdcall *TVehicleSpeed)			(TVehicle vehicle, int tire); 

..I'm unable to implement PROPER braking to my vehicles without these

 

or the script commands ?

//typedef	TScript			(_stdcall *TLoadScript)			(str filename);
//typedef	void			(_stdcall *TRunScript)			(TScript script, BP funcname, BP object);

.. this would be also great to have, now I must load dummy models to invoke scripts

 

Any idea if these are to be implemented and when?

[Canardia]

Currently only bugs are being fixed. The next new features phase comes after that

You can probably brake the car with some physics forces or mass changes.

[Paul]

Buffer::Set(buffer) should also be static

[Canardia]

Shader::Set(false); needs to be static

Can't be done, because it uses m_entity.

[Laurens]

Good to hear this is being fixed.

 

I would love to see LE 3 to be object oriented out of the box though.

[Canardia]

LE has been always object oriented (internally: yes, DLL: no, wrappers(C++,C#,Delphi,Object Pascal,Lua,etc...): yes), but the limitation was that BlitzMax can only generate procedural DLLs. In LE3 this limitation won't exist anymore, so it's possible to have an OOP DLL (and even a static lib) in addition to the procedural DLL for non-OOP languages.

[Laurens]

Wow, I never knew BMax had that limitation. Good to hear it won't be a problem for LE3 though!

[ArBuZ]

I'm not sure if this is related to current topic, but Entity::LoadAnimation() command in LEO returns boolean while it should return int - index of loaded sequence.

[Paul]

LE has been always object oriented (internally: yes, DLL: no, wrappers(C++,C#,Delphi,Object Pascal,Lua,etc...): yes), but the limitation was that BlitzMax can only generate procedural DLLs. In LE3 this limitation won't exist anymore, so it's possible to have an OOP DLL (and even a static lib) in addition to the procedural DLL for non-OOP languages.

I don't think that would work on all c++ compilers because of different ABIs

[Canardia]

I'm not sure if this is related to current topic, but Entity::LoadAnimation() command in LEO returns boolean while it should return int - index of loaded sequence.

It returns an int, I think you haven't updated your LEO files since 2.27.

[Canardia]

I don't think that would work on all c++ compilers because of different ABIs

Well, as a source owner, I could setup a batch file which compiles the OOP DLL with all needed C++ compilers. I would probably even need to compile it for different GCC versions through different virtualboxes

 

But in practice, I think VS2008, VS2010 and the newest GNU C++ should be enough.

[ArBuZ]

It returns an int, I think you haven't updated your LEO files since 2.27.

Hmm, Im quet sure I have LE 2.31 now (At least I used updater to get it). Maybe it has been fixed for 2.32. I havent downloaded it yet.

[Masterxilo]

Can't be done, because it uses m_entity.

 

What about Shader::Disable() ==> SetShader(NULL); ?

[Canardia]

What about Shader::Disable() ==> SetShader(NULL); ?

Yeah, I can do it like that then.

[Canardia]

All is done and ready. These bug fixes will make using LE a lot easier, since you don't need to specify the (str) cast anymore, and it should be a bit faster too, since I fixed some internal unoptimal programming (constants must come always before dynamic expressions!). First I only wanted to update the copyright notices in LEO, but ended up in a 5 day overhaul of all LEO formatting (a lot of spaces were replaced with tabs, resulting in a almost 10k slimmer LEO), which I always wanted to do, but it was too much work to do at once, except now since I have summer holidays. It looks very clean and consistent now, if someone enjoys good looking source code

 

I've sent the C/C++ headers to Josh, so he might put them in the SDK updater soon with some information what else has been fixed.

 

EDIT: Now the new headers are in the SDK updater, here's a short summary what has been fixed:

- missing syntax highlight keywords

- Leadwerks Copyright 1999-2010 banner updates

- more static methods, as requested by masterxilo

- more const parameters, as requested by roland

- scalar operators for all Vector types in mathlib, as requested by masterxilo

- missing commands in LEO

- misplaced commands in LEO

- missing keyboard constants

- missing viewrange constants

- wrong applog constants

[Roland]

Great and thanks

[Masterxilo]

Great, thanks.

 

 

But:

a lot of spaces were replaced with tabs, resulting in a almost 10k slimmer LEO

You shouldn't have done that. Tabs are never a good thing to use since you can't know how wide they'll be. I set my msvs to replace tabs with spaces, but it only does this with my own files, it leaves other files as they were but makes their tabs look as wide as n-spaces.

10k is nothing, it's not worth it...

Put the spaces back.

[Canardia]

Tabs allow everyone to format the tabs as wide they want, and the proven standard is 4 wide, with spaces you can't do that. There are no benefits of using spaces over tabs. LEO compiles now also much faster, and I don't want it to be as slow as before.

[Masterxilo]

LEO doesn't need to compile more than once anyways since you include it in the precompiled header.