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.

Geek Culture / views on DarkBasic...

Author
Message
Ilya
21
Years of Service
User Offline
Joined: 10th Aug 2003
Location:
Posted: 29th Nov 2004 03:15
Quote: "or an option to define a 2D box on the screen and test to see if an object is rendering to that area..."




Quote: "I've seen the word programming and I'm not sure what it means. Anybody please explain?"


Quote: "We shouldn't sacrifice the truth to preserve "balance"."
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 1st Dec 2004 02:04
*bump*


Neophyte
21
Years of Service
User Offline
Joined: 23rd Feb 2003
Location: United States
Posted: 1st Dec 2004 15:41
@Raven

Are you happy with the executable size?

No. It should be smaller.

Do you like having the Runtime Library or prefer a Linker Style Library?

Both. Runtime for Debug mode(quicker builds) and Linker Style for final exe build.

Do you want to see Object Orientation, and if so.. how?

Not really no.

Do you prefer the Rotation Commands in DarkBasic v1.0 or Professional?

Since I've never used the original DarkBasic I can't really comment.

Would you like to see a Pixel Perfect Collision Engine?

No, but it would be nice.

Is Real-World Physics important to your games?

Not currently, but it would be a welcome addition. But only if it is as easy to implement as the existing collision system.

Would you like to have direct access to the Rendering pipeline?

I'd like the option.

Some other points:

ElseIf support.

Expressions in Select statements like UWDesign suggested.

Expanded type support. Arrays in types.

Not sure if this counts, but better TPC support. You shouldn't have to work around not being able to pass back a float normally. It's returned in ST(0) just like how integers are returned in EAX. Why DBPro can't handle this, I don't know. Returning a string pointer should be no big deal either. I know that DBPro handles strings internally, but it shouldn't be difficult to add code after the function to take the string pointer out of EAX and pass it into DBPros internal string handling routines. However, I do like the way string tables are used to allow the compiler to figuare out what needs to be passed to the function. Quite clever really.

Also, make memblock shouldn't need an index number. It should just return a pointer. It's redundant to have to come up with a unique index number when a unique number can be easily returned. The pointer.

Better pointer support as well. I prefer the old fashioned BASIC way of using pointers to mess with data via Peek and Poke. But if you must have a symbol for the operator, please, use something other than * like C++ does. I've always found that confusing, especially when I was first starting out. To fetch a pointer you should just use the @ symbol like in purebasic. Makes more sense than the * way since @ means "AT" and a pointer tells you where a variable is AT in memory.

Static arrays. We can get the pointer to them and fiddle with them if we want to that way.

Pointers to functions. We can then use them in a CALL FUNC kind of function the same way we have a CALL DLL function. This would open the door way to a puesdo-function overloading way of programming. EX: you can have different AI functions for different bad guys stored in an array. When you cycle through the array you could just pass in the pointer for the baddies AI func to a single CALL FUNC function and fire away. This would beat having to pass in some kind of flag to a switch case statement just to get to the appropiate function. Saves time. Easier to use.

Plus, (I can't believe this hasn't been mentioned yet) option explict and option strict. If option strict is included, have some standardized way of converting types. A intrinsic float2int kind of function would do nicely for coverting floating point numbers to integer. Since there are multiple different round modes out there to use(some of them substantially faster than others) you could include a flag with the float2int function to tell the compiler which method to use.

I've touched on this before many times, but some kind of way to force an object to be rendered prematurely. Like a FORCE DRAW command. The current DBPro way of rendering things is quite inefficent. Graphics cards like it when you send stuff in little chunks and DBPro sends all of your objects in one whole mega chunk. One user even timed his game to see where most of the time is spent(I think it was Walaber) and found out that 90% of the time was spent in the sync command!

Debugger. Nuff said.

On the lighter side...what I thought was good(w/minor cavets):

Case-insenstive keywords. When I started out programing I started on C++ with it's case-sensitive internal functions(strcpy, etc.). It was incrediably annoying to just finish a function name and realize you missed a capital. They only thing I wish DBPro would improve on in this regard is if it made all variables and arrays and functions case -insensitive like Basic4GL. There really is no reason not to adopt this.

The simplicity of the Sync command. Although it is a little inefficent, when you are first starting out, it sure makes things simple.

Compiling small programs relatively quickly. When I started with C++ compiling stuff took a few seconds. With DBPro it seemed to happen almost instantly. The make-little-changes-and-test approach really benefits from a quick compile time.

Kick a$$ string handling routines. Clearly superior to C++'s string handling routines(though pretty much every BASIC's string handling routines are).

By far the best thing about this language though is the ease of which you could start programming. When I started programming I started on C++. It was difficult to figure out what did what and most importantly why it did it. I was reading out of one of those "Learn C++ in 21 days books" which happen to be mammoth(and I later learned were not very good at teaching you C++) and all of the crap that comes with C++ was just overwhemling. For a newbie, learning the basics of programming(loops, functions, logic, etc.), Object oriented programming(classes, inhertiance, polymorphism), and other crap that was beyond me(templates, why?) it was just too much. I tried for months to figuare it out and I think I made some good progress. But then I found out about DBPro. DLed the trial, started it up, and I swear I learned the language in a matter of days. It was mind blowingly easy.

Later on I learned the rationale for a lot of the stuff in C++, but if it wasn't for DBPro I probably would have given up on programming. With C++ I was bored out of my mind and frustrated. Typing in line after line of redundant code and characters(I now offically hate { and } by the way) chipped away at my patience. With DBPro, I felt I could do anything...and quickly. That's a pretty good feeling to have when you are a beginner. Anyway, I'm rambling. I'll stop now.
GothOtaku
20
Years of Service
User Offline
Joined: 23rd Nov 2003
Location: Amherst, MA, USA
Posted: 2nd Dec 2004 02:22
Quote: "
Expanded type support. Arrays in types.
"

Dear God please, this has been the one thing that's annoyed me to no end.

Quote: "
Better pointer support as well. I prefer the old fashioned BASIC way of using pointers to mess with data via Peek and Poke. But if you must have a symbol for the operator, please, use something other than * like C++ does. I've always found that confusing, especially when I was first starting out. To fetch a pointer you should just use the @ symbol like in purebasic. Makes more sense than the * way since @ means "AT" and a pointer tells you where a variable is AT in memory."

Since it's in there already I think it'll stay as * but I'd prefer if it was like how they're represented in Pascal and Modula with pointers being explicitly declared like 'x as pointer to integer'.

Quote: "
Pointers to functions. We can then use them in a CALL FUNC kind of function the same way we have a CALL DLL function. This would open the door way to a puesdo-function overloading way of programming. EX: you can have different AI functions for different bad guys stored in an array. When you cycle through the array you could just pass in the pointer for the baddies AI func to a single CALL FUNC function and fire away. This would beat having to pass in some kind of flag to a switch case statement just to get to the appropiate function. Saves time. Easier to use.
"

This would also be very usefull so that those who want object-orientation can hack it in themselves.


Quote: "I've touched on this before many times, but some kind of way to force an object to be rendered prematurely. Like a FORCE DRAW command. The current DBPro way of rendering things is quite inefficent. Graphics cards like it when you send stuff in little chunks and DBPro sends all of your objects in one whole mega chunk. One user even timed his game to see where most of the time is spent(I think it was Walaber) and found out that 90% of the time was spent in the sync command!"

Yes, a FORCE DRAW command would be very, very useful.
Peter H
20
Years of Service
User Offline
Joined: 20th Feb 2004
Location: Witness Protection Program
Posted: 2nd Dec 2004 03:19
Quote: "Aren't 'object screen x()' and 'object screen y() good enough for you then?

I think that is called Sarcasm

No, I think he actually didn't know about those commands.

So he really meant DBP needs better docs, so he can find those commands, and perhaps a usage example."








LOL...i sure wish i had known about those commands earlier!!!!

Thanks guys! that takes a huge load off my shoulders

lol

"We make the worst games in the universe."

BearCDPOLD
20
Years of Service
User Offline
Joined: 16th Oct 2003
Location: AZ,USA
Posted: 2nd Dec 2004 09:31
*Are you happy with the executable size?
Smaller please.

*Do you like having the Runtime Library or prefer a Linker Style Library?
Don't know.

*Do you want to see Object Orientation, and if so.. how?
I think I know what you are talking about. How about a flag when using rotation commands 1=object orientation, 0=global orientation.

*Do you prefer the Rotation Commands in DarkBasic v1.0 or Professional?
No experience with DBPro.

*Would you like to see a Pixel Perfect Collision Engine?
That'd be cool. But I've already got NG.

*Is Real-World Physics important to your games?
Yes, but we've already got Tokamak/Newton.

*Would you like to have direct access to the Rendering pipeline?
Just for timing.

Need:
Array types
3d lines
3d markers (invisible points in 3d, think like Blitz's pivots)
parent/child objects

Crazy Donut Productions, Current Project: Project Starbuks
Sony stole our name!
OSX Using Happy Dude
21
Years of Service
User Offline
Joined: 21st Aug 2003
Location: At home
Posted: 2nd Dec 2004 17:25
Now that DarkSDK has come out, for those who can use C, most of the problems are sorted... For those who cant, its unfortunately a matter of waiting

Walk softly... and carry a big gun...
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 2nd Dec 2004 19:07
Perhaps.. most of us have had the chance to use other languages with DarkBASIC Professional for quite a while.
I actually have a full Control Linker (Wrapper) for it currently for .NET languages, but the question to if we're allowed to still use that is probably a no.

The reason I'm more interested about DarkBASIC Professional problems and achievements is because, the reason I like to use DBP is because it is more straight forward to use.

In Visual C#, I'm constantly having to worry about what source is doing what; if I've set something up then coding up the engine to do what I want it to. Mostly it is the Syntax though, it just seems easier and I have no idea why.

Perhaps because it is more English based, so it is more like making sentances to program than structuring equasions.

While Dark Game SDK does really help those who want to program outside of DarkBASIC Professional, from my perspective using it would be a step in the wrong direction.
(that and I already paid a license for Renderware, might as well use that first heh)

Sure it solves all of the languages problems, but it also has shown us something quite worrying.
Framerates simply by moving language from DarkBASIC Professional to C++ in most cases triple, which means that the engine is relatively efficeint, it is DBP that isn't.

Hopefully the change will have Lee program Update 5.x / 6.0 compiler to utilise linking so we too can benifit from the much smaller compiled executables.

They key issues with DarkBASIC Professional however, are still going overlooked for the time being though.

From my perspective:

Floating Point Numbers need to be fixed
-

Pointer & Address Access
-


Data Bytes (So we can creat Recast functions)
-


More Type Access & Abilities
-


just some basic core language changes, but they would really add so much freedom.
I'm also a little conserned about not declaring Function Types, i think adding As ... to the end of the function declaration would really help, because it would help to declare them as customtypes. After all, everything that is happening is just a pointer anyways, that much is painfully obvious to just about everyone in depth with the language.

This said I would love to see built-in type casting for the basic types.

String( myVariable ) ... or Integer( myVariable ) ... or Byte( myVariable ), while you have the String and Integer ones already; STR$() and INT() seem a little backward compared to the rest of the command structure. Everything else has a descriptive name yet those have 3 letter names.


adr
21
Years of Service
User Offline
Joined: 21st May 2003
Location: Job Centre
Posted: 2nd Dec 2004 20:37
I'll be a bit of a rebel here and not answer all of your questions, but make a couple of suggestions.

*I personally don't have a problem with the exe size. Yeah it's a pain in the arse, but if you have a choice between compile times, and exe size, I'm gonna pick shorter compile times and balls to the exe size.

*to all the people who want pixel perfect collision - buy a 2D specific engine. I know it sounds narrow minded, but the only 2D games coming out now (that I care about) are console/handheld/mobile games, and DBP doesn't cross compile ... so that's that one shot out of the sky.

*Although I agree OO would be nice, it's not essential if we're honest. Fix up passing by reference and arrays in types the other stuff and you're a good step closer to a solid language that doesn't need OO.


How good is your game? - Billy Paul

Login to post a reply

Server time is: 2024-09-23 02:33:51
Your offset time is: 2024-09-23 02:33:51