Revisions of Texture and PlatformBitmap Format types#920
Open
ggcrunchy wants to merge 27 commits into
Open
Conversation
…nd buffer and assignment logic Next up, prepare details from graphics.defineEffect()
…from Program Slight redesign of TimeTransform with caching (to synchronize multiple invocations with a frame) and slightly less heavyweight call site
Err, was calling Modulo for sine method, heh That said, time transform seems to work in basic test
Fixed error detection for positive number time transform inputs Relaxed amplitude positivity requirement
Maintenance Revert Test
My mistake adding back changes made
This reverts commit 0b5e1e9.
Following that, removed Rtt_GPU.h includes and pulled GL backend stream stuff into FrameBufferObject Isolates the GL code to tachyon, so less work on ANGLE branch, and also should be helpful for some texture support Still needs a bit of testing and some Windows checks (might still have dependencies there, although they look old too)
…ged in on Windows, although the logic that used them was #if 0'd out With these out of the way we might have decoupled GL includes
…field structs (that default to the current behavior) This is adapted from some earlier work in my FPTexture branch; the coordination between the two formats is a little more explicit... and simpler, I hope... with lazier fetching of non-core format info Also worked out a promising scheme for targets, since those would also want to at hand for coordinating with samplers
…; enough that the count matches
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
First off, this is meant to build on #918.
I did a first draft of some texture stuff last year.
A big chunk of that was adding support (where possible) for other formats, e.g. floating-point or integer ones; compression; R, RG types; etc.
It got a bit kitchen sink-y, and would have been rather impolite to submit. 😄 Thus I'm trying to do another sweep and divvy it up PR-wise, this being the first offering, along with some improvements as well.
You'd have to "skip ahead" in that branch to see how some of this is put into practice, but anyhow, when adding further texture formats, some way of conveying "what am I?" is needed, at the very least. On its own, this could just mean using more bits for some constants, and bumping the format count. A minor further complication is that many such formats might not be supported on a given setup.
Some of this information, along with further details, can be looked up from a little format database we maintain, once we're up and running.
However, when doing the earlier work I ran across many little queries, e.g. "how many bytes does this have?" or "does it have an alpha channel?", needing to be done without the handy manager around to ask. The relevant details do crunch down fairly nicely, however, and so can be crammed into the same integer as the format types themselves. (
TextureandPlatformBitmapboth maintain format types, and mostly overlap.)A few assumptions about the layout of
Texture::Format(orFormatValueas theenums get renamed, with each then enclosed in aFormatclass) lining up withPlatformBitmap::FormatValue, backed byRtt_STATIC_ASSERT()s, are made and put to use: I added some utilities in RenderTypes.cpp to do some common bitfield utilities, for getting and setting all the pieces of info. This was done a bit differently in the earlier draft, but the approach there was feeling a little brittle.Compressed texture formats were part of this work and so their details show up in this, along with a couple utilities that go with them. I hadn't done packed formats, so don't know if they would bring any surprises. But anyhow, this is all internal.
New with the PR itself, there are also some bits set aside for texture targets, so you could ensure (currently) that a
sampler2Dcorrectly pairs with a 2D texture, although it's meant to open up the whole gamut, e.g. asamplerCubeArraywon't match with aBitmapPainthaving that same 2D texture. I looked over the sampler types from ES 3.2 and most recent desktop GL to allot these bits (came out to 73 possibilities, I think); some reading suggests this generalizes to other backends, but we'll see. (There are still bits to spare.)For easier / offline reference, I saved PDF snapshots of the "changed files" from each of the draft branch's commits: FPTexture.zip This PR references parts of #1 and #8. (I collapsed mostly irrelevant local changes; forgot to expand
Rtt_GLTexture.cpp, unfortunately.)