NewsForumsCodeLogsGallerySpecsSearch

Problems with type fields

BlitzMax Forums/BlitzMax Programming/Problems with type fields

TomToad(Posted 2005) [#1]
Ok, I seem to be having a weird problem here. I'm trying to encapsulate the IrrBMAX commands into helper functions to make it a little easier. Problem is that one of the fields keep changing to null for no apparent reason.

So why does driver become null after exiting the Graphics3D method, but device, smgr, and guienv do not?
I even tried using Global fields and Functions and calling them directly, but same problem there as well.


gman(Posted 2005) [#2]
greetings TomToad :) just a guess, but try changing the parameter "Driver" to something else like graphics_driver.
Method Graphics3D:Int(width:Int, height:Int, BPP:Int = 16, WindowMode:Int = False, ..
                         VSync:Int = False,graphics_driver = EDT_OPENGL,Shadow:Int = False)

i think its getting confused trying to determine which "Driver" variable you meant to store it to.

also, if you are interested i already have a project going called gg.IrrB3D whose goal is replicate the B3D command set using the Irrlicht wrappers. i am always open to anyone helping if you feel like pooling resources.

if it helps you along, here is the engine Type (your T_I3D) for gg.IrrB3D so far.




TomToad(Posted 2005) [#3]
Ack! You're right. Isn't strict suppose to catch things like that? I was going bonkers trying to track that down and I didn't realize I use the same name twice.

As far as the B3D thing goes, I was aiming more at keeping the flexibility of the IrrLicht, but wrap the commands so that they're easier to call. Instead of T_irrDimension2d_s32.create(width,height) and such stuff that makes the calls a little difficult.

ETA: While we're on the subject, do you know how the custom importer is suppose to work? I've been thinking about creating an importer that'll allow me to import .b3d files.


gman(Posted 2005) [#4]

Isn't strict suppose to catch things like that?


you would think :) the reason it compiles in this case (i believe) is because you can store objects to integers.

As far as the B3D thing goes, I was aiming more at keeping the flexibility of the IrrLicht, but wrap the commands so that they're easier to call.


i think we are on similar targets. im taking the approach of many of the BRL BMAX modules where they have functions that can do many things, but underneath they are actually calling type methods. while i have a B3D function set, all the functions really do are call methods on types. you would never actually need to call a single ib3d function if you so desired. plus, all the underlying functionality is still there (ie. the entity stores the T_irrISceneNode reference, ib3d_engine stores references to all its corrosponding T_irr types) and you can call Irrlicht commands direct any time. for example, here is my entity Type of which all the ib3d entities are based:



do you know how the custom importer is suppose to work?


you will need to extend type T_irrIMeshLoader type. override isALoadableFileExtension() and return true if you can load the file passed in. override the createMesh method. this method must return an instance of T_irrIAnimatedMesh. there is no way to actually _create_ T_irrIAnimatedMesh, but that is what T_irrSAnimatedMesh is for. so you essentially return an instance of T_irrSAnimatedMesh. you then create an instance of your new type and then pass it to the AddExternalMeshLoader() method of T_irrISceneManager.

HTH :)