Jump to content
IGNORED

More Software Sprites


NRV

Recommended Posts

I think there are gains and tradeoffs for using multiple z-page pointers, having non-standard gaps (e.g. 64, 128, 256 bytes) between scanlines, and doing self-modifying code for screen save/restore operations.

 

The best method/s to use would probably come down to how much action you want onscreen - and there's always the huge memory requirements too.

 

For games, probably a mix of direct store to the save area for some sprites, and indirection for others to help save RAM.

 

But, this method of doing sprites has the potential to do games otherwise thought impossible.

Link to comment
Share on other sites

aargh.. sorry for been late, sometimes life get in the way :)

 

yep, avoiding LMS's is one of the reasons that I choose a gr.7 32 byte wide mode for my demos, only 32 cycles every 2 scan lines, compared to other modes.. well, anyways 2 extra cycles per 96 lines don't seem so bad, and for scrolling I will need those LMS's

 

to sheddy..

 

about your comments: never mind! I never readed that like sarcasm (not from someone doing a Space Harrier conversion for the A8, I can tell that you know your sprites :) ) in the worst case I get motivated to find a better solution. Also, English is not my first language, so you need to pass all my comments through some kind of "good intentions" filter before reading them :D

 

thank you, I just begun to get a little worried when you did not reply back quickly, as this is a topic dear to my heart - English is supposed to be my first language, but it often still comes out wrong :D

 

about your question I thing I'm a little lost (I should go to sleep and answer tomorrow), you are trying to init pointers for every scan line, assuming a width of 128 bytes for every line? I don't know if I'm answering your problem (give me more info, I like this kind of problems :D), but I probably will try to init at least one pointer every 256 bytes and the others continuosly after the first one, like this:

 

ldx zp

ldy zp+1

 

inx

stx zp+2

sty zp+3

 

inx

stx zp+4

sty zp+5

 

inx

stx zp+6

sty zp+7

 

...

 

; alternate use of iny, inx and dex should let me init all the pointers, and when I need to draw I would do something like this:

 

ldy #0

lda #sprite_data1

sta (zp), y

lda #sprite_data2

sta (zp+2), y

lda #sprite_data3

sta (zp+4), y

lda #sprite_data4

sta (zp+6), y

 

ldy #4

lda #sprite_data5

sta (zp), y

lda #sprite_data6

sta (zp+2), y

lda #sprite_data7

sta (zp+4), y

lda #sprite_data8

sta (zp+6), y

 

I suppose that a fixed example should be more clear, I don't know is this will really work, but we could try..

 

NRV

 

I was trying to think how best to place and set up the pointers (zero page pairs) for your 16x16 sprites on the 32 byte wide screen. On your quick calculations you were allowing 8 cycles additional set up for each pointer. I was struggling to see how to do it that fast:

 

I got stuck on trying to set the pointers all on the left side of the sprite,each spaced out further down the column, and having trouble working out how to set them up quickly. If they are spaced exactly 128 bytes there may be a quick way to set them up though. My initial code attempt, example in post showing "adc #64" rather than "adc #128" was not really a very good explanation! This is where the pointers would be - spaced on the line left 4 lines apart (P is a pointer):

 

P>XXXX (4 lines)

P>XXXX ""

P>XXXX ""

P>XXXX ""

 

[Edit: cycle count for above 4 pointers needs 16 ldy # or iny. set up of zero page for the special case of 128 spacing can be 9 per extra pointer I think. add in the 64 lda # sta (),y (64x7=448) cycles and I make the total about 507 cycles!]

 

 

I think I see now that what you're saying is that if we set pointers up across the screen then they are quicker to set up. For some reason I didn't think that would be any good, but it is not bad!

 

PPPP

vvvv

XXXX

XXXX

XXXX

XXXX

 

With the 16x16 sprite (all pointers at top) there is still the problem with the bottom half of the sprite with only the 4 pointers. We would have to "inc" all 4 pointers, and do all the "ldy #", "iny" for the bottom half again. Even with the very quick pointer set up, I think that would work out to be about 524 cycles total. If there are an extra 4 pointers set up the same for the bottom half it is better - no more pointer "inc"'s and all the extra "ldy"'s. the pointer set up is again very quick (I make it an extra 26 cycles). I think the total cycles will then be down to 514 for the whole sprite.

 

With different pointer positions, can things be better though? that is the question...

[Edit: I still don't quite see where you are going in your example in the quote above, but anything is worth a try for some more speed!]

Edited by Sheddy
Link to comment
Share on other sites

  • 2 years later...
no post by me here? why did I missed this thread??? ;)

Ummm....

just back from taipei (computex) and just saw this which is very interesting... have to look more into the code... ;)

:)

But glad you nudged this thread up, I was looking for this particular one about software sprites but wasn't getting anywhere finding it..

Link to comment
Share on other sites

  • 4 years later...

Sorry to dig up a necro thread but has anyone tried to build a program that generates software sprite code like this?

I believe this has been experimented with on other platforms but I hadn't seen anything for the Atari.

Link to comment
Share on other sites

Entirely possible but probably not something generally released.

 

I'm about to do a little project and will likely use a source code generator program to save a bundle of typing.

These things can tend to be specific although for softsprites a generic sort of thing could be devised.

Link to comment
Share on other sites

Entirely possible but probably not something generally released.

 

I'm about to do a little project and will likely use a source code generator program to save a bundle of typing.

These things can tend to be specific although for softsprites a generic sort of thing could be devised.

 

Source code generator? Where? Spill the beans!

Link to comment
Share on other sites

 

Source code generator? Where? Spill the beans!

 

He is probably going to write one for his needs. I have taught about writing something like that in the past, but never did (maybe Sheddy have some tools written for Space Harrier).

 

Like Rybags said the code for pre compiled sprites tend to be specific to the code used to draw the sprites, but I also believe that something more generic and useful could be done.

 

For me I would like to support parameters like X/Y resolution, pixels per byte, size of every line in bytes, offset between lines (or maybe a table, to be able to use any type of exotic format created in the display list), support for APAC (maybe interlaced modes), support for character based display modes (I don't want to start thinking about this :D , it would be more complex), be able to generate the color data and the mask for the sprite (if needed), different write modes (overwrite, xor, or, masked), use of optimizations (like don't write full transparent bytes and just overwrite full bytes that don't need masking), be able to choose if the draw routine wants to write the "pixels" horizontally or vertically (probably one version can be faster or shorter, if you have more repeated bytes in one direction), maybe be able to choose the level of pre compiling that we need (I would go for full speed, but sometimes shorter versions, that use less memory, could be useful)..

Link to comment
Share on other sites

Character based modes would basiclly require the same bitmap layout as on the Commodore 64 ...

 

For example in narrow mode, you would be changing character sets every 4 character lines. This makes you a bitmap, but the bitmap is read from the character set in memory, 8 bytes at a time to make a character, which is how Commodore 64 reads bitmaps. The only difference is, you'd need some sort of flag on your screen for whenever inverse characters (Antic 4/5) are used, or if using Antic 6/7, which of the four ranges to use.

Link to comment
Share on other sites

My "source code generator" will be just a Basic program.

 

The assembler code is to do something that's an unwrapped loop and somewhat repetitive with different iterations and slightly different operations each step of the "loop".

If you were doing "brute force" softsprite rendering you'd probably want to do similar.

Another route is "executable code generation" ie - have the program actually construct routines itself at runtime. Something suited to brute-force or unrolled loops.

Link to comment
Share on other sites

I would like to see a generic code to have the soft sprites in the way I'm saying for years: ANTIC4/5 using Interleaved Charsets, like 1,2,3,1,2,3,... or the better 1,2,3,4,1,2,3,4,...

This is what would open lots of new game build possibilities because you could have more detailed background gfxs with less chars reserve needed for the software sprites.

  • Like 1
Link to comment
Share on other sites

Generic code has the advantage of usually faster dev time but usually not optimised to a particular situaiton so runs slower.

 

Using charsets 1,2,3 etc would be easy enough - the charset chosen for a particular line can easily be deduced from the character YPos.

Link to comment
Share on other sites

Using charsets 1,2,3 etc would be easy enough - the charset chosen for a particular line can easily be deduced from the character YPos.

 

And that is exactly why only "1,2,3,4" should be used. Only non coders could think of "1,2,3" :)

To make it clear, I am not refering to you Rybags :P

 

 

Extract from working code:


        ; Calc charset addr for the three used sets
                tya
                and     #%00011000
                lsr                             ; Clears C
                adc     #>MEM_FONT0
                sta     zp_l0+0
                adc     #4
                and     #%00001111
                adc     #>MEM_FONT0
                sta     zp_l1
                adc     #4
                and     #%00001111
                adc     #>MEM_FONT0
                sta     zp_l2
Edited by Creature XL
Link to comment
Share on other sites

CrtXL AhAh ;)

of course you can explain me that in other topic or send me a message, why not we ressurect that particular game ;) ?

:)

 

I plan to finish something for this years ABBUC SW-competition. This will be the last contribution the competition, it's just too much stress. At least that is my current opinion. :) Therefore, after this years deadline I might be open to spend time on a "certain game" :P

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...