_25_11_2024_15_40_33.jpg)
_25_11_2024_15_40_55.jpg)
_25_11_2024_15_43_24.jpg)
|
Socoder -> On Topic -> Speaking about Nuclear Basic |
|
| Mon, 11 Feb 2008, 10:02 | |
power mousey
|
yeah, speaking about Nuclear Basic here is an early tech demo release and some more information. 216.246.13.171/php-bin/forums/view_topic.php?id=1361&forum_id=7 I have already pre-ordered it. Hopefully, it will be out by the end of this month.  |
| Mon, 11 Feb 2008, 17:47 | |
|
Nolan |
Some of those screenshots look excellent. Kind of neat that they're all "one-liners," and I thought it interesting that they're using .b3d files in the code snippet. I do not like paying for new versions, however, and I was rather disappointed by the lack of 2d collisions. They may not be hard to add, but should certainly be integrated in any language geared towards game-programming. In any case, it'll be interesting to see what comes of this. -=-=- nolandc.com 
|
| Tue, 12 Feb 2008, 00:05 | |
|
power mousey
|
the 2d collisions will be built-in. You use the built-in commands and functions. * Is collision built in? Or does the NGC have to be bought separately? The NGC (collision system) is built in and is a standard part of the product. No additional purchase is necessary. We simply just license that section of code as a plugin to 3rd party engines. Matthew is saying that the collision system from NGC is built into Nuclear Basic. But, that they will still sell the NGC which includes the collision system to others that have and use other game engines. yeah, I'm kinda wondering why pay for more upgradeable versions rather than just having one major update version for free. But you consider the cost/expense of creating the language to begin with and as well as the purchase price for Nuclear Basic. * What's the price? If you order before March: $49.95 USD - stand alone $89.95 USD - package with NF (plus beta copies to test as they clear the beta section) If you order after or during March: $59.95 USD - stand alone $99.95 USD - package with NF and also: * How much will it cost to upgrade from major version to major version? Less than the original purchase price. The cost will vary depending on how big of a step it is. * What if I purchase and you release a new version soon after? The version you are currently running will actively be maintained. That said, if there is a bug affecting a newer model *and* your model, we can fix the bug for both in one step and release updates for both as well. So when we go to a new version it doesn't mean the end of updates for you. Also, depending on your purchase time, we may see it fit to waive or reduce the upgrade fee to the newest version. but, ya see Nolan and eveybody else: after over two years in development and testing by Matthew and a few of his assistants, it will be released for beta testing by us. Extensive beta testing and on all kinds of different computers for about a month or so. Then, with any minor or major fixes and updates it will be deemed releaseable to the public. And when it does go public, us beta testers will be the first to receive the public release for free. Then, it will be opened for anyone else. Byt also expect and assume add-on commands and 3rd party functions. As I'm sure Prime 8 is busily working on some right now.  |
| Tue, 12 Feb 2008, 01:56 | |
shroom_monk
|
power mousey  the 2d collisions will be built-in. You use the built-in commands and functions. * Is collision built in? Or does the NGC have to be bought separately? The NGC (collision system) is built in and is a standard part of the product. No additional purchase is necessary. We simply just license that section of code as a plugin to 3rd party engines.  No, that's talking about 3D collisions. Underneath, it says 2D collisions aren't in it: * Can I write 2D games, like platformers, with NB/NF? Absolutely. The product comes with complete 2D support. Currently, the only part you would need to do yourself is 2D collision. -=-=- A mushroom a day keeps the doctor away... Keep It Simple, Shroom! |
| Tue, 12 Feb 2008, 02:23 | |
|
power mousey
|
good point, Shroom. But I think and hopefully he meant that since the NGC collision system is built-in you still have to write the codes and methods to handle the collisions using the commands and functions of Nuclear Basic. I think this is what he meant. Yet, I have asked him myself and inquired about it. When I receive an answer, I will tell you and everybody else too. The thing is if I have to write my own collision system or systems from scratch then why include the NGC built-in collision system in the first place?? Doesn't make sense. Again, I think he means that the 3d collision system will handle both 2d and 3d.
|
| Tue, 12 Feb 2008, 02:49 | |
|
power mousey
|
I still wait for an answer. But I found this Shroom and others: ttp://216.246.13.171/php-bin/forums/view_topic.php?id=477&forum_id=2 buts only talking about an earlier version of NGC. I'm sure there will be at least help or even some examples to do 2d collisions in Nuclear Basic. But until I get an answer and more information...I'm sensing that sprites will be as 3d. And/or you could still handle some sort of boundary checkings and collisions by making a 3d cube or sphere over the sprite or a few of them covering certain portions of them. |edit| And just as there Sprites implemented as 3d in PureBasic and also in Blitz 3d and with Entitycollision commands and functions, I think Sprites will be implemented and utilized as 3d in Nuclear Basic. |edit| |
| Tue, 12 Feb 2008, 10:13 | |
|
Hotshot |
Wot you going to make in Nuclear Basic? mr powermousey
|
| Tue, 12 Feb 2008, 10:31 | |
|
power mousey
|
I did not get an official answer from Matthew yet. I suspect he is very,very busy busy wrapping everything together for the beta test release of Nuclear Basic. But one of his assistants who works closely with him told me that he thinks there will be collision commands to handle 2d. Thats all he could say. Yet, and just as I said in previous and above posts,that the NGC collision system could be tasked to use spheric or cubic boundary and collision checking for sprite entitites. These objects will be transparent of course and work in the background and determine if the shape of the sprite is more spheric or more cubic in shape. @Hotshot, haha. just wait and see. Serious, I have a few ideas and things in mind. okay,okay here are a few: continue on with the Chaldean Cat. work on Heras' Hell Pit of Hounds. Alfredo the Cat....screen saver Babas' Desert adventures (Forty Thieves and Forty Knives. Thieves need knives. Who is going to supply and sell them these knives?? Why Baba, of course ) Power Ninjas....screen saver cheers
|
| Tue, 12 Feb 2008, 11:31 | |
|
power mousey
|
well, I just got an answer from Matthew. 2d collision hasn't been implemented yet. What!?? I can, in comparison, excuse Graham not including a basic input command or routine in Cobra and after 2 years of working on it. Besides, I finally created a few of my own input procedures and functions in Cobra. But this, I'm really dumbfounded and sorta disappointed. His thinking is why incorporate a few methods of various pixel to pixel methods of collision for 2d when no one will want or use. huh?? It should be there for anyone to use and implement. People are still writing and developing games in 2d and use 2d a lot for fun,learning, and even profit. Look at Blitz 3d, there are collision commands for images in 2d. Haven't used them in a long time..but sometimes I do use them. But they are there if you want or need them. here is asample slice of his answer and a few responses too: 2D collision has always been something that seemed to be on the outter boundary of feature requests, although I am giving it some thought. It's one of those things were the math isn't particularly difficult, but it's a matter of perfecting and features. For instance, should it be pixel to pixel collision? Ellip to pixel collision? Ellip to ellip collision? Any manner of box collision? Etc... For collision with a character against a 2D world (thinking in terms of Mario) pixel to pixel would probably yield the best results. But when colliding against other characters or things he might need ellip-2-ellip if you don't want him to be able to stand on top of baddies, etc... Just some thoughts on what I would want to know from our buyers before implementing features nobody will want or use. ____________________ It's rarely the functionality that's difficult, it's the optimization. Prime_8 Full Beta Tester Joined: Mon Jun 5th, 2006 Location: Canada Posts: 2488 Mana: Posted: Tue Feb 12th, 2008 09:44 am Quote Reply should be pixel to pixel with teh option of using a masked shape image so default is what ever sprite shape loaded ot use an alternate unseen masking shape that could be .. round or not . math wise circular is one the user can do now. because in 2d its simple radius values and same for cubic detection using rect regions .. checking for overlap. Last edited on Tue Feb 12th, 2008 09:46 am by Prime_8 ____________________ old fart coder and mesh smithy https://www.ejectedcore.com matthew Administrator Joined: Wed Dec 31st, 1969 Location: Wisconsin USA Posts: 5553 Mana: Posted: Tue Feb 12th, 2008 09:50 am Quote Reply Problem with using a mask for round shapes with pixel to pixel is that the shapes aren't really round, so they'll stick instead of sliding off each other. One of the problems with doing an overlap check is for fast moving objects. If one passes completely through and behind another one (or even just passed the center point) collision will miss or fall to the wrong side. Cool idea for a mask btw. That could come in handy feature-wise for setting up the 2D collisions. Last edited on Tue Feb 12th, 2008 09:51 am by matthew ____________________ It's rarely the functionality that's difficult, it's the optimization. Prime_8 Full Beta Tester Joined: Mon Jun 5th, 2006 Location: Canada Posts: 2488 Mana: Posted: Tue Feb 12th, 2008 10:04 am Quote Reply I and well almost every sprite engine in past used masks . and a sort of xor put to hidden buffer looking for error color to apprear when xor is done on masks . if color in buffr the a colission has occured becaus ethe was done every frame .. it was vey accurate . but not perfect . full / tru colission like Matt says that ven detects a passing of ents during fames very precise.. possibly over kill for 2d and of course ther si iso renderd 3d stencils .. or extruded 3d ents only moving on a xy plain wher z is frozen the you can use 3d colission behind the 2d sprites ____________________ old fart coder and mesh smithy https://www.ejectedcore.com |
| Tue, 12 Feb 2008, 13:28 | |
|
power mousey
|
cough!! cough!! I feel stupid and embarrassed. And so I should. I'm sorry for all the confusion.  I completely misunderstood want he told me and others. He elaborated further to me: @power mousey Yeah, I know 2D is still in effect. I did mean the specific functionality required though. Since I have made systems in the past that people haven't even touched. Hence why I am interested in what you and your prospects want specifically. (ie: ellip to pixel, box to pixel, pixel to pixel, etc...) will sprites be implemented and utilized as 3d like they are in Pure Basic and Blitz 3d? Yes. However, there is a separate 2D commandset we are implementing. The 2D commandset will actually make use of 3D entities too, but the coordinates will be in 2D space. This will allow you to put any 3D entity in 2D space and act on them with all of the available entity/surface commands (alpha, lighting, etc...) That above said, you could use sprites in 3D space or 2D space. if I need to do 2d collisions on sprites can the built-n NGC collision system be tasked and even take over to use spheric and cubic boundary and collision checking on them?? Either manually or even automatically? Since all 2D elements will be entities, yes, it can be tasked for 2D collisions. What I'm looking at doing is simplifying that for 2D operations though (specifically the desired functionality I inquired about above). yeah, all right! bye and cheers people  |
| Wed, 13 Feb 2008, 13:59 | |
|
Hotshot |
There is far too many new programming language out there and I am not saying it is bad things but good things it keep the programming language more alive over time. who know....there could be someone who could make Blitz 3D 2 or BlitzMax 2 or Darkbasicpro 2 in the future. |
| Wed, 13 Feb 2008, 14:52 | |
steve_ancell
|
@ Kent... Is Nuclear BASIC OOP, or is it procedural ?. |
| Wed, 13 Feb 2008, 17:34 | |
|
power mousey
|
um Steve, I have no idea. But, I can find out from him at the Nuclearglory site. But feel free to contact and ask Matthew...if you wish. It goes for anybody here. But, I'll find out by asking Matthew. But, if you have questions about Nuclear Basic or even good/bad comments then let him know. cheers |edit| question posted on the site. Hopefully, awaiting for an answer. |edit|
|
| Wed, 13 Feb 2008, 18:23 | |
steve_ancell
|
Cheers Bro.
|
| Wed, 13 Feb 2008, 18:34 | |
|
power mousey
|
and here is the answer bro, It's both. You can run standard procedural programming if you want, like most Basic's (Blitz3D of DBP). Although ours is extended a bit more than usual via the library/plugin support where NF plugins can call NB-made routines and vice-versa. On the OOP front it is pretty powerful too. You can setup what are called "Types", which model very close to how you can setup Types in Blitz3D. However, we added support in for constructors/destructors (if your common to c++) via Make() and Kill() functions you can define inside the Type. That said, you can also define your own custom functions inside Types and perform true OOP, example: + code snipplet Type test Field val# Function Print() WriteConsoleText( This\val ) EndFunction EndType MakeConsole() var.test = New test var\val = 22.3 var\Print() The above program would open up a console window (like a DOS window) and print 22.3 inside it. Obviously this could also be done in 3D, but I wanted to show you full program source (the above will work as is - contains all the code) ____________________ It's rarely the functionality that's difficult, it's the optimization. Current time is 05:31 pm |
| Wed, 13 Feb 2008, 18:39 | |
|
steve_ancell
|
Sounds good... Any idea when it going to be finally released ?.
|
| Wed, 13 Feb 2008, 18:53 | |
|
power mousey
|
hopefully, by the end of this month. First, for the beta testers and then afterwards public release too. Keeping fingers crossed. cheers |
| Wed, 13 Feb 2008, 20:21 | |
|
steve_ancell
|
I'm definately starting to become interested. |edit| Nuclear BASIC seems to have the potential to become an industry standard. |edit| Cheers Bro. |
| Wed, 13 Feb 2008, 23:30 | |
|
power mousey
|
to be honest, I think it will. But whether it does or doesn't, I really like a lot of the features in the language. If you or others have any questions or concerns, Matthew is cool and willingly to answer them and even talk too. The guy is cool and knows his stuff. So, before you make any judgement calls about Nuclear Basic talk with him first and ask him. |edit| okay Nolan, Shroom and Hotshot?? Before any of you or anybody else here comes to any conclusions, best thing to do is ask him in the first place. |edit| |
| Thu, 14 Feb 2008, 21:04 | |
|
Nolan |
okay Nolan, Shroom and Hotshot?? Before any of you or anybody else here comes to any conclusions, best thing to do is ask him in the first place. To be honest, I didn't want to bother signing up on the NBforums. Not to mention that my conclusion was, in fact, correct. Besides, that's what these forums are for -- asking questions! -=-=- nolandc.com
|
| Thu, 14 Feb 2008, 23:58 | |
|
power mousey
|
such arrogance. anyway, I'll let Matthew respond as he did as I was talking with him about this: Glad to help. I know what you mean. I think people are right to be skeptical with the stuff going on the industry, particularly if they're considering building their stuff on top of it. Although I do appreciate it when they actually talk to me and see what we have under the hood and where we're headed before making judgement calls you can ask Matthew these questions too. He will be happy to answer your concerns and comments. anyay, Nolan use whatever you want and like in programming languages. No more from me to you about this, since you have already made up your mind apparently. |
| Fri, 15 Feb 2008, 10:46 | |
|
aoneweb |
From a Nuclear Basic standpoint, and being involved with Nuclear Glory for a couple of years, please let me make a comment. One of the things that wooed me to NB is a question I asked Matthew a long time ago, his answer sold me, and I pre purchased the software, and have been an avid promoter ever since. I Asked, "when NB is released, will we have to buy add on packs for additional functionality, like other game making software I could mention" Matthew replied something along these lines, he will try to incorporate everything a programmer will need to complete their project, with out having to buy add on packs from NG, however, he would not stop anyone who wished to write 3rd party add ons for the language, free or for sale, he would even promote 3rd party add ons, on the NG site if the creator asked. So my conclusion is this, not only will I be getting an up to date basic language, Matthew is willing to promote any work you may produce as well, what an out let to get your own customers I thought. As for the language, I will be helping to write some docs, and beta test the first release, the compiler will be released first, as the GUI will need a little tweaking, so much has been added to NB/NF over the last few weeks, by members request, that we need to upgrade a few things. Lastly, if you want some sort of functionality built into the language, ask Matthew, he will do his upmost to add it for you, and if not in this release, then in the upcoming updates, now how many language developers do that? Thank you all for reading my post. Happy gaming. Anoneweb. -=-=- https://www.nuclearglory.com
|
| Fri, 15 Feb 2008, 11:55 | |
|
Hotshot |
I would like to see a demo of Nuclear basic before we make our own Judgement but then everyone have own perfer on what programming language they like and you have remmy...YOU cant FORCE people to try their New programming language for your own reason as everyone have their own reason on whatever they wish to try on whatever programming language is. Nuclear Basic is interesting language but again, it is up to people on what they feel comfortable with whatever programming language they used. So power mousey, I am not knocking down on Nuclear Basic but people can be very awarey of new programming language on what they have or what can do somethings that other programming language that cant do ( for example Darkbasicpro couldnt do OOP). I am not into flamewar Match on what is best programming is. They all have PRO and CON on programming language. At the end of the day, is the person who feel comfortable and happy to program on what they want to program. I hope you all understand on what I trying to say. thank you for reading. p.s. I would love code my own programming language but no, it all hard work. |
| Fri, 15 Feb 2008, 12:05 | |
|
shroom_monk
|
power mousey okay Nolan, Shroom and Hotshot?? Before any of you or anybody else here comes to any conclusions, best thing to do is ask him in the first place.I didn't mean to say in my post that it wasn't going to have 2D collisions, but the way I interpretted the paragraph I quoted was that one would need to write out 2D collisions detection themselves. From what aoneweb has said above, and other things that have been said/I have seen, it seems like Nuclear Basic will be a pretty good language. Sorry if I sounded a little arrogant there... I didn't mean it like that...
-=-=- A mushroom a day keeps the doctor away... Keep It Simple, Shroom! |
| Fri, 15 Feb 2008, 12:18 | |
|
power mousey
|
thank you aoneweb and Hotshot. I know its peoples' choice whether they want to buy or not to buy. As well as whether they take the initiative or not to check it out. But to make judgement calls and decide its not good to buy without checking it out further...including not asking the developer...is puzzling in my book. and its okay Shroom and Hotshot. A lot of people here for some reason or another and a lot of times are slow to take the initiative. I could've myself have part of the blame. I should've said and will say it now for all good and meaningful intents and purposes: just wait till Nuclear Basic comes out! Cause the proof is in the pudding.  oh and by the way, Hotshot true DBPRO is not OOP per se but you should see what I'm doing with it. The nth version that I'm trying right now is not so bad. I'm taking the horrible and making it at least tolerable. You should see my game library functions that I'm working on. You too, Shroom. Never had so much fun with functions like the times with Pure Basic. ahhhhhhhh!! I'm going to rework both my Wolfie model and the Geisha Girl from the Dark Matter 2 model pack. Some others are obviously in the works too. cheers |
| Fri, 15 Feb 2008, 13:27 | |
|
aoneweb |
Thanks for the replying to my reply, NF/NB will be out on a demo, and of coarse you should try before you buy, Matthew and all at NG want you to be happy with the product, thats why Matthew refuses to release it, until it is as stable as it can be. I will try, along with power mousey, to keep you all up to date as possible, I am privileged to some inside info, which I can't discuss here, or anywhere else, but I will do my best to give you all here as much info about progress and release as we get at NG forum. Thank you all for reading my rants, LOL -=-=- https://www.nuclearglory.com
|
|
|
| |||
|
| ||||