Why in AGAL have we a data32PerVertex with a max value of 64 in createVertexBuffer method? - adobe

I don't understand this 64 value...
For what I've understood we have 8 registers max ,
each one with a size of 128 bits ( 4 data32),
so we can not access more than 32 data32 ?
Am I wrong ?
for what are the other 32 data32 that we can store in a vertex ?
Thanks

You can access this data with setVertexBufferAt and offset. But you're right - it's not possible to use ALL data since only 8 registers are available.

This is related to the d3d caps value of MaxStreamStride, which is typically 256.
But seriously, what do you need that much stream data for?

Their are two points to consider.
The first one is that having 8 registers of four data32 each will not mean that you can use 32 * data32 because you will waste space for padding.
The second one is that most of the time, in a video game the image you see is rendered in multiple passes that use different data from the vertex.
Hence the need to put more data in each vertex that a single shader can handle.
Imagine a stupid scenario where you want to render a model with up to 10 bones per vertex.
(this is purely theoretical, flash has an hardcoded ~200 agal instructions limit, and by the way, totally useless unless you are modelling an octopus)
In each vertex you will have a lot of data like this.
This totals to 3*3 + 12*2 = 33 data32 per vertex.
3 data32 for position
3 data32 for normal
3 data32 for tangent
2 data32 for boneData1
2 data32 for boneData2
2 data32 for boneData3
2 data32 for boneData4
2 data32 for boneData5
2 data32 for boneData6
2 data32 for boneData7
2 data32 for boneData8
2 data32 for boneData9
2 data32 for boneData10
2 data32 for texture_uv
2 data32 for lightmap_uv
In a typical defered shading render scenario you will do the following:
1 - Render a "view space normal map" in a texture.
You will then write a shader that will need to use: position, normal, tangent, and all bonedata.
So the shader will use 29 data32.
But all registers will be full, because you need to pad the position, normal and tangent
(va0 position, va1 normal, va2 tangent, va3-7 bone data).
You will waste space on va0.w, va1.w and va2.w.
2 - Render a "view space depth map" in a texture.
You will then write a shader that will need to use: position and all bonedata.
So the shader will use 23 data32.
3 - Render a view space diffuse map in a texture
You will then write a shader that will need to use: position, texture_uv and all bone data.
So the shader will use 25 data32.
4 - Render a view space light map
You will then write a shader that will need to use: position, lightmap_uv and all bone data.
So the shader will use 25 data32.
5 - Finally composite and do defered lighting to build your final image.
All 33 data32 have been used.
No shader used more than 8 registers at the same time.

Related

Seed for grid based game

I'm trying to come up with a way to generate a grid/level from a seed.
I'm thinking of using a 6 x 6 grid with 3, possible tiles in each.
The seed for that would be 108 characters long, i doubt anyone would want to copy 108 char long seed. (the game will probably be on iPhone, so the seed will be entered via keyboard)
Anyways of shortening it?
I thought a fun way would be to use words.
Separate the the grid into three 2 by 6 lines. and have each line represented by an english word.
The player would then just type in 3 words which is a lot easier & gives a kind of name to the level.
Any thoughts on how i could achieve this?
(I'm currently using gamesalad)
Thank you for your time,
Jordan
Shorting the seed.
Well 108 characters is a little over kill. You have 6 by 6 cell so that's 36 cells total. Each cell has 3 different states yet a char has at min 64 different states (A-Z,a-z,0-9, and a few punctuations to keep it simple) So even with 36 character we have way more than we need.
So lets break it down some more. Computers work in binary. A bit is the smallest bit of information it can use. One bit can be on or off so it has 2 possible states. 2 bits can be off,off or off,on or on,off or on,on so that is 4 different states. If we add another bit we get two more states for every previous state so that is 4*2 = 8 states for 3 bits. Times by 2 again for a 4th bit we get 16 states, again for 32 and again for 64 which just happens to be the number of characters we want to use. So it takes 6 bits to store 64 possible states.
Now lets look at the grid. Each cell has 3 states each. So two cells have 9 possible combination 3*3 and for 3 cells its 3*3*3 = 27 next is 3*3*3*3 = 81 or 3 to the power of 4 cells or 3^4 = 81. We can use this trend to work out how many possible combinations there are for all 36 cells. 3 to the power of 36. That is a big number 150,094,635,296,999,121 or One hundred and fifty million billion combinations.
So how many bits do we need to store that number. I could cheat and ask the calculator but that's too easy,
Let's see, 3 cells have 27 combinations and 5 bits have 32. so 3 cells go into 36 cell 12 times and we have 5 bits for every 3 cells so 5*12 is 60bits. That's a nice round number as our chars are 6 bits each we can shove every possible grid combination into 10 char with some to spare. We have 5 spare combinations for every 3 cells so we have 60 combinations spare 12*5. Darn if only we had 4 more combinations that would be 64 which is 2^6 or 6 bits or one char. We can not take away half a character so 10 characters it has to be. BTW 4 combinations is two bits so take that from our 60 char bits and the minimum number of bits to store your grid is 58. 2 to the power of 58 should be just bigger than 3 to the power of 36.
Thus your grid requires 10 chars. Each being any one of ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789:) perfect (8 bytes 4 spare bits)
I pick my first 10 char seed BLINDMAN67 now what?

5 values for a face in PLY files?

I was just barely introduced to .ply files and I don't understand how they work. The vertex list has only 3 values for each vertex: x,y,z. But each face has 5 values and I don't know what those 5 values mean. I just need a little explanation. Thanks!
This simply means that the face has 5 sides or 5 vertices and each vertex's position is specified in space by the 3 values x,y,z.
The above answer is not exactly right to my knowledge.
The first value is the number of vertices which define the face, in your case it should be 4, as there are only 4 numbers left. The four other numbers are indices of the vertices. Like often in computer science, the index of the first vertex is 0, not 1.
Some programs though support only triangular meshes, and faces with more than 3 edges are not supported.
Furthermore, if you use a visualization program which adds light and other rendering stuff, the face 3 0 1 2 is not the same as 3 0 2 1 as the triangle has another orientation.

Units vs real world

I've got a DXF (rev 10) CAD file with some 2D drawings and I'm implementing a reader. Until now I've successfully loaded everything and rasterized with ImageMagick.
But the point is, I have manually set the zoom on the coordinates to a number that made sense for me. How do I know what was the original size of the components and what unit was used to draw? Is there any specific group I have to look at?
My header is like this:
0
SECTION
2
HEADER
9
$ACADVER
1
AC1006
9
$EXTMIN
10
-14.610075
20
-14.723197
9
$EXTMAX
10
14.556421
20
15.530217
9
$LTSCALE
40
0.000394
9
$PDMODE
70
35
9
$PDSIZE
40
0.000315
0
ENDSEC
I've read what each part is about and I don't seem to find anything that helps me.
I want to know the units, because I want to be able to change the drawing accurately as it will be plotted, e.g. move a point by 2 inches.
When implementing a viewer for a dxf file, you don't actually need to know anything about the units. Unless of course, you are going to implement a Measure function in your viewer, then it gets more complicated.
Your initial 'zoom' size in your viewer can be determined from the header information that you have shown: EXTMIN and EXTMAX are the 2 key pieces of info you need. In your example the minimum coordinate use3d in the dxf file is -14.610075,-14.723197 and the maximum coordinate used is 14.556421,15.530217. This gives you a total drawing size of 29.166496(width) x 30.253414.
For a simple viewer, you can just assume that the units in the DXF file be equal to the units in your viewer (pixels or points or whatever you are using).
Then the base drawing size in your viewer will be 29.166496x30.253414, and you can scale that up (zoom) to make it fill whatever display area you have available.
EDIT
DXF files are by no means 'unitless', so in the case where you absolutely need to know the units, you will need to read the $INSUNITS group code value, and to double-check it, you can also read the $MEASUREMENT group code value.
The R2000 dxf spec, or any of the other versions, contain all the info you need on what those values mean. If you go to the 'HEADER Section Group Codes' page, and search for 'units', you will be able to find the listing of all the unit types. For example:
$INSUNITS
70
4
indicates that the dxf file is using metric units, specifically millimeters, as the base unit. So any dimensional or coordinate value stored by the dxf file will be in millimeters.
Default drawing units for AutoCAD DesignCenter blocks: 0 = Unitless; 1
= Inches; 2 = Feet; 3 = Miles; 4 = Millimeters; 5 = Centimeters; 6 = Meters; 7 = Kilometers; 8 = Microinches; 9 = Mils; 10 = Yards; 11 =
Angstroms; 12 = Nanometers; 13 = Microns; 14 = Decimeters; 15 =
Decameters; 16 = Hectometers; 17 = Gigameters; 18 = Astronomical
units; 19 = Light years; 20 = Parsecs
EDIT
I just noticed you are using a very old dxf format (R10). If I remember right, the units were not introduced into the DXF spec until about R12. Before that time, the actual size of the drawing entities didn't change based on which units were being assumed. Only the labels on the dimensions were different from imperial to metric units.
If you are set on using the old R10 format, you will just have to make an arbitrary decision on what the units are; assuming you don't have any dimension labels on your drawings that would indicate what units are being implied.

2D grid based games : represent passability

Considering a tiled based game, where each agents can move straight/diagonally (in 8-directions).
Basically, a map like this can be represented as a regular 2D grid, where 0 would represent an walkable location and 1 unwalkable locations (I'm using Lua):
-- Example : 3x3 sized map
local map = {
{0,0,0},
{0,1,1},
{0,0,0},
}
At this point, how can we represent tile walkability depending from the direction an agent comes from ?
I.e. cell [2][2] above, which is statically unwalkable, would now be walkable if coming from [1][2] (above) or [2][1] (left), but not, for instance, from [3][2] (down).
I have given to this some thoughts, but I couldn't come up with something clean enough, to me.
Thanks in advance.
I'd overlay another 2D grid with of single bytes. Each bit of the byte corresponds to a possible entrance direction with a 1 meaning it can be walked on from that direction and a 0 meaning not. You can then check for enterability using binary masking.
If most of your cells can be entered from any direction, then you may consider using a map with the tile's absolute ID (X*MaxY+Y, for instance) as a key and the byte scheme described above indicating enterability. This is slower to access, but takes less space.
For instance, let the directions be laid out as so:
Bit # X offset Y offset
123 -1 0 1 -1 -1 -1
4 5 -1 0 1 0 0 0
678 -1 0 1 1 1 1
If I go in the northeast direction, this corresponds to bit #3. I can perform masking by translating the above values into bit masks:
1 2 4
8 16
32 64 128
I can enter from a direction if the following returns true
Enterability(CurrentX+Xoffset(Dir), CurrentY+Yoffset(Dir)) & BitMask(Dir)
(Sorry, I'm afraid I don't know Lua well enough to write this up in that language)
Edit
So, say my directions and such are as above and I want a square that can be entered only from the North. To do this, I set bit #2:
Enterability(X)=2
If I want a square that is enterable from both the north and the southwest, I would use:
Enterability(X)=2 | 64
where | is the bitwise OR operation.
If I want a square to be enterable from any direction but west I use:
Enterability(X)=(~8)
where ~ is the not operation.
If I need to close a door, say to the east, I could unset that bit:
Enterability(X)=Enterability(X) & (~16)
To open the door again, I use:
Enterability(X)=Enterability(X) | 16
or, more simply,
Enterability(X)|=16
The ~16 produces a bitfield which is all ones except for the bit referring to 16. Using this with the AND operator (&) leaves all the bits on, except the one referring to 16.
Also note that hexadecimal addressing can be more convenient:
Decimal Hexadecimal
1 2 4 0x1 0x2 0x4
8 16 = 0x8 0x10
32 64 128 0x20 0x40 0x80

How to determine endpoints of Arcs in GraphicsPath PathPoints and PathTypes arrays?

I have the following PathPoints and PathTypes arrays (format: X, Y, Type):
-177.477900, 11021.670000, 1
-614.447200, 11091.820000, 3
-1039.798000, 10842.280000, 3
-1191.761000, 10426.620000, 3
-1591.569000, 10493.590000, 3
-1969.963000, 10223.770000, 3
-2036.929000, 9823.960000, 3
-2055.820000, 9711.180000, 3
-2048.098000, 9595.546000, 3
-2014.380000, 9486.278000, 3
Here is what this GraphicsPath physically looks like. The 2 Arcs are very distinguishable:
I know that this GraphicsPath.PathData array was created by 2 AddArc commands. Stepping through the code in the debugger, I saw that the first 4 PathData values were added by the first AddArc command, and the remaining 6 points were added by the 2nd AddArc command.
By examining the raw pathpoints/pathtype arrays (without previously knowing that it was 2 AddArc commands so I would know that I have 2 start and end points), I would like to determine to start and end point of each arc.
I have tried several Bezier calculations to 'recreate' the points in the array, but am at a loss to determine how to determine the separate start and end points. It appears that GDI+ is combining the start/end point between the arcs (they are the same point and the arcs are connected), and I am losing the fact that one arc is ending and other one is starting.
Any ideas?
Use the GraphicsPathIterator class in combination with the GraphicsPath.SetMarkers method.
For example:
dim gp as new GraphicsPath
gp.AddArc(-50, 0, 100, 50, 270, 90) 'Arc1
gp.SetMarkers()
gp.AddArc(0, 25, 100, 50, 270, 90) 'Arc2
Dim iterator as New GraphicsPathIterator(gp)
Dim i as Integer = 0
Dim MyPts(3) As PointF
Dim temp as New GraphicsPath
Do until i > 2
iterator.NextMarker(temp)
MyPts(i) = temp.PathPoints(0)
MyPts(i + 1) = temp.GetLastPoint()
i += 2
Loop
'Free system resources...
iterator.Dispose()
temp.Dispose()
Arc1 -> start: MyPts(0); end: MyPts(1)
Arc2 -> start: MyPts(2); end: MyPts(3)
Hope this helps!
Take a look at the PathPointType Enum (System.Drawing.Drawing2D).
Value Meaning
0 Start (path)
1 Line
3 Bezier/Bezier3
7 PathType Mask
16 Dash Mode
32 Path Marker
128 Close Subpath
This one was bugging me a lot too! I had path created beyond my control without markers and couldn't figure out curve endpoints.
In this case you'd expect that the curve starts at [i + 1] but it is not! It turns out that GDI combines path points probably to make the points array shorter. In this case the curve points are: [0], [1], [2], [3].
It seems that if PathPointType.Start or PathPointType.Line is followed by PathPointType.Bezier, then you have to treat the PathPontType.Start or Path.PointType.Line as a first point of your Bezier curve, so in your example it should be like this:
-177.47, 11021.67, 1 // Draw line to this point AND use it as a Bezier start!
-614.44, 11091.82, 3 // Second Bezier point
-1039.79, 10842.28, 3 // Third Bezier point
-1191.76, 10426.62, 3 // Fourth Bezier point AND first point of the next Bezier!
-1591.56, 10493.59, 3 // Second Bezier point
-1969.96, 10223.77, 3 // Third Bezier point
-2036.92, 9823.96, 3 // Fourth Bezier point AND first point of the next Bezier!
-2055.82, 9711.18, 3 // Second Bezier point
-2048.09, 9595.54, 3 // Third Bezier point
-2014.38, 9486.27, 3 // Fourth Bezier point
So, when analysing PathPoints array point by point, you have to also check current and following indices. The docs on PatPointType might come in handy. In most cases you can probably ignore additional data stored on bits other than the first three (these three define Start, Line and Bezier). The only exception is CloseSubpath but it's irrelevant if you consider the next advice.
It's also worth noting that if you have a complex path that consists of huge number of PathPoints then it might be handy to split the path into chunks using GraphicsPathIterator. This simplifies the whole procedure as PathPointType.CloseSubpath can be ignored - it will be always the last point of your GraphicsPath chunk.
A quick look into Reflector or here might be helpful if you want to better understand PointTypes array.

Resources