Feelin' kinda proud of myself

edited March 2010 in Development
Okay, it has bugs. But I kludged it together about 10 mins after getting the sprite thing to actually work.

http://britlion.googlepages.com/Sprity.z80

1> I mean. IM2... that was true wizard fu magic when I was a kid. Then again, so was assembler stuff, period.

2> I've got what was originally fourspriter (VERY much faster now) to work as a library for Boriel's ZX Basic compiler. (Join in at www.boriel.com)

3> And I'm pretty close to working out how to have clean IM2 stuff in it, it seems.

4> Don't forget to press QAOP. :)

And yes, if you ignore the sprite library bit, what happens on screen is written in a form of basic that isn't completely alien to sinclair basic users. I love this compiler.
Post edited by Gedlion on

Comments

  • edited March 2010
    Ha ha!

    That's pretty good!

    It's a real spanner-throwing experience if you do RUN :razz:

    Keep it up!
  • edited March 2010
    Heh.

    It would. IIRC a LOAD command disables interrupts. If you press break it carries right on where it left off, though.

    More a proof of concept than anything really functional, but I'm still bouncy over "This is written in basic". Even if it is cross-compiled Basic.
  • edited March 2010
    Gedlion wrote: »
    2> I've got what was originally fourspriter (VERY much faster now) to work as a library for Boriel's ZX Basic compiler. (Join in at www.boriel.com)

    That's great. My assembly coding is HORRIBLE, I'm glad that you fixed my cheesy routines :-) And as usable library for ZX Basic... That's awesome. Congrats and thanks.
  • edited March 2010
    Funny thing. You can write a complete Basic program (I tried drawing circles) with these things flying around.

    And it's great to see another person making his first sprite routine.

    When you were a kid, assembler seemed some kind of magic. It's great to become magic user, isn't it? :)
  • edited March 2010
    By the way, what did you do to make the routines faster? I would like to know, so I can improve my crappy assembly coding skills :-P
  • edited March 2010
    na_th_an wrote: »
    By the way, what did you do to make the routines faster? I would like to know, so I can improve my crappy assembly coding skills :-P

    What happened to the second version of the library that you were doing? Didn't you already improve your routines there?
  • edited March 2010
    Actually, the second version is fully finished, but we didn't want to release it without a working game.

    It is faster than the first version, but not enough fast. The 4th sprite flickers if it has to be drawn very high on the screen.
  • edited March 2010
    OOh... I did lots of things. We should probably talk about it privately.

    And thankyou for putting together the original code. *grin* There were some comments made about some of the routines being quite a bit more laborious than they should be. I hope when you see them over at boriel.com, you don't get offended. There was some thought it might be compiled, actually.

    In essence:

    Use fewer instructions if possible. So

    ld a,(hl)
    ld b,a

    Is reduced to
    ld b,(hl)


    Increment and decrement directly, so

    ld a,(hl)
    dec a
    ld (hl),a

    becomes
    dec (hl)


    Use LDI to copy memory, so
    ld a,(hl)
    ld (de),a
    inc hl
    inc de

    becomes
    LDI

    (The caveat here is that LDI does dec BC as well. Fortunately, we rarely cared about BC in these routines)

    I also noticed that I could hold xpos and ypos in BC instead of in memory, which made quite a big speed improvement. And saved two bytes of storage ;)

    So
    ld a,(xpos)
    dec a
    ld (xpos),a

    Actually, ended up as
    dec b


    The current code is posted over at Boriel.com for you to have a look at as MK III.

    Incidentally, my sprites flickered too. Sprite 1 flickered if it was drawn above 10 pixels down, sprite 2 about 20 pixels and so on (if we used all four sprites at once).

    The trick to doing it without flicker was to wait until AFTER the ray trace.

    So for Mk IV

    halt
    erase-buffer-redraw like crazy

    became
    halt
    wait for a while
    erase-buffer-redraw like crazy.

    Which technically, after spending the last couple of weeks on and off optimizing your code every darn T state I could, means it runs slower than the original, owing to a huge wait loop.

    That said, A clever programmer could use that time for something else than spinning in circles, so I don't think the optimizations were wasted.

    Contact me in private and/or discusss it over on Boriel's forum.

    And again, thank you for making the original code, without which that lil .z80 would never have happened.
  • edited March 2010
    I loved your .z80.

    Over all, I loved the impressive graphic you used for the sprites. It's soo good I think Flikei and his boys should use it in their DD game. Or perhaps some crap game designer could think about making it the main character of a crap game. Or perhaps ... only perhaps, there's a crap game designer out there that has already started with his new crap effort. If that were true, what could it be? ...


    Seriously now, as I told you in the boriel's forum, I love both your IM2 routine (but I must admit I have no idea how does it work or what it does) and the steroid version of foursprites you made.

    Sorry for kidnapping your post to introduce my crap game, and please go on with your colaboration with Boriel in his compiler. It's only a month now since you two are "working together" and the compiler development is flowing and the library is growing :)
  • edited March 2010
    I adore your little top hat guy.

    I expect to see more of him. He's the next famous sprite! Gonna be up there with Jetman, and miner willy!
  • edited March 2010
    Gedlion wrote: »
    OOh... I did lots of things. We should probably talk about it privately.

    And thankyou for putting together the original code. *grin* There were some comments made about some of the routines being quite a bit more laborious than they should be. I hope when you see them over at boriel.com, you don't get offended. There was some thought it might be compiled, actually.

    In essence:

    Use fewer instructions if possible. So

    ld a,(hl)
    ld b,a

    Is reduced to
    ld b,(hl)


    Increment and decrement directly, so

    ld a,(hl)
    dec a
    ld (hl),a

    becomes
    dec (hl)


    Use LDI to copy memory, so
    ld a,(hl)
    ld (de),a
    inc hl
    inc de

    becomes
    LDI

    (The caveat here is that LDI does dec BC as well. Fortunately, we rarely cared about BC in these routines)

    I also noticed that I could hold xpos and ypos in BC instead of in memory, which made quite a big speed improvement. And saved two bytes of storage ;)

    So
    ld a,(xpos)
    dec a
    ld (xpos),a

    Actually, ended up as
    dec b


    The current code is posted over at Boriel.com for you to have a look at as MK III.

    Incidentally, my sprites flickered too. Sprite 1 flickered if it was drawn above 10 pixels down, sprite 2 about 20 pixels and so on (if we used all four sprites at once).

    The trick to doing it without flicker was to wait until AFTER the ray trace.

    So for Mk IV

    halt
    erase-buffer-redraw like crazy

    became
    halt
    wait for a while
    erase-buffer-redraw like crazy.

    Which technically, after spending the last couple of weeks on and off optimizing your code every darn T state I could, means it runs slower than the original, owing to a huge wait loop.

    That said, A clever programmer could use that time for something else than spinning in circles, so I don't think the optimizations were wasted.

    Contact me in private and/or discusss it over on Boriel's forum.

    And again, thank you for making the original code, without which that lil .z80 would never have happened.

    I will do. Thanks for the pointers, I'm a very cheesy ASM coder, I didn't devote much time to it. I'm impatient and I want results, that's why I never took the time to think twice about such kind of stuff. I will study the sourches.

    Thank you, I will learn tons.

    And don't worry, I won't get offended ;)
  • edited March 2010
    This demo reminded me of this book:

    Step-by-Step Programming ZX Spectrum and ZX Spectrum+ Graphics - Book Four


    Perhaps it's a bit too late now since you've already made your own IM2 sprite routines, but that book had a sprite routine callable from BASIC, with interrupts and collision detection.

    Before I forgot, I liked the demo. :)
  • edited March 2010
    OOh, nice book link.

    Actually, I didn't make IM2 Sprite routines.

    I got fourspriter to work as a library for the compiler, and then with about two mins of work, persuaded that program to run as an Interrupt system.

    (instead of the main loop moving the sprites, it does one cycle round the main loop per interrupt).

    The sprites aren't really very intelligent, internally.

    The Basic (and yes, technically it is written in basic) source is posted on the forum at Boriel.com
  • edited March 2010
    I updated the file at http://britlion.googlepages.com/Sprity.z80 to do something else fun.

    I'm amazed /THAT/ works, actually, given it's doing the multicolor fu in basic, with interrupts flying all over the place.

    So, it looks pretty, but don't ask me why it's stable... :-)

    Remember, QAOP.

    I think there might be a game in there somewhere, now I think about it...

    Lion has an idea...
Sign In or Register to comment.