Aristotle's Mudlord & Rice Video
- Thread starter Aristotle900
- Start date
- Status
When I take a screenshot, I get a glitchy pic like this.
That's a bug with png alpha saving or something like that.
It says in mudlords newer builds.
Last edited:
I've got some good and some bad news:
The good news:
I implemented texture caching.
The drawback:
- Up to now it takes quite long to load the textures for big texture packs (55 seconds for gitech's Castelvania 2 pack...)
- Furthermore the memory occupation with texture caching is very high (around 800mb for the Castelvania 2 pack)
Hmm... what to do? Does anybody have an idea how to speed things up & how to reduce the memory usage at the same time?
The good news:
I implemented texture caching.
The drawback:
- Up to now it takes quite long to load the textures for big texture packs (55 seconds for gitech's Castelvania 2 pack...)
- Furthermore the memory occupation with texture caching is very high (around 800mb for the Castelvania 2 pack)
Hmm... what to do? Does anybody have an idea how to speed things up & how to reduce the memory usage at the same time?
Yeay! 
I jumped out of my chair and danced like a kid! :bouncy:
I hope you find some sort of answer to your inquiries!
...but if you don't I would think that waiting a minute for hours of perfect play is worth it, and if my 4 year old machine that I upgraded to 2gigs of RAM can handle it then most PC's should have no trouble with it.
My thought and a request I had in mind for a while would be to implement DXT (DDS) texture format compatibility and/or automatic conversion/compression. KoolSmoky's library for Glide64 has the compression stuff and he sais it should be easy to integrate (?). And, DXT format compatibility is awesome! I used it for my Body Harvest pack for Jabo and how it makes file sizes so small (only 128 KB for ANY 512x512 texture) without any loss in quality (I checked!) and how amazing it works with AF so you don't have to worry about "over detail pixelization" at a distance or high angle is incredible! The prospect of easy/automatic/editable/built-in 8 stage MIP-mapping is cool to.
Would you like me to alpha test it for you?
Ok, your turn,
Jay
I jumped out of my chair and danced like a kid! :bouncy:
I hope you find some sort of answer to your inquiries!
...but if you don't I would think that waiting a minute for hours of perfect play is worth it, and if my 4 year old machine that I upgraded to 2gigs of RAM can handle it then most PC's should have no trouble with it.
My thought and a request I had in mind for a while would be to implement DXT (DDS) texture format compatibility and/or automatic conversion/compression. KoolSmoky's library for Glide64 has the compression stuff and he sais it should be easy to integrate (?). And, DXT format compatibility is awesome! I used it for my Body Harvest pack for Jabo and how it makes file sizes so small (only 128 KB for ANY 512x512 texture) without any loss in quality (I checked!) and how amazing it works with AF so you don't have to worry about "over detail pixelization" at a distance or high angle is incredible! The prospect of easy/automatic/editable/built-in 8 stage MIP-mapping is cool to.
Would you like me to alpha test it for you?
Ok, your turn,
Jay
H
h4tred
Guest
microdev: You can get some optimization ideas from GlideHQ (I have now set up a SVN where updates to that go). koolsmoky uses plenty of clever ideas to keep mem usage down, including the unorthodox method of using ZLIB to make a texture cache.
So, feel free to look at that, since the code is GPL. It should be straightforward to even implement GlideHQ functionality. Though, that would involve weeding out the texture code you have now, but at least you are not reinventing the wheel and you are using a well optimized solution.
So, feel free to look at that, since the code is GPL. It should be straightforward to even implement GlideHQ functionality
. Though, that would involve weeding out the texture code you have now, but at least you are not reinventing the wheel and you are using a well optimized solution. 
You probably need cache management IE if something isn't used for a long time it needs expired (it's also called garbage collection). However with a game most times an area gets a series of loads. Those you don't need to keep 800Megs worth of textures.
Hatred has a point as well, you don't need to store those as uncompressed data. I suggest keeping it as a compressed image at best in memory for as long as it's needed. Make them textures (L1 and L2 caching in other words) when needed. Expire texture in video card memory and expire texture cache memory as needed. IE manage your data. You could tag a lifetime to each texture that diminishes each frame it's not used and increments each frame it is used. When it reaches zero it's dropped from physical memory.
Cyb
Hatred has a point as well, you don't need to store those as uncompressed data. I suggest keeping it as a compressed image at best in memory for as long as it's needed. Make them textures (L1 and L2 caching in other words) when needed. Expire texture in video card memory and expire texture cache memory as needed. IE manage your data. You could tag a lifetime to each texture that diminishes each frame it's not used and increments each frame it is used. When it reaches zero it's dropped from physical memory.
Cyb
microdev you should join the aristole video svn so you can submit changes there.
Last edited:
Level-based cache management has already been implemented by Rice. But: If textures expire after some time and are reloaded from hd when needed, the caching won't have any effect because the large textures would have to be reloaded, which causes stuttering. So, cache on demand won't be an option.
Maybe just (permanently) caching large textures in combination with on the fly compression/decompression will help. My biggest concern is the load time so far. Loading more than 500mb simply takes some time.
I would like to try some things out that came to my mind this night. If that leads to nothing, I will have a look at the GlideHQ implementation. GlideHQ is by sure a very good and smart solution for hires texture handling but it is more challenging to try some things by myself first before doing copy&paste jobs.
Gitech: I will send you a test version as soon as I did some optimization & "sexyfication" of the changes. As the debug-build doesn't work for me, I have to create a proper build w/o the logging/debug code, first.
Last edited:
H
h4tred
Guest
Yes, using S3TC (same algorithm as the DDS format) texture compression will help with VRAM usage, and with minimal effect on quality in cases.
OP
Aristotle900
New member
- Thread Starter
- #291
That's great Microdev! And hey, that's actually fine to atleast keep that current form of texture caching as an option, because most packs aren't that big. Also, most people have lots of RAM, and prefer high quality. And 1 minute wait time? That's nothing like X-Box 360 and PS2 games..Hehe.
Okay, about the runtime stuff, all that is super confusing, so I'm just going to find out what the plugin needs and find downloads for those run times, then post links.
Also, I can't really work on this plugin now, due to real life stuff as you've noticed. But, I'll be around when I can.
Wonderful work Microdev! Really! You are a great programmer.
Okay, about the runtime stuff, all that is super confusing, so I'm just going to find out what the plugin needs and find downloads for those run times, then post links.
Also, I can't really work on this plugin now, due to real life stuff as you've noticed. But, I'll be around when I can.
Wonderful work Microdev! Really!
You are a great programmer.
Last edited:
I wish i could help more.
The only one who has joined the SVN is h4tred.
The only one who has joined the SVN is h4tred.
I never realized that.
And now i cant change it
And now i cant change it
Can you start it over? With little info and only one member it should be easy to do at this early stage right??
Jay
Ok i will fix it up
EDIT:
REMOVED
EDIT2:
I cant seem to upload everything properly to it so i will have to stick with the other one.
Last edited:
vinipsmaker
C/C++ programmer, emacs user
What version of "Mudlord Rice Video" the "Aristotle Mudlord Rice Video" is based in?
And where are the "Mudlord Rice video" source code?
I think the plugin may become the max portable possible using all configurations from the ini file and don't may had the opengl code erased.
Sorry by my bad english. I will improve my english knowledge later.
And where are the "Mudlord Rice video" source code?
I think the plugin may become the max portable possible using all configurations from the ini file and don't may had the opengl code erased.
Sorry by my bad english. I will improve my english knowledge later.
Awesome man, thanks!
How's it coming along? Any new news today?
Do you know about DXT/DDS support? I could help by explaining how awesome it is and what it does/can do. Jabo uses it. I don't know how hard it would be to implement, do you know if it is possible?
@DD: I'm not sure if an SVN with incorrect spelling is a good idea. It will probably cause confusion and crap over time. Why can you not make a new one?
Jay
vinipsmaker
C/C++ programmer, emacs user
I think that usability and functionality are more important than correct spelling.
I work on the site. Take a look in the wiki pages and download sections.
http://code.google.com/p/aristole-video/
Soon maybe I add some screenshots of the plugin.
Very nice.
I just though I would let him know before it became too late...
BTW: There is no official AV 6.1.9 released yet. What is that file???
I just tried the rough alpha of the next release. It works as advertized... ...!!!!!!!!!!!
YAY!!!!!!!!! AMAZING!!!!
I have to clean out my underpants now! :evil:
,
Jay
I just though I would let him know before it became too late...
BTW: There is no official AV 6.1.9 released yet. What is that file???
I just tried the rough alpha of the next release. It works as advertized... ...!!!!!!!!!!!
YAY!!!!!!!!! AMAZING!!!!
I have to clean out my underpants now! :evil:
,Jay
Last edited:
- Status