Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Fourspriter: Alternate Version
#16
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
Reply
#17
britlion Wrote: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.
Well, the version you see here is v2.0, but with even more optimizations I added. So probably the what looks similar are, in part or totally, my modifications. :oops:

On the other hand, yes, the code is commented in Spanish. I could translate it for you these evening. But the best way to work in team is using SVN. I will update this version to the repository (and yours, if you like). So we can cooperatively work them. What do you think? Have you finaly managed to install tortoiseSVN and downloaded a source revision?
Quote: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
I didn't examine your code in depth, but if you managed to keep the coords in BC, it should be faster, and required a lot of work, that's right. By now, I think we should keep both versions and use a speed test to see if there're performance speed differences between your patch and this one or not.
I prefer to go back to your fast-math routines at this moment and check if they compile and runs ok with -O2 and -O3.
Meanwhile, I will translate the FourSpriter 2.0 optimized version into English and fix it up (it's broken, I think: I really haven't tested it yet).
Reply
#18
I'm more than a little tempted to take version one, make it even faster still and make it capable of using the whole character set instead of just the UDG.

I think, actually, that might be easier - and it's the big difference, so far as I can see.

I envision it being able to use whole charset or UDG as an option.

Could probably make it 8 sprites, 4 updating each IM2 cycle too if I really had to.

Anyway, I'm looking at options at this stage. Sadly, real world is making me a little low on playtime at the moment.

Boriel: What optimizations did you make? Can't see them at a glance.

EDIT: Ran them through a difference spotting program. :-) Now I see it. MUCH MUCH shorter - with 8 blocks of code -> 2.

Very nice.
Reply
#19
Oh, and Nathan sent me the original code as well, which I've looked at.

*chuckle* He's implied we did something similar. Meh. I suppose it's possible, for sure.

But it just makes a bigger temptation to write something even better.

Now, let's have a look at SP_lib...
Reply
#20
One immediate issue that comes to mind is that pasm allows "defs" and ZX Basic does not.

Easily converted into defb 0,0,0,0,0,0,0,0..... though.
Reply
#21
britlion Wrote:One immediate issue that comes to mind is that pasm allows "defs" and ZX Basic does not.

Easily converted into defb 0,0,0,0,0,0,0,0..... though.
Well, maybe this should go to the wishlist.
However, you can use DEFM (define message) or DEFB (they're equivalent) with strings. So:
Code:
; 5 spaces
DB 0, 0, 0, 0, 0
; Another 5 more
DB "00000"
; The above will fill the space with
; DB 48, 48, 48, 48, 48
Reply
#22
*grin*

One I knew!

I've already packed strings into defb statements in the football program.

But yes, I do like the versatility of that one.
Reply
#23
britlion Wrote:*grin*

One I knew!

I've already packed strings into defb statements in the football program.

But yes, I do like the versatility of that one.
Ok.
Please, download new version (just few minutes ago), and test your football program. Tongue
Reply
#24
Downloading right now!

Yes Sir!
Reply
#25
britlion Wrote:One immediate issue that comes to mind is that pasm allows "defs" and ZX Basic does not.

Easily converted into defb 0,0,0,0,0,0,0,0..... though.
Ok, I've added DEFS in version 1.2.5-r1513f
Please download <!-- m --><a class="postlink" href="http://www.boriel.com/files/zxb/zxbasic-1.2.5r1513f.msi">http://www.boriel.com/files/zxb/zxbasic-1.2.5r1513f.msi</a><!-- m --> and intensive test it. If we keep adding new features to this release, 1.2.5 will be never released and new bugs might appear (due to new features). Sad
That's why I'm reluctact to add new features before closing oldest issues.
Reply
#26
I do completely agree that new features should wait, personally.

Not sure if LD A,R and LD R,A are new features :-)

But yes, this is the sort of thing that should be wishlist, really. It came up here because you posted code that you suggested would work - and that was a hiccup with it. It's a very useful feature though!

Hopefully, a couple of assembler adjusts shouldn't break anything. But I'm thinking that we're stable now, unless someone finds anything broken.

(Though, I'm writing this before testing the latest version :-) )

The one I had this morning was pretty solid, though. My only real worry is the time the assembler is taking, and we can call that a feature request for next time.

Also, to save you from pulling your hair out, we should probably make you stick to one major adjustment per day. *laugh* I noticed that ...e was mentioned, and it's gone already, and now I find that's because we're on version f!
Reply
#27
Okay...

So I've been rewriting fourspriter again. More or less from scratch. Works a different way altogether. Totally speed optimized. Doesn't use UDG (instead the graphics are poked to memory somewhere, and it uses that).

It's only part done - the erase function seems to work. I did a quick speed test...wasn't sure if it was going to be any faster using this method.

Set to work on only a single sprite, Original fourspriter 250 erase functions: 10 frames.

My new version, single sprite, 250 erase functions: 3 frames.

Wow.

Little bit faster, then.

And yeah, it's going to be quite a lot faster than the new version Nathan did.
Reply
#28
Almost there.

Something in either the buffer bit, or the erase bit is putting data where it shouldn't.

But a quick test shows:

Original fourspriter, 4 sprites running, 250 "bufferAndDraw" cycles: 62 frames.

Upcoming version, 4 sprites active, 250 "bufferAndDraw" cycles: 5 frames.

If this makes, it's going to be scary fast. I have no idea if it's going to be fast enough to do four sprites flicker free at 50 FPS beating the ray-trace, but it's making a shot at goal.
Reply
#29
Okay, I'm close enough to be able to see some results.

With a halt at the start of the redraw function, I think all sprites are flicker free...

I need to debug a little - having some attributes left behind, and it doesn't like edge of screen. But looks like the goal of getting sprites cycled before the scan line arrives is clearly achievable without a long wait. So, more time for the game code to run...

(now I'm wondering how many sprites I can get away with :-) - of course I should be fixing bugs first.)

Won't be able to tell all for certain until it's fully debugged, mind.
Reply
#30
britlion Wrote: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.

Sorry, I've just read this. It is just not right. If I had used any of your code/ideas in v2, I would have credited you as I've credited everyone I've took ideas from. I coded v2 by myself way before you came with the optimizations from v1. I'm such a newbie (yeah, I am, no need to make fun of my horrible code, nobody is born knowing it all), so those optimizations are so obvious that it's not strange that we both came with the same ones. In fact, I completely recoded fsp2 from scratch, without looking at the code from fsp1. That's why sprite data is arranged differently, 'cause it was easier and faster to deal with it from code that way. I also added the obvious LDI optimizations, thanks to tips offered in the WOS and speccy.org forums.

Look, I for one am the last person you could accuse to steal code without crediting. I think that was a really strong acusation. You could have contacted me if you have an issue instead of acusing me publicly of something I haven't done.

As I told you, I coded fsp2 from scratch, and that happened on late October, 2009, way before you even started your optimizations. I even made an announcement in our blog. It wasn't released 'cause we wanted to finish a game we were coding to demonstrate the library. If you still don't believe me, you can check the forums and you'll find me asking for optimization advice around that time.

I can't believe this. I already told you at WOS that my version was worked before you optimized v1. But it shows that you don't believe. Well, look this nice screenshot and have a nice day.

[Image: date.jpg]

Sorry for the tone, but being acused of stealing code feels quite bad. Specially when everything I do is open source and available for everyone.
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)