Rybags Posted June 13, 2007 Share Posted June 13, 2007 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. Quote Link to comment Share on other sites More sharing options...
Sheddy Posted June 13, 2007 Share Posted June 13, 2007 (edited) 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 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 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 ), 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 June 16, 2007 by Sheddy Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 21, 2009 Share Posted July 21, 2009 no post by me here? why did I missed this thread??? Quote Link to comment Share on other sites More sharing options...
andym00 Posted July 21, 2009 Share Posted July 21, 2009 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.. Quote Link to comment Share on other sites More sharing options...
JamesD Posted May 3, 2014 Share Posted May 3, 2014 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. Quote Link to comment Share on other sites More sharing options...
Rybags Posted May 3, 2014 Share Posted May 3, 2014 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. Quote Link to comment Share on other sites More sharing options...
576XE Posted May 3, 2014 Share Posted May 3, 2014 I dreamed about Gr0 sprite of cursor... Is it possible? I know that pseudographics cursor is only inverted image but... Quote Link to comment Share on other sites More sharing options...
snicklin Posted May 3, 2014 Share Posted May 3, 2014 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! Quote Link to comment Share on other sites More sharing options...
NRV Posted May 3, 2014 Author Share Posted May 3, 2014 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 , 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).. Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted May 4, 2014 Share Posted May 4, 2014 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. Quote Link to comment Share on other sites More sharing options...
Rybags Posted May 4, 2014 Share Posted May 4, 2014 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. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 4, 2014 Share Posted May 4, 2014 In Arsantica the bob sprite routine was coded by 'hand' and optimized... Sprite data was 'pixeled' in .byte statements and unrolled/masked optimized with copy paste the source code really oldschoolish Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 4, 2014 Share Posted May 4, 2014 What I wanted to say... If there would be a toolset it would needed to spill out mads assembler source code so it can be adjusted to the specific needs. Quote Link to comment Share on other sites More sharing options...
José Pereira Posted May 4, 2014 Share Posted May 4, 2014 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. 1 Quote Link to comment Share on other sites More sharing options...
Rybags Posted May 4, 2014 Share Posted May 4, 2014 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. Quote Link to comment Share on other sites More sharing options...
Creature XL Posted May 4, 2014 Share Posted May 4, 2014 (edited) 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 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 May 4, 2014 by Creature XL Quote Link to comment Share on other sites More sharing options...
José Pereira Posted May 4, 2014 Share Posted May 4, 2014 CrtXL AhAh of course you can explain me that in other topic or send me a message, why not we ressurect that particular game ? Quote Link to comment Share on other sites More sharing options...
Creature XL Posted May 4, 2014 Share Posted May 4, 2014 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" Quote Link to comment Share on other sites More sharing options...
José Pereira Posted May 4, 2014 Share Posted May 4, 2014 If that "certain game" is "that game" then thats OK to me Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.