Hi Chris,

I'm using this version of the spec:
http://www.opengl.org/registry/specs/ARB/viewport_array.txt

On Thu, Nov 21, 2013 at 4:41 PM, Chris Forbes <chr...@ijw.co.nz> wrote:

> I was just comparing to the list in the ARB_viewport_array spec.
>
>
> On Fri, Nov 22, 2013 at 11:33 AM, Courtney Goeltzenleuchter <
> court...@lunarg.com> wrote:
>
>> Hi Chris,
>>
>> Where are you getting your defines?
>> I copied them from include/GL/gl.h
>> #define GL_VIEWPORT 0x0BA2
>> /* Scissor box */
>> #define GL_SCISSOR_BOX 0x0C10
>> #define GL_SCISSOR_TEST 0x0C11
>> #define GL_SCISSOR_TEST 0x0C11
>> #define GL_DEPTH_RANGE 0x0B70
>>
>> Ah, FIRST_VERTEX looks different.
>> #define GL_FIRST_VERTEX_CONVENTION        0x8E4D
>>
>> I'll add PROVOKING_VERTEX
>>
>> Looks like UNDEFINED_VERTEX was wrong as well.
>> (include/GL/glext.h) #define GL_UNDEFINED_VERTEX               0x8260
>>
>>  I was modelling one of the other extension xml files and they had
>> similar defines, though I could see no effect including or excluding them.
>>
>> Should I just get rid of the definitions for values that already exist in
>> gl.h or glext.h?
>>
>> Courtney
>>
>>
>> On Thu, Nov 21, 2013 at 1:00 PM, Chris Forbes <chr...@ijw.co.nz> wrote:
>>
>>> I'm surprised the build system accepts the conflicting second definition
>>> of SCISSOR_BOX at all, actually -- that's weird.
>>>
>>>
>>> On Fri, Nov 22, 2013 at 8:55 AM, Chris Forbes <chr...@ijw.co.nz> wrote:
>>>
>>>> I mean some of the values don't match the spec :)
>>>>
>>>>
>>>> On Fri, Nov 22, 2013 at 7:52 AM, Courtney Goeltzenleuchter <
>>>> court...@lunarg.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Nov 20, 2013 at 7:28 PM, Chris Forbes <chr...@ijw.co.nz>wrote:
>>>>>
>>>>>> Oops -- the 8E4E is obviously correct. Artifact of me switching how I
>>>>>> was commenting halfway through.
>>>>>>
>>>>>> On Thu, Nov 21, 2013 at 3:25 PM, Chris Forbes <chr...@ijw.co.nz>
>>>>>> wrote:
>>>>>> > These are bogus:
>>>>>> >
>>>>>> > +    <enum name="SCISSOR_BOX" value="0x0C10"/>
>>>>>> > +    <enum name="VIEWPORT" value="0x0BA2"/>
>>>>>> > +    <enum name="DEPTH_RANGE" value="0x0B70"/>
>>>>>> > +    <enum name="SCISSOR_TEST" value="0x0C11"/>
>>>>>> > +    <enum name="FIRST_VERTEX_CONVENTION" value="0x0C10"/>
>>>>>>
>>>>>
In the spec I'm using I see:

New Tokens

    Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv,
    GetDoublev and GetInteger64v:

        MAX_VIEWPORTS                                   0x825B
        VIEWPORT_SUBPIXEL_BITS                          0x825C
        VIEWPORT_BOUNDS_RANGE                           0x825D
        LAYER_PROVOKING_VERTEX                          0x825E
        VIEWPORT_INDEX_PROVOKING_VERTEX                 0x825F

    Accepted by the <pname> parameter of GetIntegeri_v:

        *SCISSOR_BOX                                     0x0C10*

    Accepted by the <pname> parameter of GetFloati_v:

        *VIEWPORT                                        0x0BA2*

    Accepted by the <pname> parameter of GetDoublei_v:

        *DEPTH_RANGE                                     0x0B70*

    Accepted by the <pname> parameter of Enablei, Disablei, and IsEnabledi:

        *SCISSOR_TEST                                    0x0C11*

Thus my confusion regarding "bogus" values.

    Returned in the <data> parameter from a Get query with a <pname> of
    LAYER_PROVOKING_VERTEX or VIEWPORT_INDEX_PROVOKING_VERTEX:

        FIRST_VERTEX_CONVENTION                         0x8E4D
        LAST_VERTEX_CONVENTION                          0x8E4E
        PROVOKING_VERTEX                                0x8E4F
        UNDEFINED_VERTEX                                0x8260




>
>>>>> What do you mean by "bogus"?
>>>>> I was emulating other extension xml files. Are these not needed
>>>>> because they are already defined in gl_ext.h?
>>>>>
>>>>>
>>>>>> >
>>>>>> > 0x8E4D
>>>>>> >
>>>>>> > +    <enum name="LAST_VERTEX_CONVENTION" value="0x8E4E"/>
>>>>>> >
>>>>>> > 0x8E4E
>>>>>> >
>>>>>> > add: <enum name="PROVOKING_VERTEX" value="0x8E4F"/>
>>>>>> >
>>>>>> > +    <enum name="UNDEFINED_VERTEX" value="0x8E4F"/>
>>>>>> >
>>>>>> > 0x8260
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Courtney Goeltzenleuchter
>>>>> LunarG
>>>>>
>>>>>
>>>>
>>>
>>
>>
>> --
>> Courtney Goeltzenleuchter
>> LunarG
>>
>>
>


-- 
Courtney Goeltzenleuchter
LunarG
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to