Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Author
Message
Cescano
11
Years of Service
User Offline
Joined: 4th Sep 2014
Location: Italy
Posted: 22nd Jan 2015 21:23
Reusing the same textures for different things helps to keep low the video memory usage? or every object has his own space for his texture because of different UV Maps or UVW Unwraps?

For example:

I have 10 characters, will using the same texture for the skin save up some video memory or will be better trying to have them all different as the video memory used is the same? in this last case I will have the advantage of having the characters all look more different for the same cost of video memory
TheComet
18
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 22nd Jan 2015 23:26
Textures are loaded into VRAM, usually only once per texture. If you have multiple models using the same texture then they'll all reference that one texture and you will be saving VRAM.

If you want to have characters that have similar textures with very minor differences, a common technique is to have a generic texture and a colour map. A shader can combine the two with a user specified colour for each character. This means you'll only have two different textures and yet you'll have many different coloured characters.

I like offending people. People who get offended should be offended. -- Linus Torvalds
Cescano
11
Years of Service
User Offline
Joined: 4th Sep 2014
Location: Italy
Posted: 23rd Jan 2015 00:03
I understand, but the different are not just colors but part of textures completely different (different face base for example).
I know that having the face separated from the main object will let me change just the face part, but i can't detach the face from the rest of the body, otherwise all the bones will brake, and they are several, like 70 and more bones for the Whole body
TheComet
18
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 23rd Jan 2015 01:15
In an optimised engine, if they all use the same texture for the body then all bodies should reference the same texture.

DBP is far from optimised, however, so I'm not sure. I don't know if DBP does any resource management under the hood (like trying to reference already loaded resources if they are the same instead of loading new ones). You'll have to look at the source code.

https://code.google.com/p/darkbasicpro/

I like offending people. People who get offended should be offended. -- Linus Torvalds
Rudolpho
20
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 23rd Jan 2015 11:31
Quote: "In an optimised engine, if they all use the same texture for the body then all bodies should reference the same texture."

That is really up to the modelling software to ensure when exporting an object; each part using a different texture should make up a mesh of its own.

Quote: "DBP is far from optimised, however, so I'm not sure. I don't know if DBP does any resource management under the hood (like trying to reference already loaded resources if they are the same instead of loading new ones)."

It does not, probably with the reasoning that this behaviour is up to the DBP programmer to implement (texture object obj, mySharedTexture).

Cescano
11
Years of Service
User Offline
Joined: 4th Sep 2014
Location: Italy
Posted: 23rd Jan 2015 14:02
I usually export in .x (so no textures in the file), and for .dbo objects I 1st export them in .x, then convert to .dbo, so there should not be any texture in the file.

I have also tried to enable or disable the "Include materials" option in 3ds max (using panda x exporter), but I see no difference in the object space so i think the object I export have no textures. I Always use to texture the object later with the texture object command
Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 24th Jan 2015 09:13
Always load the textures separately. Having the object file automatically reference and load a texture is just bad design. All it does is cause problems.

If you load several objects and one texture then they can all use that texture without conflict and it will save you memory.

If you load the same texture under different image numbers Dark Basic Pro will not do anything to save you memory. Even if they are the same file they will be wasteful duplicates.

If you load a texture into an image number that is already used by another texture than it will replace that texture. Any objects using that texture will automatically use the newly loaded texture.

TheComet
18
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 24th Jan 2015 17:30 Edited at: 24th Jan 2015 17:33
Quote: "It does not, probably with the reasoning that this behaviour is up to the DBP programmer to implement (texture object obj, mySharedTexture)."


It actually does.



Quote: "Always load the textures separately. Having the object file automatically reference and load a texture is just bad design. All it does is cause problems."


That's poor advice, especially now that we know DBP will only load the same image once. In which situation is it a bad idea? Why make life harder when we can let DBP handle it automatically by loading the texture from the object file?

Quote: "If you load the same texture under different image numbers Dark Basic Pro will not do anything to save you memory. Even if they are the same file they will be wasteful duplicates."


Incorrect, look at the source code.

I like offending people. People who get offended should be offended. -- Linus Torvalds
Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 24th Jan 2015 18:00
Quote: "That's poor advice, especially now that we know DBP will only load the same image once. In which situation is it a bad idea? Why make life harder when we can let DBP handle it automatically by loading the texture from the object file?
"


This is a very different behavior than I have been aware of in the past. I will test this.

In the meantime, it's bad form to have the texture load automatically with the object since it makes the program difficult to follow when reading. You're essentially loading textures to image number slots without the commands appearing in the editor. Additionally since Texture Object is skipped you miss the chance to use any non-default Texture Object commands. SO it might need to be called again, not too big a deal.

Automatically loading textures like that also degrades your ability to manage your loaded assets. The path name could be anything. If you wanted to specificly use that texture elsewhere in the program you'd not have the ability to confirm that it was loaded or that the image was something else.

You'd also be hard coding textures into objects. So if you wan to change the textures you have to change the object files. This is a much bigger issue than merely changing some code around.

I'll look into this.

TheComet
18
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 24th Jan 2015 18:52 Edited at: 24th Jan 2015 18:56
That makes sense.

Saying that you should always explicitly apply textures isn't necessarily good, though. It really depends on your intent as a programmer. For example, I couldn't imagine manually applying textures for scenery objects, that would be way too tedious.

One major downside of applying them explicitly is you can't change your object's textures without re-compiling. Your program becomes less modular, and that's never a good thing.

I like offending people. People who get offended should be offended. -- Linus Torvalds
Why is my sig being erased? It wasn't over 600x120 even with the image.
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 24th Jan 2015 20:35
I'd be very surprised if DBPro checks to see whether an image has already been loaded. My guess is that the following will store two copies of the same image which is what I assume the advice was meant to avoid:



The snippet you posted seems to only check the image ID not the image itself. But then C++ is a complete mystery to me.

I suspect the confusion (assuming I'm right of course ) stems from a statement in the DBPro Help file. Unfortunately I can't locate that statement just this minute but I know I read it somewhere just a few days ago.



Powered by Free Banners
TheComet
18
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 24th Jan 2015 20:54 Edited at: 24th Jan 2015 20:57
Quote: "The snippet you posted seems to only check the image ID not the image itself. But then C++ is a complete mystery to me. "


No, it checks the file name. The function call FindInternalImage(szFilename, &iImageID) is passing the file name szFilename and it's passing the address of the local variable iImageID, which was previously initialised to 0. The ampersand means "get the address of this variable"

Passing an address of a variable to a function allows the function to modify said variable (since it knows where it's located in memory). In that sense, iImageID is actually a second return value. This is common practice in C (not so much in C++), and it's known as an "output variable".

If we look at what FindInternalImage() is doing:



we see that it's searching a linked list (m_List.m_start) for a string matching szFilename. If a match is found, then the ID of the found image is written to the output variable (*pImageID = pCheck->id). If it is not found, nothing is written to the output variable and thus its value remains 0.

[rant]
This algorithm is so mind bogglingly slow, it hurts me to see code like this. A linked list has linear lookup time O(n) and has extremely pad performance when iterated, because none of its elements are contiguously laid out in memory. To boost, strings are being compared multiple times. Again, slow.

The best approach would have been to first hash those strings, and then store the hashed values in a tree like structure (preferably in contiguous memory to minimize cache misses). This allows logarithmic lookup time. There would be no string compares, you'd save memory, and all you'd have to do to check if a string exists is run the incoming string through the same hash function and do a lookup.
[/rant]

I like offending people. People who get offended should be offended. -- Linus Torvalds
Why is my sig being erased? It wasn't over 600x120 even with the image.
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 24th Jan 2015 21:50
Interesting. I think I stand corrected.

Your new snippet and explanation are good illustrations of why I have problems with C++ and its variants. For example, what does this bit mean?



When I see that, I assume that the value of ptr goes into another variable called szShortFilename and that the comparison checks whether that value is true. That being the case, what's the point () of the following line:



since ptr has already "gone into" the other variable?

My guess is that the -> operator is doing something different that I don't understand - and it happens to be the main initial reason I didn't follow up my studies of C++ a few years back (there were other reasons such as I didn't find the whole thing worth pursuing and could do everything, OK 99.9%, I wanted to do using the simple, straightforward, DBPro).

This isn't really a rant as I would like to know.



Powered by Free Banners
Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 24th Jan 2015 22:30 Edited at: 24th Jan 2015 23:07


I just tried loading about 20000 of the same image and monitoring task manager in windows definitely shows the memory ballooning enormously. I don't think Dark Basic Professional is doing anything other than loading the same image and wasting memory.

Perhaps this functionality only occurs when the image is hard coded into the object file? Would seem strange if so...


Quote: "One major downside of applying them explicitly is you can't change your object's textures without re-compiling. Your program becomes less modular, and that's never a good thing."


I can respect this. In many cases recompiling is just not an option. Particularly if you are working with a team or users are modding your game.

But that means you need a separate version/file of the same object for each texture you intend to use.

Even if that wasn't the case, I still wouldn't choose to hard code texture path names into objects. Oh yes hard coding object and texture paths into your program sucks too. What I've chosen to do is instead is create separate "entity" files that store all of an objects paths and settings that can be adjusted in an editor.

Obviously this all depends on your needs.

Game loads map file. Map file references entity's file. Game loads entity's file. Entity's file stores path to object file and texture. Game loads object and texture and any stored settings.

That can be more work setting up an editor, Having separate "entity" files to describe stuff like rocks, trees, walls. But editing X files and DBO files to change their texture path can't be all that elegant either. Not to mention you might just want that object or entity file anyway so you can tell the game what kind of transparency to use, the objects name, or what script to use if the object is activated... etc.

If recompiling awful hardcoded path names isn't an option.

TheComet
18
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 24th Jan 2015 23:07
OPs question is answered, so I suppose I can proceed to constructively derail this thread.

-> is a dereference operator, because the variable ptr is a pointer type pointing to a struct.

In order to explain what -> means, I must first explain what pointers are. If you already think you're familiar, skip ahead to the next book icon.


Introduction to Pointers

C comes with fundamental datatypes. void, char, short, long, int, float, double, and pointers. That's basically it.

Consider the following:


What this is telling the computer to do is: "Give me 16 bits of memory and initialise it to 42". For the sake of example, lets say the computer decided to store those 16 bits at address 0x400120. Why 16 bits? Because sizeof(short) is at least 2 bytes = 16 bits.

Thus, if we were to look at the raw memory, it would be something like this:


The bit sequence representing the number 42 begins at address 0x400120 and ends 16 bits later (assuming this is a byte addressable memory map - all x86 based computers are). The variable thing is an identifier - it literally represents the 16 bits, you can think of it as an alias.

In C/C++, it is possible to obtain the address of any known identifier. This is done with an ampersand:


ptr, in this example, would be 0x400120 because that's where the 16 bits begin in memory.

If you have a pointer and wish to know what it's pointing at, you have to dereference it. This is done with the dereference operator:


This tells the computer: "Go fetch me the memory located at whatever ptr is pointing to." You can then assign it to something:


another_thing would now be 42.

You can also assign something to it:


This instructs the computer to overwrite the 16 bits with a new number, 52.

Now, the important bit. It took me months before I realized this simple fact. You will notice I deliberately omitted the declaration type of ptr. I did this to demonstrate the problem with dereferencing something: How does the computer know how long the sequence of bits being pointed to is? In this case we know it's 16 bits because it's a short, but what if it were a long? How would the computer know that it has to fetch 32 bits and not 16? Or what if it's a type way more complicated than that, like a struct?

The computer can't know. That's why we have to tell the computer what type a particular pointer is pointing at:


This tells the computer: "ptr will be pointing at a sequence of bits representing a short". If it were a long instead of a short, we would write long* ptr;


Structs

Plain datatypes are not the only datatypes that can be created. Structs allow you to create new datatypes out of combinations of plain datatypes. Consider the following:


Just as with the very first example, this tells the computer: "Give me sizeof(my_struct_t) bytes of memory and initialise x with 2 and y with 3.14159.

The difference now is, my_struct has members, namely x and y, which can be accessed with the "." operator (much like in DBP):


And just like you can get the address to plain datatypes, you can also get the address of a struct. Nothing changes with the syntax, only the name of the datatype changes:


ptr now holds the memory location of wherever my_struct is stored.

If you've followed me this far, then you will probably understand what this means:


This will dereference the memory location pointed to by ptr (which is of type my_struct_t), fetch the contents, and copy them into a new struct called copy. The members can then be accessed normally with copy.x and copy.y.

The next logical step is: What if I wanted to access the members directly from a pointer? Well, you can! You'd just replace "copy" with "*ptr":


This would re-write the contents of the original struct, my_struct, with x=36 and y=5.3234, since ptr is pointing to the memory location of my_struct.

C programmers decided that writing (*ptr).x looks ugly. Therefore, they came up with a better way:



Back to the original question

Quote: "That being the case, what's the point () of the following line:"




ptr is of type tagData*, which is a struct and contains a member named szShortFilename. szShortFilename is of type char* and points to a string. strlen() will therefore evaluate the length (number of characters) of the string stored in the member szShortFilename of ptr, then compare it to iFindFilenameLength.

Why? No idea, strcmp() does that check already anyway.

I like offending people. People who get offended should be offended. -- Linus Torvalds
Why is my sig being erased? It wasn't over 600x120 even with the image.
Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 24th Jan 2015 23:18 Edited at: 24th Jan 2015 23:20
Explaining the finer points of passing pointers and syntax is great. But like I said loading the same image thousands of times in a for loop fills up the RAM. It's not finding or sharing the same image like you said it would.

I'll try a more detailed investigation using objects with hard coded texture paths later.

It will be very obvious who is right when the memory usage is checked.

You said I was wrong. I want to know.

TheComet
18
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 24th Jan 2015 23:19 Edited at: 24th Jan 2015 23:21
Quote: "I just tried loading about 20000 of the same image and monitoring task manager in windows definitely shows the memory ballooning enormously. I don't think Dark Basic Professional is doing anything other than loading the same image and wasting memory."


It seems dbLoadImage() doesn't end up calling LoadInternal(), it just goes straight to loading the image.

The duplicate check is only applicable when loading objects.

I like offending people. People who get offended should be offended. -- Linus Torvalds
Why is my sig being erased? It wasn't over 600x120 even with the image.
Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 24th Jan 2015 23:23
Quote: "It seems dbLoadImage() doesn't end up calling LoadInternal(), it just goes straight to loading the image."


When I check those objects with hard coded texture paths, I fully expect something like this. This doesn't surprise me.

It would not surprise me to find out that it's automatically linking already loaded matching images when and only when paths are coded into the object file.

Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 24th Jan 2015 23:27 Edited at: 24th Jan 2015 23:32
So -> is just a method of subscripting a pointer, a bit like typed variables in DBPro? Why not just say so and save the rest?

The code snippet makes sense now. Thanks.

More importantly, and back on topic, what about Mage's observation which seems to support what I was saying? [Actually, a while back Lee mentioned in one of his Reloaded blogs that he'd identified a bug in the load image command that resulted in excess memory being used. Perhaps this is the one? He didn't mention whether it was a memory leak or not.

Incidentally, who said the following (quoted from Mage's last post)

Quote: "One major downside of applying them explicitly is you can't change your object's textures without re-compiling"


That is just plain wrong. You can retexture an object or an object's stage whenever you like. No need to recompile. I've done it many times and the latest project I've just finished relies on it.

Edit OOPs () ! I see there's been a few posts while I was posting. I should have said which of Mage's posts I was talking about. And I still haven't found that statement in the Help file.



Powered by Free Banners
TheComet
18
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 24th Jan 2015 23:34
Quote: "So -> is just a method of subscripting a pointer, a bit like typed variables in DBPro? Why not just say so and save the rest?"


I had no idea how much or how little you knew about the language.

Quote: "That is just plain wrong. You can retexture an object or an object's stage whenever you like. No need to recompile. I've done it many times and the latest project I've just finished relies on it."


How do you retexture without having to compile any DBP code? Last time I checked, changing whatever load image "file.png", 1 loads and applies can't be done on the fly.

Sure, you can replace the file with a new texture but what if you wanted the filename to be different as well as the texture?

I like offending people. People who get offended should be offended. -- Linus Torvalds
Why is my sig being erased? It wasn't over 600x120 even with the image.
Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 24th Jan 2015 23:43
I think that doing a test by loading the same object into 1000 different object indexes and comparing memory usage when they are all hardcoded in file to the same texture to the same test with non-hardcoded objects merely textured to the same image index should reveal the truth.

The gap would be massive if the textures are not being shared. Hundreds of megabytes potentially. If there is sharing the gap would be relatively small, and likely not exact.


In the test I posted with Load Image, it's true there could be a memory bug. But that would also likely mean every DBP program out there has a glaring memory leak. The memory usage in my test quickly hit 500MB before completing and was consistent with code that was not sharing the same texture. Comet also seemed to confirm the source code on this issue.

Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 24th Jan 2015 23:56
Quote: "How do you retexture without having to compile any DBP code?"


Just use:

Quote: "texture object 1, 1
texture object 1, 2"


Quote: "but what if you wanted the filename to be different as well as the texture?"


Just change the filename, perhaps? In DBPro pseudo-code:



In fact the following works perfectly for me



With a bit more work you can read the filename into a string or even use standard Windows functions to read the filename and then open the file.

I think I just don't understand what you mean?



Powered by Free Banners
TheComet
18
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 25th Jan 2015 00:05
Quote: "I think I just don't understand what you mean?"


You can load fname$ from a config file and that would be fine.

The original question was: Is it better to load an object and apply textures yourself, or is it better to let DBP load the object's textures for you?

My argument is: It's better to let DBP do the heavy lifting unless you've got a very good reason to write your own error prone resource management system for the following reason:
- Elaborate code is required to reach the same amount of modability you'd have with a simple "load object".
- DBP appears to manage duplicate textures already.

Texturing one object may be as easy to do as the code in your snippet, but OP has an object with multiple textures on different limbs. Things can get very complicated very quickly if you try to texture all of that yourself, and still wish to expose the same functionality "load object" already provides.

I like offending people. People who get offended should be offended. -- Linus Torvalds
Why is my sig being erased? It wasn't over 600x120 even with the image.
Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 25th Jan 2015 00:18 Edited at: 25th Jan 2015 00:20
I just tested this problem.

Texture Paths hard coded into object files (which auto load with Load Object command) appear to access a shared texture feature in Dark Basic Professional. Testing supports the claim that DBP will detect if that exact path and file is already loaded and use it.



I grabbed the texture and model from the DBP PRO help files. renaming the texture will cause it not to auto load the texture so this code can be used:
(make sure AST1.bmp isn't in the same folder during this test)


The difference is only a few megabytes in a thousand. It's safe to say that textures are being shared.


Load Image command was confirmed to not share textures in memory at all using this test:



Verdict:

Quote: "Cescano: Reusing the same textures for different things helps to keep low the video memory usage? or every object has his own space for his texture because of different UV Maps or UVW Unwraps?"


Yes reusing the same textures will reduce memory usage. Every loaded image will use it's own space and thus potentially waste space if they are the same image. The exception being objects that have texture paths hard coded into their object file. If their hard coded texture is already loaded by Dark Basic Pro, then it will find and link the image instead of loading it again.

Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 25th Jan 2015 00:21 Edited at: 25th Jan 2015 00:29
You've confused me even more now. That seems to have little to do with your other assertions.

Edit Sorry! This post was directed at TheComet. Mage, those findings of yours are very interesting. I certainly didn't know that load object worked that way - and it's consistent with the Help file comment that I recall reading but can't now locate.



Powered by Free Banners
TheComet
18
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 25th Jan 2015 00:30 Edited at: 25th Jan 2015 00:31
@GG - Who are you referring to?

[EDIT] In what way? I was consistently of the opinion to use load object and not apply textures manually throughout this thread.

I like offending people. People who get offended should be offended. -- Linus Torvalds
Why is my sig being erased? It wasn't over 600x120 even with the image.
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 25th Jan 2015 00:32
You - see my edit.



Powered by Free Banners
Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 25th Jan 2015 00:32 Edited at: 25th Jan 2015 00:36
Quote: "My argument is: It's better to let DBP do the heavy lifting unless you've got a very good reason to write your own error prone resource management system for the following reason:
- Elaborate code is required to reach the same amount of modability you'd have with a simple "load object".
- DBP appears to manage duplicate textures already."


My rebuttal to that is this:

- It then requires a separate object file for each texture combination you intend to use.

- Changing texture paths requires editing the objects file or possibly re-exporting the object file from source.

- If you need to store stuff like Objects name, what script to use if activated, shader, weight, etc... Why not store path names for objects, and textures along with it in a separate "Entity" file?

- Storing the information yourself is easier to modify. Doesn't require any additional software or source files.

- "error prone resource management system" allows for error handling, and fallback textures. Like a "missing texture" texture.

- hard coded textures means you can't see textures being loaded when reading the source code in the editor.

- hard coded textures may be auto loading into image indexes that you have reserved for other parts of your program.


However I will certainly concede this really depends on your situation. There's no all right or all wrong answer here.

Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 25th Jan 2015 00:36
Green Gandalf, Comet stated that having the path name for the texture coded into the object file allows someone to change the texture being used without having to change any lines of code.

So you could change the texture being used and its path without needing access to the source code. This was presented as an alternative to going into the source code, and changing lines of code to point to another texture file.

You responded with:

Quote: "
Just use:

Quote: "texture object 1, 1
texture object 1, 2"
"


Which itself requires you to change the source code and recompile.

Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 25th Jan 2015 00:47
Quote: "Which itself requires you to change the source code and recompile."


Why do you need to recompile? I think we misunderstand each other. As is evident from numerous examples there isn't any need.

Anyway, there's now no obvious disagreement that I can see about how DBPro works. My objection was to the earlier statement that you couldn't change the texture or filename in DBPro. TheComet seems to have backtracked from that claim - or did someone else say that?



Powered by Free Banners
TheComet
18
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 25th Jan 2015 01:24
Quote: "My objection was to the earlier statement that you couldn't change the texture or filename in DBPro. "


You misunderstood, I said you can't change the texture name without recompiling, or reading the info from a config file.

I like offending people. People who get offended should be offended. -- Linus Torvalds

Why is my sig being erased? It wasn't over 600x120 even with the image.
Cescano
11
Years of Service
User Offline
Joined: 4th Sep 2014
Location: Italy
Posted: 25th Jan 2015 02:00
Ok my question has been replied, I have not been able to test it because the command that show the video memory usage in db pro is bugged (it crashes the exe)
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 25th Jan 2015 02:21
Quote: " I said you can't change the texture name without recompiling"


That's what I thought you said. So, yes, I've obviously misunderstood you. I guess we can agree on that.



Powered by Free Banners
James H
19
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
Posted: 25th Jan 2015 02:30
*Note* have only skim read this post as I am pressed for time so forgive me if this has been cleared up or I have misunderstood

Perhaps the textures being shared is a feature specific to video RAM rather than RAM? A good tool to test it with might be GPU-Z by TechPowerUp, older versions may not have the video RAM usage but at the least one of the latest versions does(not got time to update right now am on my way out the front door), just have to remember to use window mode to make it easier to see it real time, if there was ever any need to test window mode against full-screen exclusive mode there is a logging option. Just thought I would mention this.
Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 25th Jan 2015 02:59 Edited at: 25th Jan 2015 03:06
Quote: "Perhaps the textures being shared is a feature specific to video RAM rather than RAM?"


It was shown earlier in the thread that the existing loaded image is detected, DBP skips loading the texture again, and merely textures the newly loaded object with the existing loaded texture. This was shown to save RAM and VRAM. This only happens when loading objects with texture paths coded into their file, where the objects texture is successfully loaded and applied inside of the Load Object command.

This is similar to loading a single image and texturing it onto multiple objects instead of loading the same image multiple times to exclusively texture each object. That is in terms of memory consumption.

The merits and drawbacks to coding the texture paths directly into object files were also discussed.

Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 25th Jan 2015 12:25
I've found the bit of the Help files which, for some totally bizarre reason I couldn't find yesterday . They clearly indicate what the Mage verified and clarified:

Quote: "(from the entry for Load Object)
You must specify a model in the X, DBO, 3DS, MDL, MD2 or MD3 format. Once you have loaded the 3D object file successfully, you can use the specified 3D object number to position, rotate, scale, animate and manipulate your 3D object. The object number should be specified using an integer value. The optional Load Mode parameter controls how the data loaded from the model is handled, and which behaviour is required. An additional Reduce Texture mode also controls a run-time scale down of the loaded texture plate. Be aware that when you load an object that has associated textures, you are handing over texture management to the engine which will attempt to save texture memory by re-using textures previously loaded from the same filename. To take over texture management, use LOAD IMAGE and TEXTURE OBJECT commands."


I now understand what the highlighted bit was telling us, so thanks to TheComet and Mage for making it clear how this feature works.



Powered by Free Banners
James H
19
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
Posted: 25th Jan 2015 16:43
@Mage Although I stated I had skim read this I should have pointed out I would read thoroughly when I have more time(today) to save you(or anyone) a further explanation(and time), not only did I skim read but seem to have missed a few posts it seems but thanks for the brief and concise explanation anyway

Login to post a reply

Server time is: 2026-07-05 03:49:44
Your offset time is: 2026-07-05 03:49:44