03-16-2010, 05:55 AM
It's going to take quite a lot of work to get it into ZX Basic, not least of which because it's in Spanish which takes me quite a lot longer to read.
Also... looking closely at it, I'm pretty sure my version is faster. The Fourspriter 2 code has been changed in ways that look remarkably similar to my optimizations. (and, you know, if you are going to say "Úsalo y modifícalo como te de la gana, pero "porfa", menciónanos :-)" you could at least thank ME for some of those ideas in version 2!) It's clear that some of the code came from my updates - the redraw routine is to all intents and purposes identical to the fspredraw sub in my version. There are now two copy routines - screen 2 buffer and buffer 2 screen (which is what I named them) and so on. It's good they liked my ideas; I'm a little nonplussed that they didn't mention me.
But not all of my optimizations have been implemented. So I think the version I have is probably faster. At the very least I can see ways to make it faster in the places I did so before.
For example, I got rid of xpos and ypos completely - I held the current position in the BC register, instead of in memory. This actually made a VERY big speed increase.
I'll have to give this one a go - but I suspect it will still be unable to erase-buffer-redraw all the sprites before the screen update rolls down; which means it has to be done after waiting for it to go by.
But yes, it's not going to be five minutes to break it up and make it work for me. Probably more like 5 days. I never said I was a fast programmer. Working the kinks out of fourspriter 1 took me well over a week, and I had a lot of free time to do that.
L
Also... looking closely at it, I'm pretty sure my version is faster. The Fourspriter 2 code has been changed in ways that look remarkably similar to my optimizations. (and, you know, if you are going to say "Úsalo y modifícalo como te de la gana, pero "porfa", menciónanos :-)" you could at least thank ME for some of those ideas in version 2!) It's clear that some of the code came from my updates - the redraw routine is to all intents and purposes identical to the fspredraw sub in my version. There are now two copy routines - screen 2 buffer and buffer 2 screen (which is what I named them) and so on. It's good they liked my ideas; I'm a little nonplussed that they didn't mention me.
But not all of my optimizations have been implemented. So I think the version I have is probably faster. At the very least I can see ways to make it faster in the places I did so before.
For example, I got rid of xpos and ypos completely - I held the current position in the BC register, instead of in memory. This actually made a VERY big speed increase.
I'll have to give this one a go - but I suspect it will still be unable to erase-buffer-redraw all the sprites before the screen update rolls down; which means it has to be done after waiting for it to go by.
But yes, it's not going to be five minutes to break it up and make it work for me. Probably more like 5 days. I never said I was a fast programmer. Working the kinks out of fourspriter 1 took me well over a week, and I had a lot of free time to do that.
L