players should download this:
(66k image. might take a sec to load)
and assuming they've installed islands to the default directory, overwrite the old one in
C:\program files\island\client\data\models\bldngs\
island owners who use StdHouse01.atm will need to rename it so it'll override any older versions playerside, and put it in
C:\program files\island\data\models\bldngs\,
and then update the building texture for the StdHouse model.
i'm so sick of seeing islands with the screwed up texture where the funny alien guy is hanging out on one side. enough already! :]
the love of god, players and island owners, download this
the love of god, players and island owners, download this
Last edited by hedgehog on Thu Nov 20, 2003 6:31 pm, edited 1 time in total.
AGWAAAH!
>:0D
that's really the face i just made in real life. a small noise that sounds like "AGWAAH!!" came out.
still... better than 8 bit.
1973 called.. they want their video game back
that's really the face i just made in real life. a small noise that sounds like "AGWAAH!!" came out.
still... better than 8 bit.
1973 called.. they want their video game back
oh yes, its alright for you and all your monitors n everythin.. some of us have PCs that dont cope with more than that... (mit points at the minimum spec stuff on the downloads page.) (um mit realises the minimum spec stuff is no longer on the download page and makes another note on the TDL)
Oh well.. better make the upper limit for that an option sometime soon then.
(And yes.. in the event of that option being available, higher colour-depth textures will make a difference to rendering times, same as image size - Theres pretty much a direct connection between the size of the uncompressed image and the time it'll take to render it. i.e. a 660k texture wouldl take 10times longer to render than a 66k one).
(p.s. this isn't strictly true, coz it depends a lot on the circumstances in which the texture is being used, the caching options on the video-card, the current weather etc etc, but as a general guide its a valid starting point.)
Oh well.. better make the upper limit for that an option sometime soon then.
(And yes.. in the event of that option being available, higher colour-depth textures will make a difference to rendering times, same as image size - Theres pretty much a direct connection between the size of the uncompressed image and the time it'll take to render it. i.e. a 660k texture wouldl take 10times longer to render than a 66k one).
(p.s. this isn't strictly true, coz it depends a lot on the circumstances in which the texture is being used, the caching options on the video-card, the current weather etc etc, but as a general guide its a valid starting point.)
good 'ol minimum spec.
i'm cool with sticking to some limits as long as i kind of know when and where they're well applied. for instance if that 10 times longer is still measured in milliseconds, then it probably needs to be taken with some grains of salt.
i'd guess based on that, a house would be good at 8bit RLE compressed, whereas the radio would be fine as-is. but then there's the further question of whether or not the render time is compromised by number of instances, or more of a total-number-in-line-of-sight thing, or both, or... etc.
i know you guys don't have time to get into the details, but if you've got a good reference site handy i'd be hip to checking it out so i could make some informed decisions on what should get made how. of course the other option is just my making everything jpeg and forgetting about it.
i'm cool with sticking to some limits as long as i kind of know when and where they're well applied. for instance if that 10 times longer is still measured in milliseconds, then it probably needs to be taken with some grains of salt.
i'd guess based on that, a house would be good at 8bit RLE compressed, whereas the radio would be fine as-is. but then there's the further question of whether or not the render time is compromised by number of instances, or more of a total-number-in-line-of-sight thing, or both, or... etc.
i know you guys don't have time to get into the details, but if you've got a good reference site handy i'd be hip to checking it out so i could make some informed decisions on what should get made how. of course the other option is just my making everything jpeg and forgetting about it.
Arh, yes, my bad.
RLE is only available for 8bits, mainly cos it would produce horrible comp. ratios used on anything higher, i supose (it needs lotsa pixels being the exact same color to be barely successfull).
As for quantifying the rendering time loss... Well, no idea how it's exactly done in Directx, but i hope the mapping of textures on triangles is all the video card job. Then, if you have a poor video card and a big array of houses just in front of you, all using the same texture but with different mapping calculation on each one (cos of the perspective), it may really make a difference.
I'm afraid giving a real answer here would need some real-world testing. anybody got a spare 3DFX 1st generation to dispose of ?
RLE is only available for 8bits, mainly cos it would produce horrible comp. ratios used on anything higher, i supose (it needs lotsa pixels being the exact same color to be barely successfull).
As for quantifying the rendering time loss... Well, no idea how it's exactly done in Directx, but i hope the mapping of textures on triangles is all the video card job. Then, if you have a poor video card and a big array of houses just in front of you, all using the same texture but with different mapping calculation on each one (cos of the perspective), it may really make a difference.
I'm afraid giving a real answer here would need some real-world testing. anybody got a spare 3DFX 1st generation to dispose of ?
It really isnt worth it I only mentioned the rendering time thing coz u asked if it made a difference (yes it does) but doesnt mean you need to worry about it - especially seeing as its download times that really restrict the size and amount of textures.
(Tho it is worth noting that changing to jpegs doesnt make any difference to rendering time, as all textures are expanded into a raw format once they're loaded into memory, whether they're bmps, jpegs whatever - Using Jpegs jus helps reduce download time and size. (Actually the only exception to that is .dds files which are the directX image format and come pre-converted in the native format - but they suffer from a being a bit large file-size wise.))
But anyway.. if you really want more info...
Also, as devi mentioned, the actual rasterization of the texture onto the screen can vary depending on the size of the source texture and the size it is displayed on screen. The PS2 is particularly bad at rendering a large texture to a small space, and im sure the same (or the reverse) is true with different PC vid cards.
The general procedure in most parts of the games industry is for artists to make stupidly high-res stuff which the programmers complain about, then the programmers code somethin in to automatically reduce the res without the artists knowing, giving them somethin to complain about in return when they discover whats happened. This is excepting the extremely rare occasion when an artist produces something lower-res than expected, in which case the programmer keeps very quiet in the fear that the artist will find out and re-do it 4 times larger.
Obviously with the nature of this game you'll generally have no idea how many of what is gonna be in view at any one time, so ya jus have to assume the worst.. (Another side-effect of the configurable free-world type thing. Jus imagine how easy a time wipeout or somethin has of it..)
The main issue worth thinking about here really is the minimum spec thing, and how much that affects the level of the graphics that are made for the game.
This is where consoles make life much easier - if you want 60fps, then you know theres a pretty much fixed limit for the total size of all your textures (Jus a few megs worth on the PS2) and geometry, and hence the textures & models are made and adjusted until they're within the limits. PC is a harder to define coz it starts bringing into play various other issues about who you're aiming the game at and what levels of technology are gonna be required to see it properly.
So in summary, i dont think you should stick to any particular limits except what seems reasonable for ppl to download. Graphically, the game should have the options to override anything particularly silly you try to do anyway..
Oh and dont forget that an 8bit RLE compressed bmp still has a 32-bit palette. It really is suprisingly rare that textures suffer significantly from that compression.
(Tho it is worth noting that changing to jpegs doesnt make any difference to rendering time, as all textures are expanded into a raw format once they're loaded into memory, whether they're bmps, jpegs whatever - Using Jpegs jus helps reduce download time and size. (Actually the only exception to that is .dds files which are the directX image format and come pre-converted in the native format - but they suffer from a being a bit large file-size wise.))
But anyway.. if you really want more info...
Well.. aint simple at all really to specify the rights and wrongs in terms of textures->rendering times really, depends on all sort of stuff.. For instance, comparing the house and radio - Coz the radio is only drawn once, uploading the texture to the vid card is gonna be the most significant part of the rendering time for it, and hence reducing the texture size will make more of a difference to its overall drawtime. The houses/buildings meanwhile - in general - are grouped and rendered in batches according to the texture they use.. the texture is only uploaded once and then its the geometry rendering that'll be the significant time consumer. ( I say 'in general' because there may be cases where this is not always the case - for example, because some ' idiot' (;)) demanded larger buildings that didnt clip I had to strap in some special code that doesnt go thru the normal 'efficient' rendering system... lots of large buildings with large textures would be realllly bad. ) Usually, of course, drawing the couple of polygons used on the radio is gonna take a load less time than any number of houses, but then again, some video cards/PCs are gonna be shinola hot at dumping out geometry but absolutely useless at uploading textures and might actually take longer to draw the radio than a couple of houses (unlikely but possible) - this all can depend on the card type, the screen res, the amount of other stuff running in the background, the supported graphic formats of the video card, the detail level of shadows and any number of other bits n pieces etc etc."i'd guess based on that, a house would be good at 8bit RLE compressed, whereas the radio would be fine as-is. "
Also, as devi mentioned, the actual rasterization of the texture onto the screen can vary depending on the size of the source texture and the size it is displayed on screen. The PS2 is particularly bad at rendering a large texture to a small space, and im sure the same (or the reverse) is true with different PC vid cards.
The general procedure in most parts of the games industry is for artists to make stupidly high-res stuff which the programmers complain about, then the programmers code somethin in to automatically reduce the res without the artists knowing, giving them somethin to complain about in return when they discover whats happened. This is excepting the extremely rare occasion when an artist produces something lower-res than expected, in which case the programmer keeps very quiet in the fear that the artist will find out and re-do it 4 times larger.
In general its whats in view that matters. But then again, on some occasions certain buildings and stuff will go thru the main rendering process even when u can't see em.....number of instances, or more of a total-number-in-line-of-sight thing..
Obviously with the nature of this game you'll generally have no idea how many of what is gonna be in view at any one time, so ya jus have to assume the worst.. (Another side-effect of the configurable free-world type thing. Jus imagine how easy a time wipeout or somethin has of it..)
http://www.flipcode.com is probably the best site for serious developer info.. but as i said, its really not worth itif you've got a good reference site
The main issue worth thinking about here really is the minimum spec thing, and how much that affects the level of the graphics that are made for the game.
This is where consoles make life much easier - if you want 60fps, then you know theres a pretty much fixed limit for the total size of all your textures (Jus a few megs worth on the PS2) and geometry, and hence the textures & models are made and adjusted until they're within the limits. PC is a harder to define coz it starts bringing into play various other issues about who you're aiming the game at and what levels of technology are gonna be required to see it properly.
So in summary, i dont think you should stick to any particular limits except what seems reasonable for ppl to download. Graphically, the game should have the options to override anything particularly silly you try to do anyway..
Oh and dont forget that an 8bit RLE compressed bmp still has a 32-bit palette. It really is suprisingly rare that textures suffer significantly from that compression.
right. yeah that last bit makes sense :](/quote)
(edit: doh! you got rid of that markup on the end! my joke hath been castrated. i use the term joke loosely.)
anyway i went ahead and replaced both those with 8bit RLE'd versions, so future downloaders should be all set. i got spoiled with some of the other stuff i s'pose
still beats feckin' web design anyway.
woulden't it be much easier (probably faster too) for just the island owners to get it and use it under the name stdhouse01m.bmp? since its possible (according to mit) to convert the models preserving the mapping and thus still making accurate use of the origional stdhouse01.bmjp texture.
<--knows most of his hosted islands still use textures that look backwards
eventually, that'll be fixed.
<--knows most of his hosted islands still use textures that look backwards
eventually, that'll be fixed.