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.

Author
Message
Sepnon
16
Years of Service
User Offline
Joined: 7th Feb 2010
Location: Brazil
Posted: 15th Mar 2013 17:40
Is there a way to know if a vector2 already exists? i didnt find a command to do so
Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 15th Mar 2013 19:34
Vector Exist()

This is the same method for all vectors.

Sepnon
16
Years of Service
User Offline
Joined: 7th Feb 2010
Location: Brazil
Posted: 17th Mar 2013 20:31
:o wierd, it doesnt compile here.. u sure it isnt from a plugin or something? i use dbp v1.0761

and if i make it work, are all vec2 vec3 and vec4 indexed in an unique group?
Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 17th Mar 2013 20:47
I'm so sorry, did not realize it was part of Matrix1 utilities.

I highly recommend installing it because it adds many essential commands.

Sepnon
16
Years of Service
User Offline
Joined: 7th Feb 2010
Location: Brazil
Posted: 17th Mar 2013 21:02
oh, well.. that's bad, dbp sounds like an uncomplete pack without it directly i'll have to install that plugin then
i usually dont like installing plugins because when you deploy your application (never reached that point, but u know.. ), the client gets some unused data on the additional exe / dlls sizes

but its ok.. thanks!
Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 17th Mar 2013 23:08
DBP is plugin orientated, it gives you the responsibility for choosing what features you want. A bit like instruments in music software, the user adds what they need for the product; so it's not such a bad thing really; , which is pretty much how Microsoft's development framework works; you put the features and assemblies you want in your product.

Matrix1 however, as stated by the creator adds what should have been created originally, plus more...

When you release your game, 9 times out of 10 people will not need any additional Dlls.

Sepnon
16
Years of Service
User Offline
Joined: 7th Feb 2010
Location: Brazil
Posted: 17th Mar 2013 23:41
yeah yeah, but i meant is that if i use 1 command of an dll, i have to release the whole dll with the game, including the other functions that i dont use on it!
please correct me if im wrong, but it doesnt seem very "professional" that way (?)
Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 18th Mar 2013 01:19 Edited at: 18th Mar 2013 01:30
There are many ways to consider that point. Referencing dlls/includes/assemblies is quite traditional in most programming languages, and sometimes just for a one or two functions. At least in DBP plugins you get helpfiles, in some development kits the only help you get are function and parameter names.

On one hand the plugins should be designed to be useful; therefore to only use a few of the functions within a hundred would reflect a somewhat useless plugin; and I am sure you will be using many Matrix1 functions in future; functions like Max/Min, Call Function Ptr/Name and Get Limb Name and RGB (with alpha channel reference) are a few Matrix1 functions you'd likely find useful in many situations; and these just scratch the surface.

Another thing is, sometimes one or two functions are extremely important.

Would it be a good thing to have all functions as part of the DBP standard package without extra DLLS? I personally do not know. Would it be good to have all the 'useful' functions included as standard; now that wouldn't be realistic because what is useful for one person is useless for another.

With that said, probably Matrix1, Sparky's collision and A2D should be part of the standard package because it is highly unlikely for anybody to argue that these three are the most important DBP plugins for most projects; some may prefer D3D Func over A2D, some appear to think installing Matrix1 is not going to benefit them; and there are alternatives to Sparky's collision. Personally I use Dynamix (PhysX) for collision but still end up using Sparky's for simple purposes.

With vector exist, that should have been put in the standard package; but the creator of DBP is quite occupied with FPS Creator Reloaded; things like DBP commands are probably at the bottom of the list, although FPSC is created in DBP, perhaps we might get more commands this year.. who knows.

I personally wouldn't worry about file size or dll installations. In this broadband high speed internet age, even if you optimize; people will still complain about your file size, then they will spend the rest of the evening watching 1 GB worth of YouTube videos and will install a million DLLs without realising it throughout the course of their lifespan.

Andrew_Neale
16
Years of Service
User Offline
Joined: 3rd Nov 2009
Location: The Normandy SR-2
Posted: 18th Mar 2013 09:50
When you say you have to release the additional DLLs with the application, whilst technically true, this doesn't mean they'll be sat in the folder so that users of the application will know they are there. It is all compiled into the application itself. So yes, using just 1 command from a plugin will cause your application to be a few kilobytes bigger but it isn't realistically an issue.

As pointed out above, this particular command would absolutely have been nice to be included in the core DLLs, but it doesn't prevent you from doing anything as you can very easily track the usage of vectors yourself (which you should be doing with all assets such as objects and sprites etc. anyway), and with a free plugin adding the functionality already, I can certainly understand why Lee hasn't given it a huge priority. It may well be that his work on DBP for FPSC Reloaded will include some small tweaks like this though, which is admittedly of little use at the moment.


Previously TEH_CODERER.
Sepnon
16
Years of Service
User Offline
Joined: 7th Feb 2010
Location: Brazil
Posted: 19th Mar 2013 11:39
hmm indeed it is not reeally an issue, its just that im wondering if big games like, idk, battlefield or nfs have this kind of unused data.. i am being a bit (prissy ?) here

and isn't having to load an dll to call a function slower? i'm trying to make an 2d physics controller on dbpro directly, hope it works fast enough.. i made some few tests and realized that with the functions tested, vector2s are around 20% faster than creating a new type with x and y. What annoys me is the fact that the "assembler code" the processor runs this way has too many jumps or unneficient/unnecessary parts!

but well, problem solved, ty guys

(always say this.. sry for bad english)
Brendy boy
20
Years of Service
User Offline
Joined: 17th Jul 2005
Location: Croatia
Posted: 19th Mar 2013 19:13
Quote: "and isn't having to load an dll to call a function slower?"

you don't have to load a dll and call a function. All dlls are placed in a compiler/plugins folder and all the functions inside them are dbpro's commands.

When you type load object command you are actualy calling basic3ddebug.dll from plugins folder of dbpro.

All dbpro commands are dll functions. Only commands like if, then, type, while etc. are coded inside dbpro compiler, everything else are just dll functions

Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 19th Mar 2013 20:35 Edited at: 19th Mar 2013 20:38
Additionally most windows based software; which includes the engines you mentioned require DLLs to work, whether third party or internal.

Calling a plugin or DLL function is not slower; as a near enough valid example, somewhat irrelevant in view of Brendy's point about most commands being in one way or another DLL commands anyway; the native Left$() command returns the left most text of a string given the length parameter; however the Matrix1 plugin alternative is faster; hence its name, Fast Left$(). Ironically, most of the 'successful' plugins where created to speed up DBPRO, not slow it down.

So go ahead and install as many plugins as you wish . I install them all because they are good products that will improve my product (except Darks Clouds, Extends and Dark Ink and 2D Kit and a number of third party solutions in my case for one reason or another).

Sepnon
16
Years of Service
User Offline
Joined: 7th Feb 2010
Location: Brazil
Posted: 20th Mar 2013 14:04 Edited at: 20th Mar 2013 14:05
@brendy im not talking about the load dll dbpro command, im just talking about how the compiled .exe works!

@chris i do use plugins and i love them too man but lemme try to explain my point..
imagine the INC command. The best way a computer could run it is with a single assembler instruction, right? so anything more than just that is "slowing it down" to me, and doing it with dlls adds some jumps to the process. looks like the proc spends more time jumping than just adding!

besides, i think i saw some time ago an program that took an dbpro compiled exe and extracted the code from it; is dbpro interpreted? and what about dgdk?

i know that dbpro is not the most efficient language in the world and the fact computers are so fast nowadays makes that not being really an issue, but i'd love to have some parts of my code optimized
Brendy boy
20
Years of Service
User Offline
Joined: 17th Jul 2005
Location: Croatia
Posted: 20th Mar 2013 14:54
Quote: "@brendy im not talking about the load dll dbpro command, im just talking about how the compiled .exe works!"

still, my explanation is correct. 99% of commands are plugin calls so using aditional plugins you're not adding any more slowdown to your app

Quote: " i think i saw some time ago an program that took an dbpro compiled exe and extracted the code from it; is dbpro interpreted?"

doesn't exist, it is not interpreted. Dark GDK is also not interpreted

Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 20th Mar 2013 20:01 Edited at: 20th Mar 2013 20:05
Quote: "imagine the INC command. The best way a computer could run it is with a single assembler instruction, right?"


I think that INC and DEC are not 'commands'; I think they are 'unary operators'; not quite sure of the term to be honest; just a wild guess. I am guessing that INC is not quite in the same category as a function such as ABS (which is an expressive function), based on my 'benchmark' tests, INC is as fast as a mathematical addition (EG:v=v+1), so the lack of speed difference indicates this likely hood.

Or perhaps my statement is invalid, because I am not sure there is a difference in the speed of calling a DLL function and not; since a function is a function; it has a pointer in RAM that links to instructions; why should this be different? Once a DLL is loaded into the executable, is there really a difference between any of the functions as far as a machine is concerned? Regardless of what language it was when compiled or interpreted. Isn't every executable written in the same language when residing in physical memory?.

This is above my grade of knowledge to be honest.

Sepnon
16
Years of Service
User Offline
Joined: 7th Feb 2010
Location: Brazil
Posted: 25th Mar 2013 17:26
Quote: " since a function is a function; it has a pointer in RAM that links to instructions; why should this be different? Once a DLL is loaded into the executable, is there really a difference between any of the functions as far as a machine is concerned? Regardless of what language it was when compiled or interpreted. Isn't every executable written in the same language when residing in physical memory?."

indeed, good point

it is above mine too! i just wondered why is then gdk faster than dbpro, if they have the same dlls? there must be a significant difference.

i also dont know why using a type with x and y works slower than doing the math with vector2s.

but nevermind, i'm going waay too deep for my needs. I guess I'd need to learn how dlls are loaded and executed to answer those questions and that information wouldn't be really useful..

a last question; that function suggests that vector2s and vector3s are indexed together on dbpro internally? (having access to dbp internals seems fun )
Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 25th Mar 2013 18:46
I'm guessing Lee is storing them in separate arrays and has an internal array that links to them per type. I didn't think Types where slower than Vectors; since their is that internal check to see if vectors exist.

Brendy boy
20
Years of Service
User Offline
Joined: 17th Jul 2005
Location: Croatia
Posted: 25th Mar 2013 22:08
Quote: "it is above mine too! i just wondered why is then gdk faster than dbpro, if they have the same dlls? there must be a significant difference."

they dont't have the same dlls. Dark basic pro is a collection of dlls, dark gdk is a collection of c++ libraries. They both call functions from directx dlls.
C++ compiler is more optimized than dark basic pro's compiler so dark gdk apps can be a little or more faster, it depends on the app

Login to post a reply

Server time is: 2026-07-07 06:24:35
Your offset time is: 2026-07-07 06:24:35