Will there ever be updates
Blitz3D Forums/Blitz3D Programming/Will there ever be updates
| ||
| Has blitz3d gone dormant? If there are no updates anticipated then the author(s) should say so... I can only program so long in a language that is not going to be improved or have functions added. Any information about the future of Blitz3d would be appriciated! |
| ||
| I'm not sure. What I do know, is you can add extra functionality EASILY thanks to the ability to use decls. If you would like an example, I'd be GLAD to show you! =) Thanks! =) ~DarkShadowWing~ |
| ||
| Blitz3D is old now, even they continue adding stuff, DirectX7 will be discontinued at some point. Stay tuned though, Max3D is coming for BlitzMax sometime soon. |
| ||
| "I can only program so long in a language that is not going to be improved or have functions added." Why is that? Will it stop working? I'm going to be using Blitz3D for a good few years from now regardless. |
| ||
| Just because its old, you're just gonna GIVE UP? THAT easily? REALLY? I may not be an expert, but thanks to blitz, and these people on the forums, I may have a job soon selling my project I'm working on. I can't believe you're just gonna give up like that. Because I'm gonna tell ya right now. You're giving up a WHOLE lot. You may give up you're dream of being a programmer if you don't at least TRY to learn Blitz. I may not know alot about it, but I know one thing. Most of the people on these forums are VERY helpful.. And you're just gonna give up? I pity you. No offense.. ~DarkShadowWing~ |
| ||
| Check out the Fast extensions and others in the Toolbox. They are giving Blitz3D a new lease of life. |
| ||
| I kind of agree tho - theres a lot of smaller things that could be fixed (and I'd like to see some more advanced things)... i.e. 3D Audio is currently a software hack - it shouldn't be that hard to implement hardware DirectSound3D. Implementing the backend thats used in the devil shadow system shouldn't be that hard as several people have already done the hardwork - the only potential issue could be patent problems with creative - I'm not too sure there. This should give the shadow system a decent performance boost and hopefully fix the multi-texturing issues with it. Ageia physics or similiar could be implemented fairly easily making it much faster to work with this stuff. Theres many things that could be sped up too, sure there are dll/decls to speed up some of this stuff but its much nicer not to have too many 3rd party dependancies. As I've said before - myself and I believe quite a few others would gladly pay a reasonable fee to see an update with these kinda features. Blitz Max just doesn't have the friendly, relaxed feel that B3D has. |
| ||
| Blitz3D SDK is open source now. Hack and improve any way you wish, assuming you already have the SDK's license. |
| ||
| The problem is, mark wanted to keep things super stable with blitz3d. If he were to revisit the code, and change things, it may break on peoples machines and half the stablity of the product, which means more work tryiung to find workaround for old tech, that could be broken with DX 10 or what not. I think you just have to accept blitz3d is an incredible product that has spanned 8 odd years??? and is still a dream to use. Best software i have ever bought :o) |
| ||
| Best software i have ever bought :o) +1 on that! |
| ||
| Ross C: That already happened with 1.99, can't get worse stability wise. But I agree, it exists for pretty long now and is great, just 1-2 small things that are missing and it would be all great :) (loading from banks, asyncronous file io - both things that userlibs can not really adress unlike visual stuff -> fastexts) |
| ||
| i.e. 3D Audio is currently a software hack - it shouldn't be that hard to implement hardware DirectSound3D. That would *be* a software hack for many, since DirectSound3D no longer has hardware support in Vista. Ageia physics or similiar could be implemented fairly easily making it much faster to work with this stuff. They can also just as easily be implemented by anyone else. Having it fitted into a 3D engine (or language in this case) either ends up being superfluous or it limits flexibility. It won't be any faster or slower depending on which side of the language it's used from. |
| ||
| @Dreamora That already happened with 1.99, can't get worse stability wise. Could you please enlighten me about this? (I'm a fresh new Blitz3D customer, so 1.99 is my first version) Is there anything I should really avoid doing in Blitz3D to maintain maximum compatibility? English is not my native language but "can't get worse stability wise" sounds very critical to me. Is something very broken in 1.99? |
| ||
| Until I conpletely exhaust Blitz3D's capabilities and push it's limits and boundaries to achieve all that is possible with it and its tools, I see no reason to consider it dead ;) |
| ||
| I 2nd that ;) |
| ||
| Well openAL then or something similiar - some kinda hardware mutli-channel audio solution... I prefer something like ageia integrated into b3d natively rather than using a dll/wrapper/decls as there seems to be some issues with more extensive use resulting in random MaVs. |
| ||
| That already happened with 1.99, can't get worse stability wise. I'm curious as well...are there any bugs with it? |
| ||
| yes there are some small things like extremely slow sprites but most of it is ok as far as I know |
| ||
| Oh dang. Getting back to 1.98 ASAP! |
| ||
| @kryzon there is the same bug in both versions I think down to 1.96 but you can easily make your own sprites using pointentity |
| ||
| Well openAL then or something similiar - some kinda hardware mutli-channel audio solution... There are already libraries available for at least one, probably more, such audio solution. Unfortunately, due to superstition or something else which is beyond my comprehension, they're used by very few people. Speaking of which.. I prefer something like ageia integrated into b3d natively rather than using a dll/wrapper/decls as there seems to be some issues with more extensive use resulting in random MaVs. Given that the entire Blitz3D function set is found in a DLL - albeit that it's eventually statically linked - I think you can safely assume that there are no issues with extensively calling a DLL. Anything which MAV's with extensive use is either a bug in your code or a bug in theirs. |
| ||
| I created my own sun-flare using sprites in 1.99, thinking 'I'll have to convert it coz of the 1.99 problem'. But nope it works fine, no apparent slowdown. Maybe with 1000's of sprites?... Don't need physics/rag doll. 3D sound in Blitz works fine for me - was there a problem? And I've yet to explore the FastExt extras. So yes, best buy I ever made. A dream to kick off a 'what if', right through to full release. I'd gladly pay for B3D again. |
| ||
| Sometimes these apparent 'bugs' are just someone who did something wrong and thought it was blitz's fault. I mean, good fact, where is the proof? |
| ||
| 3D Sound works fine but its just software panning - something a little more advanced would be nice. Think I'll end up looking at fastext as I need refraction/ripple effects. Making quite heavy use of physics too but both tokamak and ageia wrappers cause random crashes when making anything other than light/medium use. |
| ||
| Sometimes these apparent 'bugs' are just someone who did something wrong and thought it was blitz's fault. I mean, good fact, where is the proof? There is the alpha-sorting bug. Put several alphaed textures/entities one behind another, move the camera around it and it will be rendered sometimes in the wrong order. The only solution would be to sort all entities according to their distance to the camera, and apparently (I just remember reading about this on a thread) this was fixed on B3D SDK, but not on B3D itself. Even if a new engine is made on DX10, and if it doesn't sort entities, this error will appear... |
| ||
| There is the alpha-sorting bug. Put several alphaed textures/entities one behind another, move the camera around it and it will be rendered sometimes in the wrong order. Ah, I've seen people complain about this before. I myself have already faced one: it seems that z-order is totally screwed up when you have two planes with alpha overlapping eachother and one of them is set to "Disable BackFace Culling". The backface stays on top. |
| ||
| There are already libraries available for at least one, probably more, such audio solution. Unfortunately, due to superstition or something else which is beyond my comprehension, they're used by very few people. Speaking of which.. Most of them tho have hideously high prices for commercial useage and features go far beyond the needs for hardware accelerated multi channel audio. I may end up having to create a DLL for this which would take considerable time away from my main project. Given that the entire Blitz3D function set is found in a DLL - albeit that it's eventually statically linked - I think you can safely assume that there are no issues with extensively calling a DLL. Anything which MAV's with extensive use is either a bug in your code or a bug in theirs. The MAV originates in the wrapper API calls themselves, but doing exactly the same thing in C++ works fine - I don't have the time to create my entire project in C however. It could be the way the wrappers do stuff with banks, etc. I dunno but its definatly not an error originating within my own code. |
| ||
| There is the alpha-sorting bug. Put several alphaed textures/entities one behind another, move the camera around it and it will be rendered sometimes in the wrong order. Note this isn't a bug with blitz. It's just the way dx 7 renders it. Alpha pixels don't have any position in the z-buffer, so are rendered in order of creation. You would need to add something to manually sort this. So it's not technically a bug with blitz, rather it's the way it is designed in dx i believe. |
| ||
| Most of them tho have hideously high prices for commercial useage and features go far beyond the needs for hardware accelerated multi channel audio. Well they won't magically get any cheaper just because BRL wrap them for you. Bass is $100. Presumably when you said you'd be prepared to pay for BRL to do this stuff you meant, massively less than $100. SFML ( Simple and Fast Multimedia Library ) is free and could be interfaced with B3D very easily, and I'm sure there's an OpenAL lib around here somewhere. I don't think it was complete, but probably enough given that most features go far beyond your needs anyway. But I get the feeling you're going to put up barriers to anything other than BRL doing it for you in any case. The MAV originates in the wrapper API calls themselves, but doing exactly the same thing in C++ works fine Again, you're trying to generalize from what is clearly a specific library, and you're going to great lengths to avoid naming that library, presumably to avoid anyone pointing out the problem and solving it. There are no problems with banks or anything else. If calling a function from Blitz3D doesn't work but does when you call it from C then either the person who wrote the DECLS wrote it wrong, or if you did it yourself, you wrote it wrong. So it's not technically a bug with blitz, rather it's the way it is designed in dx i believe. Pretty much. You can use a $100 3D engine, a free one or a $10,000 engine and this stuff isn't easy. People complain about this stuff but they don't always think it through. When you have complex alpha objects like trees, the faces can overlap. It doesn't matter what order you draw it in, it's never going to be perfect if it overlaps. This is why even AAA games resort to cheap tricks like limiting viewing angles to ensure glitches don't show, additive blending to ensure that order of drawing doesn't matter and alpha clipping/masking to avoid intermediate blending altogether. It's easy to say it's a bug, go fix it, and I don't blame anyone for having that attitude, but it really is very hard to do it, and it really will affect the speed dramatically without giving perfect results even if you had it. |
| ||
| I'm not sure why you feel the need to be hostile towards me all of a sudden... neither do I see a need to justify anything to you suffice to say its not me being cheap. I was quite clear earlier about what libraries I was having issues with and I can say quite definatly that not only do they work fine from C++ and other languages with the same input the problem does almost definatly not lie within my code. While I can't pinpoint the exact cause of the problem it does appear to be related to high frequency use of the API via decls possibly due to some problem with banks as it seems to get into a state where the information it needs to process isn't available to the dll thread in time to process it. |
| ||
| Note this isn't a bug with blitz. It's just the way dx 7 renders it. Alpha pixels don't have any position in the z-buffer, so are rendered in order of creation. You would need to add something to manually sort this. So it's not technically a bug with blitz, rather it's the way it is designed in dx i believe. Actually it is a B3D bug. Both DX and OpenGL (no matter what version) do not sort the polygons itself (and it shouldn't, since the engine you use that creates and control the camera!) Even on DX8 SDK, there is a sample showing how to sort a bunch of trees according to camera to avoid the alpha problem. When I tried making a DX9 C++ engine (stopped due to lack of time) - I had to program this myself, otherwise my particle emitters would render completly wrong. And as I said, this seems to be fixed on B3D SDK... but not on B3D itself :( |
| ||
| Well, nothing stops a 2.00 version having that problem solved. |
   |