thomashaaks
Forum Replies Created
-
AuthorPosts
-
thomashaaksParticipantThe screen shots look great and the themes are perfect!
Will update my TimelineFX editor tonight and have a play around with those effect libs!
Thanks for the great (and still free) support of TimelineFX with new libs, it’s so appreciated!
Cheers,
Thomas
thomashaaksParticipantHmm, seems to me BlitzMAXCoder issue 3 might never see the light of day π
What about posting the complete tutorial on your site, Pete?
Cheers,
Thomas
thomashaaksParticipantPete,
I think it would be nice to have some simple sample code with a scrolling world and properly scrolling emitters πDo you think you could create something?
Thanks,
Tommy
thomashaaksParticipant@peterigz wrote:
The TimelineFX module is now available via SVN at http://subversion.assembla.com/svn/timelinefx-module. Just checkout into rigz.mod in your mod directory for an easier way to keep up to date with the latest changes.
Great! And it works like a charm π
Thanks for this improvement!
September 11, 2009 at 11:21 pm in reply to: Thanks for TimelineFX tutorial in BlitzMAXCoder 2! #3502
thomashaaksParticipant
thomashaaksParticipant@peterigz wrote:
I did mean to change the name of a field in entity.mod call cs, which stands for current speed – not exactly very readable, but will change it to “Speed” and upload it probably tomorrow. So just a little forewarning that you will have to change the name in your code if you’re using it at all.
As long as you don’t forget to update your tutorials because you used it in the “Making a game from start to finish” tutorial.
Maybe while you’re at it you might also implement the parenting mechanism (attach the effect to the player object) to avoid SetPosition() in your tutorial as you suggested a few days ago?Oh, and of course, thanks for all the fixes and enhancements in the editor and the module! That’s great stuff (especially the stretch value sounds promising for space games π )!
thomashaaksParticipant@redspark wrote:
@thomashaaks wrote:
The “circular import” issue sounds to me like a design issue – that Mr Sibly doesn’t want to change.
It’s actually not possible to change it because imports are pre-compiled. Without both types present in the file that form a cyclical reference, the file wont compile. To change the import to allow it to import uncompiled code, gives you the same thing as an included file. So they are really designed for two different purposes.
Hi Redspark, first thanks a lot for the workaround suggestions – that will surely help me.
The suggestion of the Global game object isn’t cheating so much – using OO design patterns you call that a Singleton which is indeed nothing else but a global variable accessible from everywhere likeMyGlobalClass.GetSingleton();
π
But still I’m convinced that technically there would be a way around the “circular import” problem – other languages like Java, C# or C++ handle those issues fine. It would just require a multi-pass compiler/linker IMHO. To solve this problem it would surely imply quite some work from BRL/Mark Sibly. But anyway, this is not to be solved by us.
Thanks again for your helpful answer – my question is solved π
Cheers,
Thomas
thomashaaksParticipantAndrej, your suggested emitter ideas are great!
Welcome to the forum, by the way π
Cheers,
Thomas
thomashaaksParticipant@peterigz wrote:
I would just use include if you want to separate your types into separate files, that’s exactly what it’s for really.
Thanks Pete, I think I will choose that route.
The “circular import” issue sounds to me like a design issue – that Mr Sibly doesn’t want to change.
So the main Game type would include all the other files (in proper order), right? That should solve my multiple files question.
Thanks for your answer and the link!
Cheers,
Thomas
thomashaaksParticipantOh, that sounds good. It would also show proper usage of the framework.
It was already a bit confusing for me at the beginning that the player’s update routine only modifies some tlEntity fields like direction and currentspeed and all the magic happens in super.update() π
You might enhance readability by adding self. in front of those inherited fields (I wished BLIde would highlight them as “field variables”) to make clear that those variables are not just locals…
But in general the code is very readable, clear and straight to the point – I liked it a lot π
thomashaaksParticipantIn part 2 in the Create method of tSpaceWormGame there is this buggy line:
Player = New tSpaceWorm.Create(GraphicsWidth() / 2, GraphicsHeight() / 2, CopyEffect(g.wormeffect, g.particlemanager), self)
Of course g is obsolete or could be replaced by
self
.
thomashaaksParticipantYiippieh!
It’s working now. After downloading and installing rigz.mod and the extras everything is working now.
Even rebuilding the modules worked fine and a fresh compile of vaders.bmx with the newly built modules also works!Thanks for your support, Pete!
Now for the real fun π
Cheers,
Thomas
thomashaaksParticipantI’m also at work atm so I will try it tonight π
thomashaaksParticipantNope. Still not working. Now I get a dialog box that says:
Not a valid effects library.
It stops in line 443 of vaders.bmx after loading the effects library which seems to return null so effectsLib in line 443 is null and causing an error.
thomashaaksParticipantOkay, I’m not building in threaded mode. Only debug build and quick build are on. Didn’t make a difference when I switched quick build off.
That’s an annoying bug πΏ
I’m using BlitzMax 1.33 btw. on Windows XP with all Servicepacks installed.
Does the assembler source of my compiled Vaders help? I attached it anyway.
Edit: Of course I forgot to attach the file π³
-
AuthorPosts