Just wondering, should we extend the bitmap rez. settings?
I watched the Matrix again the other night, and just had to have a go at building the thing,. Note; I have it setup for the arcade machine we are building here, 800x600 TV display,. so perhaps adjust it for a high res. display. Instead of regular text I generated some alien runic type stuff,. .
I can think of multiple reasons to have smaller bitmap sizes decleared,. 8,4,2,1,. esp. things like 1 x 8 or 8 x 1024 etc.. perhaps also one or two on the top end,. no real use for this personaly (currenly) however I am sure it could come in handy,. 2048, 4096 even? (fine art prints!)
Suppose this would mess with backwards compatibility, like adding the "Use Desktop resolution" did,. only more of a pain to fix with multiple bitmaps in the project,. . so perhaps it is not that important??
bitmap size more and less,.
Moderator: Moderators
-
jph_wacheski
- Posts: 1005
- Joined: Sat Feb 16, 2008 8:10 pm
- Location: Canada
- Contact:
bitmap size more and less,.
- Attachments
-
- runictrix_003.zgeproj
- (7.56 KiB) Downloaded 636 times
iterationGAMES.com
Jph, that's a pretty convincing Matrix effect 
You are right, I can easily add higher resolutions but adding lower will break backward-compatibility. Some downsides I can think of for larger textures: they take forever to generate, lower-end graphics cards have a maximum texture resolution, BitmapRect and BitmapZoom will not operate on textures larger than screen resolution (this is a known bug that is hard to fix). But it could be useful to generate highrez pictures using a expression so I'll start by adding 2048 and 4096 to see how it works!
You are right, I can easily add higher resolutions but adding lower will break backward-compatibility. Some downsides I can think of for larger textures: they take forever to generate, lower-end graphics cards have a maximum texture resolution, BitmapRect and BitmapZoom will not operate on textures larger than screen resolution (this is a known bug that is hard to fix). But it could be useful to generate highrez pictures using a expression so I'll start by adding 2048 and 4096 to see how it works!
I'm posting this in response to the comments in the release thread. I can see a some uses for 4096 sized textures:
- generating large bitmaps in the designer and save them to disk for further processing/printing etc
- large texture can be used to contain extra data in shaders, for instance a 1x4096 texture can be seen as a 1d-array.
- large textures can be used as a height map in a vertex shader to modify geometry for a large game level
But the risk is that a user accidentally select the size 4096x4096 and believe that the program has crashed because processing time becomes huge. This can be helped by a couple of different approaches: warn the user if more than 1 million pixels will be calculated, provide visual feedback (progressbar) while generating, or generate bitmaps in a separate thread. Of these options, warn the user is the simplest to implement.
About having smaller sizes: the problem is that values are stored in zgeproj-files as numbers instead of names so if we change the order of the selectable values then the values will change when opening older zgeproj-files. There are workarounds for this too: sizes 1-8 could be set to negative values or we could start storing names ("bs1024") in zgeproj-files instead of numbers and automatically convert older files.
Both these features need more research so I suggest I'll just set the maximum size to 2048 for release 1.9.8 now, and we'll continue work on this in next beta.
- generating large bitmaps in the designer and save them to disk for further processing/printing etc
- large texture can be used to contain extra data in shaders, for instance a 1x4096 texture can be seen as a 1d-array.
- large textures can be used as a height map in a vertex shader to modify geometry for a large game level
But the risk is that a user accidentally select the size 4096x4096 and believe that the program has crashed because processing time becomes huge. This can be helped by a couple of different approaches: warn the user if more than 1 million pixels will be calculated, provide visual feedback (progressbar) while generating, or generate bitmaps in a separate thread. Of these options, warn the user is the simplest to implement.
About having smaller sizes: the problem is that values are stored in zgeproj-files as numbers instead of names so if we change the order of the selectable values then the values will change when opening older zgeproj-files. There are workarounds for this too: sizes 1-8 could be set to negative values or we could start storing names ("bs1024") in zgeproj-files instead of numbers and automatically convert older files.
Both these features need more research so I suggest I'll just set the maximum size to 2048 for release 1.9.8 now, and we'll continue work on this in next beta.
Something I found out when benchmarking on various systems. Texture lookup(s) in vertex shaders are incredibly slow on older ( GeForce 7 and older ) GPU's. Just something to keep in mind when determining minimum system requirements.
More information here in Chapter 4.
K