New update available!
Blitz3D Forums/Blitz3D Programming/New update available!
| ||
| See home page for more info. |
| ||
| Nice one... :) |
| ||
| Yay, now I can stop whistling innocently in threads about the type slowdown bug. :-) I emailed Mark about the problem a day before that thread went up and he fixed it that night and had me test it, and he's been torturing me for the past week by not reelasing the update. :-) He still hasn't told me what the "quite spectacularly stupid" (his words) bug with it was. I'm placing my bet on a for loop with a delay in the middle. :-) The new type freeing is literally 3000x faster than it used to be. It is now only 2ms slower than freeing a type of the same size without an array. Just in time too... I'm going to be releasing a system shortly which uses lots of types with arrays. |
| ||
| Mark, could you be a little more desriptive on the bug fixes please? :-) "Fixed slow mem deallocation." I'm probably the only person where who knows that refers to deallocating types with arrays. :-) And what does this mean? "Reimplemented the 'bug' that allowed alphablending while multitexturing, but in a slightly more controlled way!" There's never been a really good description of how alpha maps are supposed to work in Blitz in the first place. I don't understand how it's supposed to work, and I don't know of anyone else in the Blitz comunity who has a good understanding of it either. So what should the expected behavior be if I have one texture set to multiply in each texture unit each with an alpha map? Will the alphas be added, and the textures multiplied? And will alpha now work with textures set to multiply x2? And what will happen in the following scenarios: Card with one texture unit, one texture, set to multiply, with alpha map. Will it render the same as a card with two texture units? Card with two texture units, two textures, first texture set with alpha map, set to multiply, second texture with no alpha map set to multiply. Will that render an object with holes that has it's color multiplied by the light map in the second texture unit? Or will the second texture unit, lacking an alpha map obliterate the alpha? And will this render the same on a card with one texture unit? |
| ||
| Reimplemented the 'bug' that allowed alphablending while multitexturing, but in a slightly more controlled way! Oh, so that's where the "it's not a bug - it's a feature!" thing came from... That was a bug?? Also, I'm daft, but what is FMOD? |
| ||
| oh, and thanks for the update :D |
| ||
| I'm probably the only person where who knows that refers to deallocating types with arrays. :-) Nope -- coincidentally enough, someone else emailed me last week to complain about it, and that found its way to Mark too. Dual-pronged assault! Dillpickle: FMOD is the sound API Blitz uses... |
| ||
| Am I being dumb or can we still not jump to a position in a .mod? |
| ||
| Really pleased that the old memory deallocation bug is fixed. Whats the point of updating FMOD? The only people that wanted it updating is so that they had new sound commands to play with. Any clues as to what the real benefits are? |
| ||
| "Nope -- coincidentally enough, someone else emailed me last week to complain about it, and that found its way to Mark too. Dual-pronged assault!" Okay so two people know! That's sooooooo much better. :-) Now I want to know who who emailed FIRST. :-) |
| ||
| Thanks Mark! My gut feeling is this is a mantinance release - a tidying up of loose ends and general fixes. I am pleased. In the future it may be easier for him to just add things as we go along. The hwmultitexunits thing didn't appear for nothing. It's probably part of larger changes under the hood that allowed the alpha fix to take place. All guesswork though! As it stands, I'm happy the alpha thing's in. |
| ||
| The type array fix is a God-send. |
| ||
| The type array fix is a God-send. Yes, this is very cool |
| ||
| The type array fix is a God-send. amen. |
| ||
| Now I want to know who who emailed FIRST. There have been a ton of threads about it... |
| ||
| Yeah but as soon as I emailed Mark he fixed it, which leads me to believe nobody actually thought to email him. :-) |
| ||
| Now I want to know who who emailed FIRST. There have been a ton of threads about it... Yeah but as soon as I emailed Mark he fixed it, which leads me to believe nobody actually thought to email him. :-) What? Does that mean we should email the entire "Blitz3D Bug Reports" forum? |
| ||
| So, erm.. does the FMod update actually =mean= anything? I mean 3.72 is the latest version. Do we now have access to all that stuff? |
| ||
| I was wondering if it is possible to make a decls file for FMod. I can't see that working as it's internal to the blitz system. |
| ||
| "What? Does that mean we should email the entire "Blitz3D Bug Reports" forum?" Most of the bugs in the bug report forum aren't major, aren't bugs with Blitz (but rather FMOD), or even bugs at all. Which is probably why Mark sometimes fails to notice the real bugs. I'd only email him if you know for sure that a bug IS a bug with Blitz, that it's one he can fix, and that it's a major bug that impacts a lot of users. "So, erm.. does the FMod update actually =mean= anything? I mean 3.72 is the latest version. Do we now have access to all that stuff?" I don't know, but I thought I heard someone talkimg about some kind of listener bug recently. Perhaps that was fixed. I think there was some major problem with the 3d sounds not moving about as a result of it. |
| ||
| There have been a lot of FMod bug fixes in 3.72 (and 3.71) and I believe the listener bug was addressed. There was talk about it on the FMod forums. Just getting the updated dll is good, but there is a lot of new features in 3.72 and it would be a crime to not be able to use them. (like having an eight cylinder car, but four cylinders are blocked) |
| ||
| The FMOD bug I remember recently was sounds not being silent when a volume of 0 was specified...I think that was when Mark commented about the FMOD upgrade. |
| ||
| Cool... another update! Maybe the next one will have DXTC... and render to textures? :) |
| ||
| Thanks! Nice to see multitexturing alpha 'bug' reappear :) |
| ||
| The lowdown on why textures are far faster and more detailed under DXTC - and why they rock: http://www.nvidia.com/object/LO_20010530_3866.html |
| ||
| DXTC makes textures take up 6x less texture ram, with minimal loss of visual quality. It would be nice if Blitz supported them. You could double your texture width/height, and still save ram. Mark probably hasn't supported them because he fears people will try to write to them and complain that it is slow. I can't see any other reason he would choose not to, other than simply not thinking they are not worth supporting and I can't understand why he would come to that conclusion. They have been a standard card feature for years, so compatability isn't the issue. |
| ||
| sh*t, that is an enormous difference! it is indeed an important issue! |
| ||
| Where is the versions.txt for this release? I installed the update, but my versions.txt in my Blitz folder only goes up to 1.85 ... |
| ||
| If that's the case you probably installed it wrong. You may have mistyped the path... I don't think it checks to make sure it's correct. Mine had a versions.txt. |
| ||
| Mine has the right versions.txt as well. ***** V1.87 ***** Fixed slow mem deallocation. FMOD updated to version 372. Added HWTexUnits(), returns the number of hardware texturing units available. Reimplemented the 'bug' that allowed alphablending while multitexturing, but in a slightly more controlled way! ***** V1.86 ***** Fixed: Evil, ancient ImagesCollide bug. Added: TextureBlend mode 5, for 'multiply 2' blending. This is the same as multiply blending, only the output value is doubled. The idea behind this is that it allows lightmaps to not just darken, but also brighten colormaps. Use a lightmap texel value of .5 (eg: 128,128,128 - actually, .5 can't be represented exactly!) to get 'null' lighting, <.5 to get darkening and >.5 to get lightening. Roll on Ico in Blitz! Multiple bone weights. Each vertex can now be influenced by up to 4 bones, each with an arbitrary weight. If more than 4 weights are present, the 'heaviest' 4 are used. Weights are always normalized so that they sum to 1. Bones can still only be imported/created via B3D files. Note: The EntityRoll function and Dynamic mesh system have been tweaked a bit. Post any poroblems in the bug reports forum |
| ||
| If you want to know more about OXM format: http://www.blitzbasic.com/Community/posts.php?topic=27139 |
| ||
| For those of you weho don't read blitzcoder, norki has found that you can use .oxm files in your program! Just convert a normal xm file to oxm using this util: http://www.fmod.org/files/oggmod.zip , and rename the output *.oxm file to *.xm. Then it'll load into blitz. |
| ||
| SWEET |
| ||
| Can anyone recommend a good app for composing .xm files? I haven't worked with a tracker since Octamed on the Amiga, and I must admit I've always preferred sequencer style editing to trackers. |
| ||
| I've used modplug before and it seemed pretty good. http://sourceforge.net/projects/modplug/ |
| ||
| Thank you Mark for the brilliant updates ! :) Sergio. |
| ||
| Woah. Problem! My flickering torch (hardware) lights have failed. (LightRange = 20) Have reinstalled 1.86, and they're back! Mark? |
| ||
| Hang on. Just reinstalled 1.86 (got lights) then reinstalled 1.87, got flickering lights back. Must be me. OK. I hope. But other lighting problems on B3Ds. Will start another post. |
| ||
| EpicBoy, has your versions.txt file somehow become read-only? I'm happy with this update... while it doesn't do much, the type slowdown thing was starting to make my project look bad ;] Now it runs super smooth again! |
| ||
| what type slowdown thing? I must have missed it. |
| ||
| Well, more specifically, Blitz arrays, being the fixed size arrays stored within a type. I think. That was it, wasn't it? =] |
| ||
| Ooh an update? I seem to be a few days late at larging this. The front page hardly makes it obvious to spot a new update - I think the date should be there too (in big letters) - it should scream 'down load this sucker' at you - not blend into the walls like a turnip at a party full of teenage girls. |
   |