View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005262 | Spring engine | General | public | 2016-06-02 07:13 | 2016-12-26 19:52 |
| Reporter | Google_Frog | Assigned To | Kloot | ||
| Priority | normal | Severity | minor | Reproducibility | sometimes |
| Status | closed | Resolution | won't fix | ||
| Product Version | 101.0+git | ||||
| Summary | 0005262: 101.0.1-408 Set map texture causes grainyness when zoomed out | ||||
| Description | Squares changed with SetMapSquareTexture appear different to unchanged squares when zoomed out. They are grainy, as if the texture on other squares is blurred on zoom out. This is particularly noticable on Speedmetal because the zoom out causes beating in the modified texture. In the screenshot I have used SetMapSquareTexture on the left half of the map (except the ocean). | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| Checked infolog.txt for Errors | |||||
|
|
Also occurs in 100.0. |
|
|
"as if the texture on other squares is blurred on zoom out" that would be called "mipmapping" and it exists to prevent aliasing. if you use SetMapSquareTexture, it is your responsibility to implement similar logic with Lua. |
|
|
To clarify, do you expect lua to detect different zoom levels and apply SetMapSquareTexture as the player changes their zoom level? If so it seems very hacky. A better solution would be for SetMapSquareTexture to take a mipmap level argument and apply the texture to the appropriate zoom level. A better solution would be for the engine to do it. If there is a performance cost in processing the lua texture for mipmaps then the cost has to be paid somewhere, either in Spring or lua. If the cost is excessive then neither should implement it. |
|
|
1) Spring does not *create* mipmaps for ground-square textures, it merely chooses which level to apply when from a set assembled by the map compiler. This is already a strike against engine treatment for SetMapSquareTexture'd squares. 2) I neither want nor am going to lock Lua textures into the same algorithm, and it should be *abundantly* clear from the constant stream of issues (this one, 0005256, 0005249, 0005282, 0005186, 0005148, etcetera) arising from ZK's cargo-cult development that certain API functions come with an implicit "do not call unless you know what you are doing" disclaimer. 3) An even better solution would be for you to scan through https://springrts.com/wiki/Lua_OpenGL_Api#Textures instead. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-06-02 07:13 | Google_Frog | New Issue | |
| 2016-06-02 07:13 | Google_Frog | File Added: screen00238.jpg | |
| 2016-06-02 07:13 | Google_Frog | File Added: infolog.txt | |
| 2016-06-02 07:16 | Google_Frog | Note Added: 0016389 | |
| 2016-12-23 12:38 | Kloot | Status | new => closed |
| 2016-12-23 12:38 | Kloot | Resolution | open => won't fix |
| 2016-12-23 12:38 | Kloot | Note Added: 0016988 | |
| 2016-12-26 01:28 | Google_Frog | Status | closed => feedback |
| 2016-12-26 01:28 | Google_Frog | Resolution | won't fix => reopened |
| 2016-12-26 01:28 | Google_Frog | Note Added: 0017001 | |
| 2016-12-26 19:40 | Kloot | Note Added: 0017004 | |
| 2016-12-26 19:40 | Kloot | Assigned To | => Kloot |
| 2016-12-26 19:40 | Kloot | Status | feedback => closed |
| 2016-12-26 19:40 | Kloot | Resolution | reopened => won't fix |
| 2016-12-26 19:52 | Kloot | Note Edited: 0017004 |
