this fixes a small issue where dx doesnt like an empty target, if we do target[0] = backbuffer and target[1] = $outTex it was complaining that target[0] was null. When using the backbuffer this would be null because we write to that a different way.
These changes allows for multiple color targets from a post effect pass.
This is not 100% complete yet as the api still expects 1 target out from a posteffect and will not pass those on to other stages in a posteffect chain but will be adding that soon. This is a working state and everything renders correctly here.
- Clicking the [...] button from the Particle Emitter tab now opens to the Particle tab *and* properly selects the particle data to be edited
- Selecting an emitter object in the map and opening the particle editor now selects the Particle Data to be edited
- Selecting a new Particle Data for a particles slot on a Particle Emitter in the editor now correctly updates the values and updates the field display
- Made it so if clicking [...] button on the ParticleEmitterData or other similar fields for objects, it will now open to the Particle editor instead of the Datablock editor
add minimal padding to counteract floating point flurrer when rounding due to changes in parent element scale
revisit the aspect maintining resizer math to correct a few failures with live editing the values.
the player class (and resource derivatives, contain a mix of hardcoded animation names, as well as scriptable ones that can be tripped via playthread/setActionThread.
to determine if an animation within the stored vector is hardcoded or a scripted oneoff for that mesh, theres a demarcation at NumTableActionAnims for the up to 512 animation slots available.
when deriving from player, we must therefore allow that entry to be overridden for any class which adds additional hardcoded animations
therefore this introduces a datablock-level entry for the marked slot.
update bitmapPng reading from libpng to have context in warnings and errors, also add a bit of a better structure around the read and write functions.
Interlaced PNG's were never being accounted for before so add the png_set_interlace_handling for interlaced pngs
clearing the active program caused issues during a target bake as we call glClear after setting the shader etc. As this warning id 131204 seems to be a product of doing this, everything i read up on it says it is safe to silence it.
The core of this issue was the unlock on the GFXGLTextureObject
Few other bug fixes around setting a texture binding to 0, notice in clear function we now also clear the glprogram and the buffers. This seems to fix most of the warnings around id 131204
This warning was triggered every frame, now it just triggers when a shader expects a texture but none is active.
player and vehicle were not loading some of thier sounds.
we'll want to revisit this with a more comprehensive solution in the future, but this will at least allow folks to use the systems in place
if for some reason, function VerveEditor::CreateField( %targetStack, %fieldName, %fieldType ) is called without a %fieldType, the eval call was crashing. this fixes the imediate issue, but I'd advise followup tracing.
There is an exception on teardown usually during a debug build that is caused during shapeBase onRemove calling hasAccumulation.
This fix reorders the hasAccumulation check to be before shapebase calls Parent::onRemove, and also hard sets the mMaterialList to NULL when setMaterialList is called
