23 Apr 22, 04:17AM
I feel like i have to clarify a few things you might didnt thought about when talking about diskspace.
A texture of atm size 256x256 fits 4x into a 512x512 texture which is still low and washed, meaning that if you would update all textures to the next higher resolution you end up with 200 MB (if we just assume most would be textures) now lets calculate it up to 4k.
512x512 x 4 to archive 1024x1024 = game size of 800 MB
1024x1024 x4 for 2048x2048 = game size 3,2 GB
2048x2048 x 4 = game size 12,8 GB
Those are basics, remember all those values are uncompressed (the game textures at this state are uncompressed btw)
The about 30 MB for the few textures are uncompressed, it would be around 14MB after compression but after that we reach a point where you will notice color artefacts within the texture, therefore lower is impossible.
But lets look at the hardware itself, for textures alone you wont have to buy a new GPU or CPU (depending on amount where we would hit framebuffer limits) So even if it would end up with 2 GB for multiple Maps, these days you basicly get even USB sticks of 8GB for free. While even my old Acer notebook of the year 2000 has an 80 GB HDD. I mean even for the Android version...smartphones will mostly have that space and then seeing a few GB as a problem?
Again if we go for higher detailed models /more vertices we end up with higher diskspace usage and massive FPS loss, since models itself will get bigger in size, so no matter where you start...at the end it will cost alot more diskspace, there is no way around.
The newent clip command also does nothing else as the clips via hud, also i think the person you heard saying collision clips would be more exspensive compared to geometry ones, its the opposite (as i mentioned)
Still what i dont understand, why or for what would you need clips for, if they dont stop bullets (in code, the trails and bulletholes are normaly seperated, same for the detection of the "world") So i strongly believe that i either cant find the correct clips or there is none coded.
Seems like i have to use geometry itself, meaning getting ingame cube sizes and making them slightly bigger for about 0,02 or something as "overlay" over the world geometry (wqd and wvt in hud) that should be around 6000 wvt for that map maybe less, which then wont allow stencil shadows.
So for those who wanna know, we could predict the FPS by looking at maps where you have 6000 wvt/world vertices and evt/environment-model vertices of 7000. Combined around 13-14.000 verts without players.
I think many maps are within that area, so it should be around same performance but increased graphic textures. Have to see when i find time to rebuild that map to fit the Cube map editor cube sizes, until then piece
A texture of atm size 256x256 fits 4x into a 512x512 texture which is still low and washed, meaning that if you would update all textures to the next higher resolution you end up with 200 MB (if we just assume most would be textures) now lets calculate it up to 4k.
512x512 x 4 to archive 1024x1024 = game size of 800 MB
1024x1024 x4 for 2048x2048 = game size 3,2 GB
2048x2048 x 4 = game size 12,8 GB
Those are basics, remember all those values are uncompressed (the game textures at this state are uncompressed btw)
The about 30 MB for the few textures are uncompressed, it would be around 14MB after compression but after that we reach a point where you will notice color artefacts within the texture, therefore lower is impossible.
But lets look at the hardware itself, for textures alone you wont have to buy a new GPU or CPU (depending on amount where we would hit framebuffer limits) So even if it would end up with 2 GB for multiple Maps, these days you basicly get even USB sticks of 8GB for free. While even my old Acer notebook of the year 2000 has an 80 GB HDD. I mean even for the Android version...smartphones will mostly have that space and then seeing a few GB as a problem?
Again if we go for higher detailed models /more vertices we end up with higher diskspace usage and massive FPS loss, since models itself will get bigger in size, so no matter where you start...at the end it will cost alot more diskspace, there is no way around.
The newent clip command also does nothing else as the clips via hud, also i think the person you heard saying collision clips would be more exspensive compared to geometry ones, its the opposite (as i mentioned)
Still what i dont understand, why or for what would you need clips for, if they dont stop bullets (in code, the trails and bulletholes are normaly seperated, same for the detection of the "world") So i strongly believe that i either cant find the correct clips or there is none coded.
Seems like i have to use geometry itself, meaning getting ingame cube sizes and making them slightly bigger for about 0,02 or something as "overlay" over the world geometry (wqd and wvt in hud) that should be around 6000 wvt for that map maybe less, which then wont allow stencil shadows.
So for those who wanna know, we could predict the FPS by looking at maps where you have 6000 wvt/world vertices and evt/environment-model vertices of 7000. Combined around 13-14.000 verts without players.
I think many maps are within that area, so it should be around same performance but increased graphic textures. Have to see when i find time to rebuild that map to fit the Cube map editor cube sizes, until then piece