[continued from previous message]   
      
   > (and/or not use resource data).   
   >   
   > Still, IMO, an internal WAD image is still better than the horrid/   
   > unusable mess that Windows had used (where anymore most people don't   
   > bother with the resource section much more than storing a program icon   
   > or similar...).   
   >   
   > But, realistically, one does still want to limit how much data they   
   > stick into the EXE.   
   >   
   > ...   
   >   
   >   
   My forays into the world of graphics formats are pretty limited. I tend   
   to use libraries already written by other people. I assume people a lot   
   brighter than myself have come up with them.   
      
   A while ago I wrote a set of graphics routines in assembler that were   
   quite fast. One format I have delt with is the .flic file format used to   
   render animated graphics. I wanted to write my own CIV style game. It   
   took a little bit of research and some reverse engineering. Apparently,   
   the authors used a modified version of the format making it difficult to   
   use the CIV graphics in my own game. I never could get it to render as   
   fast as the game’s engine. I wrote the code for my game in C or C++, the   
   original’s game engine code was likely in a different language.   
      
   *****   
      
   Been working on vectors for the ISA. I split the vector length register   
   into eight sections to define up to eight different vector lengths. The   
   first five are defined for integer, float, fixed, character, and address   
   data types. I figure one may want to use vectors of different lengths at   
   the same time, for instance to address data using byte offsets, while   
   the data itself might be a float. The vector load / store instructions   
   accept a data type to load / store and always use the address type for   
   address calculations.   
      
   There is also a vector lane size register split up the same way. I had   
   thought of giving each vector register its own format for length and   
   lane size. But thought that is a bit much, with limited use cases.   
      
   I think I can get away with only two load and two store instructions.   
   One to do a strided load and a second to do an vector indexed load   
   (gather/scatter). The addressing mode in use is d[Rbase+Rindex*Scale].   
   Where Rindex is used as the stride when scalar or as a supplier of the   
   lane offset when Rindex is a vector.   
      
   Writing the RTL code to support the vector memory ops has been   
   challenging. Using a simple approach ATM. The instruction needs to be   
   re-issued for each vector lane accessed. Unaligned vector loads and   
   stores are also allowed, adding some complexity when the operation   
   crosses a cache-line boundary.   
      
   I have the max vector length and max vector size constants returned by   
   the GETINFO instruction which returns CPU specific information.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)