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 / Dark Basic Pro Performance benchmark

Author
Message
Juggernaut
14
Years of Service
User Offline
Joined: 12th Mar 2012
Location:
Posted: 21st Mar 2012 12:15
Hello,

Is there any benchmark record of the speed performance of Dark Basic Pro as compared to game written using C++ and DirectX ?

How does Dark Basic Pro compare in comparison to Python,Java,JavaScript,LUA etc. which are used in many other free opensource game engines.

Thanks,
mr Handy
18
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 21st Mar 2012 12:29
I only know that C++ is faster in a special way as it can provide low-level access to do some hard math or buffer operations.
JRH
20
Years of Service
User Offline
Joined: 8th Jul 2006
Location: Stirling, UK
Posted: 21st Mar 2012 13:07
These days I'd say what matters most is the engine itself, rather than the language it was created in or the capabilities of the hardware it runs on.
Van B
Moderator
23
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 21st Mar 2012 13:46
C++ allows for better culling and mesh control which can make a big difference to performance. For instance, instead of making the whole terrain, in C++ you could make a 'live' mesh, and add polygons as you go, so only show the polygons that are visible.

The flip side of the optimisations though is the extended development time - often our game projects are humble in what they need from an engine, so sticking with DBPro is more productive than starting from scratch - even with a pre-built engine DBPro is still about as fast a development cycle as you'll ever get, besides maybe Unity or Unreal, which are aimed at creating a particular game anyway... by that I mean if your making anything other than a FPS, your better off with a language like DBPro or C++.

Health, Ammo, and bacon and eggs!
Juggernaut
14
Years of Service
User Offline
Joined: 12th Mar 2012
Location:
Posted: 21st Mar 2012 15:10
Hello VanB,

How does Dark Basic Pro fare in number crunching or mathematical computing - is it as good as C++ ?

Thanks,
Fallout
23
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 21st Mar 2012 15:34
Quote: "How does Dark Basic Pro fare in number crunching or mathematical computing - is it as good as C++ ?"


Nowhere near as fast, hence the introduction of DGDK. But on the flip side, when I want to concatenate strings together in dbp, I go newstring$ = string1$ + string2$ + str$(anumber) + "fred" + " isn't this easy?". In c++ you have to decide is you're going to use char*, String, other constructs/classes, choose how to copy them, concatenate them, free up resources, scratch your head for half an hour, try to functionalise it all and then decide on pointers to pass, have a cup of tea, and then before you know it, you've passed out and your face down drooling onto your keyboard. It's a different story for C++ pros obviously, but it's a harder slog.

As with all these tools, it's speed vs convenience. You have to find your preferred balance. If I'd started with C++ & DirectX, I don't think I'd be developing games now.

Van B
Moderator
23
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 21st Mar 2012 16:07
Yeah, C++ is a lower level language than DBPro, meaning C++ code is closer to machine code, the closer you get to machine code the faster your code... wish I knew some machine code to explain, but this is kinda what the compiler does:

DBPro:
X=X+1 or inc X,1
So X is a variable, replace it with an internal variable address, then parse the equation and figure out how X changes. Then apply that to the variable.

C++:
X++; or X+=1;
So X is a variable, replace it with it's pointer before building the executable, work out the equation and apply it.

Assembly language:
push x
add x,1
Gimme X and add 1, do it now!

Then machine code is basically the raw instructions based on the wordier assembly language - Assembly is like human readable machine code.

The closer you get to machine code, the more complex memory management becomes, the more you have to rely on other programmers for libraries and engines, and guarantee'd that your hair will be thinner and greyer with assembly code compared to basic . As Fallout says, text handling is a major concern as soon as you step out of Basic - even with just C++, it's pretty painful. I've been throwing text about since I was a kid, mixing strings and parsing them - my first game projects were text adventures. But still, my C++ game uses a byte array for the high score table instead of a text string. Really, even if DBPro is 10 times slower at dealing with text, it's still a better option.

I think it's best to start with DBPro, and when you start pushing the envelope look into other languages. I like OpenGL, and because I used DBPro and got into memblocks and meshes and stuff, OpenGL is a lot easier to understand - in fact it works a lot like DBPro's memblocks. Of course there is DGDK, but personally I'd rather include apple devices, so I develop in DBPro for PC, and C++ for iOS devices. From my point of view, it's all a matter of syntax 99% of the time, C++ is really no more complex than Basic when it comes to game logic - it's just that a lot is done for us internally with DBPro. I wasn't at all productive with VB, as nice as the DX7 SDK was - I didn't get very much done on the PC until I got DBClassic.

Health, Ammo, and bacon and eggs!
Juggernaut
14
Years of Service
User Offline
Joined: 12th Mar 2012
Location:
Posted: 21st Mar 2012 16:17
@Fallout:

I guess I understand your point.

But how much slower than C++ ? Any data / benchmark ? I mean is Dark Basic Pro very sluggish in numerical computation ?

Thanks,
Juggernaut
14
Years of Service
User Offline
Joined: 12th Mar 2012
Location:
Posted: 21st Mar 2012 16:30
Quote: "Yeah, C++ is a lower level language than DBPro, meaning C++ code is closer to machine code, the closer you get to machine code the faster your code... wish I knew some machine code to explain, but this is kinda what the compiler does:"


In the main website - http://www.thegamecreators.com/?m=view_product&id=2000 the following has been stated.

Quote: "
COMPILER
Modern design
Creates .EXE files
Encrypt and compress exes
Icon control of exes managed
Breakpoint markers
Produces 100% machine code
"


Does this mean though the Dark Basic Pro compiler produce machine code, it is not the same as when produced using C++ ? I thought machine code is the code/language that the pc understands - chunks of binary numbers ( combinations of 1s and 0s). It is the most lowest level language and fastest too. Compilers/interpreters are made to produce machine code , because we humans are not that adept in dealing a whole project with 1s and 0s only.

So how come Dark Basic Pro is that bad when it comes to speed ?

Thanks,
Van B
Moderator
23
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 21st Mar 2012 16:49
You'd probably only notice the speed difference with a massive load of calculations - say you had 256 spheres and you wanted to check for collision on them against each other, that means around 65,000 comparisons. Doing that each loop would slow DBPro down, but it would be faster in C++, maybe by about double. That's why there are plugins for DBPro - in fact that's a major factor. Most things in DBPro are handled through libraries, like plugins that do specific things for physics and collision, the 3D engine, math even - it's all imbedded in libraries. It's really the layer of abstraction that causes the slowdown a lot of the time.

SQRT might be the same speed in C++, and in DBPro - but DBPro might be slower because it isn't so hot at handling it's memory, transferring data to variables, that sort of thing. C++ allows deeper access to things that DBPro has to do through libraries.

DBPro produces executables, but they are not exactly the same as what you'd get from C++. DBPro .exe's have libraries imbedded in them, sometimes media too. It's all down to the techniques the compiler uses. C for example, the grandfather of modern languages - the first thing to be written in C was a C compiler. Langauges like C can be broken down further and closer to machine code, DBPro can't really do that, it's more like a package of game and engine and everything included - that's why a C++ 'Hello World' would be a few kilobytes, whereas in DBPro it'd end up a few hundred kilobytes. This is kinda typical of Basic compilers though - Basic is not compiler friendly, just look at the crud you need for VB programs, runtimes and stuff like that... until they introduced .Net - which is basically a huge runtime for visual studio. You could make a C++ program in VS, but might need .Net for it to work on other PC's. At least DBPro tries to keep it's crud to itself .

Health, Ammo, and bacon and eggs!
Irradic
20
Years of Service
User Offline
Joined: 1st Jul 2006
Location:
Posted: 21st Mar 2012 18:38
Juggernaut, are you trying to create the next Crysis in DBPro ?
I followed some of your threads.
Even though DBPro isn't the fastest engine out there, you would need to have absolutely no clue about what you are doing, or some mad skills to bring a half way modern PC to its knees. Joking, but true.

I understand that you want to inform yourself, and get to know DBPro as much as possible.
No one said that DBPro is king of the cheeses, there are always options that are faster or have more (modern) features.

You got to take a look at the big picture. Besides performance, there are other important things to consider, the art pipeline, development time etc.
What good is a fast engine if you need to spend hours setting up your assets for the engine, or if you can't get them into the engine at all because the exporter keeps on crashing.

Would you rather work on a faster engine but spend a week on a simple walk through ? Or do the same on a slightly slower engine within a couple of hours !

Most of the open source engines are just render engines or lack some other vital components (sound,input, physics...) which you need in order to create your game.

With DBPro you got all you need, even though sometimes in form of a commercial Plug-in. But spending 20-40$ is still better than spending months wrapping the commands of a physics engine, in my opinion.

The debate about which engine is faster and better is endless.

I have worked with Torque3d,UDK, Leadwerks Engine 3, Unity3D and DBPro.
All have their pro's and con's, but you'll definitely won't go wrong with DBPro.
With DBPro you'll have something up and running in the shortest amount of time, unlike with Torque3D or UDK, where you first have to scan through an endless amount of code (if you want to create anything else than a shooter).
Unity3D is a different story, but the free version is absolutely feature crippled and the Pro version will set you back 1500$.

I'd say, use DBPro as a stepping stone. Start with it and see if you can bring it to its knees.
You can create the prototype of your game in DBPro and once you think you have outgrown it, take everything you learned and move on (C++ or whatever).

Juggernaut
14
Years of Service
User Offline
Joined: 12th Mar 2012
Location:
Posted: 21st Mar 2012 18:39
I see....

So if I create my own number crunching plugins in VC++ the performance hit will become negligible ?

On the other side how does the 3D commands/functions fare with VC++ ? Is loading a textured .x file in Dark Basic Pro slow - compared to doing the same thing in VC++ and DirectX SDK ? Or is the performance hit negligible ?

Thanks,
Fallout
23
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 21st Mar 2012 18:45
^ What Van said.

The rendering is always the main bottleneck for most games, and DGDK and DBP perform almost exactly the same. I remember seeing someone doing some speed comparisons and DGDK was marginally faster. However, I do remember some simple operator tests like:

DBP
for i=0 to 1000000
a=a+1;
next i

vs

DGDK
int a;
for(int i=0; i<1000000; i++){
a++;
}

I think DGDK was 100 times faster. While both languages produce machine code, for DBP to give you it's nice basic syntax and automatic type conversions, and range checking, and all that jazz, there are loads of extra commands executed behind the scenes.

Simple fact is though, if you're doing a for loop, generally you'll have a CPU intensive DBP command in there, like moving vertex data, or rotating objects, or retexturing, and those commands will run at the same speed in either language. Additionally, other CPU intensive calculations like ray casting, performed in plug-ins like Sparky DLL, are both using the same C++ code, so perform the same in both languages.

So yes, C++ is significantly faster than DBP for maths operations, but that is rarely the bottleneck for most applications. So it may be 100 times faster in C++, but in practice it's 1% faster overall for your average game with simple/medium logic.

Juggernaut
14
Years of Service
User Offline
Joined: 12th Mar 2012
Location:
Posted: 21st Mar 2012 18:58
@Irradic:

Quote: "I'd say, use DBPro as a stepping stone. Start with it and see if you can bring it to its knees.
You can create the prototype of your game in DBPro and once you think you have outgrown it, take everything you learned and move on (C++ or whatever)."


Yes I am on it ...... I am not leaving DBPro ..... just comparing where it stands compared to a C++ engine. The only free and complete engine that I came across other than DBPro is Panda3D ..... it has the same ease of use if you use python to write your game logic (but the core is OPENGL written in C++) - all things in one package - (AI,collision, sound, bullet physics,ODE physics etc.) What turned me off is the custom model format which is very hard to work with blender (2.6). The exporter in its current state has lots of constraints ... and the officially supported exporter is for MAYA only. And lastly the python runtime / interpreter has to be installed on the user's machine to play the game - that is another thing that I do - not like.

What attracted me towards Dark Basic Pro is its ability to produce machine code - which runs on the user's pc without any additional runtime(apart from Directx), good 3d file format support and a very lively and helpful community - where novices like me do not get ignored.

Thanks,
Juggernaut
14
Years of Service
User Offline
Joined: 12th Mar 2012
Location:
Posted: 21st Mar 2012 19:08
@Irradic:

And by the way ..... your skills are admirable -

http://forum.thegamecreators.com/?m=forum_view&t=195169&b=8

Thanks,
Juggernaut
14
Years of Service
User Offline
Joined: 12th Mar 2012
Location:
Posted: 21st Mar 2012 19:14
Quote: "On the other side how does the 3D commands/functions fare with VC++ ? Is loading a textured .x file in Dark Basic Pro slow - compared to doing the same thing in VC++ and DirectX SDK ? Or is the performance hit negligible ?
"


@Fallout: what is your opinion about that ?
Fallout
23
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 21st Mar 2012 20:04
I've never noticed any performance problems loading .X files. Perhaps it is slower. I couldn't tell you, but I've never made a game where I've been watching a loading bar thinking "Damn, DBP is slow at loading!". It's always been a matter of seconds.

You should never be loading media during a game loop anyway, so if DBP takes 1 second and another language take 0.5 seconds, it's not a big deal. Plus you can always save your models to .DBO format using the "Save Object" command for quicker loading.

Juggernaut
14
Years of Service
User Offline
Joined: 12th Mar 2012
Location:
Posted: 21st Mar 2012 20:54


I am only able to load around 100 models with this code, if I increase the number , the program stops - the window closes without any error message! Where am I doing it wrong ?

Thanks,
Juggernaut
14
Years of Service
User Offline
Joined: 12th Mar 2012
Location:
Posted: 21st Mar 2012 20:59
Sorry wrong code - the edited one here -

Irradic
20
Years of Service
User Offline
Joined: 1st Jul 2006
Location:
Posted: 21st Mar 2012 21:10
@Juggernaut - I know about Panda3D, downloaded it out of curiosity a long time ago. But I never spent serious time with it.
You are definitely right about the formats and the community !


Quote: "And by the way ..... your skills are admirable -"

Thank you very much !

Pincho Paxton
23
Years of Service
User Offline
Joined: 8th Dec 2002
Location:
Posted: 21st Mar 2012 21:21
Too many people think that high polygon, multiple shader, Fallout style graphics are the way to go. But if you take a look at the games that people make beautiful, they tend to put less attention into the games themselves. My favourite games come from the past. Unreal Tournament, Rollercoaster Tycoon 3, Half Life, Elite. These games unlike Fallout, can be improved in DB Pro. You can have more polygons than the real games had, you can have better shaders than the real games had. Take a game from 5 years ago, rather than a PS3 game today, and then concentrate on gameplay.

Juggernaut
14
Years of Service
User Offline
Joined: 12th Mar 2012
Location:
Posted: 21st Mar 2012 21:23
@Irrdiac:

Will you please look into the code that I have posted - I am unable to load more than 100 Samurai.X file (textured), whereas I can load 10,000 of a textured cube !

I just do not get it - the polygon count of the samurai.x is not very big - it is not a high poly model. I have attached the texture - bmp file in my second post, the model .x file is in the post above that ...

I am a little disheartened with the current situation. If anybody will help me out what I am doing wrong ....?

Thanks,
Brendy boy
20
Years of Service
User Offline
Joined: 17th Jul 2005
Location: Croatia
Posted: 21st Mar 2012 21:29
Quote: "I am only able to load around 100 models with this code, "

how much ram do you have?

Juggernaut
14
Years of Service
User Offline
Joined: 12th Mar 2012
Location:
Posted: 21st Mar 2012 21:35
@Brendy boy: 4GB Exactly.... I am running Windows7 x64 version , icore 3 processor.
Juggernaut
14
Years of Service
User Offline
Joined: 12th Mar 2012
Location:
Posted: 21st Mar 2012 21:38
@Pincho Paxton: Yes .... you are right ......
Quote: "Too many people think that high polygon, multiple shader, Fallout style graphics are the way to go."
Can't help it though ..... I myself have that disease ....
Brendy boy
20
Years of Service
User Offline
Joined: 17th Jul 2005
Location: Croatia
Posted: 21st Mar 2012 21:42
Quote: "@Brendy boy: 4GB Exactly.... I am running Windows7 x64 version , icore 3 processor. "

OK, we have practicaly the same systems. I'll give it a try to see if it works for me

Juggernaut
14
Years of Service
User Offline
Joined: 12th Mar 2012
Location:
Posted: 21st Mar 2012 21:43
Quote: "OK, we have practicaly the same systems. I'll give it a try to see if it works for me"


Ok ... please ....
Fallout
23
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 21st Mar 2012 22:03 Edited at: 21st Mar 2012 22:03
While BrendyBoy tests that out for you, you should know you don't need to load the same model 100 times. You load it once and then use instance object and clone object, which means data is shared in memory, rather than duplicated.

Brendy boy
20
Years of Service
User Offline
Joined: 17th Jul 2005
Location: Croatia
Posted: 21st Mar 2012 22:09
Quote: "Ok ... please .... "

Tried it with 110, it works. Memory consumption is around 1.1 GB

Are you running some ram heavy apps in the background?

Juggernaut
14
Years of Service
User Offline
Joined: 12th Mar 2012
Location:
Posted: 21st Mar 2012 22:22
Quote: "Tried it with 110, it works. Memory consumption is around 1.1 GB

Are you running some ram heavy apps in the background?
"


No just chrome windows... that is the point - I made a textured cubde - in blender and that I can load 10k times with that same code ! But in case of the samurai.x it is only 100-110. After that the window closes down without giving any error message ! Is it exceeding memory limit ?
Juggernaut
14
Years of Service
User Offline
Joined: 12th Mar 2012
Location:
Posted: 21st Mar 2012 22:23
Quote: "While BrendyBoy tests that out for you, you should know you don't need to load the same model 100 times. You load it once and then use instance object and clone object, which means data is shared in memory, rather than duplicated.
"


@Fallout: thank you for pointing that out. I am just trying to do a sort of load testing here. ....

Thanks,
Juggernaut
14
Years of Service
User Offline
Joined: 12th Mar 2012
Location:
Posted: 21st Mar 2012 22:37
I am able to load 150 max , something beyond that closes the game window.

I just do not realize where is the difference.

Let me give you the textured cube - .x file in this post and the texture in the second.
Juggernaut
14
Years of Service
User Offline
Joined: 12th Mar 2012
Location:
Posted: 21st Mar 2012 22:39
Here is the texture file - attached along with this post.

If you load the cube instead of the samurai - it loads 10k times ....!
Brendy boy
20
Years of Service
User Offline
Joined: 17th Jul 2005
Location: Croatia
Posted: 21st Mar 2012 22:39
Quote: "But in case of the samurai.x it is only 100-110."

I tried it with 120, it works too

Quote: " Is it exceeding memory limit ? "

No, limit is 1.85GB

Are you running the newest version U77?

Juggernaut
14
Years of Service
User Offline
Joined: 12th Mar 2012
Location:
Posted: 21st Mar 2012 22:44
yes I am running U77
Juggernaut
14
Years of Service
User Offline
Joined: 12th Mar 2012
Location:
Posted: 21st Mar 2012 22:45
@Brendy boy: have you tried the cube that I posted in the previous message. Try loading the cube .... you will see the difference...
Juggernaut
14
Years of Service
User Offline
Joined: 12th Mar 2012
Location:
Posted: 21st Mar 2012 22:48
Quote: "No, limit is 1.85GB"


Dark Basic Pro can access upto - 1.85GB of memory ? That is real nice... a plus point in its arsenal . But then why on earth is this thing failing here.
Juggernaut
14
Years of Service
User Offline
Joined: 12th Mar 2012
Location:
Posted: 21st Mar 2012 22:52
ok guys ... I am calling it a day now ... I have to go now ...... wish there was a clear cut explanation about the current situation. Anyway ... thank you ..... all of you ...folks ....for all your efforts ...
mr Handy
18
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 21st Mar 2012 23:21 Edited at: 21st Mar 2012 23:24
That whole memory talks is a complete bullsh... oh, crap, censored.
4096 texture eats...64? Hell no, 48 megs!
50 * 4096 textures = 2400 megs? Hell no, 1000 megs!
I've loaded 50 dds's without any problem. 2 gb ram, xp.

P.s. I think Billy G's 640k plan somehow still tries to work.
Brendy boy
20
Years of Service
User Offline
Joined: 17th Jul 2005
Location: Croatia
Posted: 21st Mar 2012 23:29
Quote: "That whole memory talks is a complete bullsh... oh, crap, censored."

What part exactly? All 32bit apps have that limit

Quote: "I've loaded 50 dds's without any problem. 2 gb ram, xp."

if 50 images take 1000megs then of course you hadn't problems loading it. Try 150

Brendy boy
20
Years of Service
User Offline
Joined: 17th Jul 2005
Location: Croatia
Posted: 21st Mar 2012 23:32
Quote: "If you load the cube instead of the samurai - it loads 10k times ....! "

Well, of course it does. 1 cube takes few kilobytes and samurai takes 4 megabytes. And i don't see a difference, both works for me

mr Handy
18
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 22nd Mar 2012 09:12
Quote: "if 50 images take 1000megs then of course you hadn't problems loading it."

It math, man! 4096 fits is a 48MB, 50*48=2400. I have 2GB ram. Magic?
Van B
Moderator
23
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 22nd Mar 2012 10:52
One problem might be the Samurai's animation. The more frames an object has, the more memory it takes up - old example objects had quite high frame counts, like 1000 frames where 100 frames would be plenty. So maybe it's the animation data that is causing the problem.

Health, Ammo, and bacon and eggs!
Millenium7
21
Years of Service
User Offline
Joined: 13th Dec 2004
Location:
Posted: 22nd Mar 2012 13:04
in my experience, you'll almost never have to worry about the speed of 'core' commands such as math, strings, loops, functions etc. They are all blisteringly fast anyway. Keep in mind guys we aren't working with 166mhz pentium's. The speed of the code itself will usually account for less than 1% of your performance impact. Even if you have a loop which executes hundreds/thousands of time per main loop, you'll probably never notice a performance impact at a typical 60fps cap

Now there are some commands which are slow, but only because they go about it in a very inefficient way. The text/ink/rgb commands for instance will cripple performance. That is why we have 3rd party plugins to override them and gain all that speed back. These plugins are written in C++ anyway, and usually very very fast. Ultimately the most speed impact is going to come from polygon count. And just like 'any' engine/language in order to have a high polygon count with acceptable framerate it all comes down to culling and visual 'tricks' such as shaders, textures and lighting to make things look better
Juggernaut
14
Years of Service
User Offline
Joined: 12th Mar 2012
Location:
Posted: 22nd Mar 2012 15:53
Quote: "Well, of course it does. 1 cube takes few kilobytes and samurai takes 4 megabytes. And i don't see a difference, both works for me"


@Brendy boy: So how are you able to measure the size of the memory that samurai model is occupying ? Any custom code or core commands ?


Quote: "One problem might be the Samurai's animation. The more frames an object has, the more memory it takes up - old example objects had quite high frame counts, like 1000 frames where 100 frames would be plenty. So maybe it's the animation data that is causing the problem."


@Van B: Thank you Van B, for pointing that out, it can be the cause.
Brendy boy
20
Years of Service
User Offline
Joined: 17th Jul 2005
Location: Croatia
Posted: 22nd Mar 2012 21:01 Edited at: 22nd Mar 2012 21:02
Quote: "It math, man! 4096 fits is a 48MB, 50*48=2400. I have 2GB ram. Magic? "

you have loaded 50 different images?
1. Dbpro keeps record of what you load so if you try to load the same image 50 times it will actualy be loaded only once
2. That's the size on disk. You don't know if the textures are compressed in memory. THey get decompresed in gpu if they are compressed.
3. You calculated ram usage yourself or did you look at task manager ?

Quote: "@Brendy boy: So how are you able to measure the size of the memory that samurai model is occupying ? Any custom code or core commands ?"

No, it's an aproximation. Samurai takes 4 mb on disk, in memory it is slightly more

But as I said I have the same ammount of memory as you do and it works for me

Fallout
23
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 22nd Mar 2012 21:13
As Brendy Boy has said, DBP won't load in duplicate image data unless you specifically load it into different IDs. I think you'd really struggle to use 2GB of memory though. You really have to make an epically proportioned game, or be extremely sloppy in your coding.

Juggernaut
14
Years of Service
User Offline
Joined: 12th Mar 2012
Location:
Posted: 22nd Mar 2012 22:22
@Brendy Boy:

Quote: "But as I said I have the same ammount of memory as you do and it works for me"


Do you mean, you are able to load 10,000 Samurai.X file or just ~150 ?

On my machine, the render window closes if I set the loop limit something higher than 150.
Brendy boy
20
Years of Service
User Offline
Joined: 17th Jul 2005
Location: Croatia
Posted: 22nd Mar 2012 22:38 Edited at: 22nd Mar 2012 22:39
Quote: "Do you mean, you are able to load 10,000 Samurai.X file or just ~150 ?"

No

Quote: "On my machine, the render window closes if I set the loop limit something higher than 150. "

First you said it happens when you set above 100, then you said when above 110, now you say when above 150. What is it then?

You said 100, so i tried it with 110 and it worked.
Of course you can't have 10,000 -> It doesn't fit into the RAM

I tried it with 160 and it crashed. RAM consumption was around ~1.5GB

Juggernaut
14
Years of Service
User Offline
Joined: 12th Mar 2012
Location:
Posted: 22nd Mar 2012 22:43
@Brendy boy: ok .... understood .... thoroughly and clearly ....

@Fallout:
Quote: "As Brendy Boy has said, DBP won't load in duplicate image data unless you specifically load it into different IDs. I think you'd really struggle to use 2GB of memory though. You really have to make an epically proportioned game, or be extremely sloppy in your coding. "


Looks like Dark Basic Pro makers are real pro themselves regarding coding with directx .... they have taken care of as much optimization possible ...

Login to post a reply

Server time is: 2026-07-09 17:43:07
Your offset time is: 2026-07-09 17:43:07