-
Posts
4,127 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Posts posted by Canardia
-
-
I don't think the "Null Framewerk" message can be avoided, since the engine wants a global "framewerk" object, which can only be set from BlitzMax, as the structure of the framewerk object is completely different in other languages. I think Josh should remove the message completely.
-
You should place the books in Editor, as they are physics objects.
-
I would make all meshes out of smaller objects, and make each object a physics body. Then you can destroy and move everything.
-
The "Null Framewerk" message comes probably because I need to publish the framewerk object to LUA in GameLib.
The shader errors might be because you didn't use the latest shaders.pak.
-
Ok, I can parent it to the lua object, but not to the entity, since then the animation would not work anymore.
This seems to work fine, and it also deletes the cubes for each model you place in Editor:
require "scripts/class" local class=CreateClass(...) function class:CreateObject(model) local object=self.super:CreateObject(model) object.cube=CreateCube() object.cube:SetPosition(object.model:GetPosition()) function object:Free() self.cube:Free() end end
-
Actually Josh changed it back, so Framewerk C++ has been now also changed back. There is no need for _adjust shaders anymore.
-
You need to run the updater, Framewerk C++ was changed yesterday.
-
I'm trying to spawn a cube when I place a model in editor, but Editor crashes when it tries to free the cube when I delete the model from Editor:
function class:CreateObject(model) local object=self.super:CreateObject(model) cube=CreateCube() function object:Free() cube:Free() end end
-
You don't necessarily need any inventory system, if you use physics for the inventory
-
OpenGL does this automatically, you can check also when you are inside the building, how many polys are rendered.
-
Yes, everything works better without .NET
-
You don't use the newest engine.dll.
-
That's just because the bmx framewerk is not uptodate
-
You don't need to put anything back, since when Josh uploads the new shaders.pak, your Renderer.cpp will be returned to the original version also (when you run the installer).
-
str is "the null terminated C string which LE uses", it's not the same as char*, although it might be currently similar.
At the moment it's also unsigned char*, since not all C++ compilers work with signed chars for strings. In future str might be also unsigned int*, if there are some multibyte string functions. The whole point of declaring your own types is that your code stays compatible with all current and future OS and hardware.
LE uses also flt instead of float (which is used as "the floating point resolution which LE uses for GPU floating point numbers"), since GPUs might soon be all 64-bit, so you don't have to change any code then either, as the headers will then have flt defined as double.
Note that for pure mathematical functions you should always use double, as it's about twice as fast as float. bool is also twice as fast as int.
-
Until Josh has uploaded the new shaders.pak, you can disable the _adjust shaders in Framewerk by searching for the line in Renderer.cpp which says postfiltername = "_adjust" and replace it with postfiltername = ""
-
DrawShadowText is a standalone function since Framewerk 1.03.
-
As far I know those *_adjust.* shader files have never been published yet, and even I don't have them, but Framewerk uses them. Josh just needs to upload them to the sync.
-
Maybe the temporary files in your .bmx folder are corrupted and using code from the old 2.3 SDK. BlitzMax does that quite often.
Then you can just delete the .bmx folder and have clean compile. Disabling the Quick Build mode in BlitzMax should do the same, but I trust more deleting the files myself.
-
Maybe you have some hidden character between the "" which your BlitzMax IDE doesn't show.
Try to delete the "" from both lines and rewrite it again.
-
Why don't you print out the value of submersioncolor, then you see if it's empty or not.
-
You don't necessarily need to load a sbx file, but you could also load the positions of the models from a sqlite database, then you would get also infinite streaming capability. But you should still delete and recreate the world when you switch from outer space to inside a space station.
-
Multithreading can be cores times faster, or cores times slower, depending on what you do. Usually it's faster when doing some non-memory intensive things on other cores, and slower when accessing memory on other cores.
A quaranteed benefit of multithreading would be to put disk I/O related stuff to another core, then it doesn't matter if they are a bit slower, since they don't block the main core anymore.
-
You should just load different sbx files for each environment. The gamelib demo has an example how to switch between 2 sbx maps.
Is GameLib fully functional with 2.30 at the moment?
in General Discussion
Posted
I get those warnings in shaders.pak too, but everything seems to work. The only change I had to do in gamelib so far, was to add the skybox loader for Editor:
(after the block with if(ek=="0"))