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 / Faster object loading

Author
Message
CumQuaT
AGK Master
8
Years of Service
User Offline
Joined: 28th Apr 2010
Location: Brisbane, Australia
Posted: 28th Jan 2018 10:30
Hi all.

So, loading the objects into my game to build the scenes is taking a loooooooooong time. I'm just using the Load Object command. Is there some sort of faster way to load them in? Or is it just a matter of making smaller, leaner objects?
Help out a fellow dev! Download and rate my games! They're free!

Wizzed Off! - (Android) (iOS)
God of Thunder - (Android) (iOS)
Extreme Lawn Mowing - (Android) (iOS)
Drunken Heroes - (Android) (iOS)

And you can get Fluffy Knuckleduster merchandise at our new store!
Zep
15
Years of Service
User Offline
Joined: 31st Aug 2002
Location: From PA, USA. Currently reside in Hanoi, Vietnam
Posted: 28th Jan 2018 11:20
If there's a bunch of the same object...load then clone/instance the rest?


Zep
15
Years of Service
User Offline
Joined: 31st Aug 2002
Location: From PA, USA. Currently reside in Hanoi, Vietnam
Posted: 28th Jan 2018 11:31
Check out this thread.

https://forum.thegamecreators.com/thread/116014

if you convert all your objects to DBO format, they say they load faster. (everything else loaded needs to be converted internally to DBO, which takes time)

How you do that...convert to DBO...I don't know...

Zep
15
Years of Service
User Offline
Joined: 31st Aug 2002
Location: From PA, USA. Currently reside in Hanoi, Vietnam
Posted: 28th Jan 2018 11:42
turns out it looks pretty easy...

load object "myModel.x", 1
save object "myModel.dbo", 1

write a small program that loops thru your objects and converts them. (no idea if this preserves texture information or not...)

then try your load object routine with the DBO versions.

Zep
15
Years of Service
User Offline
Joined: 31st Aug 2002
Location: From PA, USA. Currently reside in Hanoi, Vietnam
Posted: 28th Jan 2018 12:48
did a test

load 25 objects as X : 2700 timer cycles

load 25 objects as DBO: 800 timer cycles.

I just converted one X file to DBO using the load object/save object then loaded each version 25 times with load object/inc obj number in a for next loop.

loading a DBO is 3 times faster it seems.

(it did save the texture information from X to the DBO with save object, btw)
Zep
15
Years of Service
User Offline
Joined: 31st Aug 2002
Location: From PA, USA. Currently reside in Hanoi, Vietnam
Posted: 28th Jan 2018 14:38
Whoa!!!...saving as DDO and Converting the textures as DDS

load 25 objects as X with DDS texture : 3000 timer cycles

load 25 objects as DBO with DDS texture: 30 timer cycles!!!!!

DBO format with DDS textures seems the way to go.
Ortu
DBPro Master
10
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 28th Jan 2018 22:31
.dbo are much faster than .x

.dds are also faster than .png which are faster than .jpg

Of course clone and instance help.

If you are able to combine modles to export as a single object, that helps too. (Like instead of loading and positioning 5 barrels into a stack, combine them in modeling and export one file as a ready made stack
http://games.joshkirklin.com/sulium

A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.
CumQuaT
AGK Master
8
Years of Service
User Offline
Joined: 28th Apr 2010
Location: Brisbane, Australia
Posted: 29th Jan 2018 13:15 Edited at: 29th Jan 2018 13:15
All of my objects are already DBO and I'm using DDS textures Perhaps I just need leaner models.

For those talking about cloning and instancing, I'm not talking about setting up my scene. I'm talking about actually loading objects into the game.
Help out a fellow dev! Download and rate my games! They're free!

Wizzed Off! - (Android) (iOS)
God of Thunder - (Android) (iOS)
Extreme Lawn Mowing - (Android) (iOS)
Drunken Heroes - (Android) (iOS)

And you can get Fluffy Knuckleduster merchandise at our new store!
Green Gandalf
13
Years of Service
User Offline
Joined: 3rd Jan 2005
Location: Cornwall UK
Posted: 29th Jan 2018 14:43 Edited at: 29th Jan 2018 15:19
Does anyone know what .OBJ files are? The reason I ask is that some time back I was having trouble loading a complex shader. It turned out that the problem was that the shader was being compiled when DBPro loaded it and this particular shader took a few minutes to compile. Someone, I forget who[Edit: It was our good friend Rudolpho! ], suggested precompiling the shader and exporting it from the shader compiler as a .OBJ format file. All I had to do was use the .obj version of the file instead of the source .fx file when I load it. The shader now loads practically instantly. This experience makes me wonder whether there is a corresponding possibility of exporting the objects to a .OBJ file. I have no idea whether or how it can be done but might be worth investigating. Just a thought.
Ortu
DBPro Master
10
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 30th Jan 2018 00:46
There is a .obj model format, and i think dbpro can load them, but similar to .x, they would get converted to .dbo internally and should be slower than .dbo
http://games.joshkirklin.com/sulium

A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.
CumQuaT
AGK Master
8
Years of Service
User Offline
Joined: 28th Apr 2010
Location: Brisbane, Australia
Posted: 30th Jan 2018 02:34
OBJ files are an oooooold 3D format from a company called Wavefront. They became quite popular because of their simplistic nature. The simple data structure does lead to texture/shader/normal issues sometimes, and as far as I know they don't support animation.
Help out a fellow dev! Download and rate my games! They're free!

Wizzed Off! - (Android) (iOS)
God of Thunder - (Android) (iOS)
Extreme Lawn Mowing - (Android) (iOS)
Drunken Heroes - (Android) (iOS)

And you can get Fluffy Knuckleduster merchandise at our new store!
Zep
15
Years of Service
User Offline
Joined: 31st Aug 2002
Location: From PA, USA. Currently reside in Hanoi, Vietnam
Posted: 30th Jan 2018 09:24
Quote: "All of my objects are already DBO and I'm using DDS textures Perhaps I just need leaner models.

For those talking about cloning and instancing, I'm not talking about setting up my scene. I'm talking about actually loading objects into the game."


What kind of time are you talking about here? 15 seconds, a minute, 5 minutes?

How many objects?
Zep
15
Years of Service
User Offline
Joined: 31st Aug 2002
Location: From PA, USA. Currently reside in Hanoi, Vietnam
Posted: 30th Jan 2018 11:43
So...I wrote a thing (1/2 done), sort of a model viewer, thinking about this loading problem

1st: I load the object, some are already magically textured no need for an extra load texture step.

2nd: I haven't tested this yet but it will be the 2nd step, but I have got some of the basic info in.
a: do a checklist for limbs,
b: get limb texture name(1, #) (the magically loaded objects always have the texture name(s) here) sometimes 2...I have simple models.
c. if it magically loads textured, leave it alone, move objects and textures to save folder (convert to dbo, dds as nesc.)
d: if not textured, cycle thru the textures in the folder until I find the right one. (pressing the T key)
e: set object texture(s): save image(s) as dds in save folder, texture object with new dds(s), save object as dbo in "save" folder
f: hopefully that will make all objects use the texture info from the object file and skip the load texture step.

I'll know tomorrow! It's complete up to and including step d: so far.
Ortu
DBPro Master
10
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 30th Jan 2018 12:32
That's actually slower though: if multiple objects reference the same texture in thier material definitions, each of these objects will reload a new copy of that texture.

If you have objects sharing a texture, you are better off loading it once yourself and applying the texture to each object manually.
http://games.joshkirklin.com/sulium

A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.
Zep
15
Years of Service
User Offline
Joined: 31st Aug 2002
Location: From PA, USA. Currently reside in Hanoi, Vietnam
Posted: 30th Jan 2018 13:38
Quote: "That's actually slower though: if multiple objects reference the same texture in thier material definitions, each of these objects will reload a new copy of that texture.

If you have objects sharing a texture, you are better off loading it once yourself and applying the texture to each object manually."


I don't plan on that happening in my current project, but it's good to know for the future.
Zep
15
Years of Service
User Offline
Joined: 31st Aug 2002
Location: From PA, USA. Currently reside in Hanoi, Vietnam
Posted: 30th Jan 2018 13:43
Quote: "I'll know tomorrow! It's complete up to and including step d: so far."


Who can wait for tomorrow...I couldn't...heh

IT WORKS!

I haven't tried saving an object with the second stage (3rd,4th stage) texture yet, but I don't foresee any problems

That will have to wait for tomorrow
Green Gandalf
13
Years of Service
User Offline
Joined: 3rd Jan 2005
Location: Cornwall UK
Posted: 30th Jan 2018 17:41
Quote: "OBJ files are an oooooold 3D format from a company called Wavefront. They became quite popular because of their simplistic nature. The simple data structure does lead to texture/shader/normal issues sometimes, and as far as I know they don't support animation."


So it seems - and unrelated to other .obj formats apparently. Shame, since the shader ones work so well.
Zep
15
Years of Service
User Offline
Joined: 31st Aug 2002
Location: From PA, USA. Currently reside in Hanoi, Vietnam
Posted: 31st Jan 2018 01:08 Edited at: 31st Jan 2018 01:36
Hey CumQuaT,

Just curious if you have compressed your DDS files? Makes a BIG difference in the little model-viewer I am working on.

for example

This version takes almost 1 second to load
model.dbo (8KB)
model.bmp (4 MB)

This version takes almost 1 second to load (not compressing the DDS)
model.dbo (8KB)
model.dds (4 MB)

convert the BMP to DDS with the compression option at the end like so,
load image "\Textures\"+"model.bmp",1
save image "\SaveTextures\"+"model.dds",1,1
This one loads almost instantly.
model.dbo (8KB)
model.dds (513KB)

if you're not sure if your dds are compressed or not, you can do this (then compare the DDS sizes between the 2 folders)
load image "\Textures\"+"model.dds",1
save image "\SaveTextures\"+"model.dds",1,1

*I notice no lack of quality using the compression option (the comma 1, ---- ,1) at the end of the save image command.

*Disclaimer: I am old and possibly blind
Zep
15
Years of Service
User Offline
Joined: 31st Aug 2002
Location: From PA, USA. Currently reside in Hanoi, Vietnam
Posted: 31st Jan 2018 01:20 Edited at: 31st Jan 2018 01:30
Hey Ortu,

Quote: "That's actually slower though: if multiple objects reference the same texture in thier material definitions, each of these objects will reload a new copy of that texture.
If you have objects sharing a texture, you are better off loading it once yourself and applying the texture to each object manually."


What if different limbs of the same multi-textured object use the same texture? Is that images loaded multiple times also? Do you know?
Ortu
DBPro Master
10
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 31st Jan 2018 02:30
I haven't done testing for that, but my guess would be that it loads a copy for each material definition.

If the limbs are all part of the same .x file, and share the same material, I think it may only load one copy of the referenced textures. If they have separate materials that share the same texture, I'd expect it will load multiple copies.

You can try it with several different set ups and compare memory usage, more memory means more loading
http://games.joshkirklin.com/sulium

A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.
revenant chaos
Valued Member
11
Years of Service
User Offline
Joined: 21st Mar 2007
Location: Robbinsdale, MN
Posted: 31st Jan 2018 02:30
Quote: "if multiple objects reference the same texture in thier material definitions, each of these objects will reload a new copy of that texture."

Thankfully that does not seem to be the case. As can be seen within the following snippet; DBPro auto-loads and shares a single copy of each texture across all objects that require it.

Ortu
DBPro Master
10
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 31st Jan 2018 03:12
Quote: "Thankfully that does not seem to be the case. As can be seen within the following snippet; DBPro auto-loads and shares a single copy of each texture across all objects that require it."


Hmm, I guess you're right. I've tested with .x with referenced materials as well and there is no difference.

I distinctly recall running into something though several years back that convinced me to stop exporting with materials, involving unnecessary texture loading...

I dunno, maybe it had to do with using alternate / variant textures. I'll have to think on it a bit.
http://games.joshkirklin.com/sulium

A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.
revenant chaos
Valued Member
11
Years of Service
User Offline
Joined: 21st Mar 2007
Location: Robbinsdale, MN
Posted: 31st Jan 2018 06:56 Edited at: 31st Jan 2018 07:00
Quote: "I distinctly recall running into something though several years back that convinced me to stop exporting with materials, involving unnecessary texture loading..."

I'm not too fond of the feature either, DBP's image commands won't allow access to images which use negative IDs. More importantly, the following snippet seems to suggest that auto-loaded textures aren't released after their objects are deleted...

Zep
15
Years of Service
User Offline
Joined: 31st Aug 2002
Location: From PA, USA. Currently reside in Hanoi, Vietnam
Posted: 31st Jan 2018 08:42
Some good info coming out of this thread. Thanks, revenant chaos
Green Gandalf
13
Years of Service
User Offline
Joined: 3rd Jan 2005
Location: Cornwall UK
Posted: 31st Jan 2018 12:38 Edited at: 31st Jan 2018 12:41
Quote: "*I notice no lack of quality using the compression option"


Sadly, there sometimes is a loss of quality as well as visual artefacts when using compressed DDS files. The following article discusses the pros and cons of different DDS formats and I found it very helpful:

https://beyondskyrim.org/working-with-dds-files/

In addition to the issues raised in that article, I stumbled across an unexpected problem with compressed DDS files just last week while developing a new terrain shader for someone. We noticed some visual artefacts, i.e. some blocks of the terrain were coloured strangely at certain angles. We eventually narrowed the problem down to two things: the use of compressed DDS files together with certain texture read commands used in the shader. Whenever I used the tex2Dlod or tex2Dbias shader commands to read the textures then the glitches appeared. But as soon as we used any other format for the textures, i.e. .png, .jpg, .bmp, uncompressed DDS files, etc, then the glitches disappeared. The one thing that all those formats shared was that they get loaded as uncompressed DDS images in memory. It was an annoying complication because up to that point we had been using compressed DDS images as our preferred format (with occasional exceptions such as their undesirability for use with normal maps - see link for details). I haven't found a discussion of our particular issue anywhere yet so if anyone can point me to such a discussion it would be very helpful.

However, except for such unusual exceptions I agree that DDS files are the way to go - including compressed versions where appropriate, especially since they consume less video memory than uncompressed DDS images as well as loading faster than non-DDS formats.

Unfortunately, I don't think any of this helps CumQuaT. We probably need to see exactly where in his code the slowdown occurs.
CumQuaT
AGK Master
8
Years of Service
User Offline
Joined: 28th Apr 2010
Location: Brisbane, Australia
Posted: 31st Jan 2018 13:02
Sorry I disappeared there for a bit. Work has been a bit hectic since the New Year and I'm still juggling various things, my game included

I'm actually in the process of doing some more accurate analysis on which models are causing the biggest issues. Average load times for the game are sitting around 25 seconds on my machine. It's loading a lot of models, though, as it's my procedurally generated RPG, which has a lot of asset use and can't have things made simpler with pre-made BSPs or the like. To be honest, I think the worst candidates for long load times are the monsters, since they have all of their animation data, too. My texture loading doesn't take that long. It's only around 4 seconds on average for an entire suite of them, which isn't too bad.

Once I have more of a thorough understanding of which models in question are causing the slow-down, I might find a pattern.
Help out a fellow dev! Download and rate my games! They're free!

Wizzed Off! - (Android) (iOS)
God of Thunder - (Android) (iOS)
Extreme Lawn Mowing - (Android) (iOS)
Drunken Heroes - (Android) (iOS)

And you can get Fluffy Knuckleduster merchandise at our new store!
Green Gandalf
13
Years of Service
User Offline
Joined: 3rd Jan 2005
Location: Cornwall UK
Posted: 31st Jan 2018 13:31
CumQuaT,

Sounds like a good strategy.

But what is causing all those objects to be reloaded during game play, assuming that is what is happening? I mean the long loading times when you enter or leave a town or dungeon, etc. Wouldn't it be possible to clone, instance or reuse things like monsters, NPCs and trees. Static objects such as trees, rocks and pillars can be randomly re-scaled or rotated in some way to give the impression of greater variety . Perhaps I've misunderstood what you are doing exactly?

By the way, if any of you are wondering what can be achieved with DBPro/DGDK you should check out both CumQuaT's RPG Malevolence: The Sword of Ahkranox and the space exploration series Evochron.
Zep
15
Years of Service
User Offline
Joined: 31st Aug 2002
Location: From PA, USA. Currently reside in Hanoi, Vietnam
Posted: 31st Jan 2018 13:31
Quote: "Average load times for the game are sitting around 25 seconds on my machine."


Oh, that's nothing...Show a "ProTip: Use a potions when you heath is low!" etc... screen every 5 seconds or something then continuing loading (or something similar). Like the big companies do. Ya know "Reticulating Splines...."

I can imagine testing and suffering while developing, those load times can be tiring, but that's the nature of the biz
CumQuaT
AGK Master
8
Years of Service
User Offline
Joined: 28th Apr 2010
Location: Brisbane, Australia
Posted: 1st Feb 2018 02:35
Quote: "Wouldn't it be possible to clone, instance or reuse things"


I feel like there's a misunderstanding in what I'm asking. I'm only loading one of each object in, and then cloning/instancing from there. The cloning/instancing isn't taking long at all. It's just the loading of the object files into the game.

If I load all of the models that the game requires and then hold them in memory and never un-load them, the amount of RAM used by the game goes through the ROOF and people that don't have a monster PC simply can't handle it. So when you're in one type of environment, I load the objects required for that environment and unload the ones not required, to lighten the memory load.

Quote: "those load times can be tiring, but that's the nature of the biz"


Yeah but then I see a game that looks as good as, say, Duke Nukem Forever, and its load times are literally about 4 seconds. Is this just a limitation of working with DBpro?
Help out a fellow dev! Download and rate my games! They're free!

Wizzed Off! - (Android) (iOS)
God of Thunder - (Android) (iOS)
Extreme Lawn Mowing - (Android) (iOS)
Drunken Heroes - (Android) (iOS)

And you can get Fluffy Knuckleduster merchandise at our new store!
Zep
15
Years of Service
User Offline
Joined: 31st Aug 2002
Location: From PA, USA. Currently reside in Hanoi, Vietnam
Posted: 1st Feb 2018 06:27 Edited at: 1st Feb 2018 06:28
Quote: "Yeah but then I see a game that looks as good as, say, Duke Nukem Forever, and its load times are literally about 4 seconds. Is this just a limitation of working with DBpro?"


That's a BSP level tho as far as the level/environment goes. And they probably only load 4 to 5 different monster model types per BSP level.

If you're just building your world with objects, of course it will be slower.
Kuper
10
Years of Service
User Offline
Joined: 25th Feb 2008
Playing: Planescape:Torment
Posted: 1st Feb 2018 14:21 Edited at: 1st Feb 2018 14:28
2 main rules:
use .DBO for mesh
use .DDS for textures . DXT5 compression for common textures and no compression for special textures ( water , and shader effects )

If you use simple geometry and only few textures there is no difference which workflow you use.Otherside when your objects use complicated geometry and textures > 512px your workflow will be crucial.
So let me give you some advices
1) When textures assigned to object with 3d editor DBPro will load them ( and do not ask you! ) This textures will be load without image numbers and will be deleted only when object is deleted.
You can delete them by yourself.So if you want to retexture loaded object inside DBPro you will lost RAM and time with this un-deleteable stuff.
Advice: Clear material data before object load.Just save it without textures when convert from 3d editor format to dbo.
2) Read info about FVF format. Complex object which will eat RAM and load time if use additional uv stages and vertex color.
Advice: use only necessary FVF data when convert object to dbo.
3)Animated object with bones loads very slow.Character from FPSC pack consists of >1000 frames of animation.It take time to load.
Advice:Use character object with no animation and separate animation file. It can be done with this https://forum.thegamecreators.com/thread/219264
As a result load time will be minimal.

Remember: There is limit of less then 2 gb RAM for DBPro applications.Use it wisely.
Remember #2:Everybody hates long loading time!
Sedit
User Offline
Joined: 3rd Sep 2017
Location: Ghetto of NJ
Posted: 3rd Feb 2018 20:03
Is there a method that allows you to reserve the Data size in advance?

In C++ there is Vectors and arrays and Dynamic data loading is generally slow. If the size is allocated prior to attempting to place data in Speed is increased exponentially. I have no idea if thats possible in any way in this case but it might be a place to look and see if you can pre allocate the memory so its not left shuffling blocks around trying to fit as more data is loaded.
Sphere sphere = new Sphere(0.5f);
InsanelyRedundantJava insanelyredundantjava = new InsanelyRedundantJava(Redundancy1, Redundancy2);
zero32
1
Years of Service
User Offline
Joined: 28th Jul 2016
Location:
Posted: 5th Feb 2018 09:10
if you use the sync rate 60 command, it will also slow down loading objects.
If you use it, setting it to 0 while loading should work.
"It is only slightly easier than changing all sugar in a cake into stevia after it has already been baked" -Bisqwit
Mage
11
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 10th Feb 2018 00:53 Edited at: 10th Feb 2018 01:06
I have had to deal with this issue before.
This is hard because it's about making your game more efficient, and you really need to know the structure to do this well.
You have identified "Monsters with animations" as the worst performing loads.

1. Consider the Enhanced Animation plugin. This will allow you to load animations from files separately from the model data. Have the DBO files not contain animation at all. It will also provide you with better animation transitions.
2. Use DBO/DDS formats. You have mentioned this. It is fastest.
3. Never use model baked in textures. You have mentioned this.
4. Cache as much as you can, be as clever as possible. You mentioned ram goes through the roof. You should take another look at that, it's hard to see how you could be eating too much ram.
5. Keep track of every object/image number and their paths you load. If the identical one is to be loaded, clone the object instead, and/or point to the existing image. Keep track of how many times they are being used so you can delete them if no longer needed.
6. Without multi-threading support it's somewhat impossible to properly stream in assets. You could create a convoluted system that suspends the monster in some form in a deffered manner off screen, where you load the model, textures, and other assets, with screen draws in between. You'd probably get a little less screen lag doing this. Basically a monster loader manager.
7. You can extend things and build sophisticated system that manages the load in of assets. Keep a list of everything waiting to be loaded. Keep track of how much time has been taken since last frame draw. If too much time was taken stop, and pickup again when the next main loop comes around. You could mitigate lag spikes using this approach.

You definitely need to figure out clever ways to cache what you can. Depending on how your game is structured you might be able to predict things to cache allowing you to reduce the amount of caching needed. This is the hard part that isn't straight forward that turns you from being a student into a megamind.
Zep
15
Years of Service
User Offline
Joined: 31st Aug 2002
Location: From PA, USA. Currently reside in Hanoi, Vietnam
Posted: 21st Feb 2018 09:40 Edited at: 21st Feb 2018 09:41
Hey CumQuaT,

Try this, it doesn't screw anything up for me, but then my project is still pretty basic.

After your sync on, sync rate or otherwise near the top f your code
add:

lock backbuffer

right be fore your main loop starts add:

unlock backbuffer

I save about 1 second of startup time using this technique.
Zep
15
Years of Service
User Offline
Joined: 31st Aug 2002
Location: From PA, USA. Currently reside in Hanoi, Vietnam
Posted: 21st Feb 2018 09:54 Edited at: 21st Feb 2018 09:55
In b4 Mage says it doesn't save any time on Win 10.

Zep
15
Years of Service
User Offline
Joined: 31st Aug 2002
Location: From PA, USA. Currently reside in Hanoi, Vietnam
Posted: 21st Feb 2018 11:02 Edited at: 21st Feb 2018 11:07
Locking and unlocking the backbuffer takes 1 ms (or less).

So If your code does look wonky, you could experiment moving it to different places where it might not affect anything you are doing. Like before and after a function you call during setup before the main loop. Like I said, I save a solid 1 second using this on my current project.

Login to post a reply

Server time is: 2018-05-21 06:04:07
Your offset time is: 2018-05-21 06:04:07