BB3D 2.0 - how it should look like
Blitz3D Forums/Blitz3D Programming/BB3D 2.0 - how it should look like
| ||
| Hi all, I thought about to split the discussion from the Windows 7 thread to collect ideas how BB3D 2.0 should look like. Please feel free to add anything here, just see it at some kind of brainstorming so crazy ideas are welcome as well. I think I'm able to create such a beast of language. So what should it have? Some points from my side: double precision: Well yes, I missed that really in BB3D, floating point precision enough in most cases but there are cases where you need that extra precision. Question here is, how is the double type look like? Float: variable# Double: ??? DX9+/OpenGL: Clearly this is the main reason to create something new. BB3D is great, no question. I would even use it for new projects, BUT DX7 is the problem here as it's emulated on modern Windows versions. So it's not the question that BB3D would be enough for a hobbiest but that I don't start something that won't run on Windows 8 anymore. Personally I prefer OpenGL as it gives the possibility to do something cross platform later. Cross Platform: Would be nice to have, no question! Strict: I really missed that! Hours of debugging just to see a typo in a variable name where the compiler just created a new variable on the fly. Uh dear! Strict is a MUST, but should be optional. Types: Actually I never like the way types where done in BB3D that much. Something like typeA\field is a bit hard to read, I prefer the C style typeA.field but that might be a matter of preferences. I just would include both possibilities with a switch in the settings to let you work with both. ... more to come. Will edit more into this first posting! |
| ||
| why dont you write a 3d engine for Blitzmax Instead? |
| ||
| Because that already exist. Look at Xors3d. |
| ||
| Another option would be helping to develop miniB3D even further ;) It is OpenGL (would get even better if it got a "driver" for DX9), it is cross platform, superstrict (if you want) and bmax uses typeA.field as you want! |
| ||
| minib3d is great, no doubts. The thing is, I think a lot of guys want to have something that works out of the box, without the need to install mods, looking which one is the right one, download some more patches to make it work and so on. ;) Actually I already have a render engine which can handle everything BB3D can do, using DX9 and OpenGL. I just have to adapt it a bit (it has shadows as well). Of course I would have to expand the command set of BB3D to allow shader stuff but you don't have to use it if you don't like. Anyway, a lot of words, will do something to make it happen (which will take some time). Last edited 2011 |
| ||
| Hmmm, ideas: - Just use a new sigil for Double (e.g. !) - Allow names as well as sigils for primitives? - Have a way to get function pointers - If you keep B3D's dual-namespace for variables and functions, you'll need something like &FunctionName to show when you want it as a value - Please, please have Strict mode tell users off for writing code like: Local f#, a# f# = f# + a# ... type tags should be for declarations only. Anywhere else is not cool. Not cool. - If you use object.member instead of object\member, note that you'll have to change the type declarations. - Be careful that your changes don't just turn it into BlitzMax, but reflect something new and interesting. - Extending that point - language extensions are obviously cool, but if you extend it too far away from B3D, it won't be B3D 2.0. |
| ||
| Strict would be nice, double support wouldn't go amiss either, declared with double and/or using a new sigil as mentioned above. I'm not bothered too much about cross platform support myself - unfortunatly Open GL is falling by the wayside and adopting DX9 or newer limits cross platform capabilities. Two areas I'd like to see improvements in would be porting sound to Open AL with atleast some basic 3D sound options and some kind of shadowing system. Not too bothered with updating the language to support objects, etc. more extensively - I kinda like how types work now tho function pointers wouldn't go amiss and neither would basic threading support. Shader support I'm sort of on the fence with, having extendable access to it would be nice but I've never really needed it with anything I've been doing - fastext gives me the ability to do the effects I've really felt lacking (proper refraction/distortion). As always I'd be quite happy to buy the product all over again for these features - but for me moving over to something like blitzmax doesn't really work. |
| ||
| //My two cents *Make it as close to B3D as possible in terms of command list and thier uses! :) *Should execute its code at least as quickly as B3D. *All file operations (loadmesh, loadsound ect) should work on both normal file streams , and banks so that we can load from memory *All available blend modes should be accessible out of the box without external hacks to get to them *shader support optional, I think xors3d did this part wrong, some features require you to use shaders yourself.. if a shader is required for a feature it should be integrated transparently so the end user doesn't have to mess with it (imo) *support .b3d static and animated *gpu hardware animation would be nice more stuff later if anything comes to mind Oh yes, if you pull it off I would buy this product too |
| ||
| You can't have blitz3d version 2 and change the language feature :) Your best off using blitzmax and minib3d. If Blitz3d version 2 was too come out, an updated renderer (hardware animation etc) and the addition of double precision would be nice. Leave all the commands for accessing types the way they are, and declaring variables. Surely the idea is to be able to copy your blitz3d code straight in and it works. Oh, btw, does anyone know if minib3d supports animated meshes as quickly as blitz3d? I've heard of issues with that. |
| ||
| Ross C, Ive heard its slower, but not tested. MiniB3D confuses me in terms of setup.. i'm not even sure what version I should be using or how to make it all work in blitzmax. Do you need extra modules for 3D sound ? ect.. Last edited 2011 |
| ||
| One of the things that attracted me to B3D was the fact that it could do 2D as well as 3D. This is something pretty much essential. If we could have Blitzmax style 2D support it would be great. Also, the ability to import models from a variety of free modelling programs would be a huge plus, Blender 3D in particular. GLBasic supports the latest Blender so it must be possible to get something up and running for Blitz too. Not many people can afford to keep buying extra software most want an all in one solution. Support for free tools can only help. Blitz 3D style documentation would be nice too. Jason. Last edited 2011 |
| ||
| Thanks for the feedback guys, much appreciated! In a first step I'll just do a plain 1:1 conversion of the complete command set. After that I'll expand it but let's concentrate on step one first. It will definitely support DX9 and OpenGL from the beginning so it is up to the user. I will give a default parameter to the Graphics3d command. |
| ||
| I find it a little disappointing that he is receiving comments like "Your best off using blitzmax and minib3d" He's obviously a long way down his development road already, and I for one would be really interested in the result. |
| ||
| I'm not telling him to just use blitzmax :) I think if your going to modify the language, it takes it away from blitz3d. |
| ||
| I find it a little disappointing that he is receiving comments like "Your best off using blitzmax and minib3d" He's obviously a long way down his development road already, and I for one would be really interested in the result. I was thinking that myself. I'll be honest, I groaned out loud when I saw the topic title, but by the time I'd read Xaron's post, I had been turned to intrigue. First thing I'd have to say - and this is funny coming from me, since I've never used it yet, but I know it's where I'll end up - is that the dreaded OOP syntax really should be added. Whether everyone wants to use it or not shouldn't matter, it should still be a viable option. Look at it this way: you can theoretically still do "old-style" procedural programming (like B3D) in an OOP language. You CANNOT perform OOP in a procedural language (again, like B3D). Next up is an odd question, because I don't know enough about the low-level specifics of renderers nor the state of the industry behind the scenes. Since DirectX7 has already fallen by the wayside into emulation, and is no longer a particularly viable industry option, how much life does even DirectX9 have in it before it suffers a similar fate? I ask this mainly because 9 is what, six years old now? Seven? And since it's already two versions behind the cutting edge, I'm just questioning how much breath is left in the ol' horse. This is not me dooming something before it's even started, I just want to know what's what. Strict is definitely a must, even if it can be enabled/disabled. I haven't disabled strict in IDEal since the day I turned it on about three years ago; it's a life saver. The degree of strictness is rather subjective, though; I like strict right up to the point of case sensitivity, and then it loses my support entirely. I like my functions, variables and so forth to have capital letters in them; it makes them easier to read. ThisIsAnUnnaturallyLongVariableNameToDemonstrateMyPointis much simpler at-a-glance than thisisanunnaturallylongvariablenametodemonstratemypointNevertheless, I don't want to have to keep fiddling with the Shift key every time I use that variable afterwards; this is where lack of case sensitivity is a boon to me. IDEal just slaps in the capitalization that I used for the declaration, every time the variable or whatever is called. Double precision would indeed be sweet. Here's another thought, and I have no idea how useful or not it would be, nor difficult to implement, but: what are the chances of having 64-bit integers instead of the old 32-bit limit? There are times when I play around with various file manipulation ideas, and I'm never crazy about being limited to a 4GB filesize. There are also times when I want to perform large-scale calculations purely to get the results quicker than using a calculator (or even to get more digits) and although I worked out ways to perform math "the manual way" using strings instead of integers, it'd still be nice to have that extra breathing room. As far as what symbol to use for the double-precision floats, might I suggest either the "@" symbol or the "&" ampersand? Multi-threading is becoming ever more useful in this day and age, so some decent threading support would be preferred, if not required. This does of course open a whole can of worms regarding how far you go to idiot-proof the system; personally, I say just make sure it's bug-free, and if people don't use it properly then it's their own fault. Look at WritePixelFast() and ReadPixelFast(); they can cause all sorts of oddities if used incorrectly. There have also been at least a half-dozen occasions where I've crashed the blitzcc.exe environment itself because of a gaffe in my coding; I'd never blame Mark Sibly for not forseeing my error, though. Some people will whine about it, but the ones worth catering to won't. ;D DirectX vs OpenGL. Is there any reason that both couldn't be implemented? I know that BMax has the option to use one or the other at graphics initialization. Speaking of DirectX... ... Memory leaks. We all know that resetting the graphics mode with Graphics in Blitz (at least 2D and 3D, not sure about Max or Plus) causes a complete loss of textures and images, due to a DirectX memory issue. They basically just get "flushed." Also, in some circumstances (i.e. my computer) the entire 3D world gets emptied, all entities disappearing, even PIVOTS for crying out loud. I can understand that this is potentially a DX problem, and therefore can't be "fixed" as such. Here's a thought though: perhaps all the data loaded by the program (which, because of the use of handles instead of pointers, the environment would always have track of, yes?) could be "dumped" as binary into a RAM bank, then loaded back into its correct memory allocation after the graphics mode changes? Not sure of the viability, much less the speed, but it's something to consider. Oh, and of course, 3D acceleration for 2D imagery. I understand that this is native in everything DX8 and beyond, but I'm just putting it out there. |
| ||
| Is there a need for this? Actually I already have (created) a render engine which can handle everything BB3D can do, using DX9 and OpenGL. It is one thing to make an engine that can render things and a 'good' engine that can render things - I can't comment on it since I haven't seen it of course, but your statement is not enough to prove that this product would be capable of being used at a production level. We don't know your experience with 3D engines and programming. You'll have the hard task of reaching the feature set of engines that are out there for a longer time and have a dedicated team with the sole purpose of developing them (and not developing a side-language as well). I agree with AnniXa and SLotman in the sense that you should focus on working above the best engine you can find, 'adding' value to it instead of making new value from scratch (which is always harder). I think your enthusiasm is much better spent giving something from the "Blitz3D world" to the "real world", like someone at General Discussion did: opened a thread presenting work regarding a Blitz3D framework for Unity3D, and that was great. I think this is the way to go - the Blitz3D command-set is an abstraction, and that abstraction can be applied to several engines which may have "inferior" ones (to our eyes). But you have my support for whichever direction you wish to go! :) |
| ||
| Thanks again, very nice discussion! 64 bit compiles wouldn't be such a big problem, I'll add another compile option. I want to keep it simple so I won't create a direct machine code output due to the fact that gcc does this job much better than I do. So I'd translate everything to C and call gcc then but this shouldn't bother anyone as this is more a hidden step. Speed wise it will be as fast as BB3D or better. Regarding DX9: Yes it is quite old already but it is supported together with Windows XP so I think it has some more years to go. OpenGL will work out of the box as well and you don't have to have any knowledge about shaders if you don't want to use them. I want to make it as easy as BB3D now. |
| ||
| I don't know if it's possible, but it would be wonderful if gamers could switch between computer monitors if more than one is plugged in. Something like GetMonitor() returns the current monitor the game is set to, CountMonitors() returns number of monitors detected, and SetMonitor() changes the active monitor. When I'm debugging, I like to keep the code in my main monitor and run my game on my second monitor. Whenever I quit and start the game again, though, it always starts in the same monitor as wherever Blitz is running. I bet there's a lot of gamers who would like to have this option for a final version of a full screen game. Also, and this might be a long shot, but it would be awesome to be able to split the game between the monitors. I'm not sure if it's possible, in terms of rendering time and whatnot, but a fun idea to think about. Other than that, I don't have any suggestions. |
| ||
| I second MAx-ish 2d. Adam, you stole my ampersand! Please keep the symbols. What if the 64-bit ints were another data type with a different symbol? Built-in RTL memory dumps? And as a query: would you build a false "sprite" system or do we make our own? What of Poly-Poly collisions? Last edited 2011 |
| ||
| Yea, if its collision system could handle moving objects (ie, platforms vs moving players ) without a hacky dual updatworld() that would be nice. |
| ||
| One thing I thought maybe would make code nice to read is if "?" could fill in for if, ie. ?Var=1 and Keyhit(57) Then Dostuff() Maybe that's too far out there. We really can't be too demanding given that we're not working on it. Last edited 2011 |
| ||
| I don't think that's TOO far out there, but personally I'd find it far more expedient just have my fingers spider over the I and F keys in quick succession rather than jam down the carpal-inducing Shift key and find the question mark. I guess what I'm really saying is that it could work, but I myself would probably never want to use it (plus it looks weird to me in place of If). |
| ||
| Blitz3D with a better renderer and the future possibility of cross-platform compilation will do just fine. It's a great idea. Oh, and getting rid of the '\', for '.', god yes! Nothing more needs to be added at this stage. |
| ||
| Oh, and getting rid of the '\', for '.', god yes! i'm rather used to the Blitz3d way of this, I prefer the original idea of having it optional in the IDE or something like that. |
| ||
| I agree that Blitz3D is great as is, just needs to keep up with Windows/DX etc to remain the best language out there! I haven't downloaded any updates for a while but... a couple of simple suggestions.. More than 1 UNDO would be handy? Ability to alter color of text/background while editing (sounds superficial I know- but oddly, it can really helps mental focus) And as I was asking in another post- the ability to save/reload the entire chunk of memory containing all entity info- for changing graphic modes or save/load game function. (if not already possible?) Above all- I like my Blitz like my women, fast and easy! |
| ||
| @Slomas, maybe so too but also look at cfg\Blitz.prefs All hex values you can change as you will. @Adam, yeah I guess so.What I wa thinking works with if too: ? _This ? __This ? ___This or If _This If __This If ___This Last edited 2011 |
| ||
| If you're going to change If, why not make it a true ternary operator like it is in FP languages? e.g. Local a = If exp Then b Else c ; Instead of Local a If exp Then a = b Else a = c A tiny change that doesn't break existing code (because it wasn't there before), yet makes the program massively more readable. As above, I'd still counsel that you not change anything already in the language (unless you go with your idea of having a classic/new mode switch for things like . vs \), just add features. New features can't hurt old code, but of people can't copy and paste B3D into B3D 2 and have it Just Work (tm), then it's just a BASIC with a 3D engine, rather than a true B3D 2. Last edited 2011 |
| ||
| I think humbly, that should not be called Blitz3D 2.0, if you have no other name, since it is not part of the first version. The name should be something flashy that represents the new features in relation to Blitz3D. If necessary I could work with a manual in Spanish ... to terms that I have struggled with Blitz3D, the problem that the language domain: S. Greetings from the ass of the world. |
| ||
| More than 1 UNDO would be handy? Ability to alter color of text/background while editing (sounds superficial I know- but oddly, it can really helps mental focus) Those are actually issues with the way the IDE displays the code, not the language itself; download IDEal to solve both of those issues for yourself right now. http://www.fungamesfactory.com/ |
| ||
| Local a = If exp Then b Else c ; Instead of Local a If exp Then a = b Else a = c As a slight side issue - how does that make the code more readable? The second expression makes more sense to me...maybe just the way I think...it's at least written in the way I'd express it if I were to write/speak it in English. |
| ||
| Yeah the second one is more logical to me. local a if a=100 then do random stuff end if how can a=random stuff? seems like a very situational statement to me. |
| ||
| Thanks guys! :) As above, I'd still counsel that you not change anything already in the language (unless you go with your idea of having a classic/new mode switch for things like . vs \), just add features. New features can't hurt old code, but of people can't copy and paste B3D into B3D 2 and have it Just Work (tm), then it's just a BASIC with a 3D engine, rather than a true B3D 2. Yasha I agree. So it will be 100% compatible. Regarding the name, I though about something easy to remember, like: DoomBasic HawkBasic LionBasic or something similar. I know the name is yet the less important thing but I like to have a name as well. Suggestions are very appreciated! :) Last edited 2011 |
| ||
| seems like a very situational statement to me Actually you're probably right about that. (Reasoning behind my original statement: in FP languages such as Lisp/Haskell/ML, which I usually work with and thus affect my own definitions of what seems logical, everything is an evaluable expression with a returned value, even if it "does" something along the way; so "if" is just a choice operator rather than a branch jump.) In C, and its derived languages, there's actually a third way: "if" still works as in BASIC, but there's also the ternary choice operator "?:", which looks like this: int a = exp ? b : c; It's an expression, not a block statement, so this one can't "do" things any more than + or - can, unless one of the component expressions being evaluated calls a function and that function does something offscreen before returning. Unlike say making a custom QuickIf() function, however, this operator is still "lazy" - like regular If, only the branch that's relevant gets evaluated, and the other never happened. Anyway, since we have two kinds of "If" in Blitz3D - line If and block If, where a line If swallows all statements on the same line and ends with the line terminator - I thought it might make sense to allow the line If form to function as a ternary operator, as long as the compiler detects no imperative command statements in its branches. (Having block statements return values is not illogical in its own right - check the Ravioli link for an exploration of that - but certainly not BASIC-ish at all, so I would only suggest it for the line If form.) Sorry this seems to have turned into a derail, but perhaps that explains some of the logic behind the suggestion. --- EDIT: Ooo, I thought of a couple more things: - Don't forget the stepping debugger! I would argue that B3D's single greatest feature was that it introduced n00b programmers to "proper" debugging tools. This is also probably harder to write than the actual compiler... but I think it's where a lot of the value lies. (The simplest method I can think of is to keep the original source loaded in memory and attach text marker tags to the debug build of the application to tell the debug window where to highlight text.) - Since you seem to be settled on compiling via C, would it be possible to make use of C's "static" keyword? For the non-C-programmers, "static" in the declaration means a name is not exported from the current module, so it would let you have "private" helper functions, and global variables, and such, inside library Includes, without worrying about name collisions. (Note that B3D Includes are more like modules than C-style #includes anyway, as each file only gets Included once per application - so it would be easy to represent libraries as separate .o files.) You could have it like BlitzMax: "Private", and everything below that line is invisible outside the file. Or similar. Last edited 2011 |
| ||
| You could keep a similar sounding name and call it BitsBasic since it will take inspirational bits from here and there. It could also stand for Blitz Inspired & Themed Syntax :) Oh and, please start a work log on this thing so we can follow the development ! Last edited 2011 |
| ||
| You mean 3D BitBasic or 3D BBasic :) |
| ||
| BitBasic3D =). |
| ||
| Since this is the second part of Blitz, you could always name it KriegBasic...Or maybe LightningBasic... |
| ||
| LightningBasic wouldn't really work, since "Blitzen" is what means "Lightning." Not really sure what "Krieg" is. I whole-heartedly approve of (and applaud) KriegBasic, though. :D |
| ||
| Krieg = "war". Blitzkrieg is the doctrine of high-mobility, high-speed warfare where armour and air support work closely with ground forces to smash through enemy lines of defence that was introduced by the Wehrmacht during WW2. Personally I would have reservations about that particular pun. |
| ||
| Haha funny idea. I think you guys think in terms of Blitzkrieg, we Krauts have another association. A Blitz is followed by the Donner (thunder) so DonnerBasic might be the correct derivation. But actually I don't want to make Mark angry! Last edited 2011 |
| ||
| No, I was being a smart a** about that. Like Yasha says, it's probably not appropriate to name a game engine after such a dark time in history. |
| ||
| A step by step debugger is indeed a very good idea even though it is not at the top on my todo list at the moment. I think I call that baby LionBasic for the time being... Lions are powerful and lazy, that fits I guess. :D |
| ||
| I kinda liked bit basic....but whatever your project. Anyway Double precision would be awesome! as for a symbol, how about '&'? or is that already used for something that I somehow missed? |
| ||
| Ok, lets call it BitsBasic. :) Hope Mark isn't angry about that name. Well ok at the moment probably not as long as there isn't something to show... |
| ||
| I think the only thing mark might not like is if you try and sell it, trading off of his work for what is essentially an update to one of his products, but if this is a community version and free for current blitz 3D owners then I don't think mark will have any problems at all. |
| ||
| Yavin, I disagree with this, after all Xors3D did the same thing and they still post here freely.. If Mark was deeply offended i think that the Xors3D team wouldn't have Blitz Accounts to post about Xors3D on these Boards. I could be wrong , but that's my opinion anyway. There's no reason to give hard work away for free , especially something everyone has been asking for for a very long time. Last edited 2011 |
| ||
| Of course the obvious thing would really just be to get in touch with Mark and ASK HIM about how you could go about this... ;D |
| ||
| Someone should shed some light on this subject for me. I vaguely know what a Double is, but by adding this, what functionality will that give Blitz? (That's a legit question, not a rhetorical one. The way it was written kind of brings out that tone). |
| ||
| Double = "double-precision floating point", as opposed to "single-precision floating point" which is what is usually understood if people say "float" without qualification. What that means is that the var is literally twice the size, taking up eight bytes rather than four, so it has a much (much) larger range (ridiculous number of digits), and more importantly, 53-bits of precision, which is enough to mean that every 32-bit integer can be accurately represented as a double-float (you may have noticed that single-floats have very poor accuracy). On modern CPUs math operations on doubles are also faster than on singles (although still not as fast as ints). So the extra functionality is: - bigger range of numbers can be handled on the CPU - better accuracy of numbers can be handled on the CPU (I say "on the CPU" because of course you can always roll your own arithmetic operators on strings or banks and get infinite-precision bignums, but those are really slow, and best left for extremely important things like financial calculations that absolutely cannot tolerate any rounding errors). |
| ||
| You are right guys, I've just sent a mail to Mark to ask him... |
| ||
| I dont know what Xors3D is gona take a look. |
| ||
| Xors3d is a game engine similar to BB3D. The main difference is that you still need a programming language to use it. |
| ||
| Xors3d is pretty cool, the only thing preventing me from using it was the way rigged models worked. there were some tricks i could pull off in b3d that was not able to emulate in xors3d. Outside of that if your not looking to make a character customization that requires parts that use more than one bone to attach then go for it. |
| ||
| I should be working right now, but I had to submit the following thought before I forgot: One thing to really give thought to is how to handle extensions, plugins, etc. Should Nu3D ( yeah I'm calling it that, deal with it :p )have .DLL userlib support? That's been an absolute boon to me of late, I don't think B3D would be half as useful without that feature. What about modules? I understand they're basically the key principle of BMax, but would they perhaps be useful (or even possible) in Nu3D? What about other options, since I'm sure there are a lot more possibilities than I can think of? Making the code "universally" extensible is a key factor, as far as I'm concerned; I'd hate it to be overlooked. |
| ||
| I agree DLL support is essential , im not sure about going down the road of making it more like BMAX than BB3D.. just my two cents. |
| ||
| Ok Mark answered he is fine with that. :) Regarding DLLs that should be in I agree. I'm on vacation at the moment but will start soon with working on it and some kind of a worklog probably together with a small website and forum to collect additional feedback and ideas. Thanks so far for your participation and great feedback! Last edited 2011 |
| ||
| Should Nu3D ( yeah I'm calling it that, deal with it :p )have .DLL userlib support? ...why wouldn't it? DLL support is literally trivial to add to a compiler. The real question is why it took a few versions to get into Blitz3D, and why the eventual method used (.decls) is so difficult to use. (EDIT: I forgot, there's also been CallDLL in the library from the start, but that's even stranger...) Xaron said he was compiling it with GCC, which means it should be possible for a project to be broken up into separate object files... but you'd need to introduce some kind of implicit project system then, as opposed to literally just throwing one file at a compiler and getting an executable back. Shielding the inexperienced user from complicated build processes like C's (i.e. having to think about compiler and linker separately and building individual modules) is a great advantage of the original setup. Last edited 2011 |
| ||
| Since a new Blitz3D out, I decided to learn c + +. and the foundations that I got blitz, are highly prized. |
| ||
| Shielding the inexperienced user from complicated build processes like C's (i.e. having to think about compiler and linker separately and building individual modules) is a great advantage of the original setup. This. Even compiling things for C++ in um... Bloodshed Dev C++, I think... Was a bit daunting to me. The classic Blitz click-and-go functionality is something that has always been of greatest joy to me. :D |
| ||
| mmmmmmmmmmmmmmmm, Dev C++ + SDK DirextX9c |
| ||
| That's not only fun Yue, you'll see. ;) |
| ||
| I think it could use a Visual Studio style IDE to better organize the code. And to compile code for Xbox360 or PS3 would be good! Last edited 2011 |
| ||
| Any IDE with the clean, simplistic, flexible functionality of IDEal would be fine with me. But I wouldn't worry about it too much; I give it six months TOPS after you make Nu3D before someone makes an IDE for it anyway. |
| ||
| What does Nu3d mean for you? ;) |
| ||
| Well, I was thinking "Nu" as just a "new" way of spelling "new." I dunno. It's easy to spell/type/say, but I'll admit it looks odd. I just like oddness. XD |
| ||
| LOL, ok. I might start a poll about a good name to keep you guys in stress! |
| ||
| I've created a small page where I will start to post my worklogs and other stuff. I'd like to collect any crazy ideas as well. I know, another forum, another website, it doesn't matter if you create an account there or not (sure it would be nice to have some discussion over there)... Anyway, long text, here comes the link: http://www.bitsbasic.com I know the layout/design is rather simple and standard at the moment, hope you don't mind. ;) A big THANKS to RifRaf regarding the name. lol Last edited 2011 |
| ||
| Site is now in my favorites list, and I signed up. Thanks |
| ||
| Bit Basic? Good Name :) I will sign up ;) |
| ||
| I'll sign up purely because this thread is proving quite popular, and I can see it getting a bit out of hand, organization wise, for these forums. So I'll post there from now on so this board can stay on topic. XD |
| ||
| Thanks guys, that's a real motivation factor! :) Just a small shot about what already works. I know, I know, not THAT spectacular but I'm happy with it. :) Sample code: Graphics3D( 640, 400 ) cam = CreateCamera() cube = CreateCube() PositionEntity( cube, 0, 0, 5 ) RotateEntity( cube, 30, 30, 30 ) Repeat UpdateWorld() RenderWorld() Flip() Forever Result in BB3D:  Result in BitsBasic:  Renderer is OpenGL here. You might notice the difference in camera angle but this isn't a biggy. Last edited 2011 |
| ||
| no plans for DX 9 or 10 rendering ? |
| ||
| DX9 will be in. DX10 doesn't make sense IMO, maybe DX11. But for the start DX9 + OpenGL. |
| ||
| Nice milestone man. Keep up the good work. I dare say collisions will be the hardest part of this? |
| ||
| Thanks Ross! :) Collisions are not that hard, I have more headaches with all the animation commands and all these FX commands. There might be differences as things have changed a lot in the last years. There are even commands which doesn't make sense at all anymore like WBuffer |
| ||
| Personally, I'd be absolutely ASTONISHED if you made Bits ( guess I was defeated, oh well XD ) so syntactically similar that you could just copy-paste a B3D program into it and it'd work. Hell, even this starting milestone is damn impressive as far as I'm concerned. And by all means, get rid of WBuffer(). W Buffers were never implemented anyway. XD |
| ||
| Yeah. Don't think i've ever used WBuffer. If i want more rendering accuracy, I just do multiple renders, only show entities in range of the camera. Works perfect. Forgot about animation! Will you be supporting the .b3d file format? Just heard alot of people having trouble getting that to work properly. Cobra3D had problems, and as far as I'm aware, Minib3d has some issues too. I mean, I'd like to see it, but meh :) Last edited 2011 |
| ||
| Ha, this is pretty sweet! Someone else said this above, and I can't find it at the moment, but I would totally pay for the new engine, even if I didn't have to. |
| ||
| b3d format will be full supported including animations (actually it already IS supported as it's already there). I will create some demos (of the compiler) but at the moment it's still way too early. You're right with WBuffer. BitsBasic will support Antialiasing anyway so maybe I can just use WBuffer as a dummy command which simply does nothing. :D What's still on my todo list is a physics integration (probably Bullet) as well but this comes after all other stuff is done. Personally, I'd be absolutely ASTONISHED if you made Bits ( guess I was defeated, oh well XD ) so syntactically similar that you could just copy-paste a B3D program into it and it'd work That's the plan! Last edited 2011 |
| ||
| BitsBasic will support Antialiasing anyway Alright... If we're discussing this anyway, I for one would like to see full control of 0-8xMSAA, along with bi/trilinear/2-16x Anisotropic. Oh, and some triple buffering wouldn't go amiss either, though I dunno how much of a pain that would be to implement. ;D Also, if we're going DX9 here, are we looking at some hopefully easy shaaaaaaaader support? :3 |
| ||
| Shader support will be in, yes. Obviously with additional commands which don't break with the old code. |
| ||
| What do you think Comments will be like? ";" <-- Standard? ";;" <-- Maybe a double version for multi line? ;; This is the first line... And another... And another... ;; And the last. |
| ||
| DX10-DX11 Shaders Real time shadows Build level function Make A.I function who cares. Only ppl who are to lazy to code it there self. |
| ||
| I might add // for single line comments and /* */ for multi line comments as well like in C/C++. ; will be in as well. |
| ||
| Hi Xaron, this is looking very promising, keep up the good work. My main question would be - will I be able to just load my Blitz3D project into your engine and it would work straight away? That would be simply fantastic, if existing Blitz3D programs worked with no major modification needed. If you manage that, then I'd certainly purchase your new system. My SRX game uses the Blitz Tokamak lib as a core element, so I'd be very interested to know whether that would still work. I also use FastExt, FastText and FastImage, but any of those I can remove and work around so they're not critical to the game working, however Tokamak would be critical. |
| ||
| Thanks! :) All Fastlibs won't work of course. But yes I plan to make it 100% downward compatible. Userlibs will come in later when the core is finished. |
| ||
| Personally, I feel that if this works out as intended, I'll probably purchase it even if I have to learn something entirely new. XD Anything that is has a high performance:simplicity ratio and uses "current" generation rendering is fine by me. Now can we PLEASE just all take this discussion to the Bits forum? Not that I mind the thread, but seriously, Bits has its own forum now. I wouldn't come here to discuss it any more than I would C++ or Java ( assuming I even knew more than five commands in either language ;D ) |
| ||
| I'm not really interested in joining *another* forum. So, stop by now and again and let us know what happening! :) |
| ||
| No need to join another forum. Of course I will read and post here as well and keep you up to date - at least as long as Mark allows it. ;) |
| ||
| Well... Bleh alright, fair enough, and it's not as though I'm an admin or anything. I would suggest this thread be continued in General Discussion though, perhaps? I dunno. XD |
| ||
| Hi, :) Concerning the shadows, i think it would be interesting to have is 2 kinds of shadows : ->Shadows precalculated at runtime for furnitures and static objects. ->Shadows calculated each frame for characters and moving objects. When i compare the performance of the shadows in unity3d and in the swift shadow system i guess shadows with meshes are easier to calculate and render than shadows with textures ? It would be usefull to have the ability to change the color of the shadow meshes. And also to be able to show/hide the shadow meshes depending on the zone where the player is. Concerning the collisions, i think it would be usefull to keep the "groups" of Blitz3d. So that it is possible to test the collision between "PlayerCollider" and "NpcCollider" and also to test the collision between "PlayerCollider" and "LevelCollider". The less tests made the better ? |
| ||
| Related: Yay Milestones! Unrelated: Xaron, I'm not getting the confirmation email from the forum! |
| ||
| Ahh... the mail server again! Should work now (I mean your user account!) |
| ||
| all good now! |
| ||
 I can not wait for the birth of BitsBasic, though possibly never may have. Last edited 2011 |
| ||
| That possibility exists always. Don't expect any fast results within this year. There are still a lot of tasks to do! |
| ||
| My two cents. I don't know if B3D can already do this but I haven't come across it yet. I used to control things in the real world with my old commodore 64 like moving a telescope, setting off fireworks,BOOM, various other things using the user port. I think purebasic can control the individual outputs on the printer port and if B3D can't then I think that would be a handy addition. Well.....since the old printer port is pretty much obsolete thanks to USB, I guess my two cents isn't worth one cent. :) Last edited 2011 |
| ||
| Just want to let you know that I still work on this. Just doing boring compiler stuff, I'll keep you up to date! |
| ||
| Good to hear. Best of luck! |
| ||
| nice to know! @ando on XP based system you can handle the paralell port (i love it!) see: http://blitzbasic.com/Community/posts.php?topic=88573#1048973 |
| ||
| Hi all, I've been (and I am) a user and a fan of Blitz products since they appears, I'm a happy owner of Blitzbasic, Blitzmax and Monkey. Unfortunately and since they are not as adapted to the current techonology as it should be and due to the lack of updates (blitz3d mainly), I started to play around with other products and platforms. Not much time ago I discovered a language very similar to Blitz3D, actually it uses almost an identical command set (with a lot of more commands) and it offers from a user perspective, all that you always dreamed Blitz3d to have. It's name is NUCLEAR BASIC. Maybe you all know it, or most of you, I don't know, but it worth it to have a look because it's stunning!!! http://www.nuclearglory.com/products/nb/ best! Last edited 2012 |
| ||
| Blitz 3D - Excellent Blitz Max - Good but it could be better! Blitz Monkey - Good but it will get much better in next 3 years! Last edited 2012 |
| ||
| i liek milk |
| ||
| Looking forward to this very much. It feels like Christmas. |
| ||
| 104 posts in this thread needs a new thread opened to keep the thing clean and fast loading. |
| ||
| Glad to hear its still moving forward! |
| ||
| Xaron, Do you have permission from bb3d's orininal author to recreate the language? Think about a built in physics engine, That would also be worth looking into from my perspective. |
| ||
| Yes I have the permission from Mark to do it. :) Build in physics will come later. :) |
| ||
| Hey Xaron... I am so sorry! I clean forgot about offering to help with the compiler! It's probably too late to be of any use now, but if you're interested, I spent a few delightful hours (I like compilers) writing up a parser for B3D, which you can download here: http://dl.dropbox.com/u/46635275/BitsParser.rar Run it with "Bits Test0.bb > parsedoutput.txt" to get a pretty-printed AST. Source is included, but you'll need the Gambit-C compiler if you want to modify it. Note that it's only a parser (so it will accept semantically wrong programs), no type checking, linking, or C code generation, but those could be added fairly easily as they're really not that hard. The grammar it's based on is included in the archive. There are a lot of weird bits in B3D! (e.g. I never knew that inline-If forms could contain block statements, or that Object, Handle, Abs and Sgn were operators rather than functions, before going looking for edge cases!) The only form I know of which this doesn't support is the ability to leave off block closers when a scope completes, because 1) I couldn't work out the ridiculously complex rules for that, and 2) it's horrible and should be treated as an error in regular-B3D. (Of course it's probably full of bugs, but the test cases work correctly.) I know, too late. Ah well, it was fun to build. I guess if anyone else wanted one, there it is. |
| ||
| No no. Not too late! :) Thanks for that, will look into it! |
| ||
| The expectation;) overhears you thought about the price, just to whet your calcuclos and saving. Greetings. |
| ||
| I never knew that inline-If forms could contain block statements, or that Object, Handle, Abs and Sgn were operators rather than functions, before going looking for edge cases! Wait, Object is an operator? As in, x Object y, like And and Or? The mystery deepens; I never could figure out what the crap Object was for... |
| ||
| Object and Handle are secret, masonic commands. What Handle(instance.type) does is give you an integer that represents any type instance you pass to it. This integer value makes it easy to store a reference to an instance in variables, fields, arrays etc. such that they don't have to point to a single Type like they would usually do (well, they all still have to point to 'Integer', but then any Type instance can be converted to a value of this kind with the Handle When you want to retrieve the instance represented by this value, you use Object(value). If you try retrieve an Object() value to a container of a different Type than the instance it's returning, you'll get 'Null', so it's a way to check what kind of object that integer ID represents: trying to store under containers of several Types until you get something other than 'Null'. Reference 1 Reference 2 Last edited 2012 |
| ||
| OBJECT FTW! =D |
| ||
| I never could figure out what the crap Object was for... Object maps an integer to an instance of a user type. The instance in question must first have had an integer handle generated with Handle. This is mainly useful for two reasons: you can easily temporarily reference objects from banks, or you can pass objects of multiple types to the same function to get a simple form of polymorphism. Wait, Object is an operator? When I say it's an operator, I mean it's considered "special" syntax by the compiler rather than just another name that happens to map to a builtin function. It's a unary operator, like Not, Int, Str, First, Last, etc., so it only takes one following argument and returns its value to whatever is in front of it: Local obj.Foo = Object.Foo 42 ;Note that parentheses aren't required here - most people use them anyway obj = Last Foo ;Commonly seen without parentheses obj = Before Last Foo ;...etc. Local i% = Handle Object.Foo Handle Object.Foo Handle Object.Foo 42 ;Silly but technically valid There's nothing stopping you using parentheses, but because the compiler considers the meaning of these words "inherent" it can correctly decipher the expression anyway. It also means you can't define object or handle as variable or function names. I'm starting to have the sneaking suspicion that the original B3D was implemented without being properly formally-defined first, as working out the grammar backwards is ...hard. Also, the above silly examples highlights a bug with my parser. So... bugfix time. Last edited 2012 |
| ||
| How Bitbasic going on? |
| ||
| Hi. Forum seems offline: http://www.bitsbasic.com/site/ |
| ||
| It needs optional OOP. Why not just write an engine for max? I don't get it. You say it is because you do not want the whole mod thing for users to install, but just handle it in the installer scripting so the user does not need to (and just provide the mod for linux/osx users to install manually). (sorry if this has already been covered but i am not reading through 100+ posts that are almost a year old) Last edited 2012 |
| ||
| Why not just write an engine for max? Perhaps he doesnt want to limit his audience to Bmax users, I really hope he continues with it. Would be a shame if he's quit. I'm one of those who want a all in one bb3d v2.0 like engine. BB3D was such a success I think because of that all in one'ness :), even if the bb3d command set cannot be kept an all in one engine with modern abilities would appeal to me a great deal Last edited 2012 |
| ||
| If Xaron has to give up (by the sound of it he has more important things demanding his attention), I'll probably extend my stub-compiler into a full product (I was able to come up with what I thought were a decent selection of language extensions that would provide a "bridge" to more modern techniques, while still preserving 100% compatibility with BB itself). I can't be bothered to write a 3D engine, but it shouldn't be too hard to provide a wrapper around OGRE (or something) and ship them as a single unit. Wouldn't be as good or as fast as a dedicated engine, but would work as a stopgap and be moderately futureproofed. |
| ||
| Yasha, Don't wait, I for one would invest in multiple products if they are priced right..BitsBasic and others too. You are one of a handful of people here I believe could pull it off. YashaBasic? bring it on Last edited 2012 |
| ||
| Why not just write an engine for max? Because Leadwerks? |
| ||
| If a simple BB language was open sourced with good C support, then it would not be a big deal to add a 3D engine I think. |
| ||
| No no did not give up, just had a serious spam problem with the forum. ;) |
| ||
| Xaron, Is Bits anywhere near completion? |
| ||
| Not near completion, no. Will see what I can do to make it to a testable state. I'm currently on parental leave so a bit limited in my time unfortunately. That will become better in October again. :) But yes, I won't disregard this project. But I think I have to drop some of the original commands which simply don't make sense anymore. I even think I'll make it open source at some point but for that I need a stable code base otherwise it doesn't make much sense. Last edited 2012 |
| ||
| Xaron, That's great news.. I would love to help you test builds. |
| ||
| Because Leadwerks? Because leadwerks what? If you mean because there already is leadwerks, then that is like saying there is no point in writing a 3d engine for C++ because of ogre and irrlicht (and 1000 others). |
| ||
| You could try FreeBasic+OpenB3D. It already has most of the features Xaron described for an hypothetical BB3D 2.0: Double precision: in FreeBasic, it's available Multiplatform: FreeBasic works in Windows, Linux and DOS (there is an unofficial experimental version for mac); OpenB3D works in Windows and Linux. Strict: in FreeBasic is active by default. OpenGL: OpenB3D uses OpenGL, that works on almost every OS. No DX, sorry. Types: FreeBasic fully supports UDTs, and has some OOP features. Syntax is very close, so porting programs shouldn't be too hard. Plus, it's all free. |
| ||
| then that is like saying there is no point in writing a 3d engine for C++ because of ogre and irrlicht (and 1000 others) ... Well, at the risk of sounding petulant: your point would be... ? |
| ||
| I think his point was: "the more products around, the better for us consumers". |
| ||
| ... Well, at the risk of sounding petulant: your point would be... ? Haha good one :D(although my point was it is nice to have variety and a default but detachable gfx system) |
| ||
| i think a detachable gfx lib is nice, but I also think that there's a niche market for an all on one package, and it has far less competition than the plug and play gfx lirary market does. Other than Blitz3D I can't think of any worth using , a new all-in-one would would be a natural upgrade for almost everyone who wants that type of product. I have no research to back that claim, just my little opinion based on my observations over the years, and being one of "those guys" who want a product like that. |
| ||
| That kind of was my point. Max + max2d is a single package for the majority of users, which can be used out of the box with its own lib. However it is detachable meaning the best of both worlds. It is just a shame it only has max2d and no 3d. If it was sold with a 3d lib included then it would be a new b3d. The only difference between a language with a detachable and unnatachable engine is just one line of code: (an import or using statement). Everything else is the same as far as coding goes. Last edited 2012 |
| ||
| IMHO this was for people who did not want Max's syntax in B3D2. @Angros47: I created a header conversion for OpenB3D + GLBasic too, here... http://www.glbasic.com/forum/index.php?topic=6982.0 Its a very nice lib BTW. |
| ||
| Yeah, I remember it. Did you add also the last command (shader related)? |
| ||
| No because for GLBasic cross platform projects I needed GLES compatibility, which the later versions were increasingly incompatible with unfortunately. |
| ||
| That Blitz3D is a dead end was clear a long time ago! But well, you can keep on dreaming ;) There was something called 'Max3D' but it disappeared quickly. But for now I would never recommend to start with a language like Blitz3D Blitz3D was one of my first programming languages and it was hard to get away from it, but once you start coding in C# or C++, you'll see that it's much better. All these languages are strongly typed and also have doubles and whatever you need. The only thing missing is a built in 3D engine tho. But D3D7 also is no option nowadays. |
| ||
| C++ is extremely weakly typed. If it were strongly typed, it wouldn't permit casting of pointers or objects. Casting removes any pretence at type safety: in fact, B3D actually has a stronger type system than C++, since casting is impossible (which it then ignores and uses int-as-void* for everything, but the type system is at least present). C# on the other hand has a more legitimately strong type system (there are still unsafe operations, but they are properly restricted from the majority of your code). Arguably however, any language that allows the existence of "null" is not strongly-typed, because the type doesn't properly define the behaviour of values. To get proper type safety you need something like a Hindley-Milner type system. </totally offtopic> |
| ||
| @ Ian Thompson I understand. Terrains cannot be easily ported to GLES, since they are generated on the fly. Shadows maybe can be ported, by changing just few commands (glBegin... glEnd is used only once, to draw a darker rectangle, you should be able to replace it). Well, the newer version might have other functions not compatible with GLES, but it will have at least one new function that should go well even on GLES. |
| ||
| For me: B3D2 should be able to use newer DX Versions and the RotateImage-Function should be faster too. Maybe it would be possible to upgrade the 3D-part of B3D one day. Netherthanless it would be very cool if BLR and Mark would find the time to do it. Don't let B3D die ;( ;( Last edited 2012 |
| ||
| Don't let B3D die ;( ;( too late, it's already dead. Upgrading the B3D Engine would be kind of a hack, not a real implementation. Have you heard the term "Legacy code" before? The only thing which can be done with a system/engine/code this old is to rewrite it. I think the guys from BRL are already sick of Blitz3D and don't want to waste time with it.Tho I must say, there has never been anything quite like Blitz3D. I mean the ease of use and an implemented 3D engine. It sure is old, but if there was something like Blitz3D TODAY, I think it will be very welcome :) |
| ||
| Um, DC, have you missed the hundred-odd posts above you which are talking about a rewrite, not an upgrade? This thread isn't even about a proposed BRL product; Xaron's third-party implementation is designed as a from-scratch replacement. |
| ||
| To me, these days, the difference between B3D's methodology and that of a "proper" language like Java or C or whatever is like the teenagers that go to their local bookstore and buy half a dozen books on "HOW TO DRAW MANGA" rather than taking a class under an experienced teacher on how to draw. Either way you might get results you're happy with... But only one of those is ever going to teach you the principles of what makes something good and skillful. |
| ||
| Is it still developed? The site looks abandoned... |
| ||
| Angros, is there any chance of a GLES mobile branch of OpenB3D in the future? |
| ||
| I thought OpenB3D was a port of iMiniB3D, which was GLES to begin with...? iMiniB3D has its quirks, but it's very usable. |
| ||
| At the moment, a GLES branch is not in my to-do list (since I'm developing it mainly for linux and windows). Anyway, the main problem is the usage of glBegin in the terrain system (it's not supported in GLES): so, terrains should be removed, because the ROAM algorithm requires to build the triangle data at every frame (and this behaviour is non allowed in GLES). glBegin is also used in the shadow module (after the stencil is set, a single dark rectangle is drawn through glBegin to make the areas where shadows are darker), but it could easily be replaced. So, a GLES fork can be made, but you'd have to remove the terrain section; if you can live without terrains, it's not a problem, otherwise another solution is needed: if the terrain is small, it could be converted to a standard mesh, otherwise, a quadtree or an octree could be used. Anyway, I don't have the SDK needed to compile it for Android, so I never tried compiling it for mobile devices. |
| ||
| Saw the thread bumped, half hoped it would be news about a proper B3D 2.0 :( |
| ||
| I didn't know we were anywhere near Blitz3D ver 2.0 yet. ------------------------------------------------------------------ So, here are my ideas for a possible version 2.0: Question here is, how should the double type look like? I suggest use the following techniques for floating point, just add another '#' wherever you need it. var# for float, =4 bytes, (single precision) var## for double, =8 bytes,  var### for triple precision, =12 bytes var#### for double double, =16 bytes OR, alternately, var#1 for float, =4 bytes, (single precision) var#2 for double, =8 bytes var#3 for triple precision, =12 bytes var#4 for double double, =16 bytes var#n for any counts of word*n (generalized). For integer types, use the same logic: ( http://en.wikipedia.org/wiki/Integer_%28computer_science%29 ) var% =4 bytes, (=1 word), -2147483648 to +2147483647 var%% =8 bytes, (=quad), -9223372036854775808 to +9223372036854775807 var%%% =12 bytes, (???) var%%%% =16 bytes, (octaword) OR, alternately, var%1 =4 bytes, (=1 word), -2147483648 to +2147483647 var%2 =8 bytes, (=quad), -9223372036854775808 to +9223372036854775807 var%3 =12 bytes, (???) var%4 =16 bytes, (octaword) A crazy example: Function AddQuad%2(a%2, b%2) return (a+b) end function --- perhaps allow some exotic types: --- var%n =4 bits, (=1 nibble) var%b =1 byte, (=1 byte) therefore, Dim A%b(10) creates an array of about 10 chars. s$z = a null terminated string type, (= ASCIIZ string) Example: C$z = "Cat's only eat meat." creates an ASCIIz string. ---------------------------------------------------------------- Quote" Types: Actually I never like the way types where done in BB3D... " I think the types are well represented in Blitz3D. MY eyes are well adjusted for the '\' symbol. However, a dot version, '.' is fine too. I recommend adding a union option for types, allowing type data to be accessed in flexible ways. ( https://en.wikipedia.org/wiki/Union_type ) An example of a union in 'C' : union { int i; char c; }; ------------------------------------------------------------------------ Yasha's ideas were great too: quote " - Have a way to get function pointers. If you keep B3D's dual-namespace for variables and functions, you'll need something like &FunctionName to show when you want it as a value " I want to add that it would be great to have string pointers too, in order to more quickly change values in strings. In general, all the string functions seem to be kind of slow, and I wish there were a faster way. ------------------------------------------------------------------- For the Blitz3D (ver 2) Editor. Make it remember your session, so that when it restarts, it shall automatically bring back all the open BB files you had before. ( In the "recent files" menu option, let it remember more than 10. ) -------------------------------------------------------------------- Allow an option for Blitz3D to create DLLs. Allow for inline assembly language, (for geeks that like that stuff). Add some native functions to Blitz3D, such as: v = GetDS() ;; retrieves the DS (data) segment v = GetCS() ;; retrieves the CS (code) segment Add a SetPriority function, allowing a program to use less CPU. ( http://msdn.microsoft.com/en-us/library/windows/desktop/ms686277%28v=vs.85%29.aspx ) Example: r = SetThreadPriority(..., ...) I know I created some "priority" code somewhere, but I misplaced it. Maybe, make multi-threading a native part of Blitz3D v2. ( http://en.wikipedia.org/wiki/Multithreading_%28software%29#Multithreading ) ----------------------------------------------------------------------- Don't include OpenGL. My 12 year old laptop can't do OPENGL.  (Or include it as a choice, only. Sorry, my computer is really old.) --- THose were my ideas. ---- ( I'm <Andy>, also known as VirtLands ) |
| ||
| Thanks for the detailed answer Angros and sorry for the O.T. question! ;) |
| ||
| What is O.T.? ( is it "on time?" ) |
| ||
| I didn't know we were anywhere near Blitz3D ver 2.0 yet. We are not. There is not an official B3D 2.0 under development. Add a SetPriority function, allowing a program to use less CPU. You can do this in the current B3D by either putting a delay in your main loop to give some time back to the OS, or you can access the API directly and control the priority of your program. Maybe, make multi-threading a native part of Blitz3D v2. You should be able to access the Windows threading APIs from B3D. |
| ||
| @Andy OT means "off topic" |
| ||
| @ GaryV Isn't multi-threading unstable with blitz3d? Do you have any examples you could share? Taken from this post: http://www.blitzmax.com/Community/posts.php?topic=75870 "It is possible to use multi-threading in Blitz3D, I've used it. But it is useless because you can't load graphics in another thread. MAV appears on RenderWorld() when mesh or texture created in another thread but did not fully loaded. " " threads are async and you wouldn't use them to load assets independantly of the render process... to do that you'd have to check and recreate your renderer thread until the assets are ready... " "There is no problem with loading data async, all games do it beside "level based shooters". Current gen MMOs wouldn't be possible without async loading at all. " |
| ||
| Isn't multi-threading unstable with blitz3d? It is an API function of Windows. Since it is not part of B3D, there is not any hand-holding. It should only be used by those that know how to write thread-safe code. Do you have any examples you could share? I do not own Blitz3D. |
| ||
| Multithreading without language-level support is one of those things where if you have to ask how... you really shouldn't be doing it. To make threading accessible you really need a built-in notion of channels or message passing - relying on locked proxy objects is not beginner stuff. Go-style channels are for this reason top of my personal list of features to add to a new compiler. I keep meaning to give this a go myself (a simplified project, language-only, all graphics added via DLL) and chickening out at the last minute... |
| ||
| " ...relying on locked proxy objects is not beginner stuff. " for sure... |
| ||
| I'm interested in multithreading as a prospect for future projects. Although I have no experience with the coding or implementation of it, I have zero doubts about my ability to learn it secrets. Modern technically is built around the entire concept of utilizing multiple processors even though most programs/games still only take advantage of it to a limited degree. I hope this eventually becomes a clearer subject for both Blitzmax and Blitz3d. |
| ||
| At the moment there is no B3D 2.0. BB3D has not been released, yet, and there are no news about it. Anyway, FreeBasic + OpenB3D could be close enough (the syntax is not the same, but it's very close to Blitz3d, at least in lite mode) FreeBasic has threads support (http://www.freebasic.net/wiki/wikka.php?wakka=KeyPgThreadCreate ), strict mode, double precision, multiplatform (officially Windows, Linux and DOS; unofficially BSD and Mac; it has been ported to ARM, too), OOP, DLL creation, and much more. It's open source and self-compiling; with OpenB3D (that support 3d commands in OpenGL; no directx, sorry), and some good IDE, it could get very close to Blitz3d... and will offer most of the features requested in this thread. |
   |