Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
47 user(s) are online (32 user(s) are browsing Forums)

Members: 1
Guests: 46

sailor, more...

Headlines

 
  Register To Post  

(1) 2 »
How to manually initialize a bitmap
Just can't stay away
Just can't stay away


See User information
I want to be able to render directly to a texture in video memory. How can I do that? I'm thinking, that I somehow need to create a bitmap structure for that texture, that I can then pass on to the minigl CreateContext call. But I can find no information on how to set up the planes[] pointers in truecolor mode.

Go to top
Re: How to manually initialize a bitmap
Home away from home
Home away from home


See User information
Quote:

alfkil wrote:
I want to be able to render directly to a texture in video memory. How can I do that? I'm thinking, that I somehow need to create a bitmap structure for that texture, that I can then pass on to the minigl CreateContext call. But I can find no information on how to set up the planes[] pointers in truecolor mode.


The simple answer is, you can't.

Any attempt to do this would be a horrible hack. Firstly, you're not supposed to go poking about in the Warp3D structures. If you do, any update that changes those structures could stop it working, and nasty things could happen. Secondly, "truecolour" and chunky bitmaps are created by Picasso96 (or Cybergraphics on other systems), and the way that the bitmap is set up is internal to Picasso96. There is no way to manually create them. Once again, trying to do this manually could blow up with any Picasso96 update.

Warp3D was going to get render-to-texture functionality, but it never happened.

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
Go to top
Re: How to manually initialize a bitmap
Quite a regular
Quite a regular


See User information
Technically, you can render to screen, capture the image and make a texture with it ... it works ... but it's terribly slow :( ...

All we have to decide is what to do with the time that is given to us.
Go to top
Re: How to manually initialize a bitmap
Just can't stay away
Just can't stay away


See User information
@Hans

Thanks for the answer. This is really bad news, though, since it destroys that possibility for fixing the speed issues in Qt .

@freddix

Since speed is the issue in the first place, this is probably not going to help me much... I might try, though, just for the heck of it.

Go to top
Re: How to manually initialize a bitmap
Home away from home
Home away from home


See User information
@Alfkil

Do you really mean 'render to texture' ? Or just render to a bit map (which you later blit to a screen or something similar).

The two things are quite different and as Hans says you can't do the first but you can pass your own bitmaps to minigl instead of allowing it to allocate them for you.

In answer to the question in the title, then no there is no way to manually initialise a bitmap, you must use picaso96 calls (or graphics library) to do it.


Go to top
Re: How to manually initialize a bitmap
Just popping in
Just popping in


See User information
@alfkil

May I suggest you provide more detail on your QT speed issue?

Someone else may have an idea for you given the issue you are facing.

Go to top
Re: How to manually initialize a bitmap
Just popping in
Just popping in


See User information
There is a possibility to write directly to a BitMap, but BitMaps have to be allocated by AllocBitMap() or p96AllocBitMap(). If you want to play with video memory it must be attached somehow with BitMap, that's how video drivers work. To manually manipulate on video memory call p96LockBitMap() and p96UnlockBitMap(). The other way is to read pixel array with p96ReadPixelArray() to read pixel array into the bitmap and then write pixel array with p96WritePixelArray() (Picasso96API.doc).

Go to top
Re: How to manually initialize a bitmap
Just can't stay away
Just can't stay away


See User information
@alfkil

Only old-style planar bitmaps can be initialized manually. Any other types must be created with either IP96->p96AllocBitMap() or IGraphics->AllocBitMap().

Go to top
Re: How to manually initialize a bitmap
Just can't stay away
Just can't stay away


See User information
@broadblues

I really mean "render to texture", yes.

The problem I am facing is this: QPixmap is a memory representation of an image. This image can be rendered to the screen in various ways: It can be tiled, rotated, streched and perspectiviced (for instance if you attach it to a QBrush and use this brush for drawing). For all this to be possible, it needs to be represented as an opengl _texture_. Simple blits will not do, so I cannot just use a standard bitmap.

Now, lots of Qt's functions depend on the possibility to be able to render stuff into your QPixmap. On the current implementation the Qt rendering engine can only do this, by using the software renderer (called "raster engine"), and then grab the result as a texture. This is the main reason, that so much of Qt is so slow at the moment.

The only possibility I can see at the moment is to use freddix suggestion of allocating a bitmap, doing the rendering into that bitmap, and then grab the result as a texture. This is probably not going to be very much faster than what we have now, but it is the only option at the moment (that is, until we get a proper MESA implementation).

Go to top
Re: How to manually initialize a bitmap
Home away from home
Home away from home


See User information
@alfkil

Btw, what is interesting for me, its if QPixmap works now in SW mode, its mean that its should be the same 1:1 as AmyCygnix version, right ? But as it much slower, then looks like the main slowness, somethere on the stage when MiniGL itself do that SW->texture->SW transformation. Because AmiCygnix also use P96/graphics.library stuff, and because of this, we can think that its not p96/graphics.library/os related, but exactly w3d/minigl. But still for me its a bit strange, why its slower that amycygnix, its should do the same 1:1 in SW mode imho..
Or i miss some important steps which do minigl only ? (like reading/uploading in SW as texture, which is the main problem)

It is unpossible to disable opengl usage only for QPixmap , and so, it will be fully SW as on amycygnix, and will be fast enough (and even faster than on amycygnix), nope ?

One more moment which i can't understand, its why first versions of QT was more or less fast. I think its because OpenGL was just not introduced, and everything was plain SW, and not "upload-render-in-SW-as-texture" ?

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: How to manually initialize a bitmap
Just can't stay away
Just can't stay away


See User information
@kas1e

I'm only guessing, but I think the reason, that AmiCygnix version of Qt is faster than the current version in some respects is, that it is in fact _not_ the same rendering engine. The "raster" engine might be slower in some respects, than the "X11" engine.

Also, the reason that for instance the embeddeddialogs example was faster in the first version, is probably, that I was using some kind of "direct screen" rendering, which was changed later to use the backingstore screen update thingy. As far as I recall, there was some problem with doing rendering directly, I cannot recall what.

Please note, that not all examples are slower than the corresponding amicygnix version. For instance the animatedtiles example is _a lot_ faster with minigl than with amicygnix (because it doesn't need to manipulate the pixmaps, just throw them up on the screen).

Go to top
Re: How to manually initialize a bitmap
Home away from home
Home away from home


See User information
Quote:

alfkil wrote:
@broadblues

I really mean "render to texture", yes.

The problem I am facing is this: QPixmap is a memory representation of an image. This image can be rendered to the screen in various ways: It can be tiled, rotated, streched and perspectiviced (for instance if you attach it to a QBrush and use this brush for drawing). For all this to be possible, it needs to be represented as an opengl _texture_. Simple blits will not do, so I cannot just use a standard bitmap.


You can do bitmap rotation, scaling and 2D warping using CompositeTags() with vertex arrays.

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
Go to top
Re: How to manually initialize a bitmap
Just can't stay away
Just can't stay away


See User information
@Hans
Quote:
You can do bitmap rotation, scaling and 2D warping using CompositeTags() with vertex arrays.

If there was any kind of instructions how to do that or if it works with current public SDK even.

Rock lobster bit me - so I'm here forever
X1000 + AmigaOS 4.1 FE
"Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
Go to top
Re: How to manually initialize a bitmap
Just can't stay away
Just can't stay away


See User information
@Hans

Thanks for the pointer, I'm currently checking out the autodocs on it. One think that springs to mind is, how can I do rotation with it?

In any case, it is not going to be easy to assert, if this will work or not, it will require heavy customization of the opengl code. So don't expect it to happen anytime soon.

Go to top
Re: How to manually initialize a bitmap
Home away from home
Home away from home


See User information
@TSK and @alfkil

The SDK does have the definitions in graphics/composite.h for vertex arrays. However, the documentation didn't make it into the autodocs.

Basically set COMPTAG_VertexFormat to COMPVF_STW0_Present, and pass a pointer to your vertex array via the COMPTAG_VertexArray tag. Set COMPTAG_NumTriangles to the number of triangles that you are rendering.

Your vertex array should be an array of floats, with each vertex being:
typedef struct Vertex_s {
   
float xy;
   
float stw;
Vertex_t;



X and y are the destination coordinates, while s, t, and w are the source coordinates. Set w to 1.0f, unless you wish to do perspective corrected mapping.

WARNING: There is no software fallback for vertex-array based compositing.

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
Go to top
Re: How to manually initialize a bitmap
Just can't stay away
Just can't stay away


See User information
@Hans

Really really big thanks !

This is exactly the information I was looking for a couple of years ago here on amigans.net. But the only answer I got was telling to use minigl instead of compositing engine. But using compositing engine is better and easier on some tasks. You can do more with a single function call.

Quote:
WARNING: There is no software fallback for vertex-array based compositing.

Do this mean full 3D support is required or hardware compositing only ? I mean, do this vertex stuff work with current public RadeonHD drivers ?

@Hans + everybody
Btw. Do anybody know how to use compositing engine to do blue/green screen stuff ?

+ Now, if somebody could teach me how to manipulate alpha channel stuff ? For example, half of a window area being dark and the other half being bright.

Rock lobster bit me - so I'm here forever
X1000 + AmigaOS 4.1 FE
"Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
Go to top
Re: How to manually initialize a bitmap
Home away from home
Home away from home


See User information
Quote:

TSK wrote:
@Hans
Quote:
WARNING: There is no software fallback for vertex-array based compositing.

Do this mean full 3D support is required or hardware compositing only ? I mean, do this vertex stuff work with current public RadeonHD drivers ?

Hardware compositing is required. The public Radeon HD driver only supports compositing for the X1000 series, so you won't be able to use this feature with Radeon HD cards.

Quote:

@Hans + everybody
Btw. Do anybody know how to use compositing engine to do blue/green screen stuff ?

No. That's not possible. Chroma-keying is a different operation. You'd have to convert the blue/green to an alpha-channel mask.

Quote:
+ Now, if somebody could teach me how to manipulate alpha channel stuff ? For example, half of a window area being dark and the other half being bright.


You could start by creating an ARGB bitmap, and then use the fill rect operation to render a rectangle with the alpha set to 0 (i.e., completely transparent), and another rectangle with the alpha set to 1. You can also lock the bitmap and write pixels complete with the alpha channel that way. A basic composite with transparency is a src-over-dest operation, and you should set the "ignore dest alpha" flag.

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
Go to top
Re: How to manually initialize a bitmap
Just can't stay away
Just can't stay away


See User information
@Hans
Quote:
typedef struct Vertex_s {
   float x, y;
   float s, t, w;
} Vertex_t;

Edit: Nevermind. I believied I could do something which is not possible. (Which is even logical anyway.)

Quote:
blue/green screen stuff

Quote:
Chroma-keying is a different operation

I didn't mean real blue screen but how Apple does it changing background on the fly when you're sitting in front of a web cam.

Quote:
You could start by creating an ARGB bitmap, and then use the fill rect operation to render a rectangle

Quote from Autodocs for SetRPAttrs() and RPTAG_APenColor: "The alpha part is currently ignored and should be set to 0xFF".

So it looks like no chance at the moment.


Edited by TSK on 2011/7/7 0:11:21
Edited by TSK on 2011/7/7 0:12:06
Rock lobster bit me - so I'm here forever
X1000 + AmigaOS 4.1 FE
"Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
Go to top
Re: How to manually initialize a bitmap
Just popping in
Just popping in


See User information
@TSK
Quote:

Quote from Autodocs for SetRPAttrs() and RPTAG_APenColor: "The alpha part is currently ignored and should be set to 0xFF".

So it looks like no chance at the moment.


This part of the autodoc actually needs an update. Of course you can render into the alpha channel of an ARGB bitmap. What is written here only applies to bitmaps that are meant for display (a window, a screen, a backbuffer...).

Go to top
Re: How to manually initialize a bitmap
Quite a regular
Quite a regular


See User information
Quote:
It looks like w does nothing. No matter what value I put there nothing changes and the picture looks twisted when rotating it around x or y axis.


Here's the amended part of the Autodoc for CompositeTags:

Quote:
* VERTEX ARRAY MODE
*
* Instead of using a rectangle, the Composite call can also use
* triangles defined by an array of vertices. When in vertex array
* mode, the tag items COMPTAG_SrcX, COMPTAG_SrcY, COMPTAG_SrcWidth,
* COMPTAG_SrcHeight, COMPTAG_ScaleX, COMPTAG_ScaleY,
* COMPTAG_OffsetX and COMPTAG_OffsetY are ignored. Instead of
* rendering a single quad, the compositing engine will render a
* set of (disjoint) triangles using the composition source as
* a "texture".
*
* A vertex array is a set of points on the 2D plane. Each vertex
* consists of at least two floating point values defining the x
* and y coordinates of the vertex on the destination operator,
* relative to the top left corner of the bitmap (not the
* destination rectangle!). Furthermore, each vertex can have
* three or six more floating point value attributes, both of which
* are sets of texture coordinates.
*
* The first set of extra coordinates, if present, address the
* source operator bitmap itself. The second set, if present,
* are used to address the alpha mask. Each set consists of three
* floating point values. The first two values, named s and t
* respectively, define the X and Y coordinates on the source
* operator bitmap that this vertex maps to. The third, called w,
* is a homogenous space coordinate of the texture. Usually, this
* will be 1.0f, but it is possible to use different homogenous
* coordinates per vertex to achieve a perspective corrected 3D
* texture map
*
* The tag COMPTAG_VertexFormat is used to describe the format of
* each individual vertex. If ommited, the default value is for
* a vertex to only have x and y coordinates. Otherwise, the
* tag's value must be a compination of the two values
* COMPVF_STW0_Present and COMPVF_STW1_Present. These two values
* are bit masks and can be combined in any form. Each bit adds
* three floating point values to the vertex' required size. When
* both are specified, each vertex has a size of 8 floating point
* values.
*
* Vertex arrays must be specified compact, i.e. to get from one
* vertex in the array to the next, the compositing engine adds
* the size of the vertex, in bytes. Typically, your application
* would define a vertex "structure" like this:
*
* typedef struct {
* float x,y;
* float s,t,w;
* } myVertex_t;
*
* #define MYVERTEX_Format COMPVF_STW0_Present
*
* A vertex array could then be defined as
*
* myVertex_t vertices[20];
*
* The tag COMPTAG_VertexArray is used to enter triangle mode by
* providing a packed vertex array as described above. The
* size of the vertex array is undefined.
*
* A vertex array does not, however, define triangles. It only
* defines vertices. To start drawing triangles, these vertices
* must be grouped into triplets that define a triangle. There are
* two possible ways to do that, either implicitly, or explicitly.
*
* The normal mode of operation is to assume implicit grouping of
* vertices into triangles. Each three consequtive vertices,
* starting at vertex index zero, is assumed to be one triangle,
* i.e. the first triangle consists of indices 0, 1 and 2, the
* second one consists of indices 3, 4 and 5, and so on. The
* number of triangles to draw is specified via
* COMPTAG_NumTriangles, and the vertex array must have at least
* three times this number of vertices.
*
* The second mode of operation is explicit index mode. In index
* mode, the triangles are not defined by the order of vertices
* in the index array. Instead, the caller can pass an explicit
* array of indices for each triangle. As in the implicit mode,
* the tag COMPTAG_NumTriangles determines how many triangles are
* drawn, but the size of the vertex array is unaffected by this
* value, since each vertex may be used zero or more times through
* specifying its index. To pass in the indices of the desired
* triangles, the tag COMPTAG_IndexArray can be used. Indices are
* passed in as an array of 16 bit unsigned integers. If we denote
* the index array as I and the vertex array as V, then triangles
* are defined as
*
* V[I[0]], V[I[1]], V[I[2]]
* V[I[3]], V[I[4]], V[I[5]]
* and so on.
*
* The number of vertices in the array must be at least as many as
* the highest index used in the index array. No consistency check
* is done whatsoever for speed reasons, so an application has to
* take care the input to this function is valid. Failure to do so
* will have an undefined result, with "undefined" ranging from
* "nothing at all" to "total system lockup".
*
* IMPORTANT: As of AmigaOS 4.1 Update 3, triangle mode only works
* with hardware accelerated rendering. There is currently no
* software fallback.

Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Go to top

  Register To Post
(1) 2 »

 




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




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project