Jump to content
  • Advertisement
  • entries
    222
  • comments
    606
  • views
    590733

It works!

Sign in to follow this  
benryves

1177 views

  • Fire Track II for TI-83 Plus: 31 source files.
  • Fire Track for the Sega Game Gear: 42 source files.
    Based on this information alone, you can deduce that FTGG will be vastly superior. [wink]

    I just gave FT2 a try in VTI (I don't have any batteries in my calculator) and good grief it's slow. FTGG is much much faster... (though you should see it go when I set the enemy speed to two... I need more accurate control of speed, 1 being medium-ish easy, 2 being nightmarishly impossible!)

    This makes me happy.


    Things to notice about the above screenshot:
    • Near pixel-perfect parallax star background (you can see some through the bullet holes!)
    • Not one single poorly timed VDP write.

    This has required an enormous amount of code rewriting!
    First to be fixed was the VDP timing. With a few .ifdefs, restructuring of the main loop and addition of an extra function call, all sprite data is now written to a shadow in RAM and then all sent to the VDP at once. This means that in sprite-intensive frames the framerate drops (it is unnoticable!) instead of the VDP going bonkers.

    Next up, the pixel-perfection. I do not know if you know how difficult this is to do on this hardware (or, at least to a hack coder like myself), so I'll do my best to explain.

    On a purely software-driven system, you can create a bitmask of your tiles so that when you manually blend your layers together you can cut out the stars you don't need. Or, you just draw them first then draw the tiles on top.

    On more advanced hardware you can Z-order your polygons, so that's all done for you.

    On the Game Gear, I have two layers - sprites and background. I can set individual background tiles to be on top of sprites - but this would dump a solid 8x8 square on top of everything. In other words, ALL the sprites are drawn under the background tiles marked as being on top. I had toyed with the idea of bizarre palette tricks and messing around with the tiles themselves, thinking sprites would be too slow (I asked about this on the SMS Power! boards - apparantly some games do the sprite trick, so I gained confidence in it).

    What I need to do is this:
    1. Take the (x,y) of my star and convert this into an offset into the VRAM name table.
    2. Look up the value of the tile at this value. If it is 0 (blank tile), draw the star. (Special case to skip expensive stage below)
    3. Look up the tile in a table of sprites marked as transparent. If it isn't listed, don't draw it.
    4. Take the offset into our table of transparent tiles, multiply it by 64, use that as an offset into another table. Find how far into the nearest tile as an (x,y) coordinate we are - that is, x is in the range 0-7 and y is also in the range 0-7 inside the current tile.
    5. Use this coordinate to look up inside our mask whether to draw the sprite or not.


    There was an awful lot to go wrong and it did, often. [sad] It works pretty well now, so I'm happy with where it is. [smile]

    The function to calculate the VRAM name table offset based on an X,Y on screen was broken. It needs to take into account the current vertical scroll, you see, to calculate the offset, so was essentially doing this to calculate which 8-pixel-tall row a pixel was in:

    row_offset = (y/8) + (scroll_y/8)

    (where y is the coordinate we pass to the function) - which leads to all sorts of rounding errors! The correct function is, of course:

    row_offset = (y+scroll_y) / 8

    Which, oddly enough, didn't seem to work at all well - at certain times, the values returned were completely off. The reason is simple enough - our scroll_y is a value between 0 and 223, and out y coordinate is anything between 16 and 160. 160+223=383 - you try storing that in an 8-bit register! So I updated the entire function to 16-bit code where needed.

    Z80 ASM gurus - my old code to divide A by 8 was the simple:

    srl a
    srl a
    srl a


    For my divide-hl-by-8 function (srl [reg] is a sort of [reg]>>=1 function) I use this:

    srl h
    rr l
    srl h
    rr l
    srl h
    rr l


    -- is this the fastest I could use? Is there a nice 16-bit shift operation available to me?

    Next I had to generate the transparency data. I edited my tile editor - solid green &00FF00 is taken to mean "transparent!" It dumps a list of any tile with transparency, then an expanded 64-byte table of the mask (1 byte per pixel - horribly big, but much faster than packing it into a 1bpp mask).

    When I say "near pixel-perfect", I have a problem - my stars are 2x2 pixels, and so if they can overlap the borders by a pixel or two from time to time. It doesn't look too bad, and in my defense the original Fire Track displayed stars over ANY black areas on the background at some points...
  • Sign in to follow this  


    4 Comments


    Recommended Comments

    Quote:

    Is there a nice 16-bit shift operation?


    After looking through the Z80 manual it would appear that there is not. [sad]

    Share this comment


    Link to comment
    I feared as such... I don't think that's my bottleneck, though. It doesn't noticably slow with 24 stars visible (especially after just assuming it's visible if the tile index is 0), and the game is still nice and fast.

    Share this comment


    Link to comment
    rob is t3h spam bot?

    nice to heare that it works now, although the stars thing sounds extremly complicated for the rather easy thing it does.

    although the game gear might be very different in assembler than x86 plattforms, my respect for you is growing more and more while reading my new book about x86 assembler. :)

    somehow everytime the word SEGA appears in your journal it reminds me of the old days with the SEGA megadrive, never had a GameGear though...

    Share this comment


    Link to comment

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now
    • Advertisement
    ×

    Important Information

    By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

    We are the game development community.

    Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

    Sign me up!