Sorry your browser is not supported!

Greetings.

I decided to make this thread because I have noticed a few posts lately by people asking how to speed up their game, or how to squeeze those few extra Frames a second out of their game so they can run it more smoothly, and the answers seem to be kinda spread all about the place.

Ok, down to business.

Firstly, I must say, in general, there is no *Specific* way to speed up your particular game, as each game has different methods for doing different things. But, I'll tell you some no-no's and some must-do's to get you on your way to uncovering those last few Frames a Second.


DBC

The Matrix.
In theory, this is a great idea, and an easy way to make a level. But, in practice, it tends to kill of your FPS infront of a fireing squad.

Why?
Simply, there are too many polygons being drawn per loop.
A matrix consists of tiles. Each tile consists of two triangles. Each of these triangles are double-sided. Each of these triangles are being drawn *every* loop, and there's nothing you can do to stop it. Imagine a 10x10 tile Matrix. That's 100 tiles all-up, each with 4 polygons ( two double-sided triangles ), so, that's a total of 400 polygons in just a 10x10 Matrix!

What can I do?
Well, first off, don't use a Matrix.
Unless you're really unsure, I suggest using a .x terrain that you can create in one of many, many free programs ( some even written in DarkBASIC itself ), and divide that up into sections. That way, you can hide the sections that aren't on-screen, thus meaning less polygons to be drawn. And since when you make a terrain, it will most likely be single sided, you have then halved the number of polygons straight away.


Textures.
When you're using Textures for terrain, and sometimes even objects, it seems that your program slows down somewhat unexpectantly.

Why?
Most of the time, this is because the textures are *too large*. If you have a 512x512 texture that you are using to paste onto a tile that is much smaller than that, and you load that texture, it is going to take up lots of memory in the Video Card ( the textures are turned into Bitmaps when loaded into VRAM [ Video Memory ], so they take up alot of space ).
If you're using this texture on multiple area's on a terrain or object, the program is having to draw that large picture each loop. Thus you lose Frame Rate.

What can I do?
Firstly, reduce the size of the image.
[Updated 4th July '04]
Secondly, when you load the image in, you can optionally set it to not be Mip Mapped ( Mip Mapping involves creating multiple instances of the texture, at different resolutions, for LOD [Level Of Detail] purposes. This increases the amount of VRAM used by each texture. ).
[/Update]


Primitives.
DBC and DBP's built in primitive objects ( Sphere and Cone in particular ) are very high in poly count. And drawing lots of these means too many polygons on screen, thus, lower Frame rates.

Why?
Well, that's just the way it is.

What can I do?
Simply use your own model. Just make a simple cone or Sphere in an external application such as JTEdit or GMax etc, and load that in. You will be able to get a much, much lower polygon count without any significant visual quality loss.


Colour Object.
This command can slow down your program significantly if used in excess on many different objects and with many varynig colours.

Why?
The Way DBC and DBP "Colour" the objects is simple. It makes a texture of the colour specified, doesn't mip map it, then loads it directly into VRAM ( Video Memory ). The textures are often too big, and are quite unecessary.

What can I do?
Simply make your own, single coloured texure and load that in with the model. There should be a slight increase in the speed then.


Sprites
As most of you probably already know, DBC's 2D commands are quite slow, in particular, the drawing commands and the Sprite commands.
Using these commands in high quantities can result in slowed Frame rates.

Why?
The drawing engine was never fully optimised to be it's best quality. But I'm sure there are some other factors along with that too that I am unaware of.

What can I do?
Try to limit your 2D operations.
One way around this problem, is to create Plains and texture them with the images, and use them like sprites. This will give you alot more speed and help to keep your program running smoothly.


Unecessary Caculations
You may be using un-needed loops. Doing too many checks when they're all not needed. Recaculating distances all the time instead of defining it at the start. Whatever the reason, you may be executing redundant caculations, thus putting extra work on the processor when it's simply not needed.

Why?
Think about it. The more calculations you have to carry out per loop, the more work the processor has to do.

What can I do?
Have a look through your code.
Use a method called "Steping Through" where you read the code line by line, and have imaginary numbers written down on a piece of paper. And you pass these numbers throughout your code as if the computer was executing the commands. ( This isn't the best method for programs with large amounts of code, but shouldn't be a problem if you're modulated the code )
Check to see if you've got two For...Next loops in the one loop that are both using the same number ranges, and are both being executed each loop, but you've put it in twice simply because you needed to do two different things. These should be merged.
Put in checks to see when a condition has become true so you can break out of a loop when it is no longer needed. For example, lets say in a For...Next loop with values from 1 to 200, you were trying to check a random condition. Now lets say that the condition became true on the second loop. Normally, the program would execute another 198 loops before it continued, but if you put in a simple If...Then statement, you could break from that loop and continue your normal execution of code.
Also, if there is a constant that you do not need to calculate each loop. Such as the radius of an unchanging circle, compute it before entering the main loop, and store it for access later.
Similarily, if you have a large equation that keeps using calls to Object Position, or some such property retreiving command, get the value and store it, then just use that variable instead of the whole command. It is much faster to reference a variable than it is to call Object Position 40 times a loop.


[EDIT] Added 8th June '04
Object Drawing
When objects are drawn in DarkBASIC ( or any other 3D program for that matter ), All polygons that are on the screen get "drawn" even if they are facing in the wrong direction ( ie, away from the camera ). This can result in masses of away-facing polygons being calculated and drawn unecessaraly.

Why?
Well, in lot's of programs ( including DBC/P ), the away facing polygons can still be "seen" by shading the back-side of them a different colour to forward facing polygons. This is usually for modeling purposes or for seeing how a model is constructed, but in some cases, as is most likely the case in DB, the model might not be closed ( you can see "into" the model in area's ) so the away facing polygons are drawn so that parts of the model don't apear to disapear... By default, all polygons in a model that is visible get drawn to the screen.

What can I do?
Use the Set Object command to turn culling on ( set the "cull" flag to 1 ).
Culling is the name given to the process of calculating ( usually using vertex or face normals ) which way a polygon is facing, and deciding whether ot not to draw it depending on if it is facing the view port.
You should only use this command if your models are "closed", otherwise, it will seem like parts of the model just disapear.


Artificial Intelligence ( AI )
larger scal AI routines usually involve larger scale calculations. Things like Mass PathFinding, Mass AI item controll, and Mass AI bullet code tend to tie up the processor quite a bit.

Why?
Well, if you look at almost all AI scripts that are quite involved, and contain alot of code, then you'll see why straight away.

What can I do?
Limit AI routine execution to one routine per each 5 game loops, or for less intense calculations, per 3 game loops.
In this manner, you free up the processor to do other tasks while the AI is not being run.
Also, you can then divide up your execution, so that you have a sinlge routine per loop.
For example, PathFinding every first loop, Item control every second loop, and Bullet Control ever third loop, then back to PathFinding.


Usage of Memblocks
MemBlocks are just that, blocks of Memory. These blocks are area's of protected memory created in RAM by DBC/P that you have full write and read access to. You can use these area's of memory to directly access certain information and also to store certain data for much quicker acess than by conventional methods.

Why?
Well, when accessing a MemBlock, you are directly accessing area's of RAM ( don't worry, as I said, it's protected, so you can't crash your computer... Unless you really try to, anyway ), thus, you are not having to use commands ( which take time to execute ) to access data that is in RAM, ie, you're going directly to the memory rather than taking the round-about way ( in some cases ) by using DB's commands.

What can I do?
Firstly, you have to have the Expansion Pack ( comes free with DarkMATTER, or you can get a 30 day trial by upgrading to patch 1.13 ). This allows you to use the MemBlock commands ( and the DLL commands ).
MemBlocks can be used in many different routines.
As arkheii stated, they can be used to store ( using one of the many conversion to MemBlock commands ) certain data items such as images and/or object mesh data.
Once you have stored these items in a memblock, you can directly access and modify them without having to go via DBC/P's inbuilt commands.
As an example ( again, that arkheii suggested ), you can modify images on the pixel level via a MemBlock ( of course, only after you have converted the data to a MemBlock first ), which is faster than modifying them on an off-screen bitmap.
Another use is for Mesh Deformation ( refer to the code Base for this. Tip: Search for "Mesh To MemBlock" ).


Usage of Dynamic Link Libraries ( DLL's )
Due to the way that DBC creates its exe files, it is faster to make ( or get ) a pre-compiled DLL which has certain functions in it that you might require, and access them that way rather than use the in-built commands. For example, collision routines ( the major example here is Nuclear Glory's DLL ).

Why?
DBC is an interpreted language. This means that when you "compile" your code, it is turned into a little .exe file which has with it an interpreter. Think of it as an English to French interpreter. The English is your code, and the French is what get's calculated and displayed on the screen.
The Interpreter reads the english, line-by-line and repeats it exactly in french to a frenchman.
Even when the Interpreter get's back to the first line after it has read it once ( or even a thousand times ), it still has to translate it into French. As you can imagine, this is much slower than if all the English had just been converted to French, then that read by the Frenchman directly... Well, that's exactly what happens to a DLL ( and DBP source code too ). Thus, the English ( now French ) is read much, much faster.
In this way, the DLL will run faster than the exact same code in DBC ( within reason of course ).

What can I do?
Firstly, you have to have the Expansion Pack ( comes free with DarkMATTER, or you can get a 30 day trial by upgrading to patch 1.13 ). This allows you to use the DLL commands ( and the MemBlock commands ).
You need to also get ( or make, using C or C++ or Delphi, or other, depending on your language choice ) some DLL's.
Once you have these DLL's, you can simply use Load DLL in your code, then Call DLL to execute the functions that are held within the DLL's structure.

[EDIT] 9th June '04
Set Sprite
As a continuation to the General comment made about sprites in DBC, here is some aditional information.
BackSave and Transparency on sprites slow down your Frame rate somwhat.

Why?
Using BackSave, DBC is then responsible to copy and store the area of the screen behind the sprite, then restore it once the sprite moves, or is removed.
The Transparency on sprites is worked out by determining all the pixels that are black on this sprite and making them transparent. This is obviously slow.

What can I do?
You can use the Set Sprite command to turn off the backsave and transparency options, however you will then be responsible for restoring the screen ( usually using Cls )
Also if you don't need black on a sprite to be transparent turn off transparency and you will also gain a performance boost, especially in DBC.
[Addition added 21st June '04]
Ok, it has been brought to my attention that using the BackDrop instead of Cls to clear the screen is *not* a speed increase, but a hinderance.
Here is a demo.
[/Addition]


[EDIT] 14th June '04
Hiding Objects
In DBC's internal engine, when it draws objects, it still draws all those that aren't on the visible screen. As you can imagine this is somewhat of a speed hogger at times.

Why?
That's just the way it is I'm afraid.

What can I do?
Every so-often ( once every 5 or 6 loops say ) Do a check to see if the objects are on the screen. If they are, and they're visible, Hide them. This will stop them from being drawn unnecessaraly.
The code for this would be:
If Object In Screen(x) = 0 And Object Visible(x) = 0 Then Hide Object(x)
This should give you a marked speed increase if you are using alot of objects at any one time.
Note: The Object In Screen(x) command has been reported to not always report the correct information.


[EDIT] 15th June '04
Set Camera Range
The Camera Range determins the distance in world units away from the camera that polygons are drawn. Any polygons that are further away than this distance will not be drawn.

Why?
Well, imagine if you had an infinite draw distance. This means that EVERY polygon in the entire world would be drawn EVERY loop, weather or not it was so far away as to be un noticable, or is behind the camera.

What can I do?
Use the Set Camera Range command to set the minimum and maximum draw distances.
The Minimum Draw Distance is the value that as a polygon approaches the camera, if it get's too close, it is not drawn.
The Maximum Draw distance is the value that as a polygon goes away from the camera, if it goes past this distance, it is not drawn.
As you can see, this can allow you to speed up your game quite alot, espectially for those games that have a high camera angle that cannot see too far ahead. For this you would set the Maximum draw distance to relatively low.
A fair amount of experimenting is required.


[EDIT] 24th July '04
Side Note;
Bibz1st and Robin ( Author of MagicWorld ) came up with a solution to slow running 1.13 exe's;
"Having recently had speed problems regarding an exe made in DBC ver 1.13 enhanced, the rather excellent Robin King (author of MagicWorld) suggested that it might be that later versions of DBC have more modules in them so that resulting exe's have more work to do when running therefore slowing the program down,so I uninstalled my all singing/all dancing version of DBC and reinstalled the bogstandard ver 1.08 off my CD, the new exe I made ran like a dream.
So maybe this tip will work for you if you run into speed problems,it's worth a try."


There's a few points for you to start with. I hope this helps any and all
If anyone wants to add anything, just say so and I'll fix it up. Also if something I mentioned is incorrect, I can fix that up too

Happy codeing,
Jess.

About matrices, you just gave me an idea. Right now I'm playing with the memblocks to see if I can emulate a matrix by using my own memblock mesh, and adjusting the UVs to achieve the matrix tile texture effect. By using UVs, the resolution of the overall matrix texture is reduced because the tiles are reusable, instead of a super high res texture to cover up the entire matrix.

Of course, with matrix multitexturing becoming some sort of DBC requested feature in any matrix editor, I'm gonna need a few ideas on how multitexturing should be done...

when using for-loops, see if they are necessary. I'm making a space-shooter tutorial, and my code looks like this:









This is not the complete source, but if you look at the for next loops, you notice that I dynamicly change the amount of loops, by checking which sprite is the last one to check. So it doesnt run the AI / explosion loop 1000 times if there's only 1 enemy ship and no explosion

This is kinda easy to code, but difficult to understand.

Nice post Jess, as always . You have cleared some questions on my head, but there's one that I can't solve, and it's...

If we use a model for a matrix, there's any "get ground height" function for the X/3DS model?

Thanks

I thought mipmapping was supposed to increase performance by reducing the texture resolution as it it farther from the camera...

Oh yes, and don't forget to turn culling on, unless you're sure that you need to see both sides of the object's faces (which is a rare case anyway).

For things like AI, you don't have to check them every loop. A 1/3 to 1/5 second delay in between AI "think" functions (such as an A* pathfinding routine) is barely noticeable, but the reduction of processes is reduced dramatically, especially with a lot of AI entities.

Also, use DLLs and memblocks if you're using enhanced, as using those features can really speed things up (like when modifying an image, memblocks are much faster than offscreen drawing, and if some routines are used with a DLL then all the better because DLLs are machine code unlike DBC's interpreter).

@Darkguy: You can probably calculate it manually, assuming that you know the heightpoints of the mesh. But if you don't, you could read it with memblocks. For some strange reason, matrices can't be hidden like objects can. If you want to be cheap, use a 1*1 matrix textured with a black image and with transparency enabled, then set it to follow you and adjust itself according to the object by using the height data.

heh, thanks arkheii, the idea of the memblocks...there's any example to do it? and the 1*1 matrix idea...sorry, can't understand it

Hehe, beat ya! It's in the code snippets. I'll be writing a tutorial on it eventually.

Your is pro only though...

Update. New Points added, and Mip Mapping error corrected.

@Emperor Baal,
Yeah, I sort of mentioned that, but I didn't want to put in any code snippets, I wanted to keep it as a purely explanation only.

@arkheii,
I added your points, with a bit extra. And I fixed up the parts with the Mip Mapping. Thanks.

Jess.

hey

You forgot about the set sprite command, by turning of the backsave option you can drastically impove your frame rates if using sprites, especially in DBC, however you will be responsible for restoring the screen
Also if you don't need black on a sprite to be transparent turn off transparency and you will also gain a performance boost, especially in DBC.

syntax
set sprite [sprite number],[backsave flag],[transparecy flag]

for backsave off, backsave flag=0
for backsave on, backsave flag=1

for transparecy off, transparecy flag=0
for transparecy on, transparecy flag=1

pizzaman

Update - Added Set Sprite information.

Thanks pizzaman

Jess.

Are the Object position x(objectnum) and other object position commands actually slow? I thought that accessing them would be faster than putting them in arrays because that would use up some memory. I will create some arrays and store the positions in them once per loop. I access their positions many many times per frame, this could be a large speed up...

Isn't the object cull automatically set on when the object is created? If not, there could be another speed up point for Firewall...

I'll make these changes and see how much it speeds it up.

Thanks Jess

Bolt,
If you think of it, it is faster to access a variable ( with the object position stored ) than it is to call a function that has to execute internal commands that are referencing multiple variables etc.
I make it common practice ( since I started my RTS ) to create a function called "get_values" or some such, which goes through and updates all my position arrays etc, which I then simply access via my other functions.

I'm not sure of the default state of the Cull Object flag, but I'd say that it is set to off ( ie, it draws back facing polygons ). This is because of the reasons I stated in the main post above ( most people don't want parts of their objects to just disapear ).

Glad to have helped with the production of FireWall ( I like that game... alot ).

Jess.

Hey all,

Any chance of making this a sticky?
I'm sure that it will really help Novice programmers for DBC, and along with DarkGuy's Programmers Kit, these two threads could become the no 1. resource for those starting on DBC.

Just a thought. Not necessary of course.

Jess.

*Bump*

Starting to get near the bottom of the page there...

Jess.

Sticky!

Here's something I just figured out while reading the manual... Instead of loading the same sound over again, just load the sound once and use "clone sound" (I never saw that command before, hehe). For objects, use "make mesh from object", then use "make object" afterwards. ie.



*votes for sticky*

Sticky Please

Just a couple things I found out:

The "set object" command appears to be all default values of 1 because I know all the other object settings (transparent, wireframe, light, ambient, fog) are all one, so the cull must be. I set the cull to one on all of the objects that I create, no speed up. Darn.

I created a program that accessed the object position x() 100 times per loop then took the frame rate. I changed it to store the object position x() in a variable, then access the variable 100 times. No speed change. The object position was also changing every loop. I will post the little program soon, I am on the wrong computer right now...

Also:

I highly support getting rid of matrices as much as possible. In Firewall I switched to textured plains a few months ago, and it made a huge difference, and I got it to look better. Two birds with one stone!

I should really use memblocks, that could speed up some stuff, like my radar screen. That is actually currently a bitmap copied to the screen. Very bad

Another speed up suggestion:
Check to see if your objects are on the screen every tenth of a second. If they are not on the screen and visible (object in screen()=0 and object visible()=0) then hide them! It speeds up a lot!

Update - Added giude for hiding objects when they're not visible

Xander,
Ok, the Cull Object flag is at one by default, but I'm gonna leave the info there for others so they know what it is

Also, you may be correct about the storing of values as opposed to using the built in functions.

And yeah, using memblocks for the image manipulation is a perfect example of what they can be usefull for

Thanks Bolt

Jess.

Not sure about this:

About hiding objects that are not seen: by using "Print statistic(1)" (Prints the number of polys being drawn, but not necessarily visible) I noticed that objects not on the screen at some extent are hidden by default. However, for some strange reason, objects may still be drawn even though they do not "collide" with the camera's field of view because DB thinks it's colliding with the field of view "behind" the camera so it thinks it's visible when it isn't. Would be good if someone can prove/disprove this thought.

Oh, and using print statistic(1) is a good way to keep track of the number of polygons your program is drawing.

And most games don't need a ridiculous draw distance (Especially those 3rd person games with high angle cameras, or room based games). Use "Set Camera Range" and adjust the Back Value parameter to a smaller, more reasonable value.

arkheii,
You're 100% correct.

Any object that is within the Max Draw distance from the camera will have it's poly's drawn, weather or not it is in the Camera's FOV or not. This is why you do that check that Bolt mentioned, as that checks to see if the object is within the FOV, and if it isn't, it hides it.

And you're right about the Draw Distance, I'll update that now.

Thanks arkheii.

Jess.

whoa Jess! nice post! this should be made sticky too! ^_^

heh, I've read your post and it's awesome, also, I was able to understand the concept of memblocks

BTW you could add this to the camera range option: you can put fog if you want, and put his range some units less than the camera range

See ya! nice post! this should be sticky! ^_^

Hope this is Stickied!

DARKGuy & Chris Gizzi,

Thanks for the support guys

DARKGuy,
Ye-es. Putting in fog does allow this ( and can therefore mean you don't have to render as many polygons ), but I'm not too sure about the speed loss ( or gain ) due to using Fog.

Anyone got any example or speed test code for fog? If not, I'll just make some of my own up tomorrow sometime.

Thanks for the suggestion though. - And I'm glad you can now understand MemBlocks.


Jess.

I noticed that the object in screen() command may not be correct all the time, like arkheii said. So, in my game I did this to check if objects are in the screen: (not the most efficient...)



I probably don't need the object in screen()=1 part in there...

This isn't the most accurate method either because the object may be really big, so even if it is 100 pixels off the screen it might still supposed to be on the screen.

Hmm, ok, thanks for that, I'll throw that into the info.

Jess.

Quick point:

Fog still draws objects past the fog distance, as fog is only concerned with the light applied to an object.

You will get a performance decrease using fog. On my test system I get around a 15% frame p/sec speed loss using fog.

Camera clipping (set camera range ) is the quickest way to cull objects at a distance.

Twynklet

Nice topic

Sprites: if you can set the backspace off, the sprite make a "black" back while moving...

so do this:

...
backdrop on
...
set sprite 1,0,1
...

In this way, the backdrop automatically clear the back's of all sprites.

Much faster.

Rigo.

"Thank you" for all who contributed to this thread. I lowed the sync rate and set culletin on the skybox + gun model in my experimentation with the FPS demo (I'm trying to turn it into a full game) and I have noticed a nice speed boost. Before, when I looked down and then back up, I could notice DB repainting the bottom of the BSP map and now it doesn't do that anymore ^_^

Cheers!

Twynklet,
Thanks for that.

The point that DARKGuy was making was that if you set the draw distance nice and short, then put fog in to hide the horrible clipping effect that resulted, then you could increase your Frame rate because you had set the draw distance so short.

What I was after was a test that showed that the useage of fog *with* shorter clipping distance was actually faster than using a longer clipping distance without fog ( long enough so that you didn't notice the horrible clipping effects ).

Thanks for the reply all the same, and this may have been exactly what you were talking about in the first place

Rigo,
I'm not sure what you mean, but if you set the BackSave state to off, when you reposition a sprite, it does not restore the background behind where the sprite had been, instead it leaves an image of it there.
This gives you a speed increase, but means that you have an image of the sprite left behind on the screen each time it is moved, so it is up to you to clear the screen.
I have already mentioned this in the Speed-up List.

megamanx,
Glad to hear that this ever increasing resource is helping more and more people.

All,
Thanks for the posts

Jess.

Question about texture transfer to VRAM:
If two objects in your scene use the same texture, is this texture copied to VRAM twice each loop, or is DB (or DirectX) smart enough to find out it has to be done only once ?

And what's best when you're texturing an object: one big 512x512 texture, or four 256x256 files ?

I think 512x512

Yep, Emperor Baal's right.
Also, Yes, I would say that DX only copy's the texture to memory once ( that is unless you manually load the same texture twice ). Otherwise some examples that I have seen in the past would have killed my computer ( the same textures used thousands of times on a crappy 16MB vid card ).

Jess.

Jessticular:

"Rigo - I'm not sure what you mean" - that maybe about my bad english...

Okey, check this three source, you'll understand:

First one: standard sprites


Second one: Sprites without backsave, but used cls


And the last one: This code what I said. No backsave, but uses backdrop. The resolt of this version is similar to the secod one, but this is a little bit more faster...


FZoli.

Rigo,

Oh, ok, I understand now.

3D is faster in DBC than 2D is as a rule anyway. But, after running your code with 300 sprites each, I only noticed a slight difference in the FPS for about 5 seconds, then they both leveled out at a steady 19FPS for me.

So I'm not entirely convinced that using the BackDrop as the background is faster or not.

Anyone else care to try it? So we can say weather it is or isn't for certain?

Jess.

*OMFG the thread is sinking!*

Turning on the backdrop is way faster. I've never used backsaving because I never really played with sprites before, but everytime I did something 2D I always used the backdrop because the text and print commands don't clean themselves automatically (You have to use CLS, which, with my QB experience, I tried to avoid because I thought of it as a performance hog), and the backdrop was the quickest remedy I thought of.

In my test prog, I ran at 1024*768*32 @ sync rate 0. 48 transparent sprites, and the only text on the screen was the fps. Each sprite revolved around it's own origin(just for fun). The backsave version crawled at 5 fps, dropping to 2 at some places but reaching 7 once in a while. Also, there was a CLS every loop to "emulate" the disadvantage of having text that didn't clear itself. The backdrop version (still 48 revolving and transparent) ran at 45+ fps. This PC is only a 1.5GHz P4, 384mb rdram, geforce2mx400 32mb, win xp pro.

Backdrop wins. Landslide.

Yes, but did you test it with the backsave option *off*?
I mean, so that it doesn't restore the background behind the sprite, thus leaving a "trail" behind it, which means that you have to manually clear it yourself.

Because, that, compared with using the BackDrop, was basically the same FPS as I stated above.

Could I see the code's you used to test it with, so that I can confirm it?

I'll put in an addition to the sprite backsave command in the meanwhile though

Also, I again request for this thread to be made a sticky. As it is evident, the list has become quite large, and extremely usefull ( for those that want to take the time out to read it ), and has already been proven to be helpfull.
You can aso note that I am regular in my updates.
Thank you.

Jess.

About backsave off, well looky looky Manual CLS is slightly faster than backdrop. Of course, you'll need a fairly slow PC like mine to see the difference. Even so, it's only around 3 fps difference. I assume you have a solid PC JessT, because 300 sprites is a hell of a lot compared to only 48.

http://darkbasic.thegamecreators.com/?m=codebase_view_code&i=e9ad59f3cda2cd1c5b65a0f713f62327

I assume the small performance boost is from getting rid of the overhead when drawing the backdrop. It makes backsaving look useless and stupid.

With some changes, you could make it run with more sprites. Pretty useful info for fans of sprite commands though. Maybe if we churn out enough info, they'll sticky this. Then again, how many mods actually give a damn about the forum dedicated to older technology ?

hey all,

tried your sprite demo arkheii and i have to say the difference was very noticable to me. I got 58-60 frames per second with cls and only 42-45 frames per sceond with the backdrop on.
What was even more interesting though was i tried the same sprite demo program with DBpro and it would only run between 42-45 frames per second, no matter what mode i selected though really thats expected because DBpro's sprites are just 3d planes, thats proof in my opinion that DBC is better for 2d than DBpro although it could just prove that my graphics card is rubish for 3d - which it is really.

specs-
processor : Pentium 4- 1.5GHz
video card: ati Radeon 7000/Radeon VE - 32Mb DDR memory
hard drive: 20Gb - 4Gb free
RAM : 256Mb

pizzaman

arkheii,
Again, with your example, I got exactly the same FPS for both modes. Strange. I got 29-30 FPS ( mainly stayed on 30 for the entire time for both modes though ).

And this PC is a heap of useless metal, lol.
It's extremely slow with anything other than simple programs.

*My* new PC however ( this is the family one, whereas I just finished building my own ) would run this sprite demo at around 200 FPS... Oh well.


lol... Well, the list of speed tips sure is growing. And alot of them are quite handy to know too.


pizzaman,
Ye-es your partially correct about why DBP's speed was slower, but it's also due to the speed issues with the DBP engine atm with regards to 3D.

In the coming months, you should notice speed increases with all games and apps with the new updates I belive.


I'll fix up the list to reflect the demo that arkheii posted.

Thanks again guys.
Jess.

This hasn't been brought up yet: window mode is faster than fullscreen.

Any experienced D3D coders up for the challenge of making a "fullscreen window mode" for DBCe (much like the one DBP uses)? I've never played with D3D, but my guess is to destroy the window, make a new one without a title bar/borders/etc. and fit it to the screen's resolution. I'm not sure how to actually go about doing that though.

heh, arkheii, if you downloaded and played my DarkROIDS game, you'll notice it's a "fullscreen window mode". I program in this mode all the time because I hate my monitor going black when it changes video modes. It's easy to modifiy that. In your DB folder, edit the file "setup.ini" and change "windowmode=0" for "windowmode=1" and you'll see. You can also create a setup.ini in your final game folder with this:

[SETTINGS]
windowmode=1

And it will work perfectly

Just another contribution

arkheii,
Actually, you don't have to use D3D... I have a snippet at home ( I'll post it later ) that uses pure API codeing that does exactly what you're after.
First I maximise the window, then store the width and height in a memblock, then make the window with the new resolution and no title bar, and maximise it... and voila

DARKGuy,
That only stops the program from going to fullscreen mode *then* going to windowed mode. It doesn't quite do what arkheii suggested ( and what my snippet does ).

I actually have alot of API programming snippets at home... Some that scroll the title bar, others that make the window tiny, then grow so it takes up the whole screen... etc etc.

I'm not too sure if windowed mode is actually faster... But I'll run some tests later, and post the results... Although, after the strange results ( compared to others ) with the sprite tests, I don't know if my results will prove anything or not, hehe.

Thanks for the suggestions.
Jess.

Yeah, I think Jess knows what I was talking about. I really have to study API...

If you didn't notice in the sprite proggy I posted, the trigonometric values were precalculated and stored in an array. If you know that the values you will be using are limited, then might as well precalculate it instead of shoving sin and cos functions in the main loop. Sneaky.

arkheii,
The code I mentioned seems to have been lost in my archives of backups... I'll have to search around for it tonight, or tomorrow, cos it has some important snippets on that CD... But, I'll post it when I find it

And, yeah, that's what I tried to say in the "Unecesarry calculations" section of the speed tips.

Jess.

I had a look for that code, but I haven't been able to find it anywhere unfortunatly
I really wish I could, because it has along with it all my current versions of all my projects...
I have the feeling that I stupidly put them on a CDRW, and wrote over it. I hope not.

Oh, and... *Bump*

Is anyone going to even concider stickying this thread? Or am I going to have to just continually bump it?

Thanks.
Jess.

I think that the post is made sticky by the number of views the post it has I think it's when passes 1.000 or something like that, unless a mod see it and decide to sticky it...

Nah, otherwise, there'd be heaps of threads stickied in the General forums.

A mod or Rich has to come along and click the "Sticky" check box on the thread.

Jess.

[EDIT] I found my CD with all my back-up code on it So, Arkheii, I'll post that Fullscreen code when I get home, along with some other fancy API stuff if you like? I'll stick it in the Code Snippets. [/EDIT]

*bump*

Ok, now I've been reduced to begging for this post to be stickied...
Please?

lol

[EDIT]
Arkheii, here's that code;

[/EDIT]

Jess.

Update
Fixed up the Texturing section ( second from top ).
My Mip Mapping information was incorrect, but thanks to las6 over at LLRGT, I have now ammended it.

Jess.