SRec 2.x on github

	Bottom Previous Topic Next Topic
Register To Post

« 1 ... 6 7 8 (9) 10 »

salass00

Re: SRec 2.x on github

Posted on: 2016/10/19 7:25 #161

Just can't stay away

@Hans

Don't take any stress on my account. It wasn't meant as criticism, I just wondered if there were some technical problems associated with it since AFAIK the old Warp3D doesn't support it.

salass00

Re: SRec 2.x on github

Posted on: 2016/11/16 11:31 #162

Just can't stay away

SRec 2.6 is now available:

https://github.com/salass00/srec/releases

Raziel

Re: SRec 2.x on github

Posted on: 2016/11/18 7:28 #163

Home away from home

@salass00

Nice, thanks for the update

--

game box/art scans
scummvm infrequent builds

Elwood

Re: SRec 2.x on github

Posted on: 2016/11/18 22:43 #164

Just can't stay away

Thanks Salass00

Philippe 'Elwood' FERRUCCI
Sam460ex 1.10 Ghz
http://elwoodb.free.fr

walkero

Re: SRec 2.x on github

Posted on: 2017/5/17 14:05 #165

Site Builder

@salass00
The sound recording is something that you develop or there will be no chance to have such a feature?

I am pretty sure that if this is implemented then more people will be able to create videos and spread the word of AmigaOS to the world.

Follow me on
Ko-fi, Twitter, YouTube, Twitch

salass00

Re: SRec 2.x on github

Posted on: 2017/9/8 13:22 #166

Just can't stay away

@Hans

Quote:

@salass00
Quote:

XviD codec might be worth considering but only if the RGB to YUV conversion could be done using the GPU. The others are just a waste of time.

You'll be able to do this once I get bitmap-as-texture implemented in Warp3D Nova.

I noticed that bitmap-as-texture is now supported in the latest Warp3D Nova, however the W3DNBMFmtInfo example reports all the YUV pixel formats as unsupported so I assume I still can't use it to render into a YUV bitmap?

Edit: I guess what I could do is allocate a PIXF_ALPHA8 bitmap for the render target that is 1.5x as high as the source bitmap and then render the Y, U and V planes to it in different passes.

Edited by salass00 on 2017/9/8 14:51:12

Hans

Re: SRec 2.x on github

Posted on: 2017/9/8 22:46 #167

Home away from home

@salass00

AFAIK, the hardware doesn't support YUV render targets. You could easily render YUV444 to a standard ARGB bitmap. However, I assume you want YUV420p/410p, which are planar formats, in which case your idea is the way to go:
Quote:

I guess what I could do is allocate a PIXF_ALPHA8 bitmap for the render target that is 1.5x as high as the source bitmap and then render the Y, U and V planes to it in different passes.

.

Hans

Join Kea Campus' Amiga Corner and support Amiga content creation
https://keasigmadelta.com/ - see more of my work

salass00

Re: SRec 2.x on github

Posted on: 2017/9/9 12:28 #168

Just can't stay away

@Hans

Is there any way to get more information about why context->Submit() failed?

For me right now it's returning a zero submit ID and zero as error code, which is less than helpful...

Hans

Re: SRec 2.x on github

Posted on: 2017/9/11 1:06 #169

Home away from home

@salass00

Submit() isn't failing; the queue is empty (as in, there are no draw commands to submit. The error code should be W3DNEC_QUEUEEMPTY, so I'll fix that.

Hans

Join Kea Campus' Amiga Corner and support Amiga content creation
https://keasigmadelta.com/ - see more of my work

salass00

Re: SRec 2.x on github

Posted on: 2017/9/11 7:13 #170

Just can't stay away

@Hans

Thanks for the explanation.

I added some more error checking (I had missed adding it on some functions apparently) and now I get an error from FBBindBufferTags().

It is "Error 9: unsupported bitmap/texture format" but bitmap is PIXF_ALPHA8 which W3DNBMFmtInfo lists as "can be texture, can be rendered to, max width: 16384, max height: 16384". It should also be nowhere near the max width and height values.

Hans

Re: SRec 2.x on github

Posted on: 2017/9/11 7:34 #171

Home away from home

@salass00

Are you using W3DNTag_Texture instead of W3DNTag_BitMap by any chance? W3DNTag_Texture is for Warp3D Nova textures, whereas W3DNTag_BitMap is for graphics.library bitmaps.

This is where I wish we had a debug layer which would catch such things and tell you what you're doing wrong.

Hans

Join Kea Campus' Amiga Corner and support Amiga content creation
https://keasigmadelta.com/ - see more of my work

salass00

Re: SRec 2.x on github

Posted on: 2017/9/11 7:47 #172

Just can't stay away

@Hans

No, the FBBindBufferTags() call is:


errCode = context->FBBindBufferTags(NULL, W3DN_FB_COLOR_BUFFER_0, W3DNTag_BitMap, yuv_bm, TAG_END);

if (errCode != W3DNEC_SUCCESS) {

    fprintf(stderr, "Failed to bind target bitmap!\nError %u: %s\n",

        errCode, IW3DNova->W3DN_GetErrorString(errCode));

    goto cleanup;

}

and the BitMap is allocated as:


yuv_bm = IGraphics->AllocBitMapTags(width, height + (height / 2), 8,

    BMATags_Friend,      screen->RastPort.BitMap,

    BMATags_PixelFormat, PIXF_ALPHA8,

    BMATags_Displayable, TRUE,

    TAG_END);

where screen is a pointer to the default public screen, which is also passed to W3DN_CreateContextTags() using the W3DNTag_Screen tag.

Hans

Re: SRec 2.x on github

Posted on: 2017/9/11 9:45 #173

Home away from home

@salass00

Which version of Warp3D Nova are you using? Looking at the logs, PIXF_ALPHA8 has been supported as a render target since about v1.37.

Hans

Join Kea Campus' Amiga Corner and support Amiga content creation
https://keasigmadelta.com/ - see more of my work

salass00

Re: SRec 2.x on github

Posted on: 2017/9/11 10:22 #174

Just can't stay away

@Hans

Both Warp3DNova.library and W3DN_SI.library are version 1.43 (3.8.2017).

Hans

Re: SRec 2.x on github

Posted on: 2017/9/11 10:42 #175

Home away from home

@salass00

Sigh. GetBitMapAttr() returns PIXF_CLUT instead of PIXF_ALPHA8, and CLUT bitmaps are NOT valid render targets.

Hans

Join Kea Campus' Amiga Corner and support Amiga content creation
https://keasigmadelta.com/ - see more of my work

salass00

Re: SRec 2.x on github

Posted on: 2017/9/11 15:03 #176

Just can't stay away

@Hans

Yes, it seems to do that.

Maybe you can add a tag to force treating a PIXF_CLUT bitmap as PIXF_ALPHA8?

Other than that GetBitMapAttr() could be modified to return PIXF_ALPHA8 but the question is if this will have repercussions, like breaking something else.

Hans

Re: SRec 2.x on github

Posted on: 2017/9/12 1:21 #177

Home away from home

@salass00

I'll just silently treat PIXF_CLUT as an alpha map, and also fix GetBitMapAttr(). The deprecated p96GetBitMapAttr() actually returns the correct value.

However, that does mean waiting for updated versions to be released...

Hans

Join Kea Campus' Amiga Corner and support Amiga content creation
https://keasigmadelta.com/ - see more of my work

salass00

Re: SRec 2.x on github

Posted on: 2017/9/12 12:47 #178

Just can't stay away

@Hans

Thanks.

Now that GetBitMapAttr() returns PIXF_ALPHA8 I've managed to get my shader based RGB to YUV420P conversion code working.

BTW do you know what package I need to install to get glslangValidator on my Ubuntu system, or where I can get the source code so I can compile it myself?

salass00

Re: SRec 2.x on github

Posted on: 2017/9/12 13:50 #179

Just can't stay away

Comparing with a similar CPU based RGB to YUV420P conversion routine the CPU based one takes about 177 ms for one 1920x1080 32-bit bitmap and the shader based one takes only 2.5 ms.

broadblues

Re: SRec 2.x on github

Posted on: 2017/9/12 16:43 #180

Home away from home

@salass00

The glslang port is based on the glslang-3.0 src release.

Later versions had issues, though I forget what they were now, possibly dropping some language features

Src was from :

https://github.com/KhronosGroup/glslang

I have the original src archive I downloaded if you need it.

Can't find the exact link as loonix doesn't put the url in the file comment like most amiga apps.

Blender For OS4.x : Blues : Walker Broad

Register To Post	« 1 ... 6 7 8 (9) 10 »
	Top Previous Topic Next Topic

Currently Active Users Viewing This Thread: 5 ( 0 members and 5 Anonymous Users )