Worklog for Oddball
PhysLite
Return to Worklogs
| ||
Hmm... I wrote a lengthy worklog a few days back, but it seems to have vanished. Anyway. I'm working hard to try and get v1.12 out some time this week. It's turning out to be a bigger update than expected, but I guess that's a good thing. I've just made the loading and saving functions stream smart. It's a small change that won't affect most, but it does mean that ".plb" and ".plz" files can now be IncBin-ed. The more stream savvy can also do a few more imaginative things. I've re-jigged some of the internal referancing, switching from lists, slooow, to managed arrays, fast. This is a major internal shake-up so there may be a some teething trouble and a couple of unforseen issues, but it gives a big speed boost to PhysicsUpdate and allows for some other positive tweaks. One consession is that TAdvBody objects are now referanced internally and must be manually freed, but this should be the only change that affects existing code. I'm going to add in some higher-order-esque functionality too. Mainly to use internally, but I'll expose them for those that might find them useful. For those that don't know, this means that you'll be able to apply a single function to whole collections in one go. As you can imagine doing this a lot would be slow, but used in the right way it can be extremely useful. An example of this could be, if you wish to Freeze all the active TMass objects: MassApplyToActive MassFreeze Or how about drawing all the TAdvBody objects in one line of code: AdvBodyApplyToAll AdvBodyDraw I'm also removing the examples and tutorials from the update file and giving them a permanent download link. I was aware with so many examples and tutorials in the update it was getting a little cluttered. This will also allow others to see how coding with PhysLite looks without having to purchase. DaveW ![]() ![]() "When you're the last man standing and still packing nukes you don't need experience points." - Brian Van Hoose |
| ||
The collision zone editor is now done and I've also made a few changes
to the advanced body editor. They are zipped and ready for download, see
below. They are currently Windows only and as I developed them on an XP
machine the layouts may be a little off in Vista and 98. Please still
consider them as BETA versions if you choose to use them. PhysLite Editors - BETA (641KB) Version 1.11 of PhysLite shipped in the last few days so if you haven't received it yet then email me and I'll see about resending it. Finally I've been pushing headlong into the boring, but extremely vital, work of getting the help files up to date. Now that PhysLite can be built as a module I find the help file to be very useful. Being able to press F1 to get a functions syntax, and then another press to get the full help is a great asset. I'd like to eventually get sample code in for as many of the functions as possible, but with hundreds of functions in the documentation it may take some time. I am also going to be adding to the tutorials. The current tutorials only touch on the basics and I feel they should take the developer further into the functionality of PhysLite. DaveW ![]() ![]() "When you're the last man standing and still packing nukes you don't need experience points." - Brian Van Hoose |
| ||
The collision zone editor is almost done. Using it is a snap and it
speeds up PhysLite development immensely. I've just got a couple of
features to add before putting out a public release. v1.11 is almost done as well. It's a fairly big update, especially for collision zones, but most of the new methods are geared towards making editors for your PhysLite games. v1.11 has been a little delayed as I'm making it into a straight module as well as the usual include. The big benefit of this is inline help and function/method highlighting. This means I need to check all the bbdoc help entries to check I've not done anything squiffy. I'm hoping to get this out the door sometime this week. DaveW ![]() ![]() "When you're the last man standing and still packing nukes you don't need experience points." - Brian Van Hoose |
| ||
My hate/hate relationship with MaxGUI continues. The collision zone
editor (ZED) is coming along nicely, however, due to my inability to
shoehorn MaxGUI into any form of OO-ness I have abandoned my principles
and gone completely procedural for the editor. This means the code will
be a lot neater, if not completely 'clean'. ZED has had the knock on effect, as I knew it would, of improving PhysLite's TZone type. There are tons of new methods and functions, and a few improvements and bug-fixes too. Quad tree's got a big optimization boost and I've cleaned up some of the TZone internals. All in all I'm very happy with my holiday progress. DaveW ![]() ![]() "When you're the last man standing and still packing nukes you don't need experience points." - Brian Van Hoose |
| ||
I realised this week that PhysLite has been in development, in one form
or another, for more than three years, and later this year will have
been on sale for two years. During that time it has seen one complete
rewrite, 10 updates with update 11 in the works as we speak, one full
blown editor with a second currently in development, and the source
expand to nearly 5,000 lines of code containing approx. 500 types,
methods and functions. All told it has been a mammoth undertaking with
many high and low points along the way. It is in this mood of nostalgia
that I have decided to reduce the price of PhysLite licenses for the
month of January. So I guess if you haven't already joined the wonderful
world of PhysLite now is the ideal time to join us. Check out the website for more info. and payment details. On the development side I have plowed into ZED, the TZone editor. It's still early days, but I've had a little more free time over the holidays so it's been progressing nicely. I also added the ability to pack your advanced body images directly into the .plb file. This was my intention from the start, but I'd always put off doing it for one reason or another. I'm glad I did as I recently came accross a very eligant way of implementing this which only needed the addition of four lines of code. DaveW ![]() ![]() "When you're the last man standing and still packing nukes you don't need experience points." - Brian Van Hoose |
| ||
First of all let me blow the cobwebs off this worklog. *Phoo* I guess
it's been a while since I've added an entry. You'll all be happy to know
my time away hasn't been wasted. PhysLite just hit v1.10 and I've just
put together the first BETA build of the Advanced Body Editor. During
the making of the editor there have been many additions to the engine
which means v1.10 was a fairly major update. All PhysLite owners should
have recieved the update by now, if not send me an email. A few worklog
entries ago I promised a few screenies to brighten things up around here
so I give you, from left to right; a TMass object being resized, a
TConstraint being created, a TImage being added, the TRigs being
organised, the finished creation being tested, the sparse :) online
help. I'm also releasing a public build of the Advanced Body Editor(windows only) to give non-PhysLite owners a chance to see PhysLite in action. Advanced Body Editor - BETA (291KB) Next on my agenda is the zone editor. Look out for more on this soon. Until next time. Enjoy. DaveW ![]() ![]() "When you're the last man standing and still packing nukes you don't need experience points." - Brian Van Hoose |
| ||
Well I guess it's time for my monthly worklog. I've been working on the first PhysLite editor this month. It's the Advanced Body Editor, or ABE
for short, and I'm finding using MaxGUI a real nightmare. This will be
the third application I've made using MaxGUI and I still don't seem to
be able to get the hang of creating a clean implimentation. I'm sure
MaxGUI is great when in the right hands but it just doesn't seem to work
intuatively to me. Anyway enough of my inadiquacies, the editor itself
is actually working well. There are two methods of editing elements of a
body, visually, or manually. Visual editing is done straight in the
canvas and is a WYSIWYG style of editing. Manual editing is done using
textfields and gadgets, and is more for tweaking values or getting very
precise values. Currently mass, constraint, and over-all body editing is
in and next up is rig and image editing. I'm actually considering
expanding the usefulness of the TRig object to allow image scaling,
tint, alpha, etc. turning it into a bit more of a complete sprite
system. I know in a previous worklog I said I didn't want to expand it
in this way, but I think it can only be a benefit if I do. ABE
will initially be released as a Windows executable until the bugs are
ironed out and whilst I document it. Then I'll release the source and
see about getting a Mac and Linux build made. After ABE is complete I will begin working on the Zone EDitor, or ZED as it will be known. Hopefully once both are complete we'll start seeing a few PhysLite games appearing. DaveW ![]() ![]() "When you're the last man standing and still packing nukes you don't need experience points." - Brian Van Hoose |
| ||
Wow! Has it really been two months since the last update? I'd like to
say that I've spent all that time working non-stop on PhysLite, but alas
life is such that I've barely been able to touch it. The only real
update is that I've added the ability to rotate the simulation drawing.
This is a tough one to get your head round at first. It basically means
that the simulation stays exactly as it is, but when it is drawn the
whole thing appears rotated. Think LocoRoco/2D Super Monkey Ball and
you'll get the idea. My ToDo list is actually very small so once it's emptied I'm gonna start work on the object editors. Jake L has already started on an excellent looking editor. Not sure if he's planning to release it to the community, but I want to have an official-ish editor anyway. My intention is for the entire PhysLite library of functions to be as editor friendly as possible, so people can easily make their own game specific editors. Making my own editors will give me a chance to iron out any issues in that respect, and possibly give others a little insight into how it's done. DaveW ![]() ![]() "When you're the last man standing and still packing nukes you don't need experience points." - Brian Van Hoose |
| ||
Well I've been hard at work on PhysLite this past week, and I've just
finished up the collision events code. Collision events give your game
feedback for the collisions that occured during the previous update.
This was a lot of work and involved a couple of false starts, but in the
end I've gone for a system similar to the standard events system
already within BlitzMax. This means that collision events can be handled
in several ways. You can use BlitzMax's Hook functions to intercept events as they happen, Poll events from the collision events queue, or you can Seek
a collision event by choosing two objects to see if a collision occured
between the two. In fact if you wish you can use all these methods
together to give maximum flexability. Each collision event has a
position and force, and of course the objects involved. It's also
possible to create your own custom collision events, although I have no
idea why you'd wish to. So far it seems reliable and fast. I'm just
cleaning up the code before documenting it, and I hope to have it
finished up on Wednesday sometime. As promised I released a stress test to get some feedback on PhysLites performance on different specs. The results were good and consistant, and I was pleased by the response. Anyhow here's the thread for those that missed it. DaveW ![]() ![]() "When you're the last man standing and still packing nukes you don't need experience points." - Brian Van Hoose |
| ||
This week I've overhauled the internals of the drawing commands. They
still work the same, but this allowed me to add a scrolling and zooming
system. Now scrolling and zooming can be done with just two commands. No
complicated math, just tell PhysLite which part of the simulation you
want to display and how zoomed in/out you want to draw and PhysLite
works out all the math for you. Also added a drawing method for
collision zones to compliment those for bodies. However I'm very
conscious that I don't want to turn PhysLite into a sprite system. The
drawing commands should, and will, always be secondary to the physics. I also spent some time on the collision zones. I've added a new style, hole, which is the inverse of fill. And after a suggestion from Jake L I've added custom collision responses. In fact Jake's example code could have been plugged straight into PhysLite, but I decided on a similar but subtly different approach. Still no screenshots for you, but I've just finished the shifted grid tutorial, which tries throwing as many objects around as possible, so I'll probably shove this on the forums as a stress/stability test. DaveW ![]() ![]() "When you're the last man standing and still packing nukes you don't need experience points." - Brian Van Hoose |
| ||
Testing, testing, testing. And that's about it really. My goal at the
moment is to get the new code all working rock solid. I kind of went on a
Brucey-like coding frenzy over the past few weeks and I feel
testing suffered because of it. So I'm going to take a little while to
put the new code through it's paces. Hopefully get a few screenshots to
put in this worklog. There's nothing worse than lots of dry text and no
pictures. DaveW ![]() ![]() "When you're the last man standing and still packing nukes you don't need experience points." - Brian Van Hoose |
| ||
Well finally finished the advanced body type. Loading saving and
copying all seem to be working correctly. Had a couple of issues, but
hopefully I've ironed them out after I went on a major bug hunt. It's
turned out very well and is a big improvement on the code I had written
for PhysMax. However it's also very different to the PhysMax code so it
looks like I'll have to scrap the editor I'd written for PhysMax and
start a new one. But the PhysLite code is far easier to use so hopefully
it won't be too much work. Also all the moving code is in too. Now a
body can be moved, translated, positioned, rotated, spun or turned as a
single object, whilst still allowing all the individual components to be
manipulated seperatly. DaveW ![]() ![]() "When you're the last man standing and still packing nukes you don't need experience points." - Brian Van Hoose |
| ||
I got a little side tracked this week and added all the procedural
functions. Now the lib can be used completely procedurally if that's
your fancy. I did get some work done on the advanced body type and now
there's only six(edit: make that five now) more methods to add. They are
however the most complex methods, but hopefully shouldn't be too much
longer. Then there's the small matter of documenting it all. PhysLite is
now well over 2000 lines of code so I've split it into three source
files. This should hopefully help make it more understandable and easier
to use. DaveW ![]() ![]() "When you're the last man standing and still packing nukes you don't need experience points." - Brian Van Hoose |
| ||
I've been mainly working on the advanced body type, TAdvBody, this week. The TAdvBody is an extension of the TBody
type and makes a body more of a single entity instead of a collection
of masses and constraints. It also directly associates with TRig and TImage types. This means that a TAdvBody
object can be affected as a whole instead of having to use it's base
components allowing loading, copying and saving, as well as the usual
moving and positioning. This will nearly double the amount of functions
and methods in PhysLite and brings it very close to the state PhysMax is
at. As such it's going to require a lot of testing although I may
release it early so PhysLite owners can have a play with it. DaveW ![]() ![]() "When you're the last man standing and still packing nukes you don't need experience points." - Brian Van Hoose |
| ||
I suppose PhysLite requires a little explination. PhysMax was becoming a
beast to maintain and I was unable to give it the time it deserved. As a
result it's all encompassing brief was scaled down and became the new
brief for PhysLite. This has extended the scope of PhysLite, but to a
much more managable level than PhysMax. Development news I re-added shifted grid collision culling. I've decided to make it manually configured as setting the grid cells too small can break the simulation. This allows the programmer to tryout different size grids to see which performs best. Eventually I'd like to automate it, but this works for now. I've also added a new tutorial and I've started work on a practicle example. ![]() ![]() ![]() DaveW ![]() ![]() "When you're the last man standing and still packing nukes you don't need experience points." - Brian Van Hoose |
| ||
PhysLite DaveW ![]() ![]() "When you're the last man standing and still packing nukes you don't need experience points." - Brian Van Hoose |
| ||
Wrong unfortunately. As tonyg kindly pointed out I've not updated this worklog in a while so I thought it was about time. The bad news is that PhysMax
as a stand alone project is now on hold. I'm still working on it, but
only as and when I need extra functionality as my free time is now very
limited. I've turned all my efforts to a game project that uses the PhysMax module. Well I suppose I'd better mention what I've actually got done. I've added some debug drawing code. What these functions do is draw the physics data on the display so that collision areas and the like can be seen visually. I also went back and reviewed the friction code. Friction is by far the most complicated part of the simulation, and maybe it's a little too complicated for a verlet integration. Currently I'm using the coulomb cone, or infact circle in 2D, method and it gives extremely realictic results. Well I've re-jigged it a little and I've now got two different friction models running. I'll have to see over the coming weeks which is the best for speed and accuracy. DaveW ![]() ![]() "When you're the last man standing and still packing nukes you don't need experience points." - Brian Van Hoose |
| ||
The main news this week is that I released a public demo of PhysMax in action. Here's the forum thread.
This was mainly a compatibility test, to make sure the module actually
worked on computers other than my own. There'll be more demos to come
but they'll all be pointless if I don't finish the actual module. So
this week I dived back into the code for PhysLite. Mainly adding
extra functionality, but also trying a few optimizations. Even though
the module is quite fast I'd like it to be faster. I've found the main
speed issue is iterating through all the collision checks. I tried a
shifted grid collision cull which was lightning fast, but unfortunatly
the simulation became a little jittery when many objects were all
bunched tightly together. I think the issue was objects changing sectors
mid check due to their collision responses. Anyway, I've had to scrap
that method for now. It was just too jittery. DaveW ![]() ![]() "When you're the last man standing and still packing nukes you don't need experience points." - Brian Van Hoose |
| ||
Been working on the PhysMax module this week and more specifically on the Body Loading functions. PhysMax
can now load a body into the engine as a template and from that
individual bodies can be created. The templates are currently a seperate
object, but this is just whilst I work on them. Eventually they will be
integrated into the Body object and will work transparently from the
coder. Also been using the Body Editor to create some rigid body objects for testing. It's working well and I'm able to create the objects in a couple of minutes. It could do with a couple of small tweaks here and there but I'm very happy with how it turned out. I'm going to make a quick demo this week to see how well PhysMax performs on various systems as it's only been test on my PC so far. DaveW ![]() ![]() "When you're the last man standing and still packing nukes you don't need experience points." - Brian Van Hoose |
| ||
I went back to work this week so I've not been able to dedicate a lot
of time to this project. However, due to my continuing insomnia, I did
manage to finish the editor. It still needs a little tweaking here and
there, and I'm sure I'll add some extra functionality after I've used it
for a while. Next will be to plug the loading functions into PhysMax itself. It feels like a very long time since I worked on any actual physics code for PhysMax.
But with the editor done it feels like the finish line is in sight and
I'll be glad to be able to put this module to work in an actual game. DaveW ![]() ![]() "When you're the last man standing and still packing nukes you don't need experience points." - Brian Van Hoose |
| ||
It's been all boring editor stuff this week. Not my favourite thing to
do, but necessary non the less. Managed to get most of it done.
Currently rigid or soft bodies can be constructed using absolute values,
and images can be rigged up to the constraints. Next to do is the
visual editting part, and to finalize the file format. Here's a quick
screenshot for those that like looking at editors :p Once the editor is done I'm hoping to create and release some examples of the module in use so I can get some public testing. I'll be glad to get back to the exciting physics stuff. DaveW ![]() ![]() "When you're the last man standing and still packing nukes you don't need experience points." - Brian Van Hoose |
| ||
It's been over a month and nothings happened. Not my fault though as I
was taken seriously ill and hospitalised, but enough about me. I've
decided to split the project up into two seperate mods PhysLite and PhysMax. PhysLite This will contain only the physics code and nothing else. The idea being that PhysLite deals only with the physics. Displaying the results has to be dealt with else where. This part is complete although I'm sure when I get round to thoroughly testing it some bugs will rear their ugly heads. PhysMax This mod however will contain other useful automated sollutions for things like loading objects, and displaying images based on the physics simulation. I'm doing a little re-organising to this to automate it as much as possible. This means for simple situations an object can be loaded with one comand and is imediatly ready to interact with the rest of the simulation. This is not meant to be an all encompasing sollution as the games I have in mind for using this mod will require some specialised functionality. The Editor In my last worklog I eluded to the fact that I was working on an object editor. Well when I finally made it back to my computer and fired up the editor code I realised that a complete rewrite would have to be done. It seems I'm struggling to understand how to set out a clean and understandable MaxGUI project. DaveW ![]() ![]() "When you're the last man standing and still packing nukes you don't need experience points." - Brian Van Hoose |
| ||
PhysMax will be a 2D physics module for Blitz Max. The project is
already quite advanced, and the reason I'm starting a worklog so late on
is to keep me motivated to see it through to completion. The module The physics part is all done. You can create bodies, give them mass, stiffness, friction, etc. You can create scenery and bounds for the bodies to interact with. Then set them loose. It's all very stable and save for a few optimisations is complete. Still to do however is collision feedback. Whilst bodies already respond to collisions accurately there are times when you what more info about the collisions for sound and visual effects. This is where collision feedback comes in. You'll be able to get information on collision locations, force, etc. The Editor This is the part I'm working on now. It's tough going. I prefer the fun stuff of letting my little physics objects bounce around, and I'm not to keen on doing the boring stuff like checking editor buttons do what there supposed to. At the moment you can create, place and size masses, and you can join them all together with constraints. Next step is to add parameter editting such as friction, stiffness, etc. Then finally tie it all together with a file format for loading them straight into the engine. I'm sure there's more I've left out, but I'll save all that for a later worklog. DaveW ![]() ![]() "When you're the last man standing and still packing nukes you don't need experience points." - Brian Van Hoose |