Some textures are loaded into memory and saved here because they are used frequently which prevents the game stops every time you for example load window... For example Monster's maps....Originally Posted by mootie
Some textures are loaded into memory and saved here because they are used frequently which prevents the game stops every time you for example load window... For example Monster's maps....
i kno, but if u remove several types of quality textures it saves up memory usage, i thought this would be clear. this wont bring much effort when the game is not using HQ textures in the RAM right now.
Wow haven't seen such show of lack of knowledge for a long time... EVERY game loads only 1 type of textures... So if you set it to low it will load only textures from low folder.
how can u say that? far objects are using lower textures while near objects use higher textures in many games to allow weak vid cards to render the environment without client lags mostly.
well thats at least the thing i was believing on, since ie.
flyff doesnt show any texture changes while changing the graphic settings.
if u say im wrong now, explain me why it never did at me.
whatever, im not game developer / expert, i just shared my thoughts.
You must be new to RZ's FlyFF section. Bathroom's down the hall and to the left.
Texture memory usage depends on a few things really. Sure you have the raw texture size and format, but you also have some runtime options like pooling and mip levels.
Typically when choosing a pool, you have D3DPOOL_DEFAULT and D3DPOOL_MANAGED. D3DPOOL_DEFAULT has only one copy of the data in the video card's memory, while D3DPOOL_MANAGED keeps a copy in both video and system memory. While the DEFAULT pool has its uses [Dynamic textures, render targets, etc], it's generally suggested that maps use the MANAGED pool. The main reason for that is when the program loses exclusive access to the rendering device, all its resources are evicted from video memory and have to be re-acquired. Since the textures are already in RAM, D3D doesn't have to read them from the file and [possibly] decompress them, allowing it to restore a bit faster. Additionally, though I don't know any specifics, D3D has an easier time managing MANAGED resources, as the other pools are sort of "out of it's reach". From what I can see [at least from MF], FlyFF uses D3DPOOL_MANAGED, and while it does use extra RAM, I would HIGHLY suggest you don't change it, at risk of destabilizing the client even more than it already is.
Additionally, you have mipmap chains. There is a LOT that can effect which maps are generated, but by default, if you put 0 for the MipLevels parameter of the D3DX load texture functions, it will generate a full chain. A full chain for, say, a 512x512 texture will have the sizes 512x512, 256x256, 128x128, 64x64, 32x32, 16x16, 8x8, 4x4, 2x2, 1x1. Obviously that's quite a bit of seemingly wasted memory, so what's the point of mip chains?
It depends on the filtering you use. If you look at D3DX_FILTER, FILTER_NONE and FILTER_POINT do not actually get any advantage from mipmaps, but look at the description for FILTER_LINEAR and FILTER_TRIANGLE. Linear: "This filter works best when the scale on both axes is less than two." When rendering a pixel, the video card calculates two parameters, ddx and ddy, that determine the texture scaling of that pixel and BY EXTENSION which mipmap to use, to try to keep the pixel ratio in the maps 1:1. FILTER_TRIANGLE, on the other hand, says "Every pixel in the source image contributes equally to the destination image." Every pixel in the map -per pixel-. Obviously having a 512x512 map for something so far off in the distance that you can barely see it would be a -major- waste of processing power. [The other filters are either only used for generating mipmaps or act as optional filtering settings.] So for modern games, mipmaps are a sort of trade off between memory and rendering speed. Lastly, mipmaps, when used on D3DPOOL_MANAGED resources, are also stored in system memory.
Obviously stuff that wont roll off into the distance [e.g. GUI windows] wont need mipmaps, so maybe you can try to save some memory on that by setting the chain length to 1. Hopefully the above rant'll help you figure out the best options to chose when loading textures and such.
For fun: Here's a pic where someone blended different colours with the various mip map levels and rendered a typical scene with em.
Addi you have some right but look VibeTribe thinks that Flyff uses Textures from Low folder even while you set to high which is not true... If you make little changes in source you can use one folder and then see that flyff actually needs only one type of texture... Btw what directx settings in app have to what we said?
Can't comment there, we have a custom resource system that doesn't have a high and low folder and I don't have FlyFF's v15 source. If I were to take a guess though, changing -all- the textures currently being used would probably be too complicated for FlyFF's original devs, meaning at the very least, the client would have to be restarted to see any changes. I do recall noticing a minor improvement in the look of the armor and such back when I played eFlyFF though when I switched from low to high and restarted. I wonder if it'd work if you just switched it, unequipped yer armor, and put it back on. xD
Not sure what you mean by that.
maybe this was only at the pserver i was playing on for a long while, then just ignore it, jomex.
addi, thanks for the impressive lesson of texture memory usage.
i just wanna know what i may dedicate to learn c++ for understeand flyff's source in the future to make my own projects, systems, customs etc?
That's a very open question. I'd need more specifics to answer that. Do you want to be a professional developer, or just do private servers for a hobby(without profit)? When you finish your "projects", do you care if they have minor bugs/issues?
No, i want to be a professional. I wanna have knowledges just for make my own projects for flyff, new system or ever update de v15 source to new versions
What kind of some bugs?
Good Morning.
Everyone learns differently, but you'll need to at least know C++ syntax and basic networking. Most developers can code *anything* given the proper time, but what makes a developer is quality and efficiency. This comes with deliberate practice(challenging yourself and pushing your limits to improve).
Another big thing is practice, practice, practice. Write a program, throw it out, write it again, and experiment with it. Memorization can be helpful too however it's not needed due to Google. If your ever having trouble with thinking through the logic of something you can also visually draw it out with a chart. I'm actually not too big on charts, but in some cases they do help me.
I would say if you want to be a professional C++ developer, you should have most of the commonly used functions memorized. Looking at reference may not seem to significantly slow you down, but it does since it can cause you to lose some focus.
Planning in general is also essential for larger projects and can save a LOT of time especially when dealing with objects that require exclusive access such as thread writes.
Adequate research is also very important. The general term, "Don't reinvent the wheel," should be used in most cases where there is a suitable solution available or documented.
Whats the issues with the reading from .res Files if you compile all in VS2012.
I readed alot of times that the issue is caused by time_t and dword on some convertions.
But i dont know why it dont read correct from the res files.
Last edited by Exploides; 14-01-13 at 08:34 PM.
