Random WIP shots

[Jae686]

A little demo framework I'm working on.

As of now it does :

• automatic load of all assets on the romdisk (via dirent.h)

• scenes are described as xml files, parsed at load time on the DC ( thank you with the help with expat Bluecrab)

• Bitmaped font support (with fonts generated at http://kvazars.com/littera/ )

• .obj loader

[PH3NOM]

Working on glDrawElements(...)

[Jae686]

This reminds me to get my obj loader to output indexed vertex arrays since my actual vertex arrays are unindexed.

Does anyone know a good algorithm to do so ?

@ PH3NON : will you support glPolygonMode(GL_FRONT_AND_BACK, GL_LINE); ?

Best Regards.

[bogglez]

This reminds me to get my obj loader to output indexed vertex arrays since my actual vertex arrays are unindexed.
Does anyone know a good algorithm to do so ?

Your OBJ loader will create a vertex buffer (coordinate, normal, uv) and an element array buffer (indices).
In OBJ's f command you will find lines of the form f a/b/c d/e/f, where a/b/c is one vertex and d/e/f another. a/b/f would be another vertex, even though two components are the same. So basically you want to map indices from element array buffer to a/b/c tuples. You will need to have a lookup container somewhere, for example std::map<std::tuple<int, int, int>, int>. When you parse an f command, check whether a/b/c is already in the lookup. If it is, use the index you stored there. If it is not in the lookup, construct a vertex with coordinate, normal and uv according to a, b and c, store it in the vertex buffer, increase the last index by one and store that in the lookup at std::tuple(a, b, c). This way you will avoid duplicate vertices.
I don't think you will be able to optimize the order much, since the model editor should spit out vertices that are close to each other close together instead of some random order.

[Jae686]

Just started to write (and learning in the process) a blender exporter for mesh and camera positioning.
The main focus is to get blender to generate a correct xml file for the framework to parse.

[Jae686]

I can already retrieve position, although rotation seems to be off.

[Jae686]

Starting to experiment with the render to texture feature.

Although que quad only appears mid scene (due to some bug I'm still hunting).

[PH3NOM]

Keep it up buddy!

Just a quick note there, when rendering to texture at full resolution, you are rendering a 640x480 pixel image onto a 1024x512 texture.

So, your u/v will end at 640.0f / 1024.0f, and 480.0f / 512.0f ( rather than 1 / 1 as shown in your screen there ).

That said, it looks like lxdream handles u/v cords on a render-to-texture result better than NullDC, which does in fact demonstrate some problems.

[SWAT]

PH3NOM, you have GPU with DX11? If yes, try use Demul for your tests, it should work better than nullDC and lxdream.

[PH3NOM]

Yes, my GPU + OS supports DX 11.2.

Thank you for the tip, I will look at Demul as an alternative

[MisterDave]

A quick update on my engine. It's been a while since I've had the time to push it forward, but after a rewrite of parts the performance is back up to 60fps.

[Jae686]

Looks very good MisterDave! What algorithm do you use create the blur ?

Best Regards!

[MisterDave]

Looks very good MisterDave! What algorithm do you use create the blur ?
Best Regards!

Thanks Jae686. The algorithm is similar to how Shadow of the Colossus does its bloom (creating the blurred black and white highlight mask). There is a good link here http://game.watch.impress.co.jp/docs/20051207/3dwa.htm. The other thing that I did was to add a bit of radial blur on too.

[PH3NOM]

A quick update on my engine. It's been a while since I've had the time to push it forward, but after a rewrite of parts the performance is back up to 60fps.

Glad to see your back at it.

One thing I would mention is that you can use your height map for a sort of collision detection, to stop the player from moving through 'walls', as seen in your video there.
When the player moves, examine the start position with the desired end position.
If the new position has a y value that is greater than some delta you define, that should indicate the player can not move to such a height.

[MisterDave]

Thanks PH3NOM. I really need to get the collision detection coded up soon using the same method you mention, it's just a bit of laziness on my part that I've not done it yet.

[PH3NOM]

So I decided to go ahead and try to do a bloom style effect.

From what I can tell, the simplified process is as follows:
1. Render frame to texture.
2. Modify the pixels of the render-to-texture result to create a black and white version of the texture.
3. Render the frame for display, using the render-to-texture result as an alpha mask.

I am embarrassed to admit that I am having problems with step 2, specifically reading the pixels back for manipulation.
To be clear, I am accessing the pixels in VRAM without copying the texture back to main RAM. Is that a problem?

Here is my render-to-texture allocation:

Code: Select all

pvr_ptr_t RENDER_TEXTURE = pvr_mem_malloc(RENDER_TEXTURE_W * RENDER_TEXTURE_H * 2);
pvr_ptr_t BLOOM_TEXTURE = pvr_mem_malloc(RENDER_TEXTURE_W * RENDER_TEXTURE_H * 2);

I can access and modify the 'bloom' texture, for example this will create a red texture in VRAM:

Code: Select all

       GLushort * src = (GLushort *)RENDER_TEXTURE;
       GLushort * dst = (GLushort *)BLOOM_TEXTURE;
       GLushort x, y;

		for(y = 0; y < 480; y++ )
		{
        for( x = 0; x < 640; x++ )
				*dst++ = 0xF000;

				src += 1024 - 640;
				dst += 1024 - 640;
			}

But if I try to copy the render-to-texture result to the Bloom Texture, I end up with all black pixels

Code: Select all

       GLushort * src = (GLushort *)RENDER_TEXTURE;
       GLushort * dst = (GLushort *)BLOOM_TEXTURE;
       GLushort x, y;

		for(y = 0; y < 480; y++ )
		{
        for( x = 0; x < 640; x++ )
				*dst++ = *src++;

				src += 1024 - 640;
				dst += 1024 - 640;
			}

I know the render-to-texture is fine, because I can render that on a quad and see the result is ok.

Anybody have any advice here? Thanks in advance!

[BlueCrab]

I'm going to guess you might be grabbing the pixels before they've been rendered to, possibly. Remember, while the PVR is grabbing data for one frame of input, it's rendering the frame before.

[Jae686]

MisterDave, how did you embed the video on your post ?

[BlueCrab]

Put the part of the youtube URL after v= in the tag. So, for instance, for the video https://www.youtube.com/watch?v=QcQpWkvUWW8, you'd do [youtube]QcQpWkvUWW8[/youtube]

[Jae686]

Well, this is my code running on real HW, but it has some bugs that did not appear on lxdream.

I wonder on how I'm going to debug something running on the real HW..........hummmmmm gotta see if I can get DDD and GDB running on DC hw....