imported_peterigz
Forum Replies Created
-
Posts
-
Yeh that sounds like it works ok. I will do a new sample with 2 glCanvases and see if that replicates the issue.
Is the editor working ok on the Nvidia 8500GT?
Ok, I’ve attached one of the max2d samples of wxWidgets, would you mind running it and letting me know if you get the same problems when minimising, or maybe even resizing? Thanks.
Hey GfK, ok, I’m just trying to figure out what’s changed since the version it worked for you, which was version 1.01 I think? That was the version that implemented Bruceys patch to fix other people with the intel gfx who were crashing. Since 1.01 nothings changed as far as that’s concerned.
Ah, just read your edit, I wonder if there’s something I can do to reset things when a restore event happens… I’ll look into that, thanks!
Just a quick update that fixes a few bugs:
* Fixed bug with import shape importing shapes twice
* Fixed bug where resetting the stretch graph was not actually restting it.
* Saving a new effect file now adds it to the recently loaded list in the file menuThe import shape big makes it worth while updating! 😉
Yes, I’ll add it. I should have just added it when I did it for vaders but just didn’t think about it at the time 🙄
ps. that’s a nice looking tutorial, I’ll have a read through later when I get home 😎
It should just be a case of setting animating to true and setting the framerate to however fast you want it to animate. Framerate is measured in frames per second.
Entity.animating=true
Entity.framerate=30 'animate at 30 frames per second
Hi Samichan, they are supposed to be in there yes, and I’m not sure why they aren’t 😕
Anyway, I just re-uploaded the module again and it should be correct now, so just download it again and overwrite rigz.mod with this one.
Either that or you can be re-build all modules, but if you’ve never done that before it can be a bit of a hassle, so just download it again otherwise 🙂
Those are great ideas for emitter libraries 😎 , the environmental effects were something I was thinking of creating for an emitter library. All of them should be possible. Currently I’m making some enhancements to the editor and module, but then I think I’ll spend more time creating emitters and showing off what TimelineFX can do.
I would just use include if you want to separate your types into separate files, that’s exactly what it’s for really. You can use import if the code you’re importing will compile on its own, but if you have types that reference other types and objects/variables in separate files then you will have to use include instead.
The only other thing about include is that you have to make sure you include files in the right order so that every object/variable that an included file needs has already been declared.
I found this thread on blitz forums where Mark Sibly explain cyclic issues best:
Import’s can not be cyclic, so you are correct in saying that 2 types cannot mutually refer to each other via imports.
The solution to this is simple, if initially a little scary: 2 types which mutually refer to each other must appear in the same source file. You can do this either by physically placing the source code for the types into the same source file, or by using Include to produce a logically ‘large’ source file from several smaller source files. Indeed, this is the *real* reason Include is in there!
In my opinion – and I know this will be contentious – not allowing Import cycles is actually a very good thing. It gives you a very clear dependancy tree and allows for perfectly predictable startup/initialization behaviour, as any Imports are *guaranteed* to be fully initialized (ie: their ‘main’ code has run and returned) by the time you’re initializing.
I have also found that it almost forces you into writer cleaner code, making you think about your file/object dependancies a bit more carefully and occasionally prodding you into a better design – but that may be my imagination!
Link to thread here: http://www.blitzbasic.com/Community/posts.php?topic=44108
Incbin should work fine, I haven’t tried it myself but I can’t see any reason why it shouldn’t.
MyEffects:tleffectslib=loadeffects(incbin::MyEffects.eff)I’m not sure if that’s the correct syntax off the top of my head but something along those lines. Or use Blides My object:
MyEffects:tleffectslib=loadeffects(my.resources.MyEffects_eff)if you’re using a blide solution.
Something on the to do list actually is to password protect the .eff files. As they’re only zip archives and that feature is already in the zipengine mod it should be pretty easy to add.
Ahh yeh I see it, thanks.
I should change that tutorial a bit actually. Rather then add the worm effect to the particle manager and using setposition to keep it attached to the player, you could simply add it as a child of the player and it will stay relative to the player automatically.
