Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Adam_42

Member Since 03 Jul 2006
Offline Last Active Private

Posts I've Made

In Topic: Max size of Matrix4x4 Array in HLSL

22 February 2015 - 12:40 PM

As MJP said, Any GPU that's DX10 capable will support vertex texture fetch (which is simply using tex2d in the vertex shader).

 

These days that's pretty much everything. You have to go back to something like a http://en.wikipedia.org/wiki/Radeon_X1000_Series to find a card that doesn't support it.


In Topic: Max size of Matrix4x4 Array in HLSL

22 February 2015 - 10:16 AM

Yes, you can use it on D3D9 as long as the GPU supports vertex texture fetch.

 

By the way, the matrices used for skinning are actually 4x3 ones, so you can fit more like 80 of them in if you rearrange how the data is stored.


In Topic: Drawing fullscreen triangle, problem with shader

08 February 2015 - 05:20 PM


You can't draw a quad with 3 points. You need 4 points.

 

You can when it's a full screen one, because it gets clipped. You simply make the triangle twice the width and height of the screen.

 

This will give a performance improvement compared to using two triangles.

 

You can find a detailed low level explanation of the performance boost at http://michaldrobot.com/2014/04/01/gcn-execution-patterns-in-full-screen-passes/ but the essence of it is that pixel shaders process pixels in big groups. The diagonal line across the screen joining the two triangles breaks up some of those groups, and it uses the cache less efficiently.


In Topic: Why am I getting Access Violation Reading with XMVector3TransformCoord

07 February 2015 - 03:37 PM

The simple option is to override global operator new and call _aligned_malloc (or similar) from it. If you do that you can make every allocation 16-byte aligned, with only a few lines of code in one place.

 

This also means you can do things like putting aligned types in a std::vector.

 

Note that there's several variants of operator new and delete that you'll need to replace - you want to change the non-throwing variants as well.


In Topic: 1997 game graphic files

04 February 2015 - 07:49 PM

I got bored and did a bit more analysis. Below is the first part of the data with some highlighting.
 
The bold parts seem to be an identifier as you already found.
 
The green and blue numbers appear to be 16-bit width and height, but I'm not 100%.
 
The red number looks 32-bit, and I'm not sure what it means. Some kind of unique identifier maybe?
 
The next 4 bytes are 03 00 00 00 for all of them. Maybe some kind of image type?
 
Note that the numbers are all stored in little endian format (least significant byte first).
 
Following that we appear to have four more 16-bit values (in grey) of unknown meaning. They could also be part of the pixel data, but they are consistently xx 00 in all three which suggests they could well be 16-bit numbers. Needs more analysis.
 
Next there's 210 more bytes of unknown data, presumably containing the pixels.
 
For the second case, the unknown data is 214 bytes.
 
Since the overhead compared with the possible dimensions isn't consistent that suggests RLE encoding. Note that sprite RLE was generally done for improving rendering performance, and not to reduce data size.
 
I'm wondering if the image data is 16-bits per pixel, with the top bit always zero (i.e. 555 encoding not 565). That's because I can't see any obvious cases where two bytes next to each other are both 0x80 or bigger outside of the headers.
 
That's probably more than enough to get you started.

14 00 04 0F 16 00 09 00 6B 00 00 00 03 00 00 00
09 00 09 00 03 00 15 00 04 57 03 00 15 00 61 2E
03 00 13 00 E2 41 62 36 03 00 01 00 03 00 0C 00
A0 26 A0 26 81 26 21 2F 01 2F C1 2E 42 42 E1 31
03 00 02 00 80 15 03 00 04 00 E0 08 20 09 40 11
A0 15 00 1E 00 1A 60 22 A0 26 A1 2A C0 2A C0 2A
80 2A 02 4A 81 2D 80 15 03 00 02 00 03 00 02 00
60 11 00 0D C0 08 E0 0C 00 0D 20 11 80 15 A0 19
20 22 40 22 80 2A A0 2A 60 26 60 2A 22 3E A1 39
E0 21 03 00 03 00 03 00 03 00 00 11 20 0D 00 0D
00 0D 20 11 80 15 A0 19 E0 1D C0 1D 20 22 00 22
A0 29 C1 3D 40 1D A0 1D 03 00 04 00 03 00 05 00
C0 08 A0 08 00 11 40 15 20 11 00 11 40 15 60 25
C1 35 41 2D C0 10 03 00 06 00 03 00 08 00 60 04
60 04 60 04 60 04 03 00 0A 00 14 00 04 0F 15 00
08 00 6D 00 00 00 03 00 00 00 0B 00 0A 00 03 00
14 00 C1 31 03 00 13 00 22 42 03 00 01 00 03 00
06 00 80 15 00 1E 60 22 20 1E C1 2A E1 2A 01 2F
A1 26 E1 2A 01 2F C0 2E E2 39 E2 39 03 00 02 00
20 0D 20 0D 00 0D 20 0D 60 11 40 11 80 15 E0 1D
60 26 40 22 C1 2A 01 2F 01 2F E1 2E C0 2A 80 2A
41 36 E1 39 20 19 03 00 02 00 03 00 01 00 C0 08
00 0D 00 0D 20 11 20 11 60 15 C0 19 00 1E 60 26
80 26 C0 2E E1 2E A0 2A 60 2A A1 3D 61 29 60 1D
03 00 03 00 03 00 02 00 C0 0C E0 0C 40 15 80 15
60 15 A0 19 E0 1D 40 26 40 26 20 22 20 26 C3 42
83 4A A1 31 03 00 05 00 03 00 04 00 C0 0C 40 19
80 19 80 19 60 19 A0 1D E1 2D 01 36 02 42 C1 2D
A0 1D 03 00 06 00 03 00 07 00 E0 20 61 2D A1 2D
E2 31 80 25 03 00 09 00 14 00 04 0F 16 00 08 00
75 00 00 00 03 00 00 00 0B 00 0A 00 03 00 15 00
40 21 03 00 14 00 80 29 03 00 01 00 20 0D 60 11


PARTNERS