SOW open source wrapper v0.2 release
BlitzMax Forums/BlitzMax Programming/SOW open source wrapper v0.2 release
| ||
| public release of the Simple Ogre Wrapper includes Newton physics! particles! shaders! Woohooo - with full source - All basic and rudimentry at the moment, would welcome any code contributions or for that matter any media contributions from talented artists... Donate to me by all means but dont forget to donate to Ogre http://sourceforge.net/donate/index.php?group_id=2997 The Ogre engine has come on leaps and bounds in recent years and deserves your support This wrapper aims to be both simple to use and as thin as possible and even to be a little blitz3d like |
| ||
| jerry jerry <- this comment makes no sense anymorre due to heavy handed censorship of this and other threads (which is a shame cause I was having fun!)  ya gotta ask how not having the source code to somthing that wont be supported this time next year makes it better |
| ||
| . Good work Chris C , only had a lil look tho. |
| ||
| Nice. I have to check it out. But man... 20 dll to make it work? |
| ||
| @Haramanai thats ogre for you.... |
| ||
| @evak arrrgh gag me lock this thread!!!!!!!! <-- mercy someone *really* consored this thread! 80 people so far cant be wrong contribute! make this wrapper the standard! please make it simple, make it work! that was a subliminal message, please reread 1000 times to self |
| ||
| The wrapper dont seem to work :( |
| ||
| top feedback, I can really help you given that information... |
| ||
| Chris, When I try to compile example1.bmx I get a "sow.dll loading error." I extracted the zip file into a "demo" folder. The sow.dll file is there together w the example1.bmx and sow.bmx. Wonder if Alienforce had the same problem |
| ||
| I have no idea what problem alien force is having. I have had a report of a similar problem to yours, it happens rarely, went away on one machine for no apparent reason! and has me a little bemused. Have you the ability to recompile the DLL? you could try recompiling it, might give me some kind of clue as to why LoadLibraryA is failing. theres a dependancy of dll's that could cause LoadLibraryA to fail, but I'm still researching it any LoadLibraryA experts out there!? |
| ||
| What do I need to compile the dll? |
| ||
| MS visual C unfortunatly (2005 version 8)... if I get chance I'll look at doing a mingw makefile |
| ||
| I have no problem with Aurora or Sweenis Ogre wrappers. So i dont really know. What feedback do you need? |
| ||
| well thats slightly better that doesnt work what exactly happened when you ran it? what version of bmax are you using? I'm going to ask someone else to try out msvcrt.dll, as I have a feeling it might need it. Ideally I'd like to bin ms visual c altogether as it causes more problems than it solves... I'll let you know how I get on, but I'm probably going to turn it into a monolithic static library using just mingw. |
| ||
| I think an open source wrapper is a great idea BTW. There are a lot of talented people on here. And ogre is a fantastic renderer with some nice addon modules avaliable. I hope some decent coders jump onto it and make it something great :) |
| ||
| OGRE is... uh nice, except the DLL Hell thing.... |
| ||
| we only had problems with Aurora when we mixed A VC8 dll piggybacked on top of a VC7.1 dll. It's all 7.1 now though. Reason we used both was that I had to compile the source with the ofusion scene loader in VC8, which is all I had access to. On my older computer that didn't like the VC8 DLL a full windows update seemed to fix the problem. BTW, one killer feature that I'd like to see in the engine would be the ability to intercept the ogre renderer and integrate bmax output. I'm not sure how the CEGUI lib does it in ogre, but being able to use Bmax for GUI stuff would be a huge bonus, especialy if it meant we could use Maxgui or Iglass, and one of the features currently missing in the Ogre engine we are using. |
| ||
| does it matter that it's got lots of dlls? It's not like we ever have to use them and the idea of putting everything in the core like irrlicht is bad I think, since with ogre you simply delete the stuff you or ogre doesn't use. |
| ||
| Erhmmmm.... Have you updated the SOW.. Because it works now. |
| ||
| Error report for - ODE-Cubes.bmx _ Building ODE-Cubes Compiling:ODE-Cubes.bmx flat assembler version 1.64 3 passes, 30872 bytes. Linking:ODE-Cubes.exe Executing:ODE-Cubes.exe Attempt to call uninitialized function pointer Process complete _ And yes my JV-ODE is working perfect. |
| ||
| works okay here! what version of jv-ode are you using? did you run in debug mode to find out what function pointer is uninitialized? I'm only to happy to help you out but *please* meet me 1/2 way and give me a few clues to work with! thanks anyhow i'd wait till viper gets some time he said he'd throw together a car demo, just threw the ode thing together its a right hack job and I didnt mean to include it!!! I'm beginning to think that using VC++ was the dumbest "short cut" ever... it *really* sucks! I dont know if oFusion can be made to work with mingw, but I'm seriously hacked off with vc++ The quick fix to get it running if you have the "can't find sow.dll" problem is to goto windows update and grab .net framework 2.0 Then if you get a runtime error, run the example with initOgre(1,LL_BOREME) this should bring up the ogre settings dialog, and then everthing should be fine If not delete ogre.log rerun and post the last bit of the log that should detail the error, *not* all of it, its verbose to say the least! I'm open to suggestions as to exactly how this can be made more robust! its not too brill ATM anyhow I'm breaking off from pushing objects round with newton and I'm gonna see if I can't get a mingw install going... oh and I'm thinking of splitting each of the ogre dlls into 2 or 3 seperate dlls (only joking :o) ) |
| ||
| ant used codeblocks IDE with the free VC7.1 toolkit following the instructions on the ogre Wiki to compile. Much easier than Mingw He needed to tweak the SDL part of the tinyxml to not use SDL or something in order to get it to compile. http://www.ogre3d.org/wiki/index.php/Codeblocks |
| ||
| yeah was looking at that! ;) thx evak! unfortunatly the c++ toolkit compiler is no longer available Mingw is a none starter, until max can cope with an upto date version of gcc anyhow... gonna have to think about the best way to proceed, ideas welcome! |
| ||
| Hi. Been meaning to get to this. I get the "sow.dll loading error". Strange, I use the LoadLibraryA command in my own project with no problems. The DLL's I'm using were compiled with PureBasic though. I have not installed the .net 2.0 fix though. I think there needs to be a way around this error without needing to do that. |
| ||
| Chris I have not yet tried the wrapper (I will when I get a chance). Just wanted to say thanks for putting in the effort. |
| ||
| @codegit thanks! @kenshin As soon as I can rip it (sow) screaming from the teat of the .net framwork thats what I intend to do, however it means me spending a whole coding session setting up a non MS build enviroment that doesnt interfeere with max's elderly gcc requirement If you dont mind not being able to use sow for a little while would you mind NOT installing .net and contacting me via email (I have no way to test the "sow.dll loading error" out of interest I think the dependancy problem is comming from the pre-compiled dll's I'm not sure, so theres a few things I need some willing victim err I mean helpful contributor to test for me. thanks for the feedback! |
| ||
| @Chris : Check your mail |
| ||
| Hi Chris C you are making a very good job, i was waiting for this!! I tested "example1" and it runs perfect but when i exit by pressing esc it shows this error Compile Error 1.00 ZOrder:0 I am using Bmax 1.18, maybe is there the problem |
| ||
| Mingw is a none starter, until max can cope with an upto date version of gcc anyhow... In what way can Max not cope with an up to date version of GCC? I'm using the latest version of GCC to build my TrueVision wrapper and it works great. |
| ||
| @gabriel oh thats good last time I tried it broke some modules when I tried to recompile! I managed to used a different version of mingw in a different location but I'm having some problems getting my project to link properly... @Josepho reduce the logging level to LL_LOW instead of LL_BOREME its the amount of spew to the console thats confusing the ide... |
| ||
| @gabriel oh thats good last time I tried it broke some modules when I tried to recompile! I managed to used a different version of mingw in a different location but I'm having some problems getting my project to link properly... As long as you don't rebuild/modify Win32MaxGUI it can use it just fine. |
   |