09-16-2004, 06:13 PM
Why, that's great. Expect some beta testing tasks in the near future SLAVE!
Anyway....
Merging the new lib files went fine. It all works fine. I replaced most of RelSprite statements in LONG code with RelXMSPut statements. I was working with two modules in QB IDE at that time which really drains the conventional memory(from my experience) and when I replaced the standard PP256's InitImageData and MakeImageData subs(which load PP256 PUT file data into conventional memory) with RelTile2XMS(or something like that) I got Out of memory error on that spot(when that statement is executed) while with the old code I could run it in QB IDE. So it seems that some RelLib XMS statements eat a bit more conventional memory. I hope that during compiling RelXMSPut statements don't take much more memory than RelSprite statements.
To be honest, RelXMSPut was not what I expected. The big flaw of new XMS routines it that you can only load PUT files into XMS not capture part of the screen and save it in XMS. So you are limited to 100*100 pixel sprites. I also wanted to have a function that would allow me to put a FULL SCREEN saved in XMS on any part of the screen(CLIPPING) so I could enable scrolling of FULL SCREENS one after the another. The noctorious horizontal XMS scrolling. Maybe that's just wishful thinking. Still, these new routines help a lot since I can freely add big sprites that I might need for some demanding animations into XMS without worry of going outside conventional memory limit.
Oh, one more thing. Why there is no RelXMSPutRotate statement? I need it! BTW, I use your rotate routines to reduce the size of the sprite since you didn't provided a RelSpriteZoom routine of some sort. How do I reduce the size of the sprite with RelSpriteRotate? Well, I use some angle values above 360 and it works. Probably some error in the code but it helps me. I don't really NEED sprite size reduction but it makes some of game animations more cool.
Anyway....
Merging the new lib files went fine. It all works fine. I replaced most of RelSprite statements in LONG code with RelXMSPut statements. I was working with two modules in QB IDE at that time which really drains the conventional memory(from my experience) and when I replaced the standard PP256's InitImageData and MakeImageData subs(which load PP256 PUT file data into conventional memory) with RelTile2XMS(or something like that) I got Out of memory error on that spot(when that statement is executed) while with the old code I could run it in QB IDE. So it seems that some RelLib XMS statements eat a bit more conventional memory. I hope that during compiling RelXMSPut statements don't take much more memory than RelSprite statements.
To be honest, RelXMSPut was not what I expected. The big flaw of new XMS routines it that you can only load PUT files into XMS not capture part of the screen and save it in XMS. So you are limited to 100*100 pixel sprites. I also wanted to have a function that would allow me to put a FULL SCREEN saved in XMS on any part of the screen(CLIPPING) so I could enable scrolling of FULL SCREENS one after the another. The noctorious horizontal XMS scrolling. Maybe that's just wishful thinking. Still, these new routines help a lot since I can freely add big sprites that I might need for some demanding animations into XMS without worry of going outside conventional memory limit.
Oh, one more thing. Why there is no RelXMSPutRotate statement? I need it! BTW, I use your rotate routines to reduce the size of the sprite since you didn't provided a RelSpriteZoom routine of some sort. How do I reduce the size of the sprite with RelSpriteRotate? Well, I use some angle values above 360 and it works. Probably some error in the code but it helps me. I don't really NEED sprite size reduction but it makes some of game animations more cool.
![[Image: anya2.jpg]](http://rel.betterwebber.com/Mypics/anya2.jpg)
