FAQ  •  Register  •  Login

Fourspriter: Alternate Version

<<

britlion

Posts: 766

Joined: Mon Apr 27, 2009 7:26 pm

Location: Slough, Berkshire, UK

Post Tue Mar 16, 2010 5:55 am

Re: Fourspriter: Alternate Version

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
<<

boriel

Site Admin

Posts: 1463

Joined: Wed Nov 01, 2006 6:18 pm

Location: Santa Cruz de Tenerife, Spain

Post Tue Mar 16, 2010 8:37 am

Re: Fourspriter: Alternate Version

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?
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).
<<

britlion

Posts: 766

Joined: Mon Apr 27, 2009 7:26 pm

Location: Slough, Berkshire, UK

Post Tue Mar 16, 2010 8:28 pm

Re: Fourspriter: Alternate Version

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.
Last edited by britlion on Tue Mar 16, 2010 8:47 pm, edited 3 times in total.
<<

britlion

Posts: 766

Joined: Mon Apr 27, 2009 7:26 pm

Location: Slough, Berkshire, UK

Post Tue Mar 16, 2010 8:31 pm

Re: Fourspriter: Alternate Version

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...
<<

britlion

Posts: 766

Joined: Mon Apr 27, 2009 7:26 pm

Location: Slough, Berkshire, UK

Post Tue Mar 16, 2010 11:05 pm

Re: Fourspriter: Alternate Version

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.
<<

boriel

Site Admin

Posts: 1463

Joined: Wed Nov 01, 2006 6:18 pm

Location: Santa Cruz de Tenerife, Spain

Post Tue Mar 16, 2010 11:38 pm

Re: Fourspriter: Alternate Version

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
<<

britlion

Posts: 766

Joined: Mon Apr 27, 2009 7:26 pm

Location: Slough, Berkshire, UK

Post Tue Mar 16, 2010 11:40 pm

Re: Fourspriter: Alternate Version

*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.
<<

boriel

Site Admin

Posts: 1463

Joined: Wed Nov 01, 2006 6:18 pm

Location: Santa Cruz de Tenerife, Spain

Post Tue Mar 16, 2010 11:45 pm

Re: Fourspriter: Alternate Version

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. :P
<<

britlion

Posts: 766

Joined: Mon Apr 27, 2009 7:26 pm

Location: Slough, Berkshire, UK

Post Tue Mar 16, 2010 11:45 pm

Re: Fourspriter: Alternate Version

Downloading right now!

Yes Sir!
<<

boriel

Site Admin

Posts: 1463

Joined: Wed Nov 01, 2006 6:18 pm

Location: Santa Cruz de Tenerife, Spain

Post Fri Mar 19, 2010 10:54 pm

Re: Fourspriter: Alternate Version

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 http://www.boriel.com/files/zxb/zxbasic-1.2.5r1513f.msi 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). :(
That's why I'm reluctact to add new features before closing oldest issues.
<<

britlion

Posts: 766

Joined: Mon Apr 27, 2009 7:26 pm

Location: Slough, Berkshire, UK

Post Sat Mar 20, 2010 3:55 am

Re: Fourspriter: Alternate Version

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!
<<

britlion

Posts: 766

Joined: Mon Apr 27, 2009 7:26 pm

Location: Slough, Berkshire, UK

Post Sun Mar 28, 2010 10:16 pm

Re: Fourspriter: Alternate Version

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.
<<

britlion

Posts: 766

Joined: Mon Apr 27, 2009 7:26 pm

Location: Slough, Berkshire, UK

Post Mon Mar 29, 2010 4:08 am

Re: Fourspriter: Alternate Version

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.
<<

britlion

Posts: 766

Joined: Mon Apr 27, 2009 7:26 pm

Location: Slough, Berkshire, UK

Post Tue Mar 30, 2010 1:36 am

Re: Fourspriter: Alternate Version

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.
<<

na_th_an

Posts: 73

Joined: Fri May 07, 2010 7:34 am

Post Fri May 07, 2010 7:51 am

Re: Fourspriter: Alternate Version

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

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.
PreviousNext

Return to How-To & Tutorials

Who is online

Users browsing this forum: No registered users and 4 guests

cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by Vjacheslav Trushkin for Free Forums/DivisionCore.

phpBB SEO