417
edits
Difference between revisions of "AGI/Specifications/Other/AGI256/Implementation Details"
Jump to navigation
Jump to search
AGI/Specifications/Other/AGI256/Implementation Details (view source)
Revision as of 08:46, 18 July 2007
, 08:46, 18 July 2007Fixed a typo. Hadn't put & in front of some code where it should have been.
(Added reverse engineered C version of AGIOBJS.OVL.) |
(Fixed a typo. Hadn't put & in front of some code where it should have been.) |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
In the original PC AGI interpreter v2.936 the engine holds the color and priority/control | In the original PC AGI interpreter v2.936 the engine holds the color and priority/control | ||
line information for each pixel in a | line information for each pixel in a 160x168 byte buffer. The color data for each pixel | ||
is held in the byte's lower 4 bits and the priority/control line data is held in the upper | is held in the byte's lower 4 bits and the priority/control line data is held in the upper | ||
4 bits. | 4 bits. | ||
AGI256 extends this | AGI256 extends this 160x168 byte buffer to a 320x168 byte buffer so that the 256-color | ||
data is held in the right | data is held in the right 160x168 half of the buffer and the original style 16-color and | ||
priority/control line information is held in the left | priority/control line information is held in the left 160x168 half of the buffer. | ||
When loading 256-color picture resource with the unknown170 command | |||
the picture is loaded straight into the right 160x168 half of the 320x168 memory buffer. | |||
Cel blitting routine is modified so that when sprite data would normally be written | |||
to a position (x, y) in the 16-color buffer (i.e. the left 160x168 half) it's actually | |||
written to the same position (x, y) but in the 256-color buffer (i.e. the right 160x168 half). | |||
==Used external info== | ==Used external info== | ||
| Line 913: | Line 920: | ||
codeseg:9DB0 jmp AO_agi256_saveArea ; savearea(struct Sprite *s) { | codeseg:9DB0 jmp AO_agi256_saveArea ; savearea(struct Sprite *s) { | ||
codeseg:9DB0 j_AO_agi256_saveArea endp ; int srcOffset = screenOffset(s->xPos, s->yPos); | codeseg:9DB0 j_AO_agi256_saveArea endp ; int srcOffset = screenOffset(s->xPos, s->yPos); | ||
codeseg:9DB0 ; uint8 *src = agi256PicSeg[srcOffset + 160]; | codeseg:9DB0 ; uint8 *src = &agi256PicSeg[srcOffset + 160]; | ||
codeseg:9DB0 ; for (int y = 0; y < s->ySize; y++) | codeseg:9DB0 ; for (int y = 0; y < s->ySize; y++) | ||
codeseg:9DB0 ; memcpy(s->buffer + s->xSize * y, src + 320 * y, s->xSize); | codeseg:9DB0 ; memcpy(s->buffer + s->xSize * y, src + 320 * y, s->xSize); | ||
| Line 945: | Line 952: | ||
codeseg:9DB9 ; savearea(struct Sprite *s) { | codeseg:9DB9 ; savearea(struct Sprite *s) { | ||
codeseg:9DB9 ; int srcOffset = screenOffset(s->xPos, s->yPos); | codeseg:9DB9 ; int srcOffset = screenOffset(s->xPos, s->yPos); | ||
codeseg:9DB9 ; uint8 *src = agi256PicSeg[srcOffset + 160]; | codeseg:9DB9 ; uint8 *src = &agi256PicSeg[srcOffset + 160]; | ||
codeseg:9DB9 ; for (int y = 0; y < s->ySize; y++) | codeseg:9DB9 ; for (int y = 0; y < s->ySize; y++) | ||
codeseg:9DB9 ; memcpy(s->buffer + s->xSize * y, src + 320 * y, s->xSize); | codeseg:9DB9 ; memcpy(s->buffer + s->xSize * y, src + 320 * y, s->xSize); | ||