For a *real* game, you wouldn't do sprite animations like this anyways.
This method, each animation frame would be one sprite, and therefore one opengl 'material', and therefore one draw call.
(I know you only show one frame at a time per animation, but each visible on-screen sprite will be an extra draw call, slowing things down gradually).
The answer is texture atlases aka sprite sheets. Check out apps like TexturePacker that creates larger texture atlases composed of all of your sprites (or a portion if you have many sprites). It outputs a text file telling you where every sprite it located by x and y coordinates, and the sprites name. You just build an interpreter library for these files, and have commands such as Sprite.Draw("name", frameNumber) and your code will extract the x,y location (and size) from the text file, convert those values to uv coordinates to use in your X_OBJADDVERTEX commands (the examples floating around all go from 0 to 1, so only the entire sprite is displayed, not a fraction of one). Your code could detect multiple frames by the file name, such as "walk01", "walk02", etc to detect animations automatically, and set their start / end limits. TexturePacker outputs in ^2 sizes if requested too.
Search these forums for sample code for TexturePacker. I think there are some glbasic libs that read it. There is another called "DarkFunction" or similar I think.