| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I believe there were some mis-understandings
about the code. It's supposed to work
StartRendering();
BeginDraw();
EndDraw();
BeginDraw();
EndDraw();
BeginDraw();
EndDraw();
FinishRendering();
To try to enforce correct usage I separated
some platform dependant stuff from shared
stuff and added a few flags.
Also in this CL I made Texture::GetRenderSurface
not require a pack. This is so I because it feels
cleaner that way but also because I wanted to
use surfaces without a pack to take a screenshot.
Finally I put some screenshot code in for GL.
Also fixed some bugs with locking textures.
1) I thought it was x, y, width, height but it's
actually x1, y1, x2, y2
2) I was using width in places I should have been
using mip_width
Review URL: http://codereview.chromium.org/174199
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24188 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also added Texture.drawImage(canvas...)
There's still the big question of whether we
should flip textures by default in the o3d code.
Currently I'm flipping them by default in
o3djs.texture.createTextureFromRawData
and I'm flipping them by default in
o3djs.canvas.CanvasQuad.updateTexture.
I'm torn whether or not I should be flipping
them. I feel like 2d examples and examples
of displaying images, like a picasa viewer,
would be simpler if we didn't flip by default
but the problem then is if you load some textures
through a collada scene they'll be flipped
the opposite of any textures you load by hand.
Review URL: http://codereview.chromium.org/171060
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23678 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL changes Bitmap to no longer be a cubemap.
Instead there is a function, Pack::CreateBitmapsFromRawData
that returns an array of bitmaps.
For a 2D image 1 bitmap is returned
For a cubemap 6 bitmaps are returned
eventually for a volumemap N bitmaps will be returned.
To distinguish between 6 bitmaps that are a cubemap
and 6 bitmaps that are slices of a volumemap there
is a Bitmap::semantic which tells what the bitmap is
intended for.
In a previous CL I had started to break Bitmap into
classes like Bitmap8, BitmapFloat, BitmapDXT1.
These were not intended to be exposed to JavaScript,
only to make the internal code get rid of lots of
if format == or case(format) stuff.
But given that it's working as is and there are more
pressing things I'm not planning to do that right now.
I can delete the classes if you think I should.
Note: This is still not 100% done. I still need to
deal with the flipping issues or at least test.
I probably need to add more tests as well.
I also got rid of any mention of resize_to_pot in
the command buffer version. Client side command
buffer should not have to deal with POT/NPOT issues.
I also moved the pot/npot stuff out of generic code
and into the platform specific code. The generic code
is not supposed to care.
This is slower than the old way but it feels cleaner.
A few issues I'm looking for input on. There's
a function, Bitmap::GenerateMips(source_level, num_levels).
It generates mips as long as they 8Bit textures.
I can easily add half and float but not DXT. Right now
if you call it on DXT in debug it prints a LOG message
but otherwise it does nothing. Should I error for DXT?
On the one hand it would be good to know that it failed
so a user will not be wondering "I called it, why are
there no mips?"
On the otherhand, from JavaScript failing would mean
you'd need to check the format before calling it which
also seems less then ideal.
The other is that currently it doesn't ADD mips, it just
replaces the ones that are there. That means if you load
a 2d image and want mips you have to allocate a new bitmap
with the number of mips you want, copy level 0 from the
old bitmap to the new bitmap and then generate mips
Should I make generate mips effectively do that for you?
Basically, if you call it to generate mips on levels
that don't yet exist in the bitmap it would realloc itself
and then generate them. Is that better?
Also, I started down the path of taking out alpha_is_one.
I'm trying to decide what to do with it. Part of me wants
to take it out completely but since it's already there
maybe I can't.
If I leave it in I was thinking of making it check every
time it's called. First I'd just make it slow. Then later
if we want I could add a dirty flag and only recheck when
it's dirty. That would be a lot of work though. It would
mean wrapping Lock and SetRect and maybe a few other things
so that we could catch any writes to the texture. It might
also mean changing Lock to take read/write flags. I think
those are good changes but again, it's not important right
now. So, the question is what to do now. I can
1) Remove alpha_is_one. That might break something out there
2) Leave it in but just have it always false.
3) Make it check every time it's accessed.
4) Do the dirty flag thing.
Preference? I'm for 2 or 3 I think.
Review URL: http://codereview.chromium.org/164235
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23051 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22872 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
| |
Review URL: http://codereview.chromium.org/165118
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22765 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The plan is to make pack.createBitmapFromRawData
return an array of bitmaps.
1 bitmap if it's a standard 2d image
6 bitmaps if it's a cubemap
N bitmaps if it's a volume map.
The bitmaps will have a semantic so you can look at them and tell
they were from a volumemap, a cubemap or a 2d image.
On the way I'm attempting to clean up the code. Moving
stuff out of Bitmap the did not belong there and
Refactoring Bitmap so there are less If Format =
stuff.
Review URL: http://codereview.chromium.org/164034
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22583 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Originally I was going to replace Lock/Unlock with
only SetRect (and maybe GetRect) and I did that.
But then as I was going through the code things started
not being so cool. The JavaScript texture.SetRect where
as before it allocated no memory, now it needed to allocate
a temporary buffer just to be able to write the texture.
DrawImage also would have have required copying the original
texture out using GetRect, then modifying it, then copying it
back even in D3D or it would have required a temporary buffer.
That's what happens under the hood in the GL implementation
of Texture2D but why should D3D suffer because of the of GL?
Or maybe it's a reasonable compomise the D3D should go slower
so that GL isn't twice as slow as it it could be?
So, I left Lock/Unlock and added SetRect as well.
This CL should help the video guys and we can decide if
we want to get rid of Lock/Unlock later.
SetRect is really only there because trying to make GL
act like D3D makes GL slow since we had to get a copy
of the texture from GL before Locking. SetRect, since
it is not exposing the original data doesn't need to do
that.
So, now there are both. If need to read (and write) to
the texture use Lock. If you only need to write use
SetRect.
I also fixed Lock/Unlock so they return a pitch which
is required for D3D. While I did that I made Lock/Unlock
private so you have to use the TextureXXXLockHelpers
to access the data.
I didn't do the command buffer versions.
I also added stubs for texture tests. We need to add
more tests.
I feel like a lot of clean up needs to happen.
It seesm like Bitmap should be split into
Bitmap2D
BitmapCUBE
BitmapVolume
Possibly. And maybe BitmapCube should effectively
just be typedef Bitmap2D BitmapCUBE[6] and
BitmapVolume would be std::vector<Bitmap2D>
Then we wouldn't need face and volume versions
of various functions. You'd just get the face or
the slice Bitma2D and then use the 2D functions.
We should decide if that's what we want before
pushing a new release. Otherwise we should remove
bitmap.idl from idl_scons.lst and the one sample
And ship without exposing Bitmap until we are
sure they API we are exposing is the one we want.
Review URL: http://codereview.chromium.org/159725
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22332 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sadly there is some really strange voodoo to make it work.
util.js was using document.getElementsByTagName('script')
and it was not returning all the scripts. Lots of dump()
lines later the voodoo of calling
document.getElementsByTagName('script').length (the length
is important) in some place earlier in the code fixes the
issue.
Also, added the copyright to the compiled file
Added parameter docs
Review URL: http://codereview.chromium.org/159049
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21085 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
| |
Review URL: http://codereview.chromium.org/150058
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20700 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
| |
Review URL: http://codereview.chromium.org/147144
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19430 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Mostly these are fixes to warnings (signed/unsigned mismatches
were the most common), and some changes to include paths.
I've updated the build.scons files and DEPS file to match these
changes so that the scons build will still function with these
changes.
Review URL: http://codereview.chromium.org/146047
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19062 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
failure (fails with the same diff on my PC)
* Added comment about the valid values for the min, mag and mip filters in sampler.idl
* Cleaned up some typos in texture.idl
* Changed the texture-set-test to use POINT filter for min and mag to avoid issues with h/w that doesn't support linear filtering of floating point textures
* Bumped up rev for o3d_assets to include new reference image for texture-set-test
Review URL: http://codereview.chromium.org/118212
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17582 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17243 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
is not built or referenced at all by the chrome build yet, and doesn't
yet build in it's new home. We'll change that shortly.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17035 0039d316-1c4b-4281-b951-d872f2087c98
|
