Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / [LOCKED] Criticisms of DarkBASIC Professional

Author
Message
dark coder
22
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 9th Oct 2009 18:03 Edited at: 9th Oct 2009 18:05
Link
Quote: "No. PureBasic's syntax is more complex than DBPro, functions have to be declared at the start, there's a few things here and there that just push them apart. If you put DBPro code beside PB code, they would look very different in syntax, although your right that the basic operation would be the same, just like it is when comparing most modern languages."


Forward declaration of functions isn't an issue concerning syntax though. With the exception of this I don't really see any fundamental changes with the way anything must be written. Instead of 'apple as float' you write 'apple.f', instead of 'apple = MY_CONSTANT' you have 'apple = #MY_CONSTANT' and there's a slight semantic difference with how expressions are evaluated but the rest seems more or less the same, I wouldn't say these others make the language any more complex, just different.

I've not touched PureBasic or PureGDK myself so I'm only speaking by what I see in the examples and they seem rather similar. Granted, some of the examples show off advanced functionality DBPro is incapable of, but if you look at the DBPro examples that have been ported, they are practically identical. One key difference from what I can see is that you must initialize the window size and such, but with DBPro this is automatically done via the editor and compiler so it's not really that much of a difference. Perhaps Mistrel's doing himself a bit of a disservice by first showing those examples rather than simple ones, but I guess it's aimed at a slightly different market.


Quote: "The file access commands are spot on IMO, never had issue with them "


Try using the file libraries offered by other languages and you'll soon change your mind .

Back to top
Profile PM Email
tiresius
22
Years of Service
User Offline
Joined: 13th Nov 2002
Location: MA USA
Posted: 9th Oct 2009 18:48
Link
I think Havok is talking about File I/O support, which I agree is a bit stinky since it lacks an APPEND TO FILE function. But there are plugins to include it thankfully.

This thread is about improving language features, not improving core libraries.

I'm not a real programmer but I play one with DBPro!
Back to top
Profile PM Email
Van B
Moderator
22
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 9th Oct 2009 19:00
Link
To make the examples more straightforward would be denying the benefits of using PureGDK instead of DBPro - I don't think anybody should tackle PureGDK without learning PureBasic techniques. Migrating is counter-productive if not done for the right reasons, the GDK systems should be a way to expand, not replace.

I mean, if anyone tries to avoid the conventions in PB they just end up paying for it later - either when they post code on the PB forum, or find a method that is better. To get the most from it, people should be aware of what PB can do already. I think there's a myth floating about that GDK is just DBPro in a different guise, and that's making people wonder why migrating is worthwhile - the benefit should be in utilising the language you choose to it's full potential.

I think that a small project in PureGDK would help more than simplified examples. For example if there was a model viewer, but one in a proper windowed environment with GUI, maybe something like Deep Exploration. These programs can be very usefull - ESPECIALLY! - if you track the modification time of textures and update them automatically, then it becomes a cool texturing aid. This is the sort of thing that DBPro can struggle with, because it would have to behave with other applications like art packages. One of PB's main strengths is the control you can take over proceedings, making more resource friendly applications.

I'm interested in PureGDK for writing different types of applications, not necesserily games because I'm old school, I don't mind my game projects taking all the resources and screen space - but I can see the potential in using PureGDK for editors right away. I've never tried writing a game in PureBasic and to be honest I just don't see it that way yet, I just know that having the power of PureBasic with a good 3D engine affords us the possibility of making applications that DBPro just can't cope with.

PureBasic users probably see it as an extension to PB, whereas DBPro users see it as a migration - I think that once PB users get stuck in we'll see some remarkable things.

As for file access, DBPro is no worse off than any other incarnation of Basic that I've used, and I don't think that it needs more. I'd actually rather use DBPro's file access commands than VB's. But I do want to stress that anything Lee can do to expand DBPro is a good thing, whether it's DC's points, the file system, or anything really - just keeping the language moving forward is reasuring, even if that is often at a slow pace.


Health, Ammo, and bacon and eggs!
Back to top
Profile PM Email
Alfa x
18
Years of Service
User Offline
Joined: 1st Jul 2006
Location: Colombia
Posted: 9th Oct 2009 20:06 Edited at: 9th Oct 2009 20:08
Link
Quote: "You neglect to mention that time is exponential with project size due to some of these limitations and others, large projects using DBPro aren't feasible due to many compounding factors. This strays from the original intent of my topic a lot, but the compiler speed coupled with the (lack of)debugging ability in DBPro are probably the biggest killers of large projects assuming you have the skill and time to work around its other limitations. The compile speed is a joke for large projects and its debugging ability is also a joke, if you try debugging faulty code in 99% of other languages with IDEs that work then you'll fall in love with them because they just have so many more features that are incredibly useful and you can't really live without them for large projects.

Don't get me wrong, DBPro is great for small projects and for prototyping, but that's all it'll ever be with the package we're presented. The issues mentioned in the above paragraph highlight why working on large projects in this language is a chore, but there are other issues such as the lack of facilities to allow you to abstract code better, i.e. classes/namespaces/libraries. Their omission also makes it hard to write clean and reusable code, both of which are important to larger projects. This forces you to use a very consistent style for your whole program otherwise it'll be a complete mess after you reach several thousand lines[1].

As Mistrel highlights, these are issues with the core language and not the packaged libraries, the libraries sometimes get updates but the language rarely does, and the language is where 99% of the problems lie. "


I agree with all this.
I will finish my big projects for sure, but I'm experiencing these problems at the momment and like DC said i have to keep an eye in consistency, names or variables types, functions, files and everithing!. Since I work in a team have to tell my other temamtes to keep an eye on this too, and are things that should be avoided...

As you progress in the language you dream with bigger projects, you don't want to stagnate. But at that point is where the problem becomes exponential in time effort and finishing a project becomes a pain in the neck (maybe thats part of the reason almost anybody can finish a project?), because you have to invert many times the same effort (5 time for example?) to achieve something that written with some of the characteristics that DC exposed should be done in 1.5 the effort if written correctly.

I try to avoid this problems, simplifying sometimes, making workarounds. Or like int he case of UA, hoping that a solution to pass values by references comes someday,so I don't have to write the same code eight times so I can keep RAM usage low(Each write, for each player).

I think the point of DC is not that things aren't possible with DBPRO (we al l know that's many things are possible and is a very versatile language), but rather than BDPRO has problems to finish big projects (thats why he says people loses interest, no that is not possible) and that these features can provide a good solution to that. If big projects could be finished, it should be better for TGC.

Anyway I see DC doesn't take any benefit from this as he uses DGDK, and I don't know why he is writting about it. What is true is that he is making us a great favor exposing them and I'm thankful for that and hope that this features should be implemented someday so we can see great things coming on the feature..
Back to top
Profile PM Email
Visigoth
19
Years of Service
User Offline
Joined: 8th Jan 2005
Location: Bakersfield, California
Posted: 10th Oct 2009 05:58 Edited at: 10th Oct 2009 06:03
Link
I have no complaints. It is what I expected, and better, for what I payed for it.
edited to add:
now, some of the "add ons", that's a whole other gripe.
But, you live and learn, and move on.
Back to top
Profile PM Email
dark coder
22
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 10th Oct 2009 06:45
Link
Quote: "To make the examples more straightforward would be denying the benefits of using PureGDK instead of DBPro"


Well I didn't suggest he remove the more complex examples, but more or less show the simpler ones first so people from DBPro can easily switch over rather than having alien things like message handling and threads thrown in their face. But I guess the standard for spinning cube demos has gone up since I last tried one .


Quote: "I think there's a myth floating about that GDK is just DBPro in a different guise"


That's exactly what it is, it's just the DBPro libraries in C++ static library form. As such, you don't get speed advantages from GDK itself, but merely the things that aren't GDK such as the game logic and general computation.


Quote: "Anyway I see DC doesn't take any benefit from this as he uses DGDK, and I don't know why he is writting about it."


Because DBC/DBPro were my first languages I learned, thus I wasn't really aware of the majority of facilities offered by other languages. Once I moved to C++ with GDK I learned loads of things about the language and once I came back to write a small example for someone, I kept hitting limitation after limitation. These weren't like 'oh no there's no polymorphism', but limitations that make no sense and just impede development time, so I made this thread.

Back to top
Profile PM Email
Visigoth
19
Years of Service
User Offline
Joined: 8th Jan 2005
Location: Bakersfield, California
Posted: 10th Oct 2009 08:14
Link
@DC
I can understand your arguements, but, this is a very low cost, high level language. I'm surprised to hear this was your first language. I've programmed in VB and others, and found this faster and simpliar for 3d. Knowing that the guys behind this aren't Microsoft, I'm not gonna fault them. I'll take any improvements they offer. We all know you are the man when it comes to DBPro, but, don't you think you are being kind of hard on them? You said it yourself, after you moved to c++, you learned more. Maybe that is the natural progression. I know Lee and company know c++. Don't take this the wrong way, but, if you, at this time, with what you know about C++ wanted to wrap it all up into a Basic language, could you do it? And charge what they do?
I think, at best, this whole thread is just requests for features.
Again, I'll wait for them, and be happy when they come out, but, I'm not gonna criticize the language. It does what I expected, and then some.
Back to top
Profile PM Email
chwilly
15
Years of Service
User Offline
Joined: 23rd Feb 2009
Location:
Posted: 10th Oct 2009 08:39
Link
I've been following this thread since its beginning, but now it's starting to depress me.

All I know is I've worked with every langueage from PL/1 to FoxPRO to C++. All I know is that I like BASIC languages and I like DBP. So there!
Back to top
Profile PM Email Website
dark coder
22
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 10th Oct 2009 10:50
Link
Quote: "I can understand your arguements, but, this is a very low cost, high level language. I'm surprised to hear this was your first language. I've programmed in VB and others, and found this faster and simpliar for 3d."


That's no excuse for the omission of obvious features, there are other things that could be beneficial such as dynamic typing, but I didn't suggest this as it's not that fundamental. However being able to return UDTs from functions etc is, and making games is harder without this. Plus, without native support for the vector and matrix data types, writing 3D stuff isn't easier, and takes a lot more code.


Quote: "but, don't you think you are being kind of hard on them?"


No.


Quote: "Don't take this the wrong way, but, if you, at this time, with what you know about C++ wanted to wrap it all up into a Basic language, could you do it?"


Absolutely, in fact I'm confident that I would be able to write a far better compiler than what DBPro has and it likely wouldn't event take that long considering what DBPro does. Anyone who's familiar with tokenizing strings + evaluation of expressions and has a little bit of free time to learn x86 machine code should also be able to, it would also be easy to optimize a lot of things, just look at this:



Back to top
Profile PM Email
Steele
21
Years of Service
User Offline
Joined: 25th Oct 2003
Location: Somewhere over the rainbow
Posted: 10th Oct 2009 18:37
Link
I've heard talk of using PureBasic vs. Dark Basic Pro and I use both. Van B hits the target perfectly. I coded Dark Data in PureBasic because DBPro doesn't have this set of functionality. But what am I coding my game in? Dark Basic Pro. I find that I can get things done faster by letting the engine do a lot of the work for me and allow me to concentrate on the story line.

Oh yes, DBPro could use some improvements as could all programming languages. Visit some of the other forums from other boards and see the criticisms and requests for features.

All in all, I like Dark Basic. I have the most enjoyment programming in it than any other.

[At this point our orator steps off his soapbox, takes a bow, and runs as people boo and throw things at him.]

Steele

http://www.lanningsoftware.com
Your source for Games and Entertainment
Back to top
Profile PM Email
KISTech
16
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 10th Oct 2009 19:06 Edited at: 10th Oct 2009 19:11
Link
Quote: "However being able to return UDTs from functions etc is,"


I didn't mention this one before, and it seems whenever I try and counter point DC in just about anything I come off looking like an idiot. I did put some thought into this though.

Passing UDTs back from functions? Why? Arent your UDTs global? If they're in an array, just pass the index to the function and modify the data. I do this all the time.



If you can show me why I would want to pass the entire UDT and not just reference it by it's index, then great. I'm always ready to learn something new.

[edit]
In looking at the phrasing of the statement I now suspect that you're going to post some peice of code that's going to indicate I misinterpreted your meaning. So like I said, I'm ready to learn something new. Even after looking at your example in the original post, I'm not sure I see where I would ever use that.

Back to top
Profile PM Email Website
dark coder
22
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 10th Oct 2009 20:06
Link
Quote: "Oh yes, DBPro could use some improvements as could all programming languages. Visit some of the other forums from other boards and see the criticisms and requests for features."


Yes, people suggest features for all languages, but there's a difference! Most other languages have already implemented practically everything that can be within the confines of their chosen paradigms and design goals. DBPro isn't one of those languages, the first section of my list are what I can safely say are limitations, the others are features, I guess. The distinction between the two can be summed up as: features(it'd be nice to have this), limitations(Huh?? Why doesn't the language allow this).


Quote: "Passing UDTs back from functions? Why? Arent your UDTs global? If they're in an array, just pass the index to the function and modify the data. I do this all the time."


Yes you can work around it by doing this, but this isn't nearly the same. The most obvious issue with this is that is isn't even close to modular, if you have a bunch of functions that generate data that fills a UDT, to return that you'd need to copy the data from the global which in itself is a bit of a non-intuitive way to do things, and imposes several limitations.

Consider the following code:



Notice the much added complexity, plus the user can't simply use the functions as they normally would, they'd have to look at the implementation or read documentation to know how to handle the 'return value(s)'. They must also take care with how they call the functions to make sure they aren't overwriting the results from a previous call.

Your example is referring to a completely separate thing, in the case of players they are stored in the array and no where else, thus it makes sense to write a routine that accesses the array directly, as you're doing. If however you had separate lists of characters, say players, enemies, NPCs etc, then such a solution wouldn't be ideal as you'd have to write your character handling implementation several times. That would also be an instance where either references or methods would be a great boon.

While I'm aware that most of the limitations I've mentioned can be worked around, that's the whole point of this thread, you shouldn't have to. This language is touted as being designed for beginners and up, for making games; but as you can see in my above example, if you want to do seemingly simple things you must learn a lot of involved work arounds. These result in code that not only isn't clean or easy or read, but is incredibly error prone if you don't know exactly what's going on, and you must be very careful with not only what you do but in what order.

Back to top
Profile PM Email
KISTech
16
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 10th Oct 2009 21:46
Link
Fair enough.

If I had to pick just one, it would be Arrays in UDTs.

Back to top
Profile PM Email Website
david w
18
Years of Service
User Offline
Joined: 18th Dec 2005
Location: U.S.A. Michigan
Posted: 10th Oct 2009 22:15 Edited at: 10th Oct 2009 22:22
Link
EDIT: Posted in wrong sub-topic
Back to top
Profile PM Website
Mobiius
Valued Member
21
Years of Service
User Offline
Joined: 27th Feb 2003
Location: The Cold North
Posted: 11th Oct 2009 01:53
Link
Quote: "If I had to pick just one, it would be Arrays in UDTs."


I'd like this.

Your signature has been erased by a mod because we're sadistic losers with nothing better to do. (joke)
Back to top
Profile PM Email Website
EdzUp
22
Years of Service
User Offline
Joined: 8th Sep 2002
Location: UK
Posted: 11th Oct 2009 20:50
Link
Why settle for one, we shouldnt have to pick just one if all other languages have the facilities then this one should too

-EdzUp
Back to top
Profile PM Email Website
Visigoth
19
Years of Service
User Offline
Joined: 8th Jan 2005
Location: Bakersfield, California
Posted: 12th Oct 2009 03:56
Link
Quote: "Absolutely, in fact I'm confident that I would be able to write a far better compiler than what DBPro has and it likely wouldn't event take that long considering what DBPro does. Anyone who's familiar with tokenizing strings + evaluation of expressions and has a little bit of free time to learn x86 machine code should also be able to, it would also be easy to optimize a lot of things, just look at this:"


well, I have no idea what that assembly means, I admit that. I don't do assembly.
But, if you feel you can make a better compiler, or, maybe even a .dll to add some of these features, don't you think this might be an opportunity for you?

Alot of things in DBpro have been improved by other users. I am sure anything you added to the base would be greatly appreciated, and, I would bet alot of folks would pay for it.

I know you mean well. I know you just want what is best for all of us. But at the same time, I kind of understand their position right now. I'm sure alot of their focus at the moment is going into FPSC X10, because it is probably just more popular. I thought I saw a demo somewhere of a DX10 version of DBPro as well, but, don't quote me on that.

Either way, here's your chance. Make yourself famous.(Well, more famous, haha!)
Back to top
Profile PM Email
Pincho Paxton
21
Years of Service
User Offline
Joined: 8th Dec 2002
Location:
Posted: 12th Oct 2009 04:04
Link
Does anyone still use assembler code? I thought it was replaced by C ages ago.

Back to top
Profile PM Email Website
Visigoth
19
Years of Service
User Offline
Joined: 8th Jan 2005
Location: Bakersfield, California
Posted: 12th Oct 2009 04:16
Link
I know guys who are good C++ programmers, who had to learn assembly. Also, before HLSL, that was how shaders were written.
And good C++ programmers use assembly all the time to debug.
Back to top
Profile PM Email
HavokDelta6
15
Years of Service
User Offline
Joined: 22nd Aug 2009
Location: United Kingdom
Posted: 12th Oct 2009 10:08
Link
Visgoth we should not really have to pay for the functionality which we all agree should already exist. but if a user must do it, i am sure that they would be amoung GreenGandelf, IanM and Benjamin for doing it

Back to top
Profile PM
NeX the Fairly Fast Ferret
19
Years of Service
User Offline
Joined: 10th Apr 2005
Location: The Fifth Plane of Oblivion
Posted: 12th Oct 2009 13:17
Link
Quote: "And good C++ programmers use assembly all the time to debug."


What?

Back to top
Profile PM Website
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 12th Oct 2009 13:31
Link
I guess I'm not a good C++ programmer


The one and only,


Back to top
Profile PM Email
Van B
Moderator
22
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 12th Oct 2009 13:54
Link
Depends on what the C++ coder actually does. Most normal C++ coders won't bother with assembly unless they have to, that is why they use C++ and not assembly language!.
Debugging through assembly is probably not the most direct way unless your debugging someone elses executable, say a DLL in the most legal example. Even then, they might not need a lot of experience with assembly, might just have to work out what the program is doing exactly when it crashes, which might just tell them a memory register or something to check in their source. Most debugging with assembly is done to actually circumvent what the program is doing, security measures etc etc - C++ coders who are using game engines probably don't need to worry about assembly language at all.

Assembly is really an option for those who are brave enough, kinda like haggis. It's a different world than how things were done 20 years ago, back then everything was written in assembly, and programmers were bald by the end of their 20's . It is good to see inline assembly is in some languages, even some BASICS, but personally I spent the last 20 years trying to avoid it.


Health, Ammo, and bacon and eggs!
Back to top
Profile PM Email
NeX the Fairly Fast Ferret
19
Years of Service
User Offline
Joined: 10th Apr 2005
Location: The Fifth Plane of Oblivion
Posted: 12th Oct 2009 14:03
Link
Assembly's not cross platform, is it? I can't imagine raw CPU instructions (well, the next best thing) would work on both an ARM and a x86. So that probably means that if any assembler optimisation needs to be done, it needs to be written out separately for each target platform?

Back to top
Profile PM Website
Van B
Moderator
22
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 12th Oct 2009 14:13
Link
Yeah that's true, so if you had inline Assy you'd have to use alternatives for each platform - in the case of PureBasic for instance it can compile to PC, Linux, Mac, and Amiga, so it could get quite complex if cross-platforming is your bag.

Back in the day (where I spend most of my time) we were quite lucky in that the AtariST and Amiga both used 68k chips, so converting game logic at least was often very smooth, sometimes a conversion took only a week. David Braben for instance took just 1 day to make the AtariST version of Frontier, based on the Amiga code.

As I said though a legitimate C++ coder would only use assembly if they absolutely had to. There's just little need for it beyond ninja-style optimizations - if there's a few cycles to be saved by making an assembly procedure, then it might just be worth learning enough assembly to do that. The only people still using assembly extensively, besides hackers would be demo scene coders, and that's mainly just belligerence .


Health, Ammo, and bacon and eggs!
Back to top
Profile PM Email
Visigoth
19
Years of Service
User Offline
Joined: 8th Jan 2005
Location: Bakersfield, California
Posted: 12th Oct 2009 20:08
Link
sorry, I didn't mean to infer c++ programmers are not good if they can't interpret assembly.
What I meant from debugging was the output generated by Dr Watson. I guess Watson is going the way of the dinosaur these days.
When I worked in San Francisco a few years back on Firetalk, when we had crashes, we would send the Watson files to the programmers. I know my friend, who was the lead programmer, could read that disassembly like it was English.
That is all I meant about assembly as a debugger.

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/drwatson_overview.mspx?mfr=true
Back to top
Profile PM Email
EdzUp
22
Years of Service
User Offline
Joined: 8th Sep 2002
Location: UK
Posted: 12th Oct 2009 21:52
Link
Quote: "
And good C++ programmers use assembly all the time to debug.
"


Well seeing as most C compilers have tools to watch everything and debug stuff everywhere and report somewhat cryptic error messages its not really required to read assembly and Dr Watson is useless in some cases for debugging.

-EdzUp
Back to top
Profile PM Email Website
HavokDelta6
15
Years of Service
User Offline
Joined: 22nd Aug 2009
Location: United Kingdom
Posted: 12th Oct 2009 22:29
Link
On topic please guys, but with the C++ compiler thing, its common knoladge that:

"the best IDE's are the ones that provide fetures, but fail to try to do anything for you" - Quote someone.

Like with HTML + CSS; there are COUNTLESS apps to do it for you graphically, but there's something more efficent and ultimatly better about doing it yourself, chances are you know more then the program.

Ontopic, What exactly is a UTD? i think it was.

A type?

Back to top
Profile PM
Mobiius
Valued Member
21
Years of Service
User Offline
Joined: 27th Feb 2003
Location: The Cold North
Posted: 12th Oct 2009 23:33
Link
Quote: "What exactly is a UTD?"

A typo for UDT?

Your signature has been erased by a mod because we're sadistic losers with nothing better to do. (joke)
Back to top
Profile PM Email Website
HavokDelta6
15
Years of Service
User Offline
Joined: 22nd Aug 2009
Location: United Kingdom
Posted: 12th Oct 2009 23:34
Link
What is a UDT?

Back to top
Profile PM
Mobiius
Valued Member
21
Years of Service
User Offline
Joined: 27th Feb 2003
Location: The Cold North
Posted: 12th Oct 2009 23:46
Link
User Defined type.

You even got it right above!
Quote: "A type?"


Your signature has been erased by a mod because we're sadistic losers with nothing better to do. (joke)
Back to top
Profile PM Email Website
Diggsey
18
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 13th Oct 2009 00:12 Edited at: 13th Oct 2009 00:13
Link
Assembly is good for a number of reasons:

- Making a compiler (you need to convert code to assembly)
- Making a VM like java (you need every bit of speed you can get)
- Making an OS or driver software (some things can only be done in assembly)
- Debugging without symbols (the only info you get is the assembly)
- Learning (it teaches a lot about how computers actually work)
- Debugging very complicated problems (sometimes you need to see what is happening instruction by instruction)
- Fun (some people may disagree)

So it hasn't quite been replaced by C (Especially seeing as C++ is probably more common than C now)


New DBPro IDE + integrated debugger!
Back to top
Profile PM Email Website
alec the lion
18
Years of Service
User Offline
Joined: 14th Jun 2006
Location:
Posted: 13th Oct 2009 10:20
Link
Hey guys, Been away an awful long time; but I have not stoped using darkbasic.

The main, really big problem I have with it lies with "files"

1) We cannot write to files that exist (else the command fails)
2) We (therefore) can't Append to the end, or overwrite parts of the file
3) We cannot use it's pointer.
4) Reading them is done line by line.


I've found no way around this yet, but DarkBasics File support is Awful. I have had many projects die at this supposedly simple problem,

Another thing which you have mentioned and I will back you up on is that:

You can only return one generic type back from a function (string, float, integer) and type or array support would be very much apreciated over here


Back to top
Profile PM Email
Van B
Moderator
22
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 13th Oct 2009 10:35
Link
Sounds to me like your after binary access to the file. To be honest I avoid that in all languages so have no idea what DBPro is like for it.

But there are some more in-depth features through memblocks, I know people hate the word work-around, but really making your own file access system via memblocks might be worth your while.


Health, Ammo, and bacon and eggs!
Back to top
Profile PM Email
Creating Game
16
Years of Service
User Offline
Joined: 21st Oct 2008
Location:
Posted: 13th Oct 2009 16:57
Link
Why you should spend time learning the more sophisticated and complex modern programming languages when you can spent your time thinking about workaround to exploit DBP limitations?
Back to top
Profile PM
Linehan
15
Years of Service
User Offline
Joined: 13th Oct 2009
Location: Salem, MA
Posted: 13th Oct 2009 18:05
Link
These are all valid points and indeed drawbacks for some of the more advanced coders out there. However, as others have stated; I use DBPro as sort of a hobby language. I do quick fun things with it and no seriously major projects thus far. If I were going to make something with the potential for commercial development I am not sure what language I would use. Having said that, I just wanted to say that I do love DBPro. I have spent a large amount of time and money on TGC products, so I would very much like to see it grow and develop more advanced features but only as long as it remains DarkBASIC because I enjoy BASIC.

I like the idea of being able to develop for web applications though.

Linehan
Back to top
Profile PM Email Website
the_winch
21
Years of Service
User Offline
Joined: 1st Feb 2003
Location: Oxford, UK
Posted: 13th Oct 2009 20:30
Link
Quote: "The main, really big problem I have with it lies with "files""


The Matrix1Utils plugins collection

By way of demonstration, he emitted a batlike squeak that was indeed bothersome.
Back to top
Profile PM Website
KISTech
16
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 13th Oct 2009 20:42
Link
Remember random access files?

Set up the fields and their lengths and then just read or write a line by it's number? That kind of file access would be great to have back.

Back to top
Profile PM Email Website
Van B
Moderator
22
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 13th Oct 2009 20:56
Link
Quote: "Why you should spend time learning the more sophisticated and complex modern programming languages when you can spent your time thinking about workaround to exploit DBP limitations?"


We're making games, not databases

DBPro has plenty of options for saving game data, personally I always use script type formats, so they can easily change as needed. If you read and parse whole strings and contain the data inside a set format, you can tokenize and do all sorts of things with that data. File size is hardly an issue, media file sizes always outweigh game data many times over. I find it's the neatest way to mix numeric and string data, so I just don't miss the binary file commands, I only ever used them as an alternative file copy when the standard command fails in the most widely used basic out there.


Health, Ammo, and bacon and eggs!
Back to top
Profile PM Email
Ermes
21
Years of Service
User Offline
Joined: 27th May 2003
Location: ITALIA
Posted: 13th Oct 2009 21:15
Link
the only problem of dbpro is SPEED, it is a basic language, and it is slow, i don't mind how i've to declare a variable or the sintax of a command, but i would like to have a very fast language, and dbpro isn't fast at all. either way, it's very easy to learn.

ciao faccie da sedere!
Back to top
Profile PM Email Website
Steele
21
Years of Service
User Offline
Joined: 25th Oct 2003
Location: Somewhere over the rainbow
Posted: 13th Oct 2009 23:13
Link
Quote: "Remember random access files?

Set up the fields and their lengths and then just read or write a line by it's number? That kind of file access would be great to have back.
"

See Dark Data.

On a serious note: DFS stands for Dynamic File System. Some like to use the word "Dynamic" while others "Random". Anyway, it is based on that and you don't have to use KFS (Keyed Filing System) if you don't want the indexing capabilities. Anyway, that was why I wrote it because DBPro didn't have it.

It's a thought although I wasn't trying to plug, just that the thought was the same as mine way back when.

Steele

http://www.lanningsoftware.com
Your source for Games and Entertainment
Back to top
Profile PM Email
Digger412
17
Years of Service
User Offline
Joined: 12th Jun 2007
Location:
Posted: 14th Oct 2009 00:21
Link
Quote: "We're making games, not databases "


Umm...I'm actually working on a database for a teacher..so..
Back to top
Profile PM
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 14th Oct 2009 07:25
Link
Ermes hit the nail for me. Because DBP was made with a lower level language, it natively suffers from speed issues.

Optimization is key to getting the most speed out of anything.

The command set for DBP may not be as optimized as you would like, but you'd be stuck with them and dealing with their drawbacks, unless you went down a level and used C++ to work out better optimization methods. However, it's the same with C++. Those commands (even the most simplistic core commands) may not be up to your optimization par, and you would have to go down another level and use assembly.

At the very least, we're given the option to use DGDK, which would allow us to use the DBP commands when we WANTED to and wouldn't force us to.


The one and only,


Back to top
Profile PM Email
dark coder
22
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 14th Oct 2009 07:47 Edited at: 14th Oct 2009 07:51
Link
Quote: "Ermes hit the nail for me. Because DBP was made with a lower level language, it natively suffers from speed issues."


What?


Quote: "However, it's the same with C++. Those commands (even the most simplistic core commands) may not be up to your optimization par, and you would have to go down another level and use assembly."


What?

The ratio of issues with these statements to sentences is quite impressive. The compiler being written in C++ doesn't mean any language written using it will have speed issues, if anything, it guarantees that you could make it very efficient because of the amount of low-level access you're given. Perhaps you're confusing DBPro with some type of byte-code interpreter, but even then, being C++ only means you have access to the facilities to make it as optimized as you want, especially since most(all?) C++ compilers these days allow inline asm.

Furthermore, many C++ compilers have been in development for over a decade and have implemented some very advanced optimization techniques, you'd have to be an expert at a given CPU architecture and have a lot of free time to be able to optimize any code to any significant amount, and I imagine most of the time you could optimize the C++ code itself by knowing what the compiler does and coding a certain way.

So many parts of DBPro could easily be optimized: addition of floats calls a function, what?, casting calls functions, what?, why does almost everything call a function?, why are error messages checked for after statements that cannot fail? etc etc. But as I've said before, this topic is about the core language thus speed issues, bugs etc aren't the focus here.

Back to top
Profile PM Email
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 15th Oct 2009 04:56 Edited at: 15th Oct 2009 05:01
Link
I was trying to say that unless you recoded the way the DLLs function or how the compiler assembles everything, you're stuck with how the developer made it.

Quote: "addition of floats calls a function, what?, casting calls functions, what?, why does almost everything call a function?, why are error messages checked for after statements that cannot fail?"


Obviously, DBP is not coded to your optimization standards. So unless you were to recode how everything functioned, you're stuck with it until the developers change it.

I attribute some of the speed issues to the language's shortfallings. Because of limitations in how we may code our applications, we're sometimes forced to use workarounds that are not as optimized as they could have been, making our programs run at a less than intended speed.

Quote: "The compiler being written in C++ doesn't mean any language written using it will have speed issues, if anything, it guarantees that you could make it very efficient because of the amount of low-level access you're given."


If we're given such low-level access then shouldn't we be able to execute inline asm in DBP since it was made in C++? Or maybe declare arrays in our UDTs? Or perhaps stream files, pass UDT declared variables to/from functions, or even declare option explicit (not a C++ thing, but C++ does it without being told to)?
(Seriously, if we can, let me know. I would rather be corrected about my assumptions.)

You got me there with C++ being able to execute inline asm. I did not know it could do that. So, allowing the programmer to utilize the language that the compiler/language itself was written in, you're pretty much given the entire world on your plate. However, DBP does not allow for inline C++ statements or asm code as far as I am aware (but as you probably guessed by now, I am not aware of much )


Sorry for the short reply. I had much more typed up, but the internet cut-out as I hit the post button...


The one and only,


Back to top
Profile PM Email
dark coder
22
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 15th Oct 2009 06:43
Link
Quote: "I was trying to say that unless you recoded the way the DLLs function or how the compiler assembles everything, you're stuck with how the developer made it."


Why? We're talking about compiling EXEs here.


Quote: "Obviously, DBP is not coded to your optimization standards. So unless you were to recode how everything functioned, you're stuck with it until the developers change it.

I attribute some of the speed issues to the language's shortfallings. Because of limitations in how we may code our applications, we're sometimes forced to use workarounds that are not as optimized as they could have been, making our programs run at a less than intended speed."


See above.


Quote: "If we're given such low-level access then shouldn't we be able to execute inline asm in DBP since it was made in C++?"


No, because we aren't given low-level access. My point was that the language a compiler is written in is largely irrelevant; you could write a compiler in DBPro(with great difficulty due to the poo file commands) that generates EXEs that are twice as fast as DBPro ones and contains far more features, including inline asm, proper OOP, dynamic typing, etc etc, you could even generate an OS.

Back to top
Profile PM Email
Visigoth
19
Years of Service
User Offline
Joined: 8th Jan 2005
Location: Bakersfield, California
Posted: 15th Oct 2009 08:19 Edited at: 15th Oct 2009 08:41
Link
ok, I want to address DC's original post, line by line

1. Arrays in UDT's
yes, this would be quite handy, and I agree. However, it is up to the creators to implement. A feature, not a limitation, I would say.

2. Return a UDT from a function
Since a UDT is global, I see no need for this. For this to work, you would also have to pass in a UDT. Which is complaint number 4. I was taught early on to not have many, if at all, globals. So, I can understand this. However, it doesn't stop the program from running. A feature, in my opinion.

3. Global vars not initialized until run :
So what? its a rule of the language. Not a big deal, in my opinion.

4. pass UDT data from an array to a function
This is the opposite of number 2. If you can't return it, surely you can't pass it. It is solved in the language by making UDTs global. Some comments in the function can instruct the user to make the type global. This is the current method to overcome this.

5. Lack of else/ifelse



wouldn't this work?:


6. Inability to do complex statements on 'exitFunction'/'endFunction'

I happen to agree on this, but, this is a VERY simple workaround. Do the calc before you exit, and assign the result to the output of the function.

7. No function overloading
Far as I can tell, this is not even a feature of Visual Basic. Correct me if I am wrong.

8. Lack of option explicit
I thought this was IDE specific, not compiler specific.

9. Vectors and matrices aren't basic types
Well, I have to assume he is right here, I don't mess with these datatypes too much.

10. No references
Again, this can also be worked around, by simply making a copy of the original data in the array or UDT. However, I agree, it is a nice feature to be able to access the core data or the copy. This is one of the nice things about OOP programming.
edit:
well, actually, it can't be worked around. You can't change the source and have it update the copies in DBPro, not anyway I can think of. So, this would be nice, but, like I said, its more an OOP kind of thing, I think.


Seems to me, DC has learned the value of OOP, and, wants to apply it to procedural programming.
Back to top
Profile PM Email
Alfa x
18
Years of Service
User Offline
Joined: 1st Jul 2006
Location: Colombia
Posted: 15th Oct 2009 08:39 Edited at: 15th Oct 2009 08:40
Link
Quote: "10. No references
Again, this can also be worked around, by simply making a copy of the original data in the array or UDT. However, I agree, it is a nice feature to be able to access the core data or the copy. This is one of the nice things about OOP programming."


I wil not discuss all your points because I don't have much time

OOP???. OOP is based in references, but they are the base for that. References can be used without OOP.
Work Around making a copy???. Just imagine a game with 400 players, each player needs a separated UDT depending on circumstances. How you could access each UDT in a function,insert at bottom individually (Since they have different information) and return its values without indexing and a HUUUGEEE array copy????......

That's not a work around, that ruins the performance of a game...
Back to top
Profile PM Email
Visigoth
19
Years of Service
User Offline
Joined: 8th Jan 2005
Location: Bakersfield, California
Posted: 15th Oct 2009 08:42 Edited at: 15th Oct 2009 08:44
Link
yeah, I know. I just realized my mistake, and edited my post.
I agree, it would be nice to access the source, and have it update all the copies, but, this is instantiation. This is an OOP concept.
Back to top
Profile PM Email
Kira Vakaan
15
Years of Service
User Offline
Joined: 1st Dec 2008
Location: MI, United States
Posted: 15th Oct 2009 08:47
Link
Benjamin said this in the fourth post of this thread:

Quote: "Wonderful post, now let's place bets on how many people post things such as "you can create workarounds for all these things" and "these don't stop you from creating a game", completely missing the point of this thread."


I'm sure someone's sitting on a bit of money by now.
Back to top
Profile PM Email
Back to top

Login to post a reply

Server time is: 2024-11-23 05:28:23
Your offset time is: 2024-11-23 05:28:23