Going back to your fixed 80*50 grid mesh idea, you can do this with a static mesh buffer, a static texture, and a dynamic buffer of glyph ID's.
You make a static mesh, that contains a quad (or two tris) for each grid cell. Every vert can have a static texcoord that identifies which corner of the glyph it represents (e.g. 2D values of [-1,-1],[1,-1],[1,1] or [-1,1] or alternatively simply 1D values of 0,1,2 or 3) and a secondary 1D texcoord that identifies which 'cell' the vert belongs to. If theres 80*50 cells, then this cell-ID ranges from 0-3999. You can fit the corner-ID in a single byte (for the 1D version, or two bytes for the 2D version), the cell-ID in a 16-bit int.
Then your dynamic data consists of specifying which glyph should appear in which cell. Assuming you only need 256 glyphs, then this is one byte per cell, or 4000 bytes.
All of your glyphs can be stored on a static texture sheet -- e.g. a 256*256 texture gives you 256 glyphs at 16*16 resolution.
In the vertex shader, you read the vertex's cell-ID, use that to fetch the glyph-ID that should appear in that cell, convert the glyph-ID into the texture-coordinate at the centre of the glyph. Then once you've got this glyph-centre tex-coord, you use the vertex's corner-ID to offset it to the appropriate corner of the glyph.
That sounds like it should work, and should perform fine. If you're struggling with specific implementation details, ask below ;)
---------- [edit]
As an alternative implementation:
You could have a static grid mesh that only contains positions for the verts and an index buffer so you're not repeating yourself (there's 6 verts per two-tri-quad, but only 4 unique values -- so you write the 4 values into a vertex buffer, and then write 6 indices into an index buffer).
Then you make a dynamic vertex buffer for storing the UV coordinates. If your text isn't super-high resolution, then these can be stored as two bytes per UV. On the CPU, you determine which glyph appears in each cell, and write the 4 corner UV's for that glyph into your dynamic vertex buffer.
When rendering, you bind both the static position buffer and the dynamic tex-coord buffer. The size of the dynamic data is 80*50*2, or 8KiB, which is still tiny.
Most games that I've worked on have use the above implementation, except that both positions and tex-coords are dynamic and are generated by the CPU every frame.
Show differencesHistory of post edits
#3Hodgman
Posted 09 April 2012 - 11:47 PM
Going back to your fixed 80*50 grid mesh idea, you can do this with a static mesh buffer, a static texture, and a dynamic buffer of glyph ID's.
You make a static mesh, that contains a quad (or two tris) for each grid cell. Every vert can have a static texcoord that identifies which corner of the glyph it represents (e.g. 2D values of [-1,-1],[1,-1],[1,1] or [-1,1] or alternatively simply 1D values of 0,1,2 or 3) and a secondary 1D texcoord that identifies which 'cell' the vert belongs to. If theres 80*50 cells, then this cell-ID ranges from 0-3999. You can fit the corner-ID in a single byte (for the 1D version, or two bytes for the 2D version), the cell-ID in a 16-bit int.
Then your dynamic data consists of specifying which glyph should appear in which cell. Assuming you only need 256 glyphs, then this is one byte per cell, or 4000 bytes.
All of your glyphs can be stored on a static texture sheet -- e.g. a 256*256 texture gives you 256 glyphs at 16*16 resolution.
In the vertex shader, you read the vertex's cell-ID, use that to fetch the glyph-ID that should appear in that cell, convert the glyph-ID into the texture-coordinate at the centre of the glyph. Then once you've got this glyph-centre tex-coord, you use the vertex's corner-ID to offset it to the appropriate corner of the glyph.
That sounds like it should work, and should perform fine. If you're struggling with specific implementation details, ask below ;)
---------- [edit]
As an alternative implementation:
You could have a static grid mesh that only contains positions for the verts and an index buffer so you're not repeating yourself (there's 6 verts per two-tri-quad, but only 4 unique values -- so you write the 4 values into a vertex buffer, and then write 6 indices into an index buffer).
Then you make a dynamic vertex buffer for storing the UV coordinates. If your text isn't super-high resolution, then these can be stored as two bytes per UV. On the CPU, you determine which glyph appears in each cell, and write the 4 corner UV's for that glyph into your dynamic vertex buffer.
When rendering, you bind both the static position buffer and the dynamic tex-coord buffer. The size of the dynamic data is 80*50*2, or 8KiB, which is still tiny.
You make a static mesh, that contains a quad (or two tris) for each grid cell. Every vert can have a static texcoord that identifies which corner of the glyph it represents (e.g. 2D values of [-1,-1],[1,-1],[1,1] or [-1,1] or alternatively simply 1D values of 0,1,2 or 3) and a secondary 1D texcoord that identifies which 'cell' the vert belongs to. If theres 80*50 cells, then this cell-ID ranges from 0-3999. You can fit the corner-ID in a single byte (for the 1D version, or two bytes for the 2D version), the cell-ID in a 16-bit int.
Then your dynamic data consists of specifying which glyph should appear in which cell. Assuming you only need 256 glyphs, then this is one byte per cell, or 4000 bytes.
All of your glyphs can be stored on a static texture sheet -- e.g. a 256*256 texture gives you 256 glyphs at 16*16 resolution.
In the vertex shader, you read the vertex's cell-ID, use that to fetch the glyph-ID that should appear in that cell, convert the glyph-ID into the texture-coordinate at the centre of the glyph. Then once you've got this glyph-centre tex-coord, you use the vertex's corner-ID to offset it to the appropriate corner of the glyph.
That sounds like it should work, and should perform fine. If you're struggling with specific implementation details, ask below ;)
---------- [edit]
As an alternative implementation:
You could have a static grid mesh that only contains positions for the verts and an index buffer so you're not repeating yourself (there's 6 verts per two-tri-quad, but only 4 unique values -- so you write the 4 values into a vertex buffer, and then write 6 indices into an index buffer).
Then you make a dynamic vertex buffer for storing the UV coordinates. If your text isn't super-high resolution, then these can be stored as two bytes per UV. On the CPU, you determine which glyph appears in each cell, and write the 4 corner UV's for that glyph into your dynamic vertex buffer.
When rendering, you bind both the static position buffer and the dynamic tex-coord buffer. The size of the dynamic data is 80*50*2, or 8KiB, which is still tiny.
#2Hodgman
Posted 09 April 2012 - 11:41 PM
Going back to your fixed 80*50 grid mesh idea:
You make a static mesh, that contains a quad (or two tris) for each grid cell. Every vert can have a static texcoord that identifies which corner of the glyph it represents (e.g. 2D values of [-1,-1],[1,-1],[1,1] or [-1,1] or alternatively simply 1D values of 0,1,2 or 3) and a secondary 1D texcoord that identifies which 'cell' the vert belongs to. If theres 80*50 cells, then this cell-ID ranges from 0-3999. You can fit the corner-ID in a single byte (for the 1D version, or two bytes for the 2D version), the cell-ID in a 16-bit int.
Then your dynamic data consists of specifying which glyph should appear in which cell. Assuming you only need 256 glyphs, then this is one byte per cell, or 4000 bytes.
All of your glyphs can be stored on a static texture sheet -- e.g. a 256*256 texture gives you 256 glyphs at 16*16 resolution.
In the vertex shader, you read the vertex's cell-ID, use that to fetch the glyph-ID that should appear in that cell, convert the glyph-ID into the texture-coordinate at the centre of the glyph. Then once you've got this glyph-centre tex-coord, you use the vertex's corner-ID to offset it to the appropriate corner of the glyph.
That sounds like it should work, and should perform fine. If you're struggling with specific implementation details, ask below ;)
You make a static mesh, that contains a quad (or two tris) for each grid cell. Every vert can have a static texcoord that identifies which corner of the glyph it represents (e.g. 2D values of [-1,-1],[1,-1],[1,1] or [-1,1] or alternatively simply 1D values of 0,1,2 or 3) and a secondary 1D texcoord that identifies which 'cell' the vert belongs to. If theres 80*50 cells, then this cell-ID ranges from 0-3999. You can fit the corner-ID in a single byte (for the 1D version, or two bytes for the 2D version), the cell-ID in a 16-bit int.
Then your dynamic data consists of specifying which glyph should appear in which cell. Assuming you only need 256 glyphs, then this is one byte per cell, or 4000 bytes.
All of your glyphs can be stored on a static texture sheet -- e.g. a 256*256 texture gives you 256 glyphs at 16*16 resolution.
In the vertex shader, you read the vertex's cell-ID, use that to fetch the glyph-ID that should appear in that cell, convert the glyph-ID into the texture-coordinate at the centre of the glyph. Then once you've got this glyph-centre tex-coord, you use the vertex's corner-ID to offset it to the appropriate corner of the glyph.
That sounds like it should work, and should perform fine. If you're struggling with specific implementation details, ask below ;)
#1Hodgman
Posted 09 April 2012 - 11:38 PM
Going back to your fixed 80*50 grid mesh idea:
You make a static mesh, that contains a quad (or two tris) for each grid cell. Every vert can have a static texcoord that identifies which corner of the glyph it represents (e.g. 2D values of [-1,-1],[1,-1],[1,1] or [-1,1] or alternatively simply 1D values of 0,1,2 or 3) and a secondary 1D texcoord that identifies which 'cell' the vert belongs to. If theres 80*50 cells, then this cell-ID ranges from 0-3999. You can fit the corner-ID in a single byte (for the 1D version, or two bytes for the 2D version), the cell-ID in a 16-bit int.
Then your dynamic data consists of specifying which glyph should appear in which cell. Assuming you only need 256 glyphs, then this is one byte per cell, or 4000 bytes.
All of your glyphs can be stored on a static texture sheet -- e.g. a 256*256 texture gives you 256 glyphs at 16*16 resolution.
In the vertex shader, you read the vertex's cell-ID, use that to fetch the glyph-ID that should appear in that cell, convert the glyph-ID into the texture-coordinate at the centre of the glyph. Then once you've got this glyph-centre tex-coord, you use the vertex's corner-ID to offset it to the appropriate corner of the glyph.
You make a static mesh, that contains a quad (or two tris) for each grid cell. Every vert can have a static texcoord that identifies which corner of the glyph it represents (e.g. 2D values of [-1,-1],[1,-1],[1,1] or [-1,1] or alternatively simply 1D values of 0,1,2 or 3) and a secondary 1D texcoord that identifies which 'cell' the vert belongs to. If theres 80*50 cells, then this cell-ID ranges from 0-3999. You can fit the corner-ID in a single byte (for the 1D version, or two bytes for the 2D version), the cell-ID in a 16-bit int.
Then your dynamic data consists of specifying which glyph should appear in which cell. Assuming you only need 256 glyphs, then this is one byte per cell, or 4000 bytes.
All of your glyphs can be stored on a static texture sheet -- e.g. a 256*256 texture gives you 256 glyphs at 16*16 resolution.
In the vertex shader, you read the vertex's cell-ID, use that to fetch the glyph-ID that should appear in that cell, convert the glyph-ID into the texture-coordinate at the centre of the glyph. Then once you've got this glyph-centre tex-coord, you use the vertex's corner-ID to offset it to the appropriate corner of the glyph.